[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Mircea Zahan <mzahan_at_adaptive.ro>
Date: Mon, 1 Dec 2008 03:18:31 +0200

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
Received on 2008-12-01 02:18:55 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.