Stefan Küng wrote:
> 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
> 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.
That's fine. Win64 users should be made aware of possible reduced
performance on the OpenSSL (e.g. HTTPS) end of things.
XLAuditor - Perform deep spreadsheet analysis quickly and easily. Find
the problems everyone else missed. Be the hero of your company today:
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Dec 20 00:17:17 2005