Re: x86 is stone age, how about moving along ?

There are 64-bit binaries here:

http://www.sliksvn.com/en/download

But no Apache modules. As DJ indicated, the problem with Apache is
that the modules would not be compatible with the Apache binaries and
probably no one wants to provide Apache too.

On Sun, Nov 30, 2008 at 8:18 PM, Mircea Zahan <mzahan_at_adaptive.ro> wrote:
> Nope, the server binaries.
> But I decided to drop the issue, way to much fuss about it.
>
>
> Thank you for your time,
> Mircea.
>
> ----- Original Message ----- From: "D.J. Heap" <djheap_at_gmail.com>
> To: "Mircea Zahan" <mzahan_at_adaptive.ro>
> Cc: "David Weintraub" <qazwart_at_gmail.com>; <users_at_subversion.tigris.org>
> Sent: Monday, December 01, 2008 3:06 AM
> Subject: Re: x86 is stone age, how about moving along ?
>
>
>> On Sun, Nov 30, 2008 at 3:37 PM, Mircea Zahan <mzahan_at_adaptive.ro> wrote:
>>>
>>> My desire for x64 SVN comes from the fact that I want to
>>> have a pure x64 environment. That wish in turn comes from
>>> reading that at kernel level, switches to and from x32 are
>>> very costly in terms of processor cycles. While running x32
>>> apps on x64 OS is supported, is not efficient.
>>>
>>> You might say that the performance drawback is minor,
>>> but I'm dealing with a multipurpose machine, with six different
>>> servers running on it, so I want to squeze every drop
>>> of computing power out of it.
>>
>>
>> Building a 64 bit version would require a newer compiler and new
>> dependency module builds.
>>
>> As far as I know (I've only tested it once or twice and that was a
>> while ago), 64 bit support works fine if you use a newer compiler -
>> but the binaries up on tigris.org are geared towards supporting the
>> standard Apache server which is 32 bit only (as well as including the
>> Subversion client binaries, of course).
>>
>> And it is not 'just' Subversion that needs to be built -- APR, neon,
>> zlib, OpenSSL, etc. These are the harder ones (not all that hard, but
>> not nearly as straightforward as Subversion itself).
>>
>> Perfomance gains would be miniscule at best, I suspect, as others have
>> mentioned.
>>
>> Anyway, the biggest can of worms, IMO, would be the server modules.
>> If we move to a modern compiler, then we drag in a new CRT and
>> possibly require the Apache server to be built with the same compiler
>> (aside from requiring a x64 build of Apache) and then who would supply
>> that? Us? Or do we just build client binaries? Or do we build
>> clients and a server module that no one can run without building
>> Apache themselves with the same compiler we used? And there's the
>> bindings, too...I really don't want to deal with that mess of confused
>> end-user emails.
>>
>> This would all be on top of the 32 bit binaries -- I don't see the
>> need for those going away anytime soon, unfortunately. And since 32
>> bit binaries work fine on a 64 bit Windows OS, there is very little
>> motivation to add another set of packages to the list to build and
>> test and distribute.
>>
>> However, given that long list of excuses, I do plan on trying to build
>> the basic x64 client binaries for myself when 1.6 comes out and I
>> wouldn't mind posting those with a disclaimer that they are not as
>> well tested, there's no server module, no bindings, probably no
>> installer, etc. What specifically are you looking for? Client
>> binaries only?
>>
>> DJ
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org