Stefan Teleman wrote: > Danek Duvall wrote: >> Roland Mainz wrote: >> >>> The question is "why are longer build times be painfull" ? >> >> Because the official builds machine already take 10+ hours to build >> all of >> SFW. If a nightly is broken for any reason, the turnaround time to >> get a >> good build out is a long time. >> >> Again, it may still be worth the pain, but the cost of doing this is not >> free, so we should take some care in the analysis of what needs to be >> optimized, and to what degree. > > I have a (somewhat theoretical) question about the potential > performance benefit we could get by tweaking the compiler optimization > flags in this particular case: > > The discussion here seems to be centered around software which is used > by WebStack applications -- and specifically some graphics libraries. At this point, I have not identified any web stack specific applications or libraries. I am very interested in cpu intensive libraries like libgd, libjpeg etc - which are very CPU intensive. When I meant with "optimized compiler options" - I meant to enable it to build it with SSE2 and other cpu flags so that the generated code can take advantage of these modern CPU. Af course, I wonder - who is going to install OpenSolaris these days in pre-pentium cpu's that we don't enable these flags by default. But, I don't want to get into that discussion now.
Af couse, now that OpenSSL is coming to SFW, I am sure, crypto libraries can possibly benefit as well if it is compiled for modern cpu. Again, my focus is not to enable some bleeding - top of the edge compiler optimization - but only to ensure that the generated assembly code fully takes advantage of modern cpu instructions like SSE2 etc. > > Considering what a typical web application generally does: > > - parse and byte-compile PHP, generate dynamic HTML > - maybe talk to a relational database and get some data from there as > well > - get stuff from the network (referenced sites) > - wait for slowly responding referenced web sites > > Out of the total cost of rendering this hypothetical page, how much > optimization can we hope to obtain by tweaking the compiler flags for > libtiff, libjpeg and libgd2 ? These days, there are lot of ways to work around the database latency. Again, if a customer is going to benchmark his favorite graphical application against other distributions, he is going to complain that OpenSolaris is slow. He doesn't care or know about the technical detail that a particular library is not built to take advantage of his modern CPU etc. > > I am certainly not opposed to the idea of tweaking compiler flags -- > quite the opposite, i'm all for it. I'm just being a downer, and > suggesting that, out of the total cost of rendering dynamic HTML > pages, the speed increases we might obtain by tweaking the graphics > libraries could very well end up in disappointment. > > Having said that, libjpeg and libtiff on SPARC could benefit from > being built for sparcv8plusa and sparcv9a. libgd2 is already built > that way. I understand that. I am hoping we can do some thing similar - in a more generic way for other critical sfw libraries on x86 platform as well. - Sriram
