Nathan Kidd wrote:
> Stefan Küng wrote:
>>> - No assembler modules are engaged upon initial 0.9.8 release."
>>
>> I've read that too. But with a good optimizing compiler, there won't
>> be much of a speed reduction without assembler.
>
> For normal code this is true but the particular nature of OpenSSL (well
> defined algorithms looped many *many* times) is such that carefully
> tuned asm does give several times faster code than the best optimizing
> compilers. Andy Polyakov has done quite a bit of work on this, taking
> into consideration CPU architecture details, etc. (An example:
> http://www.mail-archive.com/openssl-dev@openssl.org/msg18415.html)
Ok, so asm is much faster. But let's be realistic here. OpenSSL is used
for https connections. And even if you check out big working copies, the
CPU usage never goes above 10% - the bottleneck is always the network.
Ok, let's assume you have a GB network connection, even in that case,
the bottleneck wouldn't be the CPU usage but the harddisk, because you
usually check out many smaller files which need to be written to the disk.
I'm not sure, but I don't think it's possible to load a 32-bit dll into
a 64-bit process. So OpenSSL must be 64-bit too for TSVN.
Because, the shell extension must be 64-bit for the shell to load it.
That leads to the apr dll's to be 64-bit. And I don't think those dll's
get different names for 64/32-bit builds. So if those dll's are 64-bit,
TortoiseProc and all others must be 64-bit too. Which again leads to
OpenSSL to be 64-bit too.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Dec 19 23:00:24 2005