ARM vs. X86. Lets vote

[Grench]

The iPhone tests - someone out there has to have one and can run it directly to get the subtest scores?  Or are they published somewhere for the iPhone crowd?

If we know anyone who writes fluent German, they could ask the folk who created the article in the 2nd link above for the subtest scores...?

 

[notaz]

Given those perf/W numbers, and assuming that it will have good FOSS support, I now say: go BayTrail!

With FOSS support the only place it matters is GPU drivers, as you get everything else from all other players too (thanks to Android using GPLed Linux kernel). And I'm not so sure open driver is so much of a benefit, because it's so huge and ovecomplicated so that you can't neither review it (for security issues or anything), neither improve it. The only ones who can do significant work on it are Intel themselves. The real benefit is that you get community maintained integration with future versions of mesa and kernel, which is an important thing, but not a much as some would like to think.

 

[fusion_power]

This Article about the current dolphin emulator and it's challenges to make propper OpenGL ports made me think. It seems that an big argument against ARM could be, they just have horrible driver support (besides no GLES 3.0 at all for PowerVR) compared to x86 and NVidia for instance. ARM really looks bad there let's hope it will get better in the future. So I'm at the devs side and I would choose a architecture that supports the devs as good as even possible, not only but also from the driver-side.

 

[Exophase]

GPU drivers is not an ARM vs x86 thing. If Merrifield uses Rogue then I'm sure it'll be in the same boat as whoever else is using it.

OpenGL ES 3.0 support isn't strong because the GPUs have just been getting hardware support for it and games aren't using it. Dolphin is in an unusual position, and not exactly a commanding one when even with proper ES 3 support it's still largely too slow on mobile devices.

I think Mali and Adreno have crappy drivers largely because of the relative inexperience of the GPU teams. Although it's pretty sad that when they're beaten by single person teams reverse engineering them.. I do think having a background in developing drivers for PC applications helps force them to be a lot more robust than what you get on mobile. Intel had really bad GPU drivers for years that they've only gradually made better.. but at this point it does seem that they're probably a lot better than some of the mobile GPU drivers.

 

[Seany]

since we have discussed a bit about multicore, my vote is on x86 with a larger L1/2 Cache memory useful for modelling and exploring models of fluid motion (as i mentioned in the thread of science in pandora). I remember to have read that ARM processors do not beat x86 on that.

 

[hedwards]

since we have discussed a bit about multicore, my vote is on x86 with a larger L1/2 Cache memory useful for modelling and exploring models of fluid motion (as i mentioned in the thread of science in pandora). I remember to have read that ARM processors do not beat x86 on that.

Multicore for a device like the P2 isn't really that desirable. I'd say dual core and leave it at that. Because of the screen size, it's going to be challenging to use multiple apps at the same time anyways. Or at least ones that would benefit from a quad core.

As for the ARM versus x86, that's settled. Intel had to go the RISC route on their x86 years ago because RISC was technologically superior. I fail to see how bringing along that much legacy cruft is going to be of much value. I realize that it would potentially mean wine would work here. But, I'm not convinced that this would be of much benefit. Most windows programs are bloated and designed for much larger displays.

 

[benoitb]

I have no architecture religion. ARM has been the best choice in mobile devices so far, but it looks like Intel has a very good offer with Bay Trail now on the CPU front.


So whatever is better in terms of price, openness, performance and battery life should be chosen. It could be ARM as well as x86 at the moment when the design is chosen.

 

[MrConfusion]

Multicore for a device like the P2 isn't really that desirable. I'd say dual core and leave it at that. Because of the screen size, it's going to be challenging to use multiple apps at the same time anyways. Or at least ones that would benefit from a quad core.

mt32emu on one core (it's a separate process, you pipe midi to it from dosbox and you definitely want to turn off reverb unless you got a 1 GHz core to dedicate for it...)

whatever it is you're actually viewing on screen on one core

various little background thingamalingies on third core

Of course you cannot "force" apps to specific cores, but if you count it like this then dual is good, but quad would not be bad either, since triple is unlikely to be available.

Just saying not all apps that can be CPU hungry are always visible on screen...

 

[_wb_]

Some (many) applications are multi-threaded. You don't need multiple cores just for multi-tasking between different applications.

That said, 2 cores are probably enough, but if the price difference is low, it doesn't hurt to have 4 cores. Unused cores don't consume power. In fact, if the application is nicely parallelizable, it's probably better (in terms of power consumption) to run it on 4 cores clocked at 1GHz than to run it on 2 cores clocked at 2GHz.

 

[hedwards]

Multicore for a device like the P2 isn't really that desirable. I'd say dual core and leave it at that. Because of the screen size, it's going to be challenging to use multiple apps at the same time anyways. Or at least ones that would benefit from a quad core.

mt32emu on one core (it's a separate process, you pipe midi to it from dosbox and you definitely want to turn off reverb unless you got a 1 GHz core to dedicate for it...)

whatever it is you're actually viewing on screen on one core

various little background thingamalingies on third core

Of course you cannot "force" apps to specific cores, but if you count it like this then dual is good, but quad would not be bad either, since triple is unlikely to be available.

Just saying not all apps that can be CPU hungry are always visible on screen...

Just because it's multithreaded does not mean that you're automatically going to get much benefit out of a multicore processor. You'll only see a benefit if you need to do things simultaneously and in terms of having a warm cache. Or at least not enough benefit to justify the added expense and reduced clock speed that moving to a multicore architecture usually involves.

Most apps that the Pandora runs are just not processor intensive enough to require a separate core to run on. The only time I've wished I had more cores was when I was wanting to watch a movie, and even then it's better to convert the video to something smaller as the storage requirements get ridiculous. Although for emulators, more cores would certainly be appreciated.

Some (many) applications are multi-threaded. You don't need multiple cores just for multi-tasking between different applications.

That said, 2 cores are probably enough, but if the price difference is low, it doesn't hurt to have 4 cores. Unused cores don't consume power. In fact, if the application is nicely parallelizable, it's probably better (in terms of power consumption) to run it on 4 cores clocked at 1GHz than to run it on 2 cores clocked at 2GHz.

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.

I could see this being useful for some of the more resource intensive emulators, but I'm not sure that going quad core is necessarily going to be better for most of the things that the Pandy can do over a higher clock speed dual core processor.

So, I say again, we really don't need more than 2 cores for the processor. There would be some benefit, obviously, but in a handheld like the Pandy, having a faster clock speed is something that's more likely to have an impact as the number of resource intensive programs that we're going to be running simultaneously is likely to be much lower than a desktop or laptop would.

 

[MrConfusion]

mt32emu on one core (it's a separate process, you pipe midi to it from dosbox and you definitely want to turn off reverb unless you got a 1 GHz core to dedicate for it...)

whatever it is you're actually viewing on screen on one core

various little background thingamalingies on third core

Just because it's multithreaded does not mean that you're automatically going to get much benefit out of a multicore processor.

To clarify: I did not say any of those three is multithreaded.

So far I have always seen benefit on multicores when running several separate programs with little to no communication between them.

DOSBox can utilize a separate core pretty much fully. It is (as far as I know) not threaded.

mt32emu is a totally different program fully capable of utilizing a separate code fully, if you run it with the (convolving?) reverb, not (again AFAIK not threaded).

But admittely the little background tasks probably won't add up to even a few percents of a third core. Still, supposing that for example the midipipe between dosbox and mt32emu ended up running on that third core, it might improve the timing of the midi stream a bit.

I won't be DOSBoxing any games that have native Roland MT32 support on the Pandora. Or yes, maybe I will, but I'll probably run them without AdLib sounds then too... I'd much rather enjoy silence than "dirty digital version" of FM. That means several games that would be theoretically playable will be left out.

 

[hedwards]

To clarify: I did not say any of those three is multithreaded.

So far I have always seen benefit on multicores when running several separate programs with little to no communication between them.

DOSBox can utilize a separate core pretty much fully. It is (as far as I know) not threaded.

mt32emu is a totally different program fully capable of utilizing a separate code fully, if you run it with the (convolving?) reverb, not (again AFAIK not threaded).

But admittely the little background tasks probably won't add up to even a few percents of a third core. Still, supposing that for example the midipipe between dosbox and mt32emu ended up running on that third core, it might improve the timing of the midi stream a bit.

I won't be DOSBoxing any games that have native Roland MT32 support on the Pandora. Or yes, maybe I will, but I'll probably run them without AdLib sounds then too... I'd much rather enjoy silence than "dirty digital version" of FM. That means several games that would be theoretically playable will be left out.

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.

The problems that a multicore processor is there to solve are mainly ones where you have multiple processes needing the processor at the same time. If that isn't the case, then you do get a benefit from being able to keep the cache warm. Which may or may not yield any significant benefits depending upon what exactly you're doing with the processor.

As I said earlier, having multicores isn't really that desirable. Resources that go to cores which are likely to be turned off most of the time aren't there to speed up the cores that are being used, or perhaps giving us more RAM etc. And going beyond just a dual core processor doesn't make a lot of sense for a device of this sort. With the exception of emulators, it's going to bring no meaningful benefits, and even for emulators, they'd have to be specifically written to make use of the extra cores, which would mean that they may or may not work on the Pandy.

This is a bit like games, RTS games are relatively easy to make use of as many cores as you like. FPS games are really tough to write in a way that they can make use of more than a handful of cores.

 

[ptitSeb]

Personnaly, I like x86 very much, because I grow up with that, starting with 8086 (soon replace by a NEC V30 in the hunt for more speed)... But ARM is fine too, I'm getting use to it.

What I do like in the Pandora, is the quality of the software we have, enabled by the uniqueness of the Pandora (i.e. handheld PC with Console controls). The Repo may not hold hundreds of thousands of native titles, but the thousand we have has been tailored and fine-tuned for the Pandora, making use of the specifics controls, screen size, and overall CPU/GPU capabilities of the Pandora.

When something new happens on the Repo, you know you will most probably have a very good experience, with something desinged or adpated to the Pandora.

Whatever the CPU/GPU will be, I thing Successor has to propose at least a similar experience for End User than the Pandora.

I personnaly doesn't think having a huge Linux distrib, with tens of thousands package available (with only a few of them confortable to use on the Successor), with a Repo flooded with cheap ports from Linux/Adroid software is a good thing.

The magic will be lost.

Just my 2cts.

 

[Exophase]

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.

 

[rohezal]

PCSX2

I read about a new speedhack so 3 cores can now be used for emulation of the ps2. I this true?

 

[Exophase]

I read about a new speedhack so 3 cores can now be used for emulation of the ps2. I this true?

Well, if by new you mean 2 years old, yes

 

[rohezal]

Do you think it would be realistic to emulate a PS2 on a Z3770? I saw it 3 years ago on a Q6600 with a AMD 4870. It was quite ok, some glitches but ran

fine. Do you think it could run at least some games?

Edit: some typing mistakes

 

[Exophase]

Do you think it would be realistic to emulate a PS2 on a Z3770? I saw it a 3 years ago on a Q6600 with a AMD 4770. It was quite ok, some glitches but ran fine. Do you think it could run at least some games?

I don't know. Probably depends tremendously on the game. Z3770 is likely much weaker than Q6600, on average.

 

[fusion_power]

[  ] ARM
[  ] X86
[x] Whatever Exophase prefers

^^

 

[MrConfusion]

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.