Yes. Maybe it got renamed... It used to be named 'amd32'. On Tue, May 12, 2015 at 12:45:36PM +0200, Tomasz Kontusz wrote: > By amd32 do you mean amd64 with 32 bit pointers? > > "Lluís Batlle i Rossell" <[email protected]> napisał: > >amd32 should be ready in the kernel and gcc/glibc. We just need someone > >to > >prepare nix/nixpgks/nixos for this. :) > > > >On Tue, May 12, 2015 at 12:05:29PM +0200, Christian Theune wrote: > >> Hi, > >> > >> same here. > >> > >> Many interpreted languages (like Python) are affected by this as they > >tend to be quite pointer-happy. As pointer-size doubles from 32bit to > >64bit we find that in most applications we have about 70% increase when > >moving to 64-bit ending up with 1.7 as much memory as before. So we > >also currently run applications in 32-bit virtual machines and rather > >use many 3GiB processes than a few bigger ones. Moving from 3GiB to > >64bit requires about 5GiB just to even out the pointer-size effects. > >> > >> Supposedly the amd64 instruction set has some benefits that make e.g. > >Python run faster on certain computational stuff, but I don’t have > >prove for that. > >> > >> In the long term we will include 64-bit in the mix anyway as some > >applications (Mongo, sigh) are quite trigger happy with allocating > >virtual (non residential) memory for mmapping insane numbers of > >insanely large files … > >> > >> Christian > >> > >> > On 12 May 2015, at 11:59, Lluís Batlle i Rossell <[email protected]> > >wrote: > >> > > >> > My experience is equal with Marco, about memory and my usage of > >i686. i686 > >> > is important for me too. > >> > > >> > On Tue, May 12, 2015 at 11:43:47AM +0200, Marco Maggesi wrote: > >> >> I use 32 bit a lot. > >> >> First of all, I use it on some old machines with 32bit hardware. > >> >> But, more importantly, I use it regularly on virtuabox and xen > >virtual > >> >> machines. > >> >> In my experience, for most of my use cases the 32bit require less > >memory > >> >> (which is often not abundant on virtual instances) and it is thus > >generally > >> >> faster for many computing tasks . I made some tests with HOL > >Light (the > >> >> theorem prover). The bare program has memory occupation which > >almost the > >> >> double in the 64bit version (~1.2Gb) with respect to the 32bit > >version > >> >> (~0.7Gb). On a virtual machine with 2Gb of ram, the 32 bit it is > >often > >> >> 10%-20% faster on typical usage and 50% faster or more when the > >computation > >> >> requires more memory. > >> >> In my experience, the version 32 bit can be more convenient than > >the 64bit > >> >> version in a variety of situations. > >> >> So, please, do not give-up with 32 bit support. > >> >> Marco > >> >> > >> >> > >> >> > >> >> 2015-05-12 11:08 GMT+02:00 Luke Clifton <[email protected]>: > >> >> > >> >>> +1 > >> >>> > >> >>> This seems like a good idea. > >> >>> > >> >>> On 12 May 2015 at 06:45, William Kennington > ><[email protected]> > >> >>> wrote: > >> >>> > >> >>>> Maybe it would make more sense to only build the i686 builds if > >our > >> >>>> tested set of x86_64 binaries build correctly. We would still > >release with > >> >>>> both but it would cut down on a lot of redundant failures. > >> >>>> > >> >>>> On Mon, May 11, 2015 at 3:39 PM Ryan Trinkle > ><[email protected]> > >> >>>> wrote: > >> >>>> > >> >>>>> I encountered an i686 user just the other day! I don't use it > >> >>>>> personally, but having solid support in Nix was fantastic, > >especially > >> >>>>> because older, 32-bit machines tend to be slower, which makes > >Nix's binary > >> >>>>> caching functionality even more important. > >> >>>>> > >> >>>>> On Mon, May 11, 2015 at 6:36 PM, Shea Levy <[email protected]> > >wrote: > >> >>>>> > >> >>>>>> Hi all, > >> >>>>>> > >> >>>>>> Do we still have users running 32-bit machines? It would > >reduce the > >> >>>>>> load on > >> >>>>>> hydra significantly if we could drop support for i686, though > >of course > >> >>>>>> if > >> >>>>>> people are still relying on it we shouldn't make the change > >yet. > >> >>>>>> > >> >>>>>> ~Shea > >> >>>>>> _______________________________________________ > >> >>>>>> nix-dev mailing list > >> >>>>>> [email protected] > >> >>>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev > >> >>>>>> > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> nix-dev mailing list > >> >>>>> [email protected] > >> >>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev > >> >>>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> nix-dev mailing list > >> >>>> [email protected] > >> >>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev > >> >>>> > >> >>>> > >> >>> > >> >>> _______________________________________________ > >> >>> nix-dev mailing list > >> >>> [email protected] > >> >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev > >> >>> > >> >>> > >> > > >> >> _______________________________________________ > >> >> nix-dev mailing list > >> >> [email protected] > >> >> http://lists.science.uu.nl/mailman/listinfo/nix-dev > >> > > >> > > >> > -- > >> > (Escriu-me xifrat si saps PGP / Write ciphered if you know PGP) > >> > PGP key D4831A8A - https://emailselfdefense.fsf.org/ > >> > _______________________________________________ > >> > nix-dev mailing list > >> > [email protected] > >> > http://lists.science.uu.nl/mailman/listinfo/nix-dev > >> > >> — > >> Christian Theune · [email protected] · +49 345 219401 0 > >> Flying Circus Internet Operations GmbH · http://flyingcircus.io > >> Forsterstraße 29 · 06112 Halle (Saale) · Deutschland > >> HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. > >Zagrodnick > >> > > > > > > > >-- > >(Escriu-me xifrat si saps PGP / Write ciphered if you know PGP) > >PGP key D4831A8A - https://emailselfdefense.fsf.org/ > >_______________________________________________ > >nix-dev mailing list > >[email protected] > >http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- > Wysłane za pomocą K-9 Mail.
-- (Escriu-me xifrat si saps PGP / Write ciphered if you know PGP) PGP key D4831A8A - https://emailselfdefense.fsf.org/ _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
