[haiku] Re: gcc4 hibryd
- From: Christian Packmann <Christian.Packmann@xxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Sat, 07 Mar 2009 14:23:29 +0100
Stephan Aßmus - 2009-03-04 10:55 :
Christian Packmann schrieb:
But maybe the
turned off optimizations in our GCC4 indeed account for the missing
performance boost, then it could be low hanging fruit to get a boost
for GCC4 Haiku in general. :-)
I'm rather certain of that; let's just hope that full optimizations
don't break anything. We should see a 50-100% speed increase throughout,
and that would be cool.
Yes, the SSE version of the benchmark should have revealed if any
slowness can be attributed to running on Haiku as a platform. (Which one
couldn't have ruled out completely, BTW.)
For pure computational code, there is little opportunity for running slow;
I can only think of wrongly configured caching attributes for memory areas
which would give slowdowns when doing many memory accesses. Otherwise only
the excessive occurrence of interrupts could slow down the execution time;
the CPU itself is still the same, after all. Okay, maybe you could disable
the cache or invalidate the cache content on each context switch, but I
assume that our kernel coders won't be doing this. ;-)
It would also negate some current deficiencies: e.g. JPG decoding is
noticeably slower for really big images on Haiku compared to Windows
(comparing ShowImage to XnView). That is on my quad Core2@xxx GHz; on
slower machines, this will be noticeable even with rather normal image
sizes, e.g. 5MP photos or such. A "true" GCC4 build would remove such
disadvantages and level the playing field compared to Windows and Linux.
Note that there is a so called SIMD assembly version of libjpeg by a
Japanese coder, IIRC. I came across that by accident, ie googling, at
one point. I still have it on another computer, but it's probably still
available on the web as well, just don't know the URL right now.
This would be a workaround, not a real solution. You'd have to do this for
basically all codecs which use lots of processing time - PNG saving,
video, etc. This is not feasible given Haikus current state of programmer
resources.
And it wouldn't solve the problem of actual applications running slow -
especially web browsers are relevant here. I just realized that the fact
of Firefox being so slow on Haiku compared to other platforms is probably
not OS-specific, but compiler-specific. The rendering engines of modern
web browsers are very calculation-intensive, and all rendering engines
will probably run half as fast on Haiku as compared to other OSs on which
modern compilers are used.
This will not be much of a problem on high-end machines, where web
browsers cannot tax the CPU anyway, but on lower-spec machines this should
be very noticeable, especially when rendering complex pages. This is a
serious problem, as web browsers are one of the main applications in
todays world. IMHO it wouldn't do to release Haiku R1, have people test it
only to find that their web browsers work half as fast on Haiku than on
Windows or Linux. This will certainly make an impression... just not a
good one.
Christian
Other related posts: