x32 abi support?

[Neal Becker]

I noticed this article:

http://www.phoronix.com/scan.php?page=news_item&px=MTEwMTk

Has this been discussed on fedora?

[Josh Boyer]

On Wed, May 16, 2012 at 9:18 AM, Neal Becker <ndbecker2(a)gmail.com&gt; wrote:
>  I noticed this article:
>
>  http://www.phoronix.com/scan.php?page=news_item&px=MTEwMTk
>
>  Has this been discussed on fedora? 
Not that I've seen.  Also, the article is either incomplete or
incorrect, as full x32 support for glibc hasn't landed yet.  Upstream
is still working on that and it might get in for glibc-2.16.

If this were to come to Fedora, I would expect it to start as a
secondary architecture.

josh

[Nicolas Chauvet]

2012/5/16 Josh Boyer <jwboyer(a)gmail.com&gt;:
>  On Wed, May 16, 2012 at 9:18 AM, Neal Becker
> <ndbecker2(a)gmail.com&gt; wrote:
> > I noticed this article:
> >
> > http://www.phoronix.com/scan.php?page=news_item&px=MTEwMTk
> >
> > Has this been discussed on fedora?
>
>  Not that I've seen.  Also, the article is either incomplete or
>  incorrect, as full x32 support for glibc hasn't landed yet.  Upstream
>  is still working on that and it might get in for glibc-2.16.
>
>  If this were to come to Fedora, I would expect it to start as a
>  secondary architecture. 
Secondary arch suggests the whole fedora collection is built with x32 ABI.
But there is one noticeable exception with that; as I understood:the
kernel will anyway "remains" at x86_64.

So that make me wonder if we really need to built the whole collection
as x32 ? Or if we only wants a selection of components to be optimized
by x32. For example does it matter to move the whole Xorg server
infrastructure as x32 or is it possible to leave it as x86_64 ? or is
there any benifit for the move to x32 in this area ?

Nicolas (kwizart)

[Josh Boyer]

On Wed, May 16, 2012 at 4:24 PM, Nicolas Chauvet <kwizart(a)gmail.com&gt; wrote:
>  2012/5/16 Josh Boyer <jwboyer(a)gmail.com&gt;:
> > On Wed, May 16, 2012 at 9:18 AM, Neal Becker <ndbecker2(a)gmail.com&gt; wrote:
> >> I noticed this article:
> >>
> >> http://www.phoronix.com/scan.php?page=news_item&px=MTEwMTk
> >>
> >> Has this been discussed on fedora?
> >
> > Not that I've seen.  Also, the article is either incomplete or
> > incorrect, as full x32 support for glibc hasn't landed yet.  Upstream
> > is still working on that and it might get in for glibc-2.16.
> >
> > If this were to come to Fedora, I would expect it to start as a
> > secondary architecture.
>
>  Secondary arch suggests the whole fedora collection is built with x32 ABI.
>  But there is one noticeable exception with that; as I understood:the
>  kernel will anyway "remains" at x86_64. 
The kernel is x86_64, with support for the x32 ABI, yes.

>  So that make me wonder if we really need to built the whole
> collection
>  as x32 ? Or if we only wants a selection of components to be optimized
>  by x32. For example does it matter to move the whole Xorg server
>  infrastructure as x32 or is it possible to leave it as x86_64 ? or is
>  there any benifit for the move to x32 in this area ? 
You can't link x32 binaries against i686/x86_64 libraries, etc.  You
need entirely separate userspace.  From a Fedora perspective, the way
to do that is to add an architecture to koji and build whatever you
want.  That arch add should start as secondary.

josh

[Kevin Kofler]

Nicolas Chauvet wrote:
>  So that make me wonder if we really need to built the whole
> collection
>  as x32 ? Or if we only wants a selection of components to be optimized
>  by x32. For example does it matter to move the whole Xorg server
>  infrastructure as x32 or is it possible to leave it as x86_64 ? or is
>  there any benifit for the move to x32 in this area ? 
As already explained in this thread by others, if you have a mix of x32 and 
normal x86_64, you end up with both multilibs in memory, negating the memory 
savings from the bastard x32 ABI.

        Kevin Kofler

[Alexander Larsson]

On Thu, 2012-05-17 at 02:28 +0200, Kevin Kofler wrote:
>  Nicolas Chauvet wrote:
>  > So that make me wonder if we really need to built the whole collection
>  > as x32 ? Or if we only wants a selection of components to be optimized
>  > by x32. For example does it matter to move the whole Xorg server
>  > infrastructure as x32 or is it possible to leave it as x86_64 ? or is
>  > there any benifit for the move to x32 in this area ?
>  
>  As already explained in this thread by others, if you have a mix of x32 and 
>  normal x86_64, you end up with both multilibs in memory, negating the memory 
>  savings from the bastard x32 ABI. 
I don't think this is always the case. Obviously if you run a lot of
both kinds of apps it matters, but if there are a few, small x86-64
processes (say e.g. the xserver, or a database instance) the doubled mem
use from some shared libraries should not affect things overly much. In
most practical uses of computers (i.e. those that actually *do*
something) most memory is used for the users "data", and for that, x32
uses less ram, as all pointers in the ram structures are half the size.

Obviously, it all "depends". But I think x32 makes a lot of sense as an
option, especially in the virtual machine space.

[Tomasz Torcz]

On Thu, May 17, 2012 at 09:53:12AM +0200, Alexander Larsson wrote:
>  I don't think this is always the case. Obviously if you run a lot
> of
>  both kinds of apps it matters, but if there are a few, small x86-64
>  processes (say e.g. the xserver, or a database instance) the doubled mem
>  use from some shared libraries should not affect things overly much. In
>  most practical uses of computers (i.e. those that actually *do*
>  something) most memory is used for the users "data", and for that, x32
>  uses less ram, as all pointers in the ram structures are half the size.
>  
>  Obviously, it all "depends". But I think x32 makes a lot of sense as an
>  option, especially in the virtual machine space. 
  Can we get some definite numbers?

-- 
Tomasz Torcz                 "God, root, what's the difference?"
xmpp: zdzichubg(a)chrome.pl         "God is more forgiving."

[Frank Ch. Eigler]

Tomasz Torcz <tomek(a)pipebreaker.pl&gt; writes:

>  [...]  Can we get some definite numbers? 
Yeah, not enough of those going around.  A quick test with systemtap,
a typical pointer/datastructure-heavy program, on same x86-64 machine,
compiled with -m64 and -m32, same workload.  It parses /proc/self/statm.

64-bit
./stap -p4 -v -e 'probe syscall.* { println($$vars$)}'
Pass 1: ... using 201380virt/24228res/2896shr/21564data kb, ...
Pass 2: ... using 492512virt/277164res/92932shr/184036data kb, ...
Pass 3: ... using 492512virt/277288res/93056shr/184036data kb, ...

32-bit
./stap -p4 -v -e 'probe syscall.* { println($$vars$)}'
Pass 1: ... using 26752virt/15732res/2560shr/13196data kb, ...
Pass 2: ... using 260524virt/213144res/92632shr/120352data kb, ...
Pass 3: ... using 260524virt/213264res/92752shr/120352data kb, ...

I tried corresponding tests, eyeballing top while running
gcc/emacs/firefox: same pattern, around 50% more data usage.

- FChE

[Andrew Haley]

On 05/17/2012 04:37 PM, Frank Ch. Eigler wrote:
>  
>  Tomasz Torcz <tomek(a)pipebreaker.pl&gt; writes:
>  
> > [...]  Can we get some definite numbers?
>  
>  Yeah, not enough of those going around.  A quick test with systemtap,
>  a typical pointer/datastructure-heavy program, on same x86-64 machine,
>  compiled with -m64 and -m32, same workload. 
What workload, though?

Andrew.

[Matthew Garrett]

On Wed, May 16, 2012 at 09:18:32AM -0400, Neal Becker wrote:
>  I noticed this article:
>  
>  http://www.phoronix.com/scan.php?page=news_item&px=MTEwMTk
>  
>  Has this been discussed on fedora? 
x32 is mostly beneficial in that it reduces pointer size and so memory 
consumption, with the side benefit that it may also provide slightly 
higher performance due to being able to fit more in cache. But this is 
only true for a pure x32 system. If you have any applications that need 
to be 64-bit (ie, anything that is going to need more than 4GB of 
address space, which is very different from needing more than 4GB of 
RAM) then you need to have two copies of your libraries and suddenly 
your memory benefits have entirely vanished.

So, overall, x32 is only really beneficial for embedded platforms rather 
than general purpose ones. As Josh says, if there's sufficient interest 
then it could potentially be implemented as a separate architecture and 
spend some time in secondary, but I don't know that there'd be a huge 
benefit to Fedora to spend much time on it.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Frank Ch. Eigler]

mjg59 wrote:

>  [...]  If you have any applications that need to be 64-bit (ie,
>  anything that is going to need more than 4GB of address space, which
>  is very different from needing more than 4GB of RAM) then you need
>  to have two copies of your libraries and suddenly your memory
>  benefits have entirely vanished. [...] 
This is not clear to me.  The unwelcome duplication for this case
would consist only of the 64-bit shared libraries' own text & data -
and not the data of the 64-bit apps themselves.  Thus having x32 on
the system is still a win *if* the memory savings from the x32 apps is
larger than the duplicated 64-bit shlib text/data.

- FChE

[Lennart Poettering]

On Wed, 16.05.12 14:31, Matthew Garrett (mjg59(a)srcf.ucam.org) wrote:

>  On Wed, May 16, 2012 at 09:18:32AM -0400, Neal Becker wrote:
>  > I noticed this article:
>  > 
>  > http://www.phoronix.com/scan.php?page=news_item&px=MTEwMTk
>  > 
>  > Has this been discussed on fedora?
>  
>  x32 is mostly beneficial in that it reduces pointer size and so memory 
>  consumption, with the side benefit that it may also provide slightly 
>  higher performance due to being able to fit more in cache. But this is 
>  only true for a pure x32 system. If you have any applications that need 
>  to be 64-bit (ie, anything that is going to need more than 4GB of 
>  address space, which is very different from needing more than 4GB of 
>  RAM) then you need to have two copies of your libraries and suddenly 
>  your memory benefits have entirely vanished.
>  
>  So, overall, x32 is only really beneficial for embedded platforms rather 
>  than general purpose ones. As Josh says, if there's sufficient interest 
>  then it could potentially be implemented as a separate architecture and 
>  spend some time in secondary, but I don't know that there'd be a huge 
>  benefit to Fedora to spend much time on it. 
Mhmm, so I was under the impression that x32 was mostly about increasing
the scalability of virtualized systems. i.e. run a higher number of
x32 containers/VM on an x86_64 host. Most server software that is run in
containers/VMs does not require 64bit address space, and hence using x32
for them should be quite benificial so that you can run more
containers/VMs per host. After all this would reduce memory and CPU
consumption of each, and due to smaller memory usage also result in less
IO?

I'd assume that Fedora is supposed to be suitable to build highly
scalable virtualized hosts, so I'd also assume that x32 should be very
much in focus for us?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Matthew Garrett]

On Wed, May 16, 2012 at 04:28:31PM +0200, Lennart Poettering wrote:

>  Mhmm, so I was under the impression that x32 was mostly about
> increasing
>  the scalability of virtualized systems. i.e. run a higher number of
>  x32 containers/VM on an x86_64 host. Most server software that is run in
>  containers/VMs does not require 64bit address space, and hence using x32
>  for them should be quite benificial so that you can run more
>  containers/VMs per host. After all this would reduce memory and CPU
>  consumption of each, and due to smaller memory usage also result in less
>  IO? 
I was under the impression that it was to make Android work better on 
Intel. Scalable VMs are an interesting idea, but for a typical session 
how much RAM are we talking about?

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Lennart Poettering]

On Wed, 16.05.12 15:30, Matthew Garrett (mjg59(a)srcf.ucam.org) wrote:

Heya,

(added hpa to CC, who appears to be behind x32 upstream)

>  On Wed, May 16, 2012 at 04:28:31PM +0200, Lennart Poettering wrote:
>  
>  > Mhmm, so I was under the impression that x32 was mostly about increasing
>  > the scalability of virtualized systems. i.e. run a higher number of
>  > x32 containers/VM on an x86_64 host. Most server software that is run in
>  > containers/VMs does not require 64bit address space, and hence using x32
>  > for them should be quite benificial so that you can run more
>  > containers/VMs per host. After all this would reduce memory and CPU
>  > consumption of each, and due to smaller memory usage also result in less
>  > IO?
>  
>  I was under the impression that it was to make Android work better on 
>  Intel. Scalable VMs are an interesting idea, but for a typical session 
>  how much RAM are we talking about? 
I have no idea. hpa did a talk about it last year at LPC, where the
one line  summary is:

"A work-in-progress new ABI for x86 combines the memory footprint of a
32-bit process with the enhanced capabilities of the x86-64 ISA."

http://www.linuxplumbersconf.org/2011/ocw/sessions/531

I didn't attend the talk, but I figure if hpa claims it lowers memory
footprint (and puts this in the oneline summary) then he has some
statistics and other data to back it up?

Peter, can you give us some background? What's the influence of x32 on
the memory consumption, in comparison to x86_64? Is x32 useful as a
technology to increase scalability on virtualized systems?

Thanks,

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Alexander Larsson]

On Wed, 2012-05-16 at 15:30 +0100, Matthew Garrett wrote:
>  On Wed, May 16, 2012 at 04:28:31PM +0200, Lennart Poettering wrote:
>  
>  > Mhmm, so I was under the impression that x32 was mostly about increasing
>  > the scalability of virtualized systems. i.e. run a higher number of
>  > x32 containers/VM on an x86_64 host. Most server software that is run in
>  > containers/VMs does not require 64bit address space, and hence using x32
>  > for them should be quite benificial so that you can run more
>  > containers/VMs per host. After all this would reduce memory and CPU
>  > consumption of each, and due to smaller memory usage also result in less
>  > IO?
>  
>  I was under the impression that it was to make Android work better on 
>  Intel. Scalable VMs are an interesting idea, but for a typical session 
>  how much RAM are we talking about? 
If you look at some contemporary VM hosting providers, like e.g.:
http://bloggerkhan.com/vps-hosting-vps-servers/185

You'll see that most of them are in the 384-1024 meg of ram range, and
almost none are larger than 4 gigs. I'm sure most of these run 32bit
images, but the hosts are likely 64bit, so it seems to make quite some
sense to use an x32 ABI here.

[drago01]

On Wed, May 16, 2012 at 9:33 PM, Alexander Larsson <alexl(a)redhat.com&gt; wrote:
>  On Wed, 2012-05-16 at 15:30 +0100, Matthew Garrett wrote:
> > On Wed, May 16, 2012 at 04:28:31PM +0200, Lennart Poettering wrote:
> >
> > > Mhmm, so I was under the impression that x32 was mostly about increasing
> > > the scalability of virtualized systems. i.e. run a higher number of
> > > x32 containers/VM on an x86_64 host. Most server software that is run in
> > > containers/VMs does not require 64bit address space, and hence using x32
> > > for them should be quite benificial so that you can run more
> > > containers/VMs per host. After all this would reduce memory and CPU
> > > consumption of each, and due to smaller memory usage also result in less
> > > IO?
> >
> > I was under the impression that it was to make Android work better on
> > Intel. Scalable VMs are an interesting idea, but for a typical session
> > how much RAM are we talking about?
>
>  If you look at some contemporary VM hosting providers, like e.g.:
>  http://bloggerkhan.com/vps-hosting-vps-servers/185
>
>  You'll see that most of them are in the 384-1024 meg of ram range, and
>  almost none are larger than 4 gigs. I'm sure most of these run 32bit
>  images, but the hosts are likely 64bit, so it seems to make quite some
>  sense to use an x32 ABI here. 
Can x32 run i686 software (multilib) ?
Because not being able to run existing software might be a reason for
many to want such a host.

[Alexander Larsson]

On Wed, 2012-05-16 at 21:37 +0200, drago01 wrote:
>  On Wed, May 16, 2012 at 9:33 PM, Alexander Larsson
> <alexl(a)redhat.com&gt; wrote:
>  > On Wed, 2012-05-16 at 15:30 +0100, Matthew Garrett wrote:
>  >> On Wed, May 16, 2012 at 04:28:31PM +0200, Lennart Poettering wrote:
>  >>
>  >> > Mhmm, so I was under the impression that x32 was mostly about increasing
>  >> > the scalability of virtualized systems. i.e. run a higher number of
>  >> > x32 containers/VM on an x86_64 host. Most server software that is run in
>  >> > containers/VMs does not require 64bit address space, and hence using x32
>  >> > for them should be quite benificial so that you can run more
>  >> > containers/VMs per host. After all this would reduce memory and CPU
>  >> > consumption of each, and due to smaller memory usage also result in less
>  >> > IO?
>  >>
>  >> I was under the impression that it was to make Android work better on
>  >> Intel. Scalable VMs are an interesting idea, but for a typical session
>  >> how much RAM are we talking about?
>  >
>  > If you look at some contemporary VM hosting providers, like e.g.:
>  > http://bloggerkhan.com/vps-hosting-vps-servers/185
>  >
>  > You'll see that most of them are in the 384-1024 meg of ram range, and
>  > almost none are larger than 4 gigs. I'm sure most of these run 32bit
>  > images, but the hosts are likely 64bit, so it seems to make quite some
>  > sense to use an x32 ABI here.
>  
>  Can x32 run i686 software (multilib) ?
>  Because not being able to run existing software might be a reason for
>  many to want such a host. 
x32 is not a kernel, so it doesn't "run software". The kernel you run is
a standard x86-64 one which can access all your physical memory, then
you have a 32bit userspace mode similar to i386-on-x86-64 but with a
different ABI that lets it use more x86-64 features while only using
32bit pointers (so each process can only use 4 gig of virtual memory).

[Frank Ch. Eigler]

drago01 <drago01(a)gmail.com&gt; writes:

>  [...]  Can x32 run i686 software (multilib) ?  Because not being
>  able to run existing software might be a reason for many to want
>  such a host. 
x32 is not a different cpu architecture.  It's a software ABI to run
on x86-64, especially suited for smaller-memory machines/processes.
That same x86-64 cpu/kernel can run i686, x86-64, x32 software.

- FChE

[Richard W.M. Jones]

On Wed, May 16, 2012 at 03:30:23PM +0100, Matthew Garrett wrote:
>  On Wed, May 16, 2012 at 04:28:31PM +0200, Lennart Poettering wrote:
>  
>  > Mhmm, so I was under the impression that x32 was mostly about increasing
>  > the scalability of virtualized systems. i.e. run a higher number of
>  > x32 containers/VM on an x86_64 host. Most server software that is run in
>  > containers/VMs does not require 64bit address space, and hence using x32
>  > for them should be quite benificial so that you can run more
>  > containers/VMs per host. After all this would reduce memory and CPU
>  > consumption of each, and due to smaller memory usage also result in less
>  > IO?
>  
>  I was under the impression that it was to make Android work better on 
>  Intel. Scalable VMs are an interesting idea, but for a typical session 
>  how much RAM are we talking about? 
... and also how does it compare to other (better IMHO) approaches
such as KSM?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

[Ralf Ertzinger]

Hi.

On Thu, 17 May 2012 19:28:04 +0100, Richard W.M. Jones wrote

>  > I was under the impression that it was to make Android work
> better
>  > on Intel. Scalable VMs are an interesting idea, but for a typical
>  > session how much RAM are we talking about?
>  
>  ... and also how does it compare to other (better IMHO) approaches
>  such as KSM? 
Well, not having to use RAM in the first place beats crawling through
every page on the hypervisor trying to find pages to consolidate in
my book. Anyway the two things are orthogonal.

-- 
Why do kamikazi pilots wear helmets?

[Jakub Jelinek]

On Wed, May 16, 2012 at 04:28:31PM +0200, Lennart Poettering wrote:
>  Mhmm, so I was under the impression that x32 was mostly about
> increasing
>  the scalability of virtualized systems. i.e. run a higher number of
>  x32 containers/VM on an x86_64 host. Most server software that is run in
>  containers/VMs does not require 64bit address space, and hence using x32
>  for them should be quite benificial so that you can run more
>  containers/VMs per host. After all this would reduce memory and CPU
>  consumption of each, and due to smaller memory usage also result in less
>  IO? 
Note that x32 is less secure than x86-64, the possible address space
randomization is much more limited there, while there is ASCII armor, it
can protect just a couple of libraries, unlikely all of them.  With LP64
certain kinds of exploits are harder.

And, for various programs you usually don't need 64-bit address space,
but in the case where you have say bigger input you are simply out of luck
if you are limited to 32-bit address space.  Say with compilers/linkers,
you can usually compile smaller stuff just fine with 32-bit compiler, but
if you have some larger source code, x32 won't do it.  Similarly
various other programs that don't have constant memory requirements, but
linear (or worse) with the size of the input.

	Jakub

[Gregory Maxwell]

On Wed, May 16, 2012 at 10:41 AM, Jakub Jelinek <jakub(a)redhat.com&gt; wrote:
>  And, for various programs you usually don't need 64-bit address
> space,
>  but in the case where you have say bigger input you are simply out of luck
>  if you are limited to 32-bit address space.  Say with compilers/linkers,
>  you can usually compile smaller stuff just fine with 32-bit compiler, but
>  if you have some larger source code, x32 won't do it.  Similarly
>  various other programs that don't have constant memory requirements, but
>  linear (or worse) with the size of the input. 
It's for this reason (and the multilib memory bloat) that I was really
disappointed to see x32 created.

32bit of an addressable space is a real limitation on modern machines—
and completely reasonable software which is linear in input size is
simply less useful on 32 bit machines.

If it ever comes up that Fedora wants to further limit the usability
of the i686 with older machines (e.g. by adding a SSE2 requirement),
then perhaps it would be instead better to replace i686 with x32...
but otherwise I think it would be really unfortunate to end up
subjecting fedora users to the 32bit vm limits who otherwise might not
be.

[Bill Nottingham]

Gregory Maxwell (gmaxwell(a)gmail.com) said: 
>  It's for this reason (and the multilib memory bloat) that I was
> really
>  disappointed to see x32 created.
>  
>  32bit of an addressable space is a real limitation on modern machines—
>  and completely reasonable software which is linear in input size is
>  simply less useful on 32 bit machines.
>  
>  If it ever comes up that Fedora wants to further limit the usability
>  of the i686 with older machines (e.g. by adding a SSE2 requirement),
>  then perhaps it would be instead better to replace i686 with x32...
>  but otherwise I think it would be really unfortunate to end up
>  subjecting fedora users to the 32bit vm limits who otherwise might not
>  be. 
Plus, there's the minor "incompatible with every single existing piece of
i686/x86_32 software that exists in the wild." While Fedora isn't directly
targeting the existence of third-party or local software, a new 32-bit
option that breaks it all isn't the most polite. It's why it would be much
more useful for something like spinning up a new embedded target rather than
switching an existing userbase.

Bill

[Richard W.M. Jones]

On Wed, May 16, 2012 at 04:41:06PM +0200, Jakub Jelinek wrote:
>  On Wed, May 16, 2012 at 04:28:31PM +0200, Lennart Poettering wrote:
>  > Mhmm, so I was under the impression that x32 was mostly about increasing
>  > the scalability of virtualized systems. i.e. run a higher number of
>  > x32 containers/VM on an x86_64 host. Most server software that is run in
>  > containers/VMs does not require 64bit address space, and hence using x32
>  > for them should be quite benificial so that you can run more
>  > containers/VMs per host. After all this would reduce memory and CPU
>  > consumption of each, and due to smaller memory usage also result in less
>  > IO?
>  
>  Note that x32 is less secure than x86-64, the possible address space
>  randomization is much more limited there, while there is ASCII armor, it
>  can protect just a couple of libraries, unlikely all of them.  With LP64
>  certain kinds of exploits are harder.
>  
>  And, for various programs you usually don't need 64-bit address space,
>  but in the case where you have say bigger input you are simply out of luck
>  if you are limited to 32-bit address space.  Say with compilers/linkers,
>  you can usually compile smaller stuff just fine with 32-bit compiler, but
>  if you have some larger source code, x32 won't do it.  Similarly
>  various other programs that don't have constant memory requirements, but
>  linear (or worse) with the size of the input. 
Also functional language runtimes tend to benefit from 64 bit, since
it gives more room to use tag bits and GC coloring bits.  The OCaml
runtime gets a major benefit here.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

[Kevin Kofler]

Neal Becker wrote:
>  http://www.phoronix.com/scan.php?page=news_item&px=MTEwMTk
>  
>  Has this been discussed on fedora?  
Yes:
http://lists.fedoraproject.org/pipermail/devel/2011-January/148092.html
The answer was "no".

        Kevin Kofler