Did You Know...?


Squidge

Certified Guru
Joined
Nov 16, 2003
Messages
8,493
Location
UK
Website
Visit site
[Oops, this should be posted in the developer section, as it's only intended for developers. None developers don't need to worry about this.]

More and more people seem to using the memory above the 32Mb GP2X Linux limit, so I thought I'd just drop in this small piece of information before they go overboard with it.

Did you know that in GP2X Linux, memory above 32Mb (ie, 0x02000000 and above) is 65% slower than memory < 32Mb (ie, memory allocated with malloc & c++'s new operator) ?

So, please don't store ROMs and other constantly accessed data in the upper memory, as it'll only slow your program down by a significant amount.

As a small benchmark, a simple byte copying 'for' loop can read and write 32Mb/sec with memory that was malloc'd, and 19Mb/sec with memory mmap'd to access above the 32Mb barrier.
 
If windows was at all comparable to linux for the use linux is being put to here, perhaps it would be subject to similar restrictions.
 
Did you know that in Linux, memory above 32Mb (ie, 0x02000000 and above) is 65% slower than memory < 32Mb (ie, memory allocated with malloc & c++'s new operator) ?

Squidge, you're a god and all, but I'm going to have to start insisting that you add "DignSys'" or "the GP2x's current version of" in front of every instance of the word Linux.

The GP2x is hardly a poster child for embedded linux, there are phones out there using linux that perform better than the GP2x at the moment (think boot up time!).

It was an informative post, but try not to start any more linux suxorz/linux roxorz flamewars...
 
Last edited by a moderator:
"The GP2x is hardly a poster child for embedded linux,"

Agreed! And Squidge, thanks for the info, it was interesting! You seem to know what you are doing..
 
Can I have that in English please?

Alright, it was in English, how about in laymans terms then?

It sounded very important, now I am scared stiff that I might have accidently stored some roms in my upper memory, is that covered in the warrenty?
 
Did you know that in Linux, memory above 32Mb (ie, 0x02000000 and above) is 65% slower than memory < 32Mb (ie, memory allocated with malloc & c++'s new operator) ?

Squidge, you're a god and all, but I'm going to have to start insisting that you add "DignSys'" or "the GP2x's current version of" in front of every instance of the word Linux.

The GP2x is hardly a poster child for embedded linux, there are phones out there using linux that perform better than the GP2x at the moment (think boot up time!).

It was an informative post, but try not to start any more linux suxorz/linux roxorz flamewars...
Squidge posted on a gp2x site, in a gp2x forum, and he's giving advice to people writing gp2x apps. Does he really need to explain where this version of linux he is talking about is actually running? Do people really think he's refering to all versions of linux? :blink:
 
Last edited by a moderator:
Can I have that in English please?

Alright, it was in English, how about in laymans terms then?

It sounded very important, now I am scared stiff that I might have accidently stored some roms in my upper memory, is that covered in the warrenty?

Just in case this wasn't a joke without a smiley...

It's only of importance to developers using the RAM. The NAND and SD card are completely different.

Or, more basically, users don't have to worry about it, only developers.


FluffyPanda: Ok, this only applies to the version of Linux installed by default on the GP2X.

It can be fixed by a kernel upgrade, or by using HH-mode apps (which don't have this problem, but there's nothing but a few test programs for hh-mode at the moment. oh and for those who don't know what 'hh' is, it's basically a program that doesn't require linux and either kills linux before running, or runs before Linux has booted).
 
Last edited by a moderator:
I'm not entirely surprised by that result, but it's a bit disappointing that the slow down is that severe.

I guess the important question to ask is why is that the case? Is it simply the overhead of writing the memory through a mmap'ed 'file' or is there another reason behind it? If that is the reason the I guess there is no slow down in HH mode for either processor, and even in Linux the second processor can access the upper 32MB at full speed. Correct?

Andrew
 
vic20-ian: its not *all* linux that is like that, its only the ARM linux config of the GP2X.

when Squidge says "Linux" in reference to the GP2X, keep in mind that there are alternatives to the linux implementation currently on the GP2X ..


woogal: "Squidge posted on a gp2x site, in a gp2x forum, and he's giving advice to people writing gp2x apps. Does he really need to explain where this version of linux he is talking about is actually running? Do people really think he's refering to all versions of linux? "

yes, he really, really does. its a huge problem with the advocacy of linux that in fact, 'linux' as a term is a huge, and i mean really, really huge, generality. there is no such thing as 'linux', there are only 'linux builds/implementations' - not all linux builds are equal!

it should be clear to all guru's that the linux on the GP2X is not exactly the best possible linux config one can build .. until we get other bootable linux configs for the GP2X that do interesting things, it must be made clear: GPH-Linux is what we're talking about, not the 'general term' of Linux, itself ..
 
vic20-ian: its not *all* linux that is like that, its only the ARM linux config of the GP2X.

when Squidge says "Linux" in reference to the GP2X, keep in mind that there are alternatives to the linux implementation currently on the GP2X ..


what alternatives would those be?
 
Last edited by a moderator:
Cheers that's cleared that up then.

Don't you guys have a Dev's Forum to chat in ? stop worrying us simple folk!
 
vic20-ian: its not *all* linux that is like that, its only the ARM linux config of the GP2X.

when Squidge says "Linux" in reference to the GP2X, keep in mind that there are alternatives to the linux implementation currently on the GP2X ..


what alternatives would those be?
I think he meant "there are alternatives to (the linux implementation currently on the GP2X)"
NOT "there are alternatives to (the linux implementation currently) on the GP2X"

EDIT: i'm not making any sense B)
As in there are other linux alternatives than the gp2x impementation, not there are other linux alternatives on the gp2x
 
Last edited by a moderator:
I guess the important question to ask is why is that the case? Is it simply the overhead of writing the memory through a mmap'ed 'file' or is there another reason behind it? If

There is an overhead of writing to memory through a mmap'd file, but I would expect that overhead to be less than 1%, as the bulk will simply be virtual memory management.

The main reason is the attributes on the memory above 32Mb are simply left as default, whilst the memory below 32Mb has buffering and caching enabled.

that is the reason the I guess there is no slow down in HH mode for either processor, and even in Linux the second processor can access the upper 32MB at full speed. Correct?

Yes, if you configure the 940 correctly, it can access the upper 32MB at full speed. If you leave it at default, it will suffer even worse however, as the running code will be in the same type of memory. A couple of lines of assembler will setup the 940 correctly, and can easily be inserted into the programs startup code, so that's nothing to worry about.

(Its very easy to speed up on the 920 also, but GPH-Linux denies us access to the needed registers...)
 
Last edited by a moderator:
squidge would running a small bootloader that sets the proper flags for the ram before starting linux resolve that problem?
And if so could the code just be hexedited in front of the kernel without actualy needing to recompile it?
 
woogal: "Squidge posted on a gp2x site, in a gp2x forum, and he's giving advice to people writing gp2x apps. Does he really need to explain where this version of linux he is talking about is actually running? Do people really think he's refering to all versions of linux? "

yes, he really, really does. its a huge problem with the advocacy of linux that in fact, 'linux' as a term is a huge, and i mean really, really huge, generality. there is no such thing as 'linux', there are only 'linux builds/implementations' - not all linux builds are equal!
[edit: didn't notice that this wasn't in the developer's section]
 
Last edited by a moderator:
Squidge posted on a gp2x site, in a gp2x forum, and he's giving advice to people writing gp2x apps. Does he really need to explain where this version of linux he is talking about is actually running? Do people really think he's refering to all versions of linux? :blink:

Yes he does. And here is why:

Why is Linux so $h!t ;)

People don't realise that linux is actually perfectly capable of being an excellent embedded OS and could be a fantastic thing for the GP2x. The version on current GP2xs is a bit pathetic but it can get much better.

People do come here before buying and if they keep hearing that "linux sucks" then they'll see the linux banners on gbax.com and just decide not to buy.
 
Last edited by a moderator:
(Its very easy to speed up on the 920 also, but GPH-Linux denies us access to the needed registers...)
lol, thanks :D

And by the way, I wasn't being sarcastic when I said you were a god. Just re-read my post and thought ooops. Total respect for Squidge.
 
Last edited by a moderator:
squidge thanks for the info.
and looking at a few of the responses... welcome to 'pedantic friday' B)

Yes, if you configure the 940 correctly, it can access the upper 32MB at full speed. <snip> A couple of lines of assembler will setup the 940 correctly, and can easily be inserted into the programs startup code, so that's nothing to worry about.

so a quick question: what commands are needed?
 
critical:
You'd have to be pretty thick, or looking to deliberately misunderstand Squidge's post to come to your conclusion. I'm sure you fall in the latter category, but of course the use of the word 'Linux' is a generality. Squidge's post was as clear as day referring to the GP2X's current implementation.


ermm... listen. the fact is, someone *DID* misunderstand Squidge, pretty much straight away. so, your argument is moot. you do not have to be thick: you *do* have to understand that the world is a big place and not as homogenized as you might think it is; some people use far, far different language than you.

a lot of the problems with linux advocacy, and idiots who think they know about linux and are thus qualified to crap on it, happen because people aren't responsible enough for making sure that they are understood .. and i'm pointing this out in Squidges case, because he has altitude, people will listen to him and favor what he says, so saying "Linux sucks" without qualifying it as "the GPH Linux build sucks" is definitely leaving the door open for people to assume "all Linux sucks".

and i, for one, know that this is not the case, and would rather the pro's and experts present the Linux case in proper light. we can, as of today, build a Linux for the GP2X that would far exceed the performance and capabilities of the stock GPH one .. we won't get so far in such an effort, however, if all the world thinks "Linux is the sux0r", when truly: it isn't.
 
Back
Top