To see how reasonable it might be to use OOo 2.0.1 and Firefox 1.5 under Wine routinely, I benchmarked their startup time on a Fedora Core 5 test 2 system under four conditions: native vs. with wine from cvs, and with 416MB RAM vs. 96 MB RAM (by booting with mem=96M; this was to simulate running on one of those cheapo 128MB boxes that uses shared video RAM). This was on a zippy Compaq Presario 3000 Athlon 64 3000+. All apps were downloaded from openoffice.org and mozilla.com.
Results for first run of app after booting (1st column is startup time):
5 Firefox run1 native 416MB 12 Firefox run1 wine 416MB 11 Firefox run1 native 96MB 15 Firefox run1 wine 96MB 11 ooo run1 native 416MB 15 ooo run1 wine 416MB 60 ooo run1 native 96MB 37 ooo run1 wine 96MB
So wine is 1.4 to 2.5 times slower at app startup generally, but when ram is really short, win32 openoffice starts up with wine 1.5 times *faster* than the native linux version! (Maybe because the Microsoft tools are better at avoiding I/O or relocations during loading?)
I then measured how long it took to start up the app the second time, when the cache was nice and hot:
3 Firefox run2 native 416MB 4 Firefox run2 wine 416MB 4 ooo run2 native 416MB 6 ooo run2 wine 416MB 4 Firefox run2 native 96MB 6 Firefox run2 wine 96MB 36 ooo run2 native 96MB 28 ooo run2 wine 96MB
The times are uniformly faster on the second run, but the patter holds, i.e. wine is 1.4-1.5 times slower than native generally, but win32 openoffice under wine is 1.5 times *faster* than the native version when starved for RAM. - Dan
-- Wine for Windows ISVs: http://kegel.com/wine/isv
On 1/30/06, Dan Kegel dank@kegel.com wrote:
To see how reasonable it might be to use OOo 2.0.1 and Firefox 1.5 under Wine routinely, I benchmarked their startup time on a Fedora Core 5 test 2 system under four conditions: native vs. with wine from cvs, and with 416MB RAM vs. 96 MB RAM (by booting with mem=96M; this was to simulate running on one of those cheapo 128MB boxes that uses shared video RAM). This was on a zippy Compaq Presario 3000 Athlon 64 3000+. All apps were downloaded from openoffice.org and mozilla.com.
Very interesting. Keep in mind that the FC5t2 kernels and libraries currently have some debugging stuff enabled that might have a big effect in these tests.
You should think about posting these results to the fedora-devel or fedora-test list.
n0dalus.
On 1/29/06, n0dalus n0dalus+wine@gmail.com wrote:
Very interesting. Keep in mind that the FC5t2 kernels and libraries currently have some debugging stuff enabled that might have a big effect in these tests.
The few bits I've verified in Ubuntu 05.10 are the same as in FC5t2, so perhaps that isn't a problem. I'll do future measurements in Ubuntu, probably.
There are some rendering problems in Firefox; to see them, run firefox 1.5 under wine, then log in to gmail.com; you'll see black streaks to the left of the text entry areas.
Firefox also seems to render slowly; it's tempting to run wine under oprofile and see if that finds the bottleneck. cf. http://www.winehq.com/?issue=249#oprofile%20&%20Wine - Dan
-- Wine for Windows ISVs: http://kegel.com/wine/isv
On 1/29/06, Dan Kegel dank@kegel.com wrote:
To see how reasonable it might be to use OOo 2.0.1 and Firefox 1.5 under Wine routinely, I benchmarked their startup time on a Fedora Core 5 test 2 system under four conditions: native vs. with wine from cvs, and with 416MB RAM vs. 96 MB RAM [On cold start and 96 MB RAM], win32 openoffice starts up with wine 1.5 times *faster* than the native linux version!
Nope. Measurement error. Turns out running Firefox in wine and then OpenOffice in wine makes OpenOffice start up fast, since wine's in the cache. Gotta reboot between runs of even different apps.
I then measured how long it took to start up the app the second time, when the cache was nice and hot:
4 Firefox run2 native 96MB 6 Firefox run2 wine 96MB 36 ooo run2 native 96MB 28 ooo run2 wine 96MB
I measured this again tonight. It's still roughly true; tonight I got 35 seconds native, 30 with Wine (leaving wineserver and the helper window running between runs).
I suspect the reason is the slow shared library loading that Michael Meeks is working on fixing. Once that's in (if he can convince Ulrich Drepper), native OOo should load as fast as OOo under wine. - Dan
-- Wine for Windows ISVs: http://kegel.com/wine/isv
On Thu, 2006-02-09 at 21:40 -0800, Dan Kegel wrote:
Nope. Measurement error. Turns out running Firefox in wine and then OpenOffice in wine makes OpenOffice start up fast, since wine's in the cache. Gotta reboot between runs of even different apps.
I don't know -- it may be more interesting to separate out wine start-up from application loading. After all, the wine startup is a one time hit. You don't time native OOo by counting the bootup time as well (hmmm, maybe we should -- this way we may actually get some decent boot times :)).
Hi,
On Thu, Feb 09, 2006 at 09:40:31PM -0800, Dan Kegel wrote:
On 1/29/06, Dan Kegel dank@kegel.com wrote:
To see how reasonable it might be to use OOo 2.0.1 and Firefox 1.5 under Wine routinely, I benchmarked their startup time on a Fedora Core 5 test 2 system under four conditions: native vs. with wine from cvs, and with 416MB RAM vs. 96 MB RAM [On cold start and 96 MB RAM], win32 openoffice starts up with wine 1.5 times *faster* than the native linux version!
Nope. Measurement error. Turns out running Firefox in wine and then OpenOffice in wine makes OpenOffice start up fast, since wine's in the cache. Gotta reboot between runs of even different apps.
Reboot?? Most likely not necessary, try something like here: http://bhhdoa.org.au/pipermail/ck/2005-September/004476.html
(probably minus the swapoff part)
Gotta make sure that you really get an OOM, though, otherwise your machine is dead ;)
I suspect the reason is the slow shared library loading that Michael Meeks is working on fixing. Once that's in (if he can convince Ulrich Drepper), native OOo should load as fast as OOo under wine.
Nice!
Andreas
On Thu, 2006-02-09 at 21:40 -0800, Dan Kegel wrote:
I then measured how long it took to start up the app the second time, when the cache was nice and hot:
4 Firefox run2 native 96MB 6 Firefox run2 wine 96MB 36 ooo run2 native 96MB 28 ooo run2 wine 96MB
It takes you 28 secs to warm-start OO.o ? that's pretty amazing ;-) it's ~4 seconds for me.
I suspect the reason is the slow shared library loading that Michael Meeks is working on fixing. Once that's in (if he can convince Ulrich Drepper), native OOo should load as fast as OOo under wine.
Yes - quite; of course, there are still a -few- bonus' with Win32 linking I think; ordinal lookups rather than hash/string comparisons - but by more cunning sorting, pre-computed hash value comparisons, and direct linkage we can drastically reduce that cost.
As you say though - convincing Ulrich it is a good idea is the main challenge here :-)
HTH,
Michael.
From: "michael meeks" michael.meeks@novell.com
4 Firefox run2 native 96MB 6 Firefox run2 wine 96MB 36 ooo run2 native 96MB 28 ooo run2 wine 96MB
It takes you 28 secs to warm-start OO.o ? that's pretty amazing ;-) it's ~4 seconds for me.
On the same 96MB config? With or without your patches?
As you say though - convincing Ulrich it is a good idea is the main challenge here :-)
What's the status of that effort BTW? :)
On Mon, 2006-02-13 at 11:34 -0500, Dimi Paun wrote:
As you say though - convincing Ulrich it is a good idea is the main challenge here :-)
What's the status of that effort BTW? :)
Hard to say; the sole insightful prognostication available is: http://sourceware.org/ml/binutils/2005-10/msg00437.html
which doesn't inspire much hope of constructive engagement really.
Heh,
Michael.
Hi,
On Wed, Feb 15, 2006 at 12:46:02PM +0000, michael meeks wrote:
On Mon, 2006-02-13 at 11:34 -0500, Dimi Paun wrote:
As you say though - convincing Ulrich it is a good idea is the main challenge here :-)
What's the status of that effort BTW? :)
Hard to say; the sole insightful prognostication available is: http://sourceware.org/ml/binutils/2005-10/msg00437.html
which doesn't inspire much hope of constructive engagement really.
Well, but that was a rather rough-shot reply, and your reply to that (if it was valid) was quite important, so for now it seems he doesn't have too much of a point here. Not to mention that application startup time still *is* a bottleneck on Linux, so there should be more effort to reduce that. I want to keep using my 450MHz box for some more decades ;)
BTW, did you do some oprofile runs of app startup?
Andreas Mohr
Hi Andreas,
On Wed, 2006-02-15 at 16:33 +0100, Andreas Mohr wrote:
Well, but that was a rather rough-shot reply, and your reply to that (if it was valid) was quite important, so for now it seems he doesn't have too much of a point here.
So my personal feeling (having never used it) is that prelink is a pain to setup, maintain, get distros running with, fragments the disk etc. etc. ;-) [ but this is all 2nd hand angst ].
Not to mention that application startup time still *is* a bottleneck on Linux, so there should be more effort to reduce that. I want to keep using my 450MHz box for some more decades ;)
BTW, did you do some oprofile runs of app startup?
Well - valgrind / cachegrind - sure. You can get some pretty graphical pictures with do_lookup_x chewing 1/2 the screen ;-) [ and some after pictures with it burning way less of the screen ] - and it's all data access problems; L1 & L2 cache misses all over the shop.
Regards,
Michael.
From: "michael meeks" michael.meeks@novell.com
So my personal feeling (having never used it) is that prelink is a pain to setup, maintain, get distros running with, fragments the disk etc. etc. ;-) [ but this is all 2nd hand angst ].
I run FC4, and AFAIK it is implemented on that system. I must say however that I was never aware of it, which is pretty cool. Don't know how much it helps (I still feel the startup of pretty much everything needs work), but at least it doesn't get in the way.
On 2/15/06, Dimi Paun dimi@lattica.com wrote:
From: "michael meeks" michael.meeks@novell.com
So my personal feeling (having never used it) is that prelink is a pain to setup, maintain, get distros running with, fragments the disk etc. etc. ;-) [ but this is all 2nd hand angst ].
I run FC4, and AFAIK it is implemented on that system. I must say however that I was never aware of it, which is pretty cool. Don't know how much it helps (I still feel the startup of pretty much everything needs work), but at least it doesn't get in the way.
Prelinking only helps in situations where you build once and run many times.
When you're developing large systems, however, you tend to build once and run once. In these situations prelinking helps not at all. - Dan
-- Wine for Windows ISVs: http://kegel.com/wine/isv
-
Andreas Mohr -
Dan Kegel -
Dimi Paun -
michael meeks -
n0dalus