Mark Phippard wrote:
> Stefan Küng <tortoisesvn@gmail.com> wrote on 12/19/2005 03:53:38 PM:
>
>> I've read that too. But with a good optimizing compiler, there won't be
>> much of a speed reduction without assembler.
>>
>> What do you mean with "run circles"? And why should 32-bit builds even
>> try to load *our* openssl dll? The dll is in our own install dir, and
>> that's the only place it belongs (read the openssl docs: they clearly
>> state that you must not put it in Windows or System32 or the Win64
>> equivalent of these dirs).
>
> I believe he was implying that a 32-bit version of TSVN would run circles
> around the 64-bit version because of this. Personally, I am more in your
> camp on this. I think that SSL plays such a small role in the equation
> that the difference wouldn't be that big.
I would definitely agree here. For TortoiseSVN's use case,
encryption could be a 1000 times slower and still probably not
matter... the network bandwith is the dominating factor.
> Besides, 64-bit is not supposed
> to be faster than 32-bit. It is supposed to allow access to more RAM. The
> point of TSVN being 64-bit is that it is an Explorer shell extension and
> since Explorer is 64-bit this is just about being compatible and
> convenient for the user. It is not as if TSVN or SVN for that matter are
> taking advantage of what 64-bits offer. To be honest, I am not sure why
> anyone runs Win 64-bit anyway. Do you have more than 4 GB of RAM in your
> desktop? Neither the Intel nor the AMD processors incur any performance
> hit for 32-bit code so running 64-bit doesn't really give you anything. If
> anything it probably makes things marginally slower as items take a bit
> more space and use a bit mor RAM.
Well, if I'm not mistaken, the Itanium has to run 64-bit windows;
and even though it _can_ run 32-bit code, it does so very poorly,
and it sucks your processor dry.
In addition, while the focus has been on the '64-bit' nature
of the platform, the platform also added 8 additional general
purpose registers, which do make a significant difference in
performance for some real-world applications even without
extra memory.
Also, keep in mind that it isn't just 64-bits of physical address
space, but 64-bits of virtual address space. This can make some
things perform better even in the absence of extra memory. (I
suspect the system file-system cache may be one of these as it
is somewhat limited by virtual memory space in 32-bit windows.)
In terms of performance, here is an interesting article:
http://www.pcstats.com/articleview.cfm?articleID=1665
The long and short is that indeed, there can be some minor
reduction of memory bandwidth due to the 64-bit pointers,
but their are also major performance wins available for
anything that could use more registers (gzip) or wider
registers (encryption using bignum packages.)
In addition to performance benefits, 64-bit windows currently
confers a certain immunity to its users from root-kits, since
it will not use 32-bit driver software.
Also, Microsoft has to a small degree broken from it's
'compatibility above security' philosophy with 64-bit
windows. An example of this is the fact that 64-bit
windows disables hooking of kernel functions (adding
stability and breaking more root-kits.)
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Dec 20 00:05:56 2005