Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, Dec 16, 2009 at 12:30:11AM +, Paul Jakma wrote: On Tue, 15 Dec 2009, Matthew Garrett wrote: And the remaining 0.1% of the work is probably the other 99.9% of the time. I think you massively underestimate the number of corner cases present in an utterly untested configuration. My data-point is that I ran an x86-64 kernel on i386 F10 for a few months until I got tired of yum not being able to update kernel packages. The kernel side apparently works fine AFAICT. The .1% is yum. It works for me is a poor standard of support. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, 16 Dec 2009, Matthew Garrett wrote: On Wed, Dec 16, 2009 at 12:30:11AM +, Paul Jakma wrote: On Tue, 15 Dec 2009, Matthew Garrett wrote: And the remaining 0.1% of the work is probably the other 99.9% of the time. I think you massively underestimate the number of corner cases present in an utterly untested configuration. My data-point is that I ran an x86-64 kernel on i386 F10 for a few months until I got tired of yum not being able to update kernel packages. The kernel side apparently works fine AFAICT. The .1% is yum. It works for me is a poor standard of support. and if running an x86_64 kernel on an i386 install is something we want to do then we can make some changes to make that work. But complaining that yum doesn't work for something it was never designed to work for is a bit silly. -sv My this camel is not a very fast swimmer. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
It works for me is a poor standard of support. There must be something transmogrifying my emails before it reaches other subscribers of this list, either that or I am being unreasonable in thinking He is just pointing out that there is lot more work to do than you think. In other words he is contesting your claim that The kernel side apparently works fine AFAICT. Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, Dec 16, 2009 at 06:29:17PM +, Paul Jakma wrote: On Wed, 16 Dec 2009, Matthew Garrett wrote: It works for me is a poor standard of support. There must be something transmogrifying my emails before it reaches other subscribers of this list, either that or I am being unreasonable in thinking that by asking /if/ Fedora would consider *supporting* this configuration (i.e. in the future) that it would be clear that: - I am not complaining about software not working quite right now The problem here is that you appear to be massively underestimating the amount of work that would be required to actually support this configuration. We'd need to audit every ioctl entry point, every file in proc and every sysfs attribute. We'd need to port every application that uses vm86 over to using x86emu. We'd need to add, test and support a 32-to-64 bit cross building toolchain. yum would need some amount of work that Seth has implied is significant. That's a lot of work for marginal benefits, and nobody seems interested in stepping up to do that work. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Chris Adams wrote: Have you actually shown any concrete benefits, or has it all just been hand-waving? Well, the benefits were already known from the introduction of 64bit systems in the mid 90s. E.g. a rule of thumb with AXP systems was that they required at least 30% odd more RAM, compared to other Unix systems (either 32bit, or 32-userspace/64kernel systems - which is what most of the other Unix RISC vendors went with when they went to 64bit CPUs). E.g., a fresh F12 install: 32bit free -m: used +/- buffers/cache at gdm: 71 logged into desktop: 123 +firefox:183 +OO writer: 203 64bit: at gdm: 113 logged in: 159 Unfortunately, I couldn't get the 64bit one past logged in and even then I couldn't get it to display a useful desktop (good bit of GNOME stuff was running, but nothing shown), so it's probably under-representative. That shows a 59% increase for at GDM, and at least a 29% increase for logged into desktop. However, to be fair, that's probably /over/-representing the difference, as I didn't do much with any applications. Pure data, like the contents of webpages, your email, etc.. doesn't contain arch-dependent variable width data like pointers. That said, attendent meta-data (e.g. mail indices, data structures for the layout of your rendered webpage, etc..) may have arch-dependent variable-width data. So I'd expect that that 60% figure would go down a bit if you really used the system. I would expect a memory increase, due to 64bit, of somewhere between 30 and 60%, depending on system - or a saving of between 23 to 38%. I can't do this test as running F12 x86-64 under Qemu is just too damn slow, even if did finish login successfully. If someone wants to replicate the above with KVM on x86_64: 1. Install F12 2. After the first boot, reboot again, to eliminate the run of 'firstboot' 3a. login via ssh 3b. login via GDM 4. start firefox 5. switch to the 2nd desktop 6. start oowriter Use the SSH session to note the memory usage with 'free -m' after steps 3b, 4 and 6. You may need to run the command a few times to wait for the usage to stabilise (it probably will spike and decrease again). For certain workloads, e.g. servers dealing in large numbers of instances of small amounts of data, 60% extra could be quite normal (or even low). It was in optimising memory usage for a BGP implementation where I personally noticed just how much bloody space those 64bit pointers can take up. ;) If somebody shows real benefits (with real data to back it up), and is willing to put forth the effort to make it work, it might be interesting. All I'm saying is that it would be nice if: a) an x86_64 kernel was made a supported option for a 32bit Fedora (it pretty much works already) - i.e. its an additional kernel. b) yum grokked out of the box how to upgrade such systems (at the moment you have to tweak some file to make it think it's a 32bit system, and then kernel updates have to be done manually) I'm saying there is at least one very reasonable and rational reason for 32-on-64. I personally think the model used by many Unixes from the 90s makes a lot of sense - 32bit userpace by default, 64bit kernel, 64bit for a select few applications that actually need the benefits of x86_64 (memory/bit more performance), but hey.. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: If you can't learn to do it well, learn to enjoy doing it badly. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
I personally think the model used by many Unixes from the 90s makes a lot of sense - 32bit userpace by default, 64bit kernel, 64bit for a select few applications that actually need the benefits of x86_64 (memory/bit more performance), but hey.. Assuming this was the case and somebody decided to install (say) a 64 bit Epiphany then she will end up with two copies of the entire GNOME stack. That will come with its own storage and network costs, among other things. Running the 64-bit Epiphany will cause two copies of shared libraries to be kept in memory. Is this really worth it? Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Le mardi 15 décembre 2009 à 16:54 +, Paul Jakma a écrit : I personally think the model used by many Unixes from the 90s makes a lot of sense - 32bit userpace by default, 64bit kernel, 64bit for a select few applications that actually need the benefits of x86_64 (memory/bit more performance), but hey.. Apples and oranges. 64bit on other arches only changes memory accesses, x86_64 changes a lot more than just that, and the other changes in x86_64 trump the memory costs. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, 2009-12-15 at 16:54 +, Paul Jakma wrote: On Mon, 14 Dec 2009, Chris Adams wrote: Have you actually shown any concrete benefits, or has it all just been hand-waving? Well, the benefits were already known from the introduction of 64bit systems in the mid 90s. E.g. a rule of thumb with AXP systems was that they required at least 30% odd more RAM, compared to other Unix systems (either 32bit, or 32-userspace/64kernel systems - which is what most of the other Unix RISC vendors went with when they went to 64bit CPUs). But again, Apples to Oranges. x86_64 (we should formally call it Intel 64, or similar, since I'm not aware of x86_64 having a formal blessing) doesn't have the fixed instruction width that you get on most RISC ISAs. Not that any of it matters when we're already creeping up the minimum memory requirements over time and not so interested in older hardware anyway (e.g. recent i586/i686 changes). I know not everyone is living in the US, but here at least someone drew my attention to a ludicrously cheap laptop on sale last weekend that also had 3GB of RAM installed. I think we should treat it like migrating to i686 and once everyone has a 64-bit capable (x86) CPU just plan to do a gradual migration over. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Jon Masters j...@redhat.com said: But again, Apples to Oranges. x86_64 (we should formally call it Intel 64, or similar, since I'm not aware of x86_64 having a formal blessing) Intel 64 has no formal blessing either (it is Intel's marketing name for their copy of AMD's instruction set). If you want to call it after a vendor, it should be AMD 64 anyway, since AMD created it. They called it x86-64 (which is where the x86_64 name came from), until marketing got in the way and they changed to AMD 64. Intel 64 is confusing anyway, since Intel has pushed multiple 64 bit architectures. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, Dec 15, 2009 at 9:24 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Jon Masters j...@redhat.com said: But again, Apples to Oranges. x86_64 (we should formally call it Intel 64, or similar, since I'm not aware of x86_64 having a formal blessing) Intel 64 has no formal blessing either (it is Intel's marketing name for their copy of AMD's instruction set). If you want to call it after a vendor, it should be AMD 64 anyway, since AMD created it. They called it x86-64 (which is where the x86_64 name came from), until marketing got in the way and they changed to AMD 64. Intel 64 is confusing anyway, since Intel has pushed multiple 64 bit architectures. Also there is the x64 marketing bullshit floating around -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, 15 Dec 2009, Jon Masters wrote: But again, Apples to Oranges. x86_64 (we should formally call it Intel 64, or similar, since I'm not aware of x86_64 having a formal blessing) doesn't have the fixed instruction width that you get on most RISC ISAs. It's not about the instruction set. If you look back at the posts, from myself and the poster who gave a toy test case, the extra memory usage is from data, not from programme text. Programme text is not too significant in size when compared to data (about a 10:1 data:text ratio for cases I've looked at). So the instructions being compact is simply not very relevant - pointers and longs in *data* double up in size on 64bit. (This transcends specific ISAs..). the US, but here at least someone drew my attention to a ludicrously cheap laptop on sale last weekend that also had 3GB of RAM installed. Right. I.e. a 64bit *kernel* is very useful (and much faster than a PAE one). That's precisely what I am arguing for. Again, there is a difference between aggregate usage (e.g. of RAM) and per-process memory requirements, similarly for performance. I.e. in the aggregate, a system can make good use of *both* 32 and 64 bit. I.e.: - In the aggregate, systems now need to make efficient use of 3GB of memory - PAE (slow, other problems) - 64bit - more and more systems have this, it'd be nice to be able to use this with a 32bit install. - On a per-process basis, few processes need 64bit pointers - those which do, can easily be 64bit on a 32/64 system. - those which can be 32bit can avoid a circa 30 to 60% memory overhead - On a per-process basis, few processes need the advantages of x86-64 - I am incredulous at the people who keep arguing that x86-64 is better because it has PC-relative addressing, or because the ABI is pass-by-register by default. I am extremely sceptical that these respondents would be able to distinguish between a 32bit and a 64bit cp or nautilus or ls or gnome-panel or ... etc. It'd be interesting to see if this applied even to browsers. (E.g. Chrome on 32bit is extremely fast, hard to see that it'd get much faster on 64. Firefox is slow on 64bit too). - those processes which do, can be 64bit I would like to have the advantages of *both* 32 and 64bit, as and where each one is appropriate. I'd like to be able to use that 30-60% of memory on more VMs, e.g., rather than bigger gnome-*, etc. processes. A lot of respondents have argued as if this is a binary matter, approaching the debate as if it's an either-or choice between 32 OR 64, which was not my intention at all. And again, far from being some incredibly difficult thing that I'm asking for, the support is pretty much 99.9% there.. Anyway :) Sorry for extending this thread, but it seemed I miscommunicated in previous emails and failed to get the basic points across properly. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Seeing is believing. You wouldn't have seen it if you hadn't believed it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, Dec 15, 2009 at 09:28:10PM +, Paul Jakma wrote: And again, far from being some incredibly difficult thing that I'm asking for, the support is pretty much 99.9% there.. And the remaining 0.1% of the work is probably the other 99.9% of the time. I think you massively underestimate the number of corner cases present in an utterly untested configuration. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, Dec 15, 2009 at 10:28 PM, Paul Jakma p...@dishone.st wrote: - I am incredulous at the people who keep arguing that x86-64 is better because it has PC-relative addressing, or because the ABI is pass-by-register by default. I am extremely sceptical that these respondents would be able to distinguish between a 32bit and a 64bit cp or nautilus or ls or gnome-panel or ... etc. It'd be interesting to see if this applied even to browsers. (E.g. Chrome on 32bit is extremely fast, hard to see that it'd get much faster on 64. Firefox is slow on 64bit too). Well while there was no x86_64 chromium build midori (which uses webkit) was faster in every JS while the whole web was praising google's V8 as the fastest JS engine ... Once the 64bit chromium come out, this was indeed the case. So a software that is supposed to be slower than another one was faster only because it was running an x86_64 version. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, 15 Dec 2009, Paul Jakma wrote: I would like to have the advantages of *both* 32 and 64bit, as and where each one is appropriate. I'd like to be able to use that 30-60% of memory on more VMs, e.g., rather than bigger gnome-*, etc. processes. Ah, and to get the memory benefits, you need a generally-32bit userspace (32bit apps on x86-64 obviously works just fine, but there's no savings benefit when most of userspace is 64bit). Sorry again for the noise. :) regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Your own qualities will help prevent your advancement in the world. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, Dec 15, 2009 at 10:54 PM, Paul Jakma p...@dishone.st wrote: On Tue, 15 Dec 2009, Paul Jakma wrote: I would like to have the advantages of *both* 32 and 64bit, as and where each one is appropriate. I'd like to be able to use that 30-60% of memory on more VMs, e.g., rather than bigger gnome-*, etc. processes. Ah, and to get the memory benefits, you need a generally-32bit userspace (32bit apps on x86-64 obviously works just fine, but there's no savings benefit when most of userspace is 64bit). Sorry again for the noise. :) There are shops that sells stuff called ram sticks ;) (sorry I will shut up already) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Tue, 15 Dec 2009, Matthew Garrett wrote: And the remaining 0.1% of the work is probably the other 99.9% of the time. I think you massively underestimate the number of corner cases present in an utterly untested configuration. My data-point is that I ran an x86-64 kernel on i386 F10 for a few months until I got tired of yum not being able to update kernel packages. The kernel side apparently works fine AFAICT. The .1% is yum. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Lots of folks confuse bad management with destiny. -- Frank Hubbard -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Wed, 16 Dec 2009, Paul Jakma wrote: My data-point is that I ran an x86-64 kernel on i386 F10 for a few months until I got tired of yum not being able to update kernel packages. The kernel side apparently works fine AFAICT. The .1% is yum. Oh, I don't quite remember the details, but I think libvirt also gets a bit confused when its 32bit and the kernel is 64. Another data-point is that I've used and developed on other 32/64 x86-64 systems for a number of years and those manage it just fine. It really shouldn't be hard, if you decide its worth supporting. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Life is like an onion: you peel off layer after layer and then you find there is nothing in it. -- James Huneker -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Paul Jakma p...@dishone.st said: My data-point is that I ran an x86-64 kernel on i386 F10 for a few months until I got tired of yum not being able to update kernel packages. The kernel side apparently works fine AFAICT. The .1% is yum. No, it's the whole development environment. For example, if you need to build a kernel module, gcc on i386 is not capable of building for x86_64 (IIRC it isn't a gcc configuration issue, it is an issue with gcc itself). You could just always install the x86_64 gcc, but then you need all the development tools and libraries to match. gcc hello.c is going to generate native code, and native will still be x86_64, so you have to have the x86_64 shared libraries and support in place (and now you're back to a multilib system, which loses on RAM usage, disk space, install time, update downloads, etc.). Also, part of your justification was that in the real world, people run some 32 bit anyway (like wine). Well, what happens with some of those real world binary modules people use, like nVidia? Do they work with a split 32/64 user/kernel space (and development stack somewhere in between)? If they don't, users are going to blame Fedora, not nVidia (or whoever else ships binary modules). Again, most of the Fedora people developing things like yum, anaconda, etc. don't appear to be interested in this; there just doesn't seem to be a significant benefit (okay, you save a little RAM, but for the majority of 64 bit systems, that isn't a big deal). If you think otherwise, nobody is stopping you from doing the work to make it happen, and if it proves to work and be a benefit, I bet it would be accepted. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Ralf Ertzinger wrote: It does. There may not be a yum repo for it, but the last update was some days ago to 10.0 r42, similar to the 32 bit version. There is an unofficial yum repo for 64-bit flash-plugin: http://forums.fedoraforum.org/showthread.php?t=205642 signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Le Dim 13 décembre 2009 22:35, Chris Adams a écrit : As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it much in the real world. The worst case I've seen reported is when the RAM overhead managed to annihilate register improvements (worst case in a very specific load). So RAM overhead is pretty much a urban myth on x86_64 -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
That's assuming that the footprint of libraries relative to distinct applications is large enough to cancel out the space savings. (I have no data either way). A 64bit kernel doesn't need any 32bit userspace. An X server, on my 32bit system has about 8.5MB of programme text (server and libs) and loads about another 1.5MB worth of modules itself, i.e. 10MB. Regarding shared libraries its worth noting the point about Instruction pointer relative data access: http://en.wikipedia.org/wiki/X86-64#Architectural_features Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On 12/14/2009 10:27 AM, Nicolas Mailhot wrote:
Le Dim 13 décembre 2009 22:35, Chris Adams a écrit :
As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it
much in the real world.
The worst case I've seen reported is when the RAM overhead managed to
annihilate register improvements (worst case in a very specific load). So RAM
overhead is pretty much a urban myth on x86_64
It's not an urban myth - Conversely, it can quite easily be proven:
int main()
{
long i;
void *array[100];
for ( i = 0; i 100; i++ ) {
array[i] = (void*) i;
};
while(1) {};
}
Compile this snippet for -m64/-m32:
# gcc -m64 -o test-64 -Wall test.c
# gcc -m32 -o test-32 -Wall test.c
Then run them and watch memory consumption (here top):
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
5909 corsepiu 20 0 11536 8128 248 R 100.0 0.4 0:16.93 test-64
5903 corsepiu 20 0 5560 4180 224 R 99.0 0.2 1:10.20 test-32
QED
Of course, this is an extreme case, but they also aren't that rare in
real world cases.
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Ralf Corsepius wrote: Of course, this is an extreme case, It isn't that extreme - pointers can make up a significant component of data-structures. E.g. any programme that has to store many instances of small amounts of data, the pointer size can have a big impact on memory usage. If the data is heavily inter-linked, even more so. Whether that's the case for most applications, I do not know however. It would though be interesting for someone to go measure this, especially in the aggregate. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: If this is timesharing, give me my share right now. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Le Lun 14 décembre 2009 12:51, Ralf Corsepius a écrit : Of course, this is an extreme case, but they also aren't that rare in real world cases. They aren't that rare on very specific workloads (numeric computation). People in those fields often have large datasets that appreciate lots of memory (ours work with GiB-sized datasets at least) -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Debarshi Ray wrote: Regarding shared libraries its worth noting the point about Instruction pointer relative data access: http://en.wikipedia.org/wiki/X86-64#Architectural_features You're missing the point. If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. The point is that few applications need to be 64bit (this may change in time, when email and browser apps start to demand 4GB+, but that time is a while away - per-process memory demands should stay flat for a while if browsers and the like switch from single-process/multi-threaded to a multi-processes model). For the few apps where it makes a difference, sure, run them as 64bit. (Also, please assume in any replies that I have a modicum of clue about the low-level technical details between i386 and x86_64). regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: magnetic interferance from money/credit cards -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Paul Jakma p...@dishone.st said: If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. Then you might as well run the native system architecture, which is 64 bit, rather than try to figure out which apps run better as 32 bit and maintain a full duplicate set of libraries! :-) -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, Dec 14, 2009 at 7:33 AM, Paul Jakma p...@dishone.st wrote: If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. Yet I could tell from the applications where performance is important. You reject my metric, I reject yours. Something of an impasse. [snip] time, when email and browser apps start to demand 4GB+, but that time is a while away I enjoyed how in nearly one breath you claim that performance is usually irrelevant then go on to name an application where performance is quite visible: A considerable amount of page load time is browser rendering. (It's also not too hard to make firefox use more than 3GB of virtual address space, though I admit you do need to work at it a little) What was the point of this conversation again? People have demonstrated on this list, with benchmarks, that x86_64 makes a material performance improvement across a broad swath of applications where performance matters. You point out that users don't care about performance in many cases. I do not disagree but I have no clue how we can qualify or quantify that. Certainly, when some website posts benchmarks of Fedora vs other distribution those threads get a lot of discussion but that isn't really evidence. I also do not know how it is relevant, in context of x86_64, to Fedora as the use of x86_64 is effectively free. The costs, such as reduced compatibility with binary browser plugins, are simply not relevant to many people. You're obviously convinced of your opinion, other people hold the view that good performance is part of the distribution's core job. Other than the point that x86_64 also increases security (from greatly increased address space layout randomization, and reduced PIE cost), I think we've hit on every point for and against using x86_64 in this thread— yet I think not a single person has changed their initial view. I don't see how any resolution is going to come from further discussion. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On 12/14/2009 01:56 AM, Jon Masters wrote: On Sun, 2009-12-13 at 16:19 -0600, Chris Adams wrote: Once upon a time, Jon Mastersjonat...@jonmasters.org said: Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very different beast. Intel fixed a lot of the issues with the (more than 20 year old really x86 ISA) That would be AMD that fixed it, not Intel. Intel tried to push everybody to a new architecture (Itanium), while AMD revised and extended i386 to 64 bits. After Itanium failed to catch on in the marketplace, Intel had to copy AMD's work. That's presumptuous and unfair. Sure, without AMD and others we'd likely be on Itanium (which I actually quite like as an architecture) but Intel 64 isn't just some copy-and-paste effort either. I thought Intel adopted AMD 64-bit extensions pretty much wholesale. No shame in that---they were well-designed and well engineered. We the CPU consumers should be thankful for how well this was executed by both Intel and AMD. Kudos to Intel for acting in the best interest of their customers especially since they had so much invested in Itanium, both financially and in term of company pride. While Itanium (aka Itanic :) was well-intentioned and looked good on paper, Intel/HP run into practical problems with the extent to which VLIW can be exploited by compilers, and with the hardware implementations, so that the actual performance is underwhelming. The Itanium siren song contributed to demise of SGI and wobbliness of HP so let's not be too nostalgic about it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Gregory Maxwell wrote: Yet I could tell from the applications where performance is important. You reject my metric, I reject yours. Something of an impasse. I'm not rejecting the performance metric at all. (It's also not too hard to make firefox use more than 3GB of virtual address space, though I admit you do need to work at it a little) Only because it's obsolete. Multi-process browsers use a lot less RAM per process. What was the point of this conversation again? For those who can't sort by thread in their MUA: To ask that 32-userspace-on-64 be supported (it pretty much all works, except for yum updating certain things, like the kernel), as there are definite benefits to a 32-by-default userspace. Some people chose to argue But you should just run 64bit completely, despite people already having described one reason to 32bit (memory usage). And from that we somehow got into a x86_64 versus x86 thread of doom, with (IMHO) much missing of the general point. Anyway, enough. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Where do you go to get anorexia? -- Shelley Winters -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 2009-12-14 at 12:33 +, Paul Jakma wrote: You're missing the point. If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. That's a silly argument, because it simply relies on the fact that most uses of computers aren't CPU-bound at all. In the same way I could probably steal half the RAM from your system and clock the CPU down 50% (the BOFH's favourite revenue-generating technique!) and from 'the interactive performance of common applications' you wouldn't be able to tell the difference. I don't think that _means_ very much, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, 14 Dec 2009, Adam Williamson wrote: On Mon, 2009-12-14 at 12:33 +, Paul Jakma wrote: You're missing the point. If I put you in front of 2 identical machines, one running 32bit and one 64bit software, would you be able to tell which one was which, from the interactive performance of common applications? I'd be willing to bet that for the vast majority of applications you wouldn't be. That's a silly argument, because it simply relies on the fact that most uses of computers aren't CPU-bound at all. In the same way I could probably steal half the RAM from your system and clock the CPU down 50% (the BOFH's favourite revenue-generating technique!) and from 'the interactive performance of common applications' you wouldn't be able to tell the difference. I don't think that _means_ very much, though. It's quite meaningful, e.g. for power conservation. As you no doubt are aware of, modern system regularly clock down the CPU. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: It occurred to me lately that nothing has occurred to me lately. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, Dec 14, 2009 at 05:18:47PM +, Paul Jakma wrote: For those who can't sort by thread in their MUA: To ask that 32-userspace-on-64 be supported (it pretty much all works, except for yum updating certain things, like the kernel), as there are definite benefits to a 32-by-default userspace. There's little testing effort done on this. People still occasionally trip over bugs in the ioctl conversion code in the kernel, and there's a couple of other cases where exported ABI doesn't get converted correctly. Now, while it's undeniable that these are bugs that should be fixed, it's also pretty difficult to justify adding a third x86 variant to our list of supported configurations, especially when it's known to be more problematic than the other two that already satisfy almost everybody's needs. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, Dec 13, 2009 at 7:33 PM, Paul Jakma p...@dishone.st wrote: On Wed, 18 Nov 2009, Jeff Garzik wrote: Running a 64-bit kernel with a 32-bit userland is a common practice on non-x86 platforms, and non-Linux OS's. FWIW, it works on Linux too. I ran F10 i386 on a x86_64 kernel for a while. About the only thing that doesn't work right is yum wrt kernel updates. For a lot of tasks, you simply do not need 64-bit pointers and a 64-bit process address space. Both executable code and in-memory data structures tend to be smaller on 32-bit. Indeed. It would be nice if i386-userspace/x64-kernel were officially support.. such a setup does not make much sense, when your hardware supports x86_64 not using it for userspace is a waste -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Paul Jakma p...@dishone.st writes: On Wed, 18 Nov 2009, Roland McGrath wrote: x86 is unlike other architectures because 64-bit also has twice as many registers as 32-bit. So you get to trade off the benefits of register allocation across more registers against the memory/cache footprint of 64-bit pointers. For what percentage of code is that an appreciable advantage? Pretty much everything, actually. The x86 ISA completely sucks. regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, 13 Dec 2009, drago01 wrote: such a setup does not make much sense, when your hardware supports x86_64 not using it for userspace is a waste a) i386 has a lower memory footprint, as has been mentioned in this thread. b) The amount of code on your system that is CPU bound and/or memory-bound due to register pressure, to an extent that the x64 registers would make an appreciable difference is probably not that significant - kernel hotpots - graphics hotspots (X server perhaps) I havn't measured this, but nor have the people who say x86_64 is faster AFAICT, and there's plenty of experience to say that most software is far from CPU bound or memory bound. c) There is a definite cost to a distro in having to maintain 2 x86_64 and i386 as separate arches - QA - package building and distribution Every supported arch increases the size of the test matrix. Minimising the number of arches you have to, say, test a cp bugfix against helps reduce QA load and helps you get better software to your users, faster (better cause you release time spent on architecture QA that can be spent on improving software generally). d) Like or not, i386 is the de-facto standard for binary interfaces: - Netscape plugins - Windows executables The retort no doubt will Oh but this is Fedora, we don't care about any closed-source stuff, but that would miss the point entirely re *Interface*. The i386 machine can be a plugin interface between 2 different open-source systems, e.g. consider: - VM images to run in, say, QEMU/KVM - Sandboxing technologies for, say, browser plugins (I think Google have stuff in this area) - Free software windows-only apps (don't know if they exist) All the code here can be open-source/free-software and still be relying on i386 as a widely known and hence convenient /interface/. As such, it likely needs to be supported on x86_64 kernel-based systems anyway, as performantly as possible. (And yeah, I gather KVM x86_64 doesn't work for i386 VMs - annoying). So personally I think x86_64-pure is unrealistic and, independently, I think 32-on-64 makes sense, but hey. :) regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: He who despises himself nevertheless esteems himself as a self-despiser. -- Friedrich Nietzsche -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, 13 Dec 2009, Paul Jakma wrote: b) The amount of code on your system that is CPU bound and/or memory-bound due to register pressure, to an extent that the x64 faster AFAICT, and there's plenty of experience to say that most software is far from CPU bound or memory bound. Oops, this is unclear - memory bound here in these 2 cases refers to memory-I/O, not amount of memory. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Plus ,ca change, plus c'est la m^eme chose. [The more things change, the more they remain the same.] -- Alphonse Karr, Les Gu^epes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, Dec 13, 2009 at 8:16 PM, Paul Jakma p...@dishone.st wrote: On Sun, 13 Dec 2009, drago01 wrote: such a setup does not make much sense, when your hardware supports x86_64 not using it for userspace is a waste a) i386 has a lower memory footprint, as has been mentioned in this thread. Yes which is pretty much the only valid complaint but trading memory for performance is a price I am willing to take ... b) The amount of code on your system that is CPU bound and/or memory-bound due to register pressure, to an extent that the x64 registers would make an appreciable difference is probably not that significant - kernel hotpots The kernel doesn't do any have computing... - graphics hotspots (X server perhaps) I havn't measured this, but nor have the people who say x86_64 is faster AFAICT, and there's plenty of experience to say that most software is far from CPU bound or memory bound. Yes but the stuff adds up, you gain almost nothing by running i686 code but where it matters x86_64 can make a HUGE difference. c) There is a definite cost to a distro in having to maintain 2 x86_64 and i386 as separate arches Not a reason to move forward with hardware development. d) Like or not, i386 is the de-facto standard for binary interfaces: - Netscape plugins This is slowly being fixed. - Windows executables Nobody stops you from running i386 apps on a x86_64 system. - VM images to run in, say, QEMU/KVM - Sandboxing technologies for, say, browser plugins (I think Google have stuff in this area) - Free software windows-only apps (don't know if they exist) All the code here can be open-source/free-software and still be relying on i386 as a widely known and hence convenient /interface/. As such, it likely needs to be supported on x86_64 kernel-based systems anyway, as performantly as possible. (And yeah, I gather KVM x86_64 doesn't work for i386 VMs - annoying). Er.. don't quite get your point here, what is stopping me from running i686 VMs on a x86_64 host? I have been doing this for a while and there are there problems (you don't even need multilib for that) So personally I think x86_64-pure is unrealistic and, independently, I think 32-on-64 makes sense, but hey. :) I did not suggest using pure x86_64 but using x86_64 where we can (ie. not just the kernel). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, Dec 13, 2009 at 9:09 PM, drago01 drag...@gmail.com wrote: c) There is a definite cost to a distro in having to maintain 2 x86_64 and i386 as separate arches Not a reason to move forward with hardware development. reason to _not_ move ... Er.. don't quite get your point here, what is stopping me from running i686 VMs on a x86_64 host? I have been doing this for a while and there are there problems (you don't even need multilib for that) should read _zero_ problems. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Paul Jakma p...@dishone.st said: b) The amount of code on your system that is CPU bound and/or memory-bound due to register pressure, to an extent that the x64 registers would make an appreciable difference is probably not that significant - kernel hotpots - graphics hotspots (X server perhaps) I havn't measured this, but nor have the people who say x86_64 is faster AFAICT, and there's plenty of experience to say that most software is far from CPU bound or memory bound. As soon as you bring in even one 64 bit user-space program that is run much, you've pulled in at least glibc and friends. At that point, you might as well run all (or as close to all as possible) 64 bit user-space, because the libraries are shared (code will be in the cache, etc.). The only time my systems have run 32 bit code in several years is for the Flash plugin (since the open-source plugins don't seem to be able to keep up and since the 64 bit Adobe plugin doesn't seem to get the security updates) and sometimes the Acrobat Reader plugin (since I've run into websites that assume they can embed PDFs in the page and AFAIK there's no plugin for Evince). Since both cases are not all that common in my every-day use, I don't hit the 32 bit libraries and such very often. Running a single-arch and single-lib system is more efficient. As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it much in the real world. I have one 32 bit desktop at work, and comparing the resident RAM usage between it and a 64 bit desktop, I don't see much difference in the common desktop programs. I know that for some reason PHP on 64 bit arches bloats up significantly (at least older versions), but that's the only major difference I've seen. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, 2009-12-13 at 13:53 -0500, Tom Lane wrote: Paul Jakma p...@dishone.st writes: On Wed, 18 Nov 2009, Roland McGrath wrote: x86 is unlike other architectures because 64-bit also has twice as many registers as 32-bit. So you get to trade off the benefits of register allocation across more registers against the memory/cache footprint of 64-bit pointers. For what percentage of code is that an appreciable advantage? Pretty much everything, actually. The x86 ISA completely sucks. Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very different beast. Intel fixed a lot of the issues with the (more than 20 year old really x86 ISA) and it's not simply a doubling of memory footprint because variable width instructions are used in the first place, and continue to be used in the newer ISA upgrade. Personally, I think anyone running i386 on x86_64 who isn't doing some kind of testing under KVM or similar is completely wasting their computing resources and should receive a free copy of the Intel documentation for the holidays ;) Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Jon Masters jonat...@jonmasters.org said: Indeed. Paul, take a look at the Intel 64 ISA and you'll see it's a very different beast. Intel fixed a lot of the issues with the (more than 20 year old really x86 ISA) That would be AMD that fixed it, not Intel. Intel tried to push everybody to a new architecture (Itanium), while AMD revised and extended i386 to 64 bits. After Itanium failed to catch on in the marketplace, Intel had to copy AMD's work. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, 13 Dec 2009, Chris Adams wrote: As soon as you bring in even one 64 bit user-space program that is run much, you've pulled in at least glibc and friends. At that point, you might as well run all (or as close to all as possible) 64 bit user-space, because the libraries are shared (code will be in the cache, etc.). That's assuming that the footprint of libraries relative to distinct applications is large enough to cancel out the space savings. (I have no data either way). A 64bit kernel doesn't need any 32bit userspace. An X server, on my 32bit system has about 8.5MB of programme text (server and libs) and loads about another 1.5MB worth of modules itself, i.e. 10MB. So if you ran a 32bit system with a 64bit kernel and X server, you'd lose out on about 10MB of shareable code. For comparison, my 32bit system has O(10) times that allocated to things like browsers and feed-readers. It's using 4.8GB in total (ex buffers/cache) apparently. Space for text (programmes, code) is simply insignificant these days, compared to the huge amounts of data which programmes allocate - data which sometimes includes a lot of pointers. You're also assuming that this cancels out the other benefits. The only time my systems have run 32 bit code in several years is for the Flash plugin (since the open-source plugins don't seem to be able to keep up and since the 64 bit Adobe plugin doesn't seem to get the security updates) and sometimes the Acrobat Reader plugin (since I've run into websites that assume they can embed PDFs in the page and AFAIK there's no plugin for Evince). It's interesting that both you and drago have almost always (to paraphrase) run 64bit pure systems. Surely that *reinforces* my point about the futility of 64bit pure systems as an achievable goal (in the aggregate across all reasonable uses of a distro), and i386 being a de-facto standard for software interfaces. As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it much in the real world. I have one 32 bit desktop at work, and comparing the resident RAM usage between it and a 64 bit desktop, I don't see much difference in the common desktop programs. That's the wrong comparison - compare the aggregate RAM usage, with each system in similar states. I know that for some reason PHP on 64 bit arches bloats up significantly (at least older versions), but that's the only major difference I've seen. Pointer rich data structures, likely.. Anyway, as I don't intend to contribute anything, I'll try stop making noise. Aside to the list: Thanks for all the hard-work on Fedora ;) regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Dogs just don't seem to be able to tell the difference between important people and the rest of us. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Sun, Dec 13, 2009 at 16:19:54 -0600, Chris Adams cmad...@hiwaay.net wrote: That would be AMD that fixed it, not Intel. Intel tried to push everybody to a new architecture (Itanium), while AMD revised and extended i386 to 64 bits. After Itanium failed to catch on in the marketplace, Intel had to copy AMD's work. I expect that has a lot to do with AMD being open source friendly. If they had had to rely on Microsoft to get an OS to run on their machine, they probably would have failed as well. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, Dec 14, 2009 at 00:20, Bruno Wolff III br...@wolff.to wrote: On Sun, Dec 13, 2009 at 16:19:54 -0600, Chris Adams cmad...@hiwaay.net wrote: That would be AMD that fixed it, not Intel. Intel tried to push everybody to a new architecture (Itanium), while AMD revised and extended i386 to 64 bits. After Itanium failed to catch on in the marketplace, Intel had to copy AMD's work. I expect that has a lot to do with AMD being open source friendly. If they had had to rely on Microsoft to get an OS to run on their machine, they probably would have failed as well. Actually i think the reason AMDs approach worked was because it was backward compatible with ix86 so instead of having to have an OS ready up front and people having to migrate wholesale customers could start upgrading to x86_64 processors slowly while still using 32bit OS. Then as 64bit OS becomes available people can use that whilst still enjoying their favorite apps that haven't yet been ported to 64bit. In short it was evolutionary rather than revolutionary. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On Mon, Dec 14, 2009 at 00:32:15 +, John5342 john5...@googlemail.com wrote: Actually i think the reason AMDs approach worked was because it was backward compatible with ix86 so instead of having to have an OS ready up front and people having to migrate wholesale customers could start upgrading to x86_64 processors slowly while still using 32bit OS. Then as 64bit OS becomes available people can use that whilst still enjoying their favorite apps that haven't yet been ported to 64bit. In short it was evolutionary rather than revolutionary. I think that was also needed. But I don't think they would have been able to get traction in the server market without having the prompt linux / gcc support. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Hi. On Sun, 13 Dec 2009 15:35:27 -0600, Chris Adams wrote: The only time my systems have run 32 bit code in several years is for the Flash plugin (since the open-source plugins don't seem to be able to keep up and since the 64 bit Adobe plugin doesn't seem to get the security updates) It does. There may not be a yum repo for it, but the last update was some days ago to 10.0 r42, similar to the 32 bit version. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Another data point for this thread: Running a 64-bit kernel with a 32-bit userland is a common practice on non-x86 platforms, and non-Linux OS's. For a lot of tasks, you simply do not need 64-bit pointers and a 64-bit process address space. Both executable code and in-memory data structures tend to be smaller on 32-bit. cp(1), for example, can be 32-bit as long as it supports O_LARGEFILE and off64_t. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Once upon a time, Jeff Garzik jgar...@pobox.com said: Running a 64-bit kernel with a 32-bit userland is a common practice on non-x86 platforms, and non-Linux OS's. For a lot of tasks, you simply do not need 64-bit pointers and a 64-bit process address space. Both executable code and in-memory data structures tend to be smaller on 32-bit. However, on x86, the 32-64 bit jump also gives a larger register set and (IIRC) SSE (or SSE2?) on all chips, which allows better code generation for all kinds of things. The i386 architecture is register-starved compared to many other architectures. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Another data point for this thread: x86 is unlike other architectures because 64-bit also has twice as many registers as 32-bit. So you get to trade off the benefits of register allocation across more registers against the memory/cache footprint of 64-bit pointers. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On 11/18/2009 09:56 PM, Roland McGrath wrote: Another data point for this thread: x86 is unlike other architectures because 64-bit also has twice as many registers as 32-bit. So you get to trade off the benefits of register allocation across more registers against the memory/cache footprint of 64-bit pointers. Absolutely. x86-64 is definitely one of my favorite ISAs. Worlds improvement from i386. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
