[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: Joel Low <joel_at_joelsplace.sg>
Date: Mon, 1 Dec 2008 09:57:49 +0800

Hello,

I thought I'd give my opinion on this because I attempted to build SVN x64 a week ago.

I agree with all the points so far, especially those on support. Although x64 builds _work_, there isn't enough testing to say for sure it works _properly_. I have not got a server crash or database corruption yet, but I don't think anyone will guarantee that it will never happen (and not everyone is willing to take that risk, testing may resolve that). On top of that, remember that Apache isn't supported on x64 Windows: that's also a big factor IMHO that will tilt the balance here.

Having said all of that, I must note that I didn't successfully build every bit of SVN, only mod_dav_svn, mod_authz_svn, the Python bindings (for Trac) and their dependencies. Even for those that did build, it was a little hit-and-miss. I probably won't be able to replicate it another time, so I doubt I can give instructions...

If anyone's interested, I used VS2008 SP1 on Windows Vista SP1, cross-compiling for my server which is running Windows Server 2008. The VS2008 x64 cross-compiler for x86 seems to be the same version as the one in the Windows 2008/.NET 3.5 SDK. I used Apache 2.2.10 and all the associated apr libraries in that Apache distribution.

Regards,
Joel

> -----Original Message-----
> From: Mark Phippard [mailto:markphip_at_gmail.com]
> Sent: Monday, 1 December, 2008 9:39 AM
> To: Mircea Zahan
> Cc: D.J. Heap; David Weintraub; users_at_subversion.tigris.org
> Subject: 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

---------------------------------------------------------------------
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:58:45 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.