Dear Tim, Have many thanks for raising this issue. It is weird. But this is exactly why we have this list IMHO.
On 08/03/2011 10:48 AM, Tim Booth wrote: > Hi, > >> Creating a "static" package would be easy, but would double the size >> (which is large) for blast+ on servers, > > Actually, it makes it about 8x the size, as each binary has its own > copies of every library. I do not see why a static package should now become any faster upon startup - it needs to read more if I am not erroneous. >> and it could be confusing for >> the user, no? (selecting between dynamic and static). > > Yes, but I already have a confused user asking why his analysis takes > six times as long when he recently upgraded BLAST. How would you > suggest tackling this problem? Something must be wrong. Somewhere. The newer compilers should be better, especially for their link time optimisation ... if we had enabled it. > Actually, I realise I'm jumping the gun a bit here. I've not yet tried > compiling my own static version from source in order to do a speed > comparison with the binary version distributed by NCBI. I'll try that > today. That sounds like a good idea. I do not really know what to hope for. If their version is behaving same as bad, then we have a weird BLAST version. If theirs is better, then somewhere we have non-optimised code. The only way I would see the static version rule is when there is redundant code shipping with the BLAST sources that is compiled in a better way than what Debian is shipping. You'd then prevent the system libraries from interfering. Just guessing - the effect is on a 32 bit system? There would be a series of optimisations not kicking in for default Debian, like SSE instructions, which might be somewhat beneficial to have for what BLAST is doing. Those are switched on by default on amd64, so the effect would be less dramatic on that end ... but I do not see how this could effect startup time ... Steffen -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
