Active Topics

 



Notices


Reply
Thread Tools
Estel's Avatar
Posts: 5,029 | Thanked: 8,597 times | Joined on Mar 2011
#241
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
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following 2 Users Say Thank You to Estel For This Useful Post:
Posts: 2,802 | Thanked: 4,489 times | Joined on Nov 2007
#242
It's easy for anyone to check (extras-cauldron-builds is your friend). The last Fremantle build was built using just
Code:
DEB_BUILD_OPTIONS="parallel=4"
and configured thus:
Code:
./configure --host=arm-linux-gnueabi --build=arm-linux-gnueabi --prefix=/usr --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --enable-core-inline CFLAGS="-Wall -g -DMAEMO -DMAEMO_VERSION=5 -Os -fomit-frame-pointer -ffast-math" CXXFLAGS="-Wall -g -DMAEMO -DMAEMO_VERSION=5 -Os -fomit-frame-pointer -ffast-math" LDFLAGS="-Wl,-z,defs"
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?
 

The Following 4 Users Say Thank You to lma For This Useful Post:
Posts: 3,037 | Thanked: 12,669 times | Joined on Mar 2010 @ Sofia,Bulgaria
#243
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
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer

 

The Following 2 Users Say Thank You to freemangordon For This Useful Post:
javispedro's Avatar
Posts: 2,330 | Thanked: 5,200 times | Joined on Jan 2009 @ Barcelona
#244
Originally Posted by freemangordon View Post
I am using the "official" Nokia VmWare image, which (afaik) provides DEB_BUILD_OPTIONS="...,vfp,..." by default.
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.

Originally Posted by freemangordon View Post
@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
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.

Last edited by javispedro; 2013-06-23 at 13:47.
 

The Following 3 Users Say Thank You to javispedro For This Useful Post:
Posts: 1,147 | Thanked: 2,776 times | Joined on Dec 2010
#245
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.
I'm using scratchbox from the install scripts. My version came with "maemo-launcher,thumb,vfp" set in FREMANTLE_ARMEL.environment.
 

The Following 4 Users Say Thank You to Android_808 For This Useful Post:
nokiabot's Avatar
Posts: 1,973 | Thanked: 1,822 times | Joined on Mar 2013 @ india
#246
^^so you mean it wont get better than what we already have
 
javispedro's Avatar
Posts: 2,330 | Thanked: 5,200 times | Joined on Jan 2009 @ Barcelona
#247
Originally Posted by Android_808 View Post
I'm using scratchbox from the install scripts. My version came with "maemo-launcher,thumb,vfp" set in FREMANTLE_ARMEL.environment.
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...

:/
 

The Following User Says Thank You to javispedro For This Useful Post:
Estel's Avatar
Posts: 5,029 | Thanked: 8,597 times | Joined on Mar 2011
#248
Originally Posted by javispedro View Post
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?
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 
Posts: 3,037 | Thanked: 12,669 times | Joined on Mar 2010 @ Sofia,Bulgaria
#249
@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
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer

 
Posts: 1,102 | Thanked: 1,686 times | Joined on Jan 2011 @ Touring
#250
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.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 01:17.