[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.


Other related posts: