ARM vs. X86. Lets vote

To make things clear now: Which Architecture do you want for a Pandora Successor (assuming both are


  • Total voters
    104

With the Pandora/With ARM can you more then i Thought @ the beginning.

First i thought: OpenGL ES?

Cool then go all OpenGL Games.

But this work on other Wise and is not real combatible to OpenGL Software.

Thx for LinuxBochs and his Genious Library to make it Combatible.

Same Thing thought i about ARM.

Wow overclockable up to 1GHZ... ...that reaches for many Games....

..but it came nearly ;)

My Windows Software cannot i use with the Pandora

but with LinuxBochs Wine work Winamp,IrfanView and many other Applications

(Wine X86 for Pandora is still in Development)

X86 Emulation work naturaly slow but its ok and wonderfull for

NEO RETRO GAMING like Diablo1 Fullspeed,Starcraft,Age of Empires and many other old Games.

Now my Fazit(dont know if the English Word is Fazit too)

I dont recomment ARM realy but it saves lot of Energy,

Work fine with nearly all Things

and when there are People like Notaz,Exophase,LinuxBochs,PtitSeb and and and...

...must i say that ARM is much better than i thought.

For Mobile is ARM realy the Future ;)

But i love X86 Emulation Things too :p
 
Last edited by a moderator:
To clarify: I did not say any of those three is multithreaded.

...
That's nitpicking. And the only reason why you should see a difference with several programs is if the scheduler isn't very good or you're hitting the limit for how much the processor can handle.
What is nitpicking? Third time: DOSbox+mt32emu: Two totally separate programs. Two totally separate processes. No shared memory. No IPC in traditional sense. Running on two separate cores. No idea how many threads. --> Both can utilize a (edit: individual, separate) 1 GHz core fully.

And for me this is about 25% of use cases of the potential P2.
Yes, it's nitpicking. They're not really totally separate processes in the sense that you're suggesting, they're processes that were spawned by the same app that the user is running and they're ultimately they're a part of the same process tree. When you kill DOSBox, the mt32emu is supposed to also be killed.

If you're going to gripe about me, could you not pretend like you're not being pedantic here? This style of multithreading is quite common in the *NIX world even if it isn't technically.
 
Just because something is multithreaded does not mean that you're going to be gaining much by adding a second or third core. And yes, it most certainly does hurt to have a third or fourth core. For any given price, the four core processors will typically have lower clock speed than the dual core. But in general going to four processors tends to reduce the speed that any one thread can go. And unless you're mostly using apps that are bound by the scheduler or cache, then the amount of benefit from those extra cores is largely reduced.
This is totally wrong. Modern CPUs, especially mobile ones, have very aggressive DVFS and very effective clock and power gating. When you're only using two out of four cores you can clock them just as high as if those other two cores weren't there at all. Going dual core buys you nothing in terms of performance.

A lot of software these days does gain a fair amount by having more than two cores, even if it isn't linear scaling. Even some emulators, like Dolphin and PCSX2. Even DraStic (current beta version on Android) is utilizing > 2 cores to enough extent that having them really helps. Emulators are definitely not the go-to case for threading, they're one of the harder things to thread reasonably. Normal games are much more so these days, and other tasks like compiling.
I feel like I'm missing something here. Either that or you misread my post.

I'm not talking about power from having cores disabled, I'm talking about versus the cores not being there at all. The cost of additional cores is most certainly not zero, there's definitely costs from defects as well as just having to use better techniques to fit the extra cores onto the chip.

Whenever I'm looking at processors, which admittedly aren't in this space, the clock speeds you can get from a processor tend to be lower when you've got a larger number of cores on the chip, for a given price.
 
 When you kill DOSBox, the mt32emu is supposed to also be killed.

If you're going to gripe about me, could you not pretend like you're not being pedantic here? This style of multithreading is quite common in the *NIX world even if it isn't technically.
On Windows I start mt32emu-qt.exe. I then start dosbox.exe. If I stop dosbox.exe I can still continue using mt32emu-qt via Cubase. It most certainly isn't "supposed to be killed"!

They are not sharing a process tree. Processwise the only thing they have in common is what started the new processes: explorer.exe, being the Windows shell!

And the point was originally: This is a perfect example of why I definitely would like to see multiple cores in P2, even if the current console emulators were not all that threaded.
 
Back
Top