Notices

Could someone point our belowed maemo management to above post (I don't have contact with them anymore, not want to estabilish one)? I wouldn't be surprised, if, indeed, someone would define vfp in DEB_BUILD_OPTIONS, during autobuilder set-up after migration.

In any case, it won't hurt to check.

/Estel

It's easy for anyone to check (extras-cauldron-builds is your friend). The last Fremantle build was built using just
and configured thus:
The latest package built today is still using the same DEB_BUILD_OPTIONS.

FWIW "-march=armv6j -mtune=arm1136jf-s -mfpu=vfp" look like Diablo/OMAP2-specific flags, perhaps a misconfigured scratchbox environment?

Or rather bad debian/rules. I am using the "official" Nokia VmWare image, which (afaik) provides DEB_BUILD_OPTIONS="...,vfp,..." by default.

What I did is:

apt-get source dosbox
dpkg-buildpackage -rfakeroot -b

in my FREMANTLE -thumb target. and configure was called with the above options. However, it seems that autobuilder is setup differently to Maemo 5 SDK, so I stand corrected that the dosbox package in the repos is built with wrong CPU type.

@javispedro - If you remember, a long time ago we argued over the IRC whether dosbox build with -mthumb will be stable. That is what I was trying to check, not if it will be faster. Though I guess gcc 4.7.2 makes some difference. And yes, it IS stable, .deb is in cssu-thumb repo, you can verify if you still have time, will, n900 and cssu-thumb istalled on it

Ok, so we now know who is to blame here. Neither the autobuilder nor the official Scratchbox have this enabled, so it's probably that the Vmware image guys forgot to disable it when doing the Fremantle version.

Well, fortunately, because I have terrible memory, we have IRC logs!
More than a year ago I argued that thumb's performance on the N900 sucked, but I also mentioned that it had worked flawlessly.

My assertions where based on the fact that I had benchmarked the different implementations of the DOSBox ARM JIT, including thumb and non-thumb ones, and was surprised to find that the non-thumb one was faster. That benchmark I did around 3 years ago. Note how we also tried to explain how it was possible for Thumb code to be slower, and how the general knowledge until that point was that thumb code was a guaranteed crash. At the end, we concluded (wrongly) that it was only Thumb2 the problematic one. I personally had no idea about the errata in those days.

I do not mention what the benchmark was, but I can guess it was the one thing I use DOSBox for: the boot time of Windows 3.11 (yes, I am a sad guy ).

But here comes the surprises. As you can see on that chat log 3 years ago, DOSBox until that day had been using the Thumb JIT, and I did not get complains about crashes.

The second surprise you can see in the DOSBox patched source, in file src/cpu/core_dynrec/risc_armv4le.h (ie the "config" file for the JITter): the Thumb JIT is STILL enabled to this day!!!!

How is it possible, if I knew the Thumb JIT was virtually half the performance on the N900? There were several reasons that made me do that choice:
A ) At that time, I thought the extremely low thumb performance on the N900 was because of a CPU errata. It might be possible fixed in future releases, or it might work better on the N8x0!
B ) I also contacted the author of the JIT compiler, and basically, got the hint that the non-Thumb generators would eventually be deprecated or worse, bitroted. He was seeing a 20% improvement when using the Thumb JIT on his platform, so the non-Thumb one made no sense for him.

So, the Thumb JIT is already in use in DOSBox. No one except me, to my knowledge, has benchmarked the non-JIT Thumb on the N900, so feel free to repeat the tests by changing that risc_armv4le.h file.


Now, on the third surprise. -mthumb on CFLAGS will not change which JIT version is used, it will only change how the rest of DOSBox code will be compiled. This code is certainly NOT any bottleneck; I could compile it with -O0 and you would still get very similar performance, because the bottleneck is, obviously, on JITTed code. And this is the reason I mentioned on my previous post on this thread that -mvfp, -mthumb, or even -O0 will not have much measurable effect on the performance on DOSBox builds!

Which means that, if anyone adds -mthumb and experiences "a performance increase", they are, in my eyes, experiencing the textbook definition of a placebo.

I'm using scratchbox from the install scripts. My version came with "maemo-launcher,thumb,vfp" set in FREMANTLE_ARMEL.environment.

^^so you mean it wont get better than what we already have

Interestingly, I've been checking, and found out that you're not the only one was has seen that. Even DocScrutinizer complained:

http://mg.pov.lt/maemo-ssu-irclog/%2...07-19T09:54:08

I usually setup Scratchbox manually (e.g. sb-conf se ....), not using the automated script, which could explain why I don't have such flags.

This is indeed quite a "gotcha": quite a lot of the official packages use DEB_BUILT_OPTIONS. A quick Google reveals Cairo at least. If a lot of people have that it might explain a bunch of the errors they get when trying to rebuild official packages...

:/

Maybe it's good idea to let them know via maemo-developers mailing list? Some kind of general announcement?

@javispedro - oh, I remember now . However, I've never said (IIRC) that -mthumb will bring performance boost, besides what it is all about - less RAM usage. Though if you give some idea what and how to benchmark I'll try to find some spare time these days and do it.

*If there is speedup, for sure it won't be because of -mthumb, but because of the newer compiler. For example - some of the openssl algos are 2 times faster when compiled with gcc 4.7.2, despite -mthumb

@estel - that's been announced a couple of times already

FWIW I tried SystemShock, first go rebooted my phone.
With a bit of overclock I got it to run... barely
The MIDI music chugged down to where I was always expecting a crash, I couldn't really understand most of the intro video.
It has been about 20 years so I dont remember all of the tricks but it is not really playable. Interestingly the emulator does not use up more than 50% to 75% CPU between 500 and 800mhz when I peeked at conky. If I can play SuperMario3D there must be a tweak to play system shock.
When everyone else was playing Doom the smart kids were playing System Shock.