2x Cpu Benchmarks

[skeezix]

Bah, not biased at all. I assumed it was region coded, but I just read an article (who knows where that mentioned few handhelds are region coded for all sorts of interesting reasons. It didn't occur to me it might be split between the two operating modes. Doesnt' matter to me .. I couldnt' care less about music or movies on the PSP, as I don't carry it around anywhere. Its only for GTA:LCS when I get a spare moment (which isn't often

jeff

 

[Squidge]

Ok kids, the memory benchmark results are pretty much what I expected:

Using 10MB of data memory:
2GB of writes to that memory
1GB of reads from that memory (not including instruction fetch)

920 or 940 on there own took 28 seconds
splicing between the 920 and 940 (sharing the load over both, so both are attempting to access the memory bus at the same time) - 31 seconds.

 

[xafier]

So basically we can conclude from your preliminary tests that using both CPU's will have benificial speed increases if coding is done correctly... AND that both CPU's eating away memory isn't going to impact performance much either? 3 seconds really isnt that much when your talking such a significant amount of data transfer... after all what sort of game will be swapping Gigs of memory about every minute?

[edit]

Btw Squidge... was this ALL read then ALL write? Any chance of testing perhaps 920 reading while 940 writes? then vice versa? see how this impacts against pure read then pure write?

 

[skeezix]

Another question would be..

What if they're both doign the full loads?

ie: Lets make up scenarios closer to reality.

An common old school emu would be a CPU core running (dominating) the main thread; it handles the emualtion run, plus GUIs and such; the second core would be doing the sound thread and not much else.

The main core would thus be in a busy read/write tight loop, while the audio thread would be small-read/big-write (where 'big' is not all that big

ie: Splitting a CPU emulator across cores would be ugly and not likely to occur; running a dual-cpu VM on a dual-core could be easily ('naturally') partitioned, but lets worry about that later.

The question is.. does the CPU emulator performance tank as a sound theread fills up the buffer?

Answer.. not too much I imagine; memory bandwidth is shared to the cores, but I doubt a sound core would hit it all _that_ much.

Now, a cpu emulator on each core.. that could slow things down a bit.

But lets cut to the chase.. being stuck at 200, or being stuck at dual-200? Obviously we'll get some improvement, and its not going to be perfect (400).. more likely around 200+(0-150) depending how well used, effective throughput?

Don't listen to me, I'm seriously wiped out

jeff

 

[Series-8]

So, interesting....

A small performance hit, but much less than what I thought.

Someone should start making some kind of easy to use, library to shove code over to the 2nd core.

Would IRQs work on the second core?
Or some small section of shared memory to issue queued commands to it.

can't really use Linux threading so some kind of 2nd_core main loop is needed.
(right, threading is not useable without a MMU on core 2)

If you program it, they will come.

 

[moz]

wonder what this does to the battery life

 

[Squidge]

xafier: the actual test is:

for (i = 0; i < 100; i ++)
{
memcpy (mallocbuffer1, mallocbuffer2, 5120*1024);
memcpy (mallocbuffer2, mallocbuffer1, 5120*1024);
memset (mallocbuffer1, 0x55, 5120*1024);
memset (mallocbuffer2, 0xAA, 5120*1024);
}

So 10MB of read/write + 10MB of just write per loop iteration.

Series-8: Yes, IRQ's work on the second core. You can actually use built-in registers instead of memory locations to communicate between the processors if you prefer, and writing to the registers can cause an interrupt to occur on the other processor. Much better than polling IRQ's on the 920 is a lot more involved under Linux, as Linux uses interrupts itself for the task switching.

moz: It'll drain more power than just sitting at the menu, but less than what the movie player requires, as the mpeg hardware will not be operational.

 

[xafier]

Thanks Squidge... so basically when both cores are running that code they're both reading and writing constantly so they're definitly battling... in which case the 3sec is quite good and most likely realistic of anything that'd be stressing it with both cores

 

[Mr. Anderson]

Thanks Squidge... so basically when both cores are running that code they're both reading and writing constantly so they're definitly battling... in which case the 3sec is quite good and most likely realistic of anything that'd be stressing it with both cores

​

or in other words: the Memory Controller has no splitsecond to rest h34r:

 

[slygamer]

Squidge, I'm assuming your test was with both CPUs accessing the same memory. Would it be any different if they were accessing different memory areas? Or is it just simply fighting for the memory bus?

 

[Squidge]

slygamer: actually, that is with the two cores accessing different memory. Reason being is that it's difficult to get the 940 to read 920 memory correctly, as there's no MMU, and since Linux thinks there only 32MB of RAM, I'm assuming that memory over 32MB will be uncached and unbuffered for the 920 to access.

so, the 920 uses two malloc'd chunks of memory, whilst the 940 uses two chunks of memory above 32MB which I specifically mark as cachable/bufferable (using the MPU of the 940) for maximum performance.

Also, a number of people have asked for the prime bench source code. I've replied to those requests, but for anyone else who wants it:

http://ibiblio.org/paulc/gp2x-gen/primebench.zip

A small warning though - It isn't pretty ! It gets hacked up for each test. The basics are there though if you want to do your own 940 hackings under Linux.

 

[slygamer]

Thanks for that, Squidge.

I didn't realise you had to mark memory as cachable/bufferable above 32MB to get the best performance.

I'm definitely considering the use of the 940 in my game. Just trying to work out the best use for it.

 

[DaveC]

How is the chargable battery worse? It is different. Further, you can buy multiples, so PSP should be equal to 2x on that.. this is the bias showing. Myself, I'd take charable over cells anytime.. I have no interest in buying a dozen AA's a week, and alkaline rechargables last an hour or two in a 2x. PSP clear wins there IMHO, but one must be fair and so .. should be even.

..

jeff

​

OOooh ouch, it sounds like the PSP is quite a bit more powerful for emus from this :blink: I still like the screen format better on the GP2X for emulation, stretching to 16:9 on the PSP= Bah!

About the battery thing: Don't use Alkaline rechargeables. Alkaline sucks for high drain devices like the GP2X, they don't last worth a shit. Get some high quality NiMH batteries, they last MUCH longer in the GP2X. The 15 minute ones are nice because you don't have to let them charge all night.

 

[Jarska333]

You're basing the "it sounds like the PSP is quite a bit more powerful for emus from this" on the fact that it has a battery pack instead of AA-rechargeables? :blink:

 

[Mr. Anderson]

The PSP isn't more powerful for emus, really not. It's a powerful hardware though. But if you look at it... I don't know, I guess it's pretty hard to use the GPU part of the system(without an actual devkit) and without it, it's barely as powerful as the gp2x -on one core...

If one would want some nice running ps1 emulation on a handheld, a really powerful pocket pc or a gp2x(if the second core play out well, if not, well then we will most likely get at least what zodiac owners get) would be the best bet.

Also 2x 2600mAh batteries cost arround 5 Euro where I live, they supply my gp2x for incredible 6 hours, longer than anything but mp3 could last on a psp. And then, oh if the batteries are empty, I just switch to the next pair of em: Another 6 hours, oh joy

Like mentoinded before, the Screen of the psp is great for movies but awful for emulation, the systems that can be emulated never had 16:9 support ^^

ps: oh my god, totally off topic, how could this happen *shoots hisself in the head*

 

[OrR]

You're basing the "it sounds like the PSP is quite a bit more powerful for emus from this" on the fact that it has a battery pack instead of AA-rechargeables? :blink:

​

No, he obviously isn't... <_<

 

[g4m3r]

Nice job! B)

BTW If people are getting 6 hours with a 2600mAh batteries, with the power leakage...how much would you get later in the GP2X's life?

 

[Paradox]

probably the actual time GPH promised us