Re: BLAST+ speed & build issues
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
Reply to: