[Nix-dev] i686 Builds?

Tomasz Kontusz tomasz.kontusz at gmail.com
Tue May 12 12:45:36 CEST 2015


By amd32 do you mean amd64 with 32 bit pointers?

"Lluís Batlle i Rossell" <viric at viric.name> 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 <viric at viric.name>
>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 <ltclifton at gmail.com>:
>> >> 
>> >>> +1
>> >>> 
>> >>> This seems like a good idea.
>> >>> 
>> >>> On 12 May 2015 at 06:45, William Kennington
><william at wkennington.com>
>> >>> 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
><ryan.trinkle at gmail.com>
>> >>>> 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 <shea at shealevy.com>
>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
>> >>>>>> nix-dev at lists.science.uu.nl
>> >>>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>> >>>>>> 
>> >>>>> 
>> >>>>> _______________________________________________
>> >>>>> nix-dev mailing list
>> >>>>> nix-dev at lists.science.uu.nl
>> >>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>> >>>>> 
>> >>>> 
>> >>>> _______________________________________________
>> >>>> nix-dev mailing list
>> >>>> nix-dev at lists.science.uu.nl
>> >>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>> >>>> 
>> >>>> 
>> >>> 
>> >>> _______________________________________________
>> >>> nix-dev mailing list
>> >>> nix-dev at lists.science.uu.nl
>> >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>> >>> 
>> >>> 
>> > 
>> >> _______________________________________________
>> >> nix-dev mailing list
>> >> nix-dev at lists.science.uu.nl
>> >> 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
>> > nix-dev at lists.science.uu.nl
>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>> 
>>>> Christian Theune · ct at flyingcircus.io · +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
>nix-dev at lists.science.uu.nl
>http://lists.science.uu.nl/mailman/listinfo/nix-dev

-- 
Wysłane za pomocą K-9 Mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150512/168692e3/attachment-0001.html 


More information about the nix-dev mailing list