Re: Intel Core2Duo (T7400)
On Mon, Nov 12, 2007 at 11:51:49PM +0100, Gabor Gombas wrote: AFAIK SSE is also available in 32-bit mode so that is no reason why x86_64 should be faster. Available yes, but not default. You would have to recompile all libraries and applications that use floating point and tell them all to use sse math instead of x87 math. With 64bit that is the default and x87 is never used. So yes it is possible, but it is not trivial and has compatibility issues. Of course you also loose 80bit floats when you go to sse math and end up with only the standard 64bit (I don't think anything other than x87 ever had 80bit floats). Again this is a reason why new 32-bit processors are faster than old 32-bit processors, but not a reason why x86_64 mode should be faster than i386 mode on the same processor. I think the new instructions may be a big part. After all things that were added along the way on 32bit x86 chips couldn't be used by default in compilers since not all 32bit x86 cpus would have the instruction. By being a new demarcation point the 64bit cpus can say all those new instructions are mandetory and hence the compiler can always use them. There have been some useful stuff added over the years and while you always had the option of compiling code for only a certain level of CPU it was not the default. After all there have been linux distributions compiled so that they only run on 686 and higher CPUs at the loss of backwards compatibility, and they did claim in gave performance improvements. I don't have numbers so I can't really argue, but that is the largest visible difference between the two modes. I think the set of instructions that are required by the architecture is much more important. It would be interesting to compare what the performance is in 32bit mode between gcc compiling for 686 with sse and all that and gcc compiling for 64bit limited to the same register count. I have also seen things that say some operations are way faster in 64bit mode due to having new instructions to do them in much less time than you could with the 32bit instruction set (I think 64bit interger multiplication was one of the ones I read about, where in 32bit mode it takes twice as long as in 64bit mode since to 64bit mode it is a native operation while 32bit mode has to do two instructions to perform the same thing or something like that). So certainly new instructions can have helped a lot. You said Sparc/Solaris; I don't know the current top-of-line configs but several hundred gigabytes of memory should not present a problem for a really high-end Sun server and as you said most of the userspace is still 32-bit... Most of user space yes. They run 64bit capable kernel and a 32bit mainly userspace (to avoid the performance hit of pointer size increase and all that and since for the most part sparc doesn't gain any speed going to 64bit mode, it is just a change in memory model). The few programs that have a need for a larger memory space run in 64bit mode. The kernel of course must be 64-bit, but that's not a problem even if 64-bit mode is significanlty slower since applications do not spend too much time in the kernel (and if they do that's almost certainly a bug). Well I run a 64bit kernel with 32bit user space for x86, since I mainly use 32bit stuff (that's what I develop for in my job, since we use embedded x86 chips), but it means I can still run 64bit programs when I want to try something, and I have a chroot with all 64bit stuff in it to play with. But back to the original issue: x86_64 is _NOT_ faster because it is using 64-bit addressing - quite the contrary, that alone would have made it slower than 32-bit mode. But AMD also did a lot of other modifications that they _could_ have also enabled in 32-bit mode but they simply choose not to, because otherwise they could not have sold their 64-bit processors. Certainly you could have added any new instructions to 32bit mode, and you could have added the extra registers, and you could have declared sse the default floating point and eliminated mmx and all that, but you would essentially have had to declare a new operating mode so the OS and applications would know it was not the same as previous 32bit modes (the p3 did that when it added SSE as far as I recall, and I believe the pentium managed to avoid adding a new mode for MMX by reusing the floating point registers so that the OS didn't need to know about any new registers, but the application had to pick either MMX or floating point and couldn't do both easily). Given the state of the computing world, adding a new mode without adding 64bit address space at the same time would have made no sense, and being AMD it probably wouldn't have been seen as important enough to bother supporting if they hadn't gone all the way. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Thu, Nov 08, 2007 at 09:31:31AM -0500, Lennart Sorensen wrote: I don't consider it a real issue either, but it is still something. I am not sure why sparc tends to run 32bit for most programs and only 64bit for select cases where it helps. Certainly x86_64 seems to be better than i386 in just about all cases. Taking the same code, going from 32-bit to 64-bit will cause a slowdown, period. The only way to overcome that is if you can write better code in 64-bit mode than you could in 32-bit mode. There are apps that indeed benefit from directly accessing more than 2G of address space and therefore can use simpler algorithms in 64-bit mode, but they are rare (at least on desktop). AMD knew all this and they also knew they have to counter-balance the slowdown if they ever wanted 64-bit to became the norm, so they did a smart trick and doubled the register set size in 64-bit mode. Since i386 is a very register-starved architecture, that move indeed helped a lot by making it much easier for compilers to generate better code. So it's not only in 64-bit mode you can keep more variables in registers but also it is easier to write good compilers for 64-bit mode. AFAIK Sparc (and basycally any other 64-bit capable processor) offers the same number of registers in both 32-bit and 64-bit mode, so there is nothing that could balance the slowdown caused by going 64-bit. And even if they wanted to use the same trick as AMD it would not help as Sparc already has enough registers - adding more would give a much much smaller performance gain than it did for x86_64. I hope they come out with a way faster improved CPU before then. Hehe, they could introduce a new 32-bit mode that has the same number of registers as the 64-bit mode has. OTOH marketing people would have a really tough time to push down such a change on consumers' throats... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Mon, Nov 12, 2007 at 02:46:00PM +0100, Gabor Gombas wrote: Taking the same code, going from 32-bit to 64-bit will cause a slowdown, period. The only way to overcome that is if you can write better code in 64-bit mode than you could in 32-bit mode. There are apps that indeed benefit from directly accessing more than 2G of address space and therefore can use simpler algorithms in 64-bit mode, but they are rare (at least on desktop). AMD knew all this and they also knew they have to counter-balance the slowdown if they ever wanted 64-bit to became the norm, so they did a smart trick and doubled the register set size in 64-bit mode. Since i386 is a very register-starved architecture, that move indeed helped a lot by making it much easier for compilers to generate better code. So it's not only in 64-bit mode you can keep more variables in registers but also it is easier to write good compilers for 64-bit mode. They also deprecated MMX and x87 (hence reducing the old crap to carry around on centext switches), and switched to sse match (which is much faster and not stack based), and add some new instructions that can help code in general. That almost certainly is much more important than the register count. As far back as the Pentium Pro the pipeline's out of order execution had a large register rename file which allowed it to do speculative execution. It also allowed skipping stack accesses to memory by simply renaming the old register into an unused spot in the register file boing by the assumption that stuff put on the stack is often needed again soon, so rather than putting it in memory, just keep it in an unused virtual register. As a result the Pentium Pro and most newer x86 processors actually already perform as if they had more registers than the architecture does in most cases. I am not saying adding registers wasn't a good idea, but I think people are highly over estimating their significance. I guess a simple way to test is to convince the compiler that the 64bit mode has the same number of registers as 32bit mode and then compiling software that way and comparing the result in 32 and 64bit mode when both have the same register count. Shouldn't be too hard to do for someone that understands gcc's code (which is not me). AFAIK Sparc (and basycally any other 64-bit capable processor) offers the same number of registers in both 32-bit and 64-bit mode, so there is nothing that could balance the slowdown caused by going 64-bit. And even if they wanted to use the same trick as AMD it would not help as Sparc already has enough registers - adding more would give a much much smaller performance gain than it did for x86_64. I don't think the sparc added any really useful new instructions in 64bit mode. I believe it mainly just added 64bit versions of the instructions where needed. Hehe, they could introduce a new 32-bit mode that has the same number of registers as the 64-bit mode has. OTOH marketing people would have a really tough time to push down such a change on consumers' throats... Given the amount of ram in your average desktop is getting close to requiring a 64bit OS, there is really no point designing anything new with 32bit operation in mind. People have to switch to 64bit OSs if they want to be able to use more ram within the next year or so. But then again who knows. Perhaps 2GB of ram really is all anyone will ever need. :) -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Mon, Nov 12, 2007 at 09:46:57AM -0500, Lennart Sorensen wrote: Given the amount of ram in your average desktop is getting close to requiring a 64bit OS, there is really no point designing anything new with 32bit operation in mind. People have to switch to 64bit OSs if they want to be able to use more ram within the next year or so. I have and use 6GB in a 32 bit machine, and have for years. Sure, no one process can use 3GB, (3/1 user/kernel split) but the machine handles two 3G processes just fine. I believe the limit for machines like this is 64G. -- Rob signature.asc Description: Digital signature
Re: Intel Core2Duo (T7400)
On Mon, Nov 12, 2007 at 09:40:40AM -0700, Rob Sims wrote: I have and use 6GB in a 32 bit machine, and have for years. Sure, no one process can use 3GB, (3/1 user/kernel split) but the machine handles two 3G processes just fine. I believe the limit for machines like this is 64G. Sure, but 32bit vista and Xp don't do PAE (and it is a slight performance hit to use PAE anyhow). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On 11/12/07, Gabor Gombas [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 09:31:31AM -0500, Lennart Sorensen wrote: I don't consider it a real issue either, but it is still something. I am not sure why sparc tends to run 32bit for most programs and only 64bit for select cases where it helps. Certainly x86_64 seems to be better than i386 in just about all cases. Taking the same code, going from 32-bit to 64-bit will cause a slowdown, period. The only way to overcome that is if you can write better code in 64-bit mode than you could in 32-bit mode. There are apps that indeed benefit from directly accessing more than 2G of address space and therefore can use simpler algorithms in 64-bit mode, but they are rare (at least on desktop). In my opinion certainly all the applications wrote in the past has no designed to use 64 bits operations and many algorithms could have beneffits of this, if in the same bus (64 bits) are you only use 32= bits operands there is no gain at all... The plus is involved in move and operate data at double rate 64/32 if the code is rarely doing this we have this slowdown, obviously thats not true if its not a full 64 bits REAL bus... And (this is only my knowledge from 8085 - 8088/80188 old procesors) the pointers to the data are in many cases relatives and not necesarily should be so long, if this is not true now let me know, I just presume that the nowadays procesors still have the ugly segment registers... AMD knew all this and they also knew they have to counter-balance the slowdown if they ever wanted 64-bit to became the norm, so they did a smart trick and doubled the register set size in 64-bit mode. Since i386 is a very register-starved architecture, that move indeed helped a lot by making it much easier for compilers to generate better code. So it's not only in 64-bit mode you can keep more variables in registers but also it is easier to write good compilers for 64-bit mode. AFAIK Sparc (and basycally any other 64-bit capable processor) offers the same number of registers in both 32-bit and 64-bit mode, so there is nothing that could balance the slowdown caused by going 64-bit. And even if they wanted to use the same trick as AMD it would not help as Sparc already has enough registers - adding more would give a much much smaller performance gain than it did for x86_64. I hope they come out with a way faster improved CPU before then. Hehe, they could introduce a new 32-bit mode that has the same number of registers as the 64-bit mode has. OTOH marketing people would have a really tough time to push down such a change on consumers' throats... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Perhaps the depth of love can be calibrated by the number of different selves that are actively involved in a given relationship. Carl Sagan (Contact) Jaime Ochoa Malagón Integrated Technology Tel: (55) 52 54 26 10
Re: Intel Core2Duo (T7400)
On Mon, Nov 12, 2007 at 03:36:27PM -0600, Jaime Ochoa Malag?n wrote: In my opinion certainly all the applications wrote in the past has no designed to use 64 bits operations and many algorithms could have beneffits of this, if in the same bus (64 bits) are you only use 32= bits operands there is no gain at all... The plus is involved in move and operate data at double rate 64/32 if the code is rarely doing this we have this slowdown, obviously thats not true if its not a full 64 bits REAL bus... And (this is only my knowledge from 8085 - 8088/80188 old procesors) the pointers to the data are in many cases relatives and not necesarily should be so long, if this is not true now let me know, I just presume that the nowadays procesors still have the ugly segment registers... Yes they have the segment registers, but they only apply in real mode. In protected mode the cpu has a flat memory model instead and uses memory mapping and other tricks to manage memory access. 32bit protected mode provides a flat 4GB address space. PAE allows the OS to map memory up to 64GB into the 4GB address space of a given application, so that even though a single application only has a 4GB address space, the system can have up to 64GB of memory to use for running multiple applications (and caching and other OS related uses). In 64bit mode you get a flat 64bit memory space, although current CPUs only support 48bits or something like that, and ignore the high bits for now, which means you could use all your ram for a single application. Neither 32 nor 64bit mode use the segment registers at all (or at least not the way they were used in real mode). The i386 and above support 32bit protected mode. The 286 had a different protected mode that provided a 24bit flat memory model (this clearly shows in the 32bit page tables since you have a 16bit value in one place, an 8bit value somewhere else and finally another 8bit value yet somewhere else all in one structure to provide the 32bit address of the page. It's been a while since I looked at that stuff). In protected mode all pointers are full addresses in general (although you certainly can still use offsets from a register too, and often do). Given the register offset accesses on x86, you probably don't get quite the same hit on performance that you would on 64bit RISC designs where the general model seems to be you move data between memory addresses and registers, and then operate on the registers and then move data to memory again. Even those do tend to have the ability to refer to the address in a register though so you still don't have to always use 64bit memory addresses to refer to memory. x86 also has variable length instructions, where RISC would make all instructions 32bit or 64bit long. I am not sure if the instructions have changed length on x86_64 at all compared to x86. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Mon, Nov 12, 2007 at 09:46:57AM -0500, Lennart Sorensen wrote: They also deprecated MMX and x87 (hence reducing the old crap to carry around on centext switches), and switched to sse match (which is much faster and not stack based), and add some new instructions that can help code in general. AFAIK SSE is also available in 32-bit mode so that is no reason why x86_64 should be faster. That almost certainly is much more important than the register count. As far back as the Pentium Pro the pipeline's out of order execution had a large register rename file which allowed it to do speculative execution. It also allowed skipping stack accesses to memory by simply renaming the old register into an unused spot in the register file boing by the assumption that stuff put on the stack is often needed again soon, so rather than putting it in memory, just keep it in an unused virtual register. As a result the Pentium Pro and most newer x86 processors actually already perform as if they had more registers than the architecture does in most cases. Again this is a reason why new 32-bit processors are faster than old 32-bit processors, but not a reason why x86_64 mode should be faster than i386 mode on the same processor. I am not saying adding registers wasn't a good idea, but I think people are highly over estimating their significance. I don't have numbers so I can't really argue, but that is the largest visible difference between the two modes. I guess a simple way to test is to convince the compiler that the 64bit mode has the same number of registers as 32bit mode and then compiling software that way and comparing the result in 32 and 64bit mode when both have the same register count. Shouldn't be too hard to do for someone that understands gcc's code (which is not me). I don't think it would be that easy, but the idea is interesting. Given the amount of ram in your average desktop is getting close to requiring a 64bit OS, there is really no point designing anything new with 32bit operation in mind. People have to switch to 64bit OSs if they want to be able to use more ram within the next year or so. You said Sparc/Solaris; I don't know the current top-of-line configs but several hundred gigabytes of memory should not present a problem for a really high-end Sun server and as you said most of the userspace is still 32-bit... The kernel of course must be 64-bit, but that's not a problem even if 64-bit mode is significanlty slower since applications do not spend too much time in the kernel (and if they do that's almost certainly a bug). But back to the original issue: x86_64 is _NOT_ faster because it is using 64-bit addressing - quite the contrary, that alone would have made it slower than 32-bit mode. But AMD also did a lot of other modifications that they _could_ have also enabled in 32-bit mode but they simply choose not to, because otherwise they could not have sold their 64-bit processors. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Problemas with 64 bit cleanliness (was: Re: Intel Core2Duo (T7400))
On Nov 07 2007, Bernd Petrovitsch wrote: On Tue, 2007-11-06 at 13:35 -0500, Lennart Sorensen wrote: A few programs still don't compile or work on 64bit systems (not amd64 Any real-world examples? Yes, one package that I maintain does not work with 64 bit systems (hfsprogs). This is code taken directly from Apple's Darwin system and has a few silly programming mistakes (like using index -1 in a C array). For luck, fsck.hfsplus works on 32 bit systems, but that just what I said: luck. BTW, fixing it would be a major undertaking... :-( The only which I remember rumors are grub. But being a bootloader, that probably doesn't hurt much. Does anybody know how about the status of grub 2? I would like to use just one booloader for the main architectures that I live with (ppc, amd64, i386). Fact is that I run pure 64bit Linux since months on my home desktop (though I'm not the typical desktop user;-). I consider myself a pretty typical Desktop user (working on papers for my studies and preparing classes, surfing the web, reading mail etc) and I'm using a pure 64 bit Linux system. :-) Of course, one of the reasons I like alternative ports (like PowerPC also) is that it is a very good test for pureness of Free Software: it's also got something to do with me liking Free Software to the point of maintaining the Virtual RMS (package: vrms). :-) I guess you could say that the fact the programs are slightly bigger (since all pointers become 8 bytes rather than 4) is a disadvantage, but on the other hand a lot of code runs slightly faster with 64bit, with a Yes, x86_64 has more registers than i386. Yes, this is a good thing for compilers, as less parameters are passed by memory and less temporary expressions are spilled to memory. I wish that x86-64 had more of them... Some browsers (konqueror, firefox as far as I've been told) allow to run 32bit plugins from the 64bit version. Didn't know that. Since the flash-plugin and others is not really important for me, I don't really care. Same thing here: I even block other things with privoxy. :-) problems since many are 32bit windows code only. Some people just run the few problem programs in a 32bit chroot and deal with it that way, Or install 32bit libs and run a 32bit browser/application on the x86_64 installation. While this can be done, it would taint the pure 64 bit installation... Regards, -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Mit, 2007-11-07 at 14:19 -0500, Lennart Sorensen wrote: On Wed, Nov 07, 2007 at 12:05:26AM +0100, Bernd Petrovitsch wrote: Any real-world examples? Even OpenOffice runs as 64bit since months. The only which I remember rumors are grub. But being a bootloader, that probably doesn't hurt much. Fact is that I run pure 64bit Linux since months on my home desktop (though I'm not the typical desktop user;-). I know people were working on openoffice, but it has been sufficiently unstable both 32bit and 64bit that it's hard to ever tell when openoffice is really working right. :) I'm not an OOorg power user - it's more a .doc/.xls viewer for me. How is mplayer with w32codecs doing on 64bit? How about java plugin? flash v9 plugin? No official flash (which always everyone uses) but there is a free replacement project somewhere which AFAIK works on 64bit. But I don't know how good this (and I'm in no need for flash - I can live without youtube;-). The few movies I want to look ran with one of mplayer, totem or xine (but seldom with all). I never looked in to though. [...] In short: FUD?! No, theoretically you could have code with so many pointers that the doubling of size of pointers actually costs enough memory bandwidth to make a difference. I hope nobody writes code like that. I was just ACK - in theory. ACK - and since that software (also) needs to be fixed. Therefor I'm counting this in practice as an non-issue. trying to be thorough on any disadvantages too. Probably irrelevant on an AMD, but might hurt on a multi cpu intel since they still have much more limited memory bandwidth available. Hmm, any better numbers on it (or links to places with them)? Some browsers (konqueror, firefox as far as I've been told) allow to run 32bit plugins from the 64bit version. Since the flash-plugin and others is not really important for me, I don't really care. Well they are important to a lot of people. The new ability to run Yes, very probably. 32bit plugins certainly helps too. ACK. Or install 32bit libs and run a 32bit browser/application on the x86_64 installation. Except that is a bit of a pain and doesn't fit dpkg/apt very well. On FC6 (IIRC) it took 80 i386 RPMS just to install OOorg. The problem is not really the disk space for it (or the time and resources OOorg needs to start) but that `yum upgrade` also pulls new i386 packages which are not realy needed on the next update just because the x86_64 version is upgraded. So unless you cleanup regularly you end up with all of them (or you ignore i386 in yum.conf and temporarily add it if some dependency lib of OOorg wants to be updated - which is awkward too). Yes, but that implies Vista there and God knows how compatible (even to pre-Vista Windoze) the result will be. Well there was 64bit xp although few used it (often due to lack of drivers for their hardware. Hooray for closed source drivers!), and :-) certainly a number of programs do not officially support 64bit vista yet even though they support 32bit vista and 32 and 64bit XP. I guess in a year or two when people start wanting to use 4 or 8GB ram on their desktops they won't have a choice anymore and things might start working in 64bit windows world. That reminds me of a TYAN mainboard (Toledo i3100/S5207, Intel E6600 CPU on it IIRC[0], Ubuntu + self-compiled kernel on it IIRC[0]) bought in March 2007 which ran fine with 4GB but didn't even boot[1] with 8GB RAM (and RAM is on their recommend RAM list for that board) and stopped with an BIOS error not mentioned in the manual. The third BIOS update - to a beta version - (since March) seems[1] to make it work now. Bernd [0]: It is not back online yes so I can't `ssh` into it. [1]: To be more exact: It booted 5 times completely without any problems and then it stopped booting (when I was with at the hosters place to put it onthe Internet, God I was fed up with it and cursed it to hell!). So the seems needs probably some time and several more reboots to generate more confidence. -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Thu, 2007-11-08 at 10:31 +0100, Bernd Petrovitsch wrote: trying to be thorough on any disadvantages too. Probably irrelevant on an AMD, but might hurt on a multi cpu intel since they still have much more limited memory bandwidth available. Hmm, any better numbers on it (or links to places with them)? Blackford/Greencreek (Xeon): 21.3GBs mem b/w per motherboard G35, DDR2 Mode (Core 2): 12.8GBs mem b/w per motherboard G35, DDR3 Mode (Core 2): 17.0GBs mem b/w per motherboard Socket F Opteron : 10.6GBs mem b/w per physical CPU Socket AM2 Athlon64: 10.6GBs mem b/w per physical CPU Memory performance increases with CPUs in AMD platforms, decreases in Intel platforms. That's the incredibly naive version, anyway. -- __ / Jo Shields [EMAIL PROTECTED] \ | Systems Manager, | \ Oxford Supercomputing Centre / --- \ ,__, \ (oo)___ (__))\ ||--|| * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Thu, Nov 08, 2007 at 03:36:15PM +0100, Bernd Petrovitsch wrote: Well, since the mainboard does not even try to load the boot loader, I consider that above a pretty OS-independent problem/bug. I would think they also put the max load of RAMs (at least for the recommended ones) into their mainbords and boot it with anything. They should yes. I actually remember working with an IBM desktop once where IBM said the machine supported up to 512MB ram, while Crucial said it supported 1GB of ram. Apparently IBM only documented what they had actually tested, while the chipset could theoretically support 1GB just fine (as could the bios). It did in fact work with 1GB but the docs were never updated to say it did. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Thu, Nov 08, 2007 at 10:01:20AM +, Jo Shields wrote: Blackford/Greencreek (Xeon): 21.3GBs mem b/w per motherboard G35, DDR2 Mode (Core 2): 12.8GBs mem b/w per motherboard G35, DDR3 Mode (Core 2): 17.0GBs mem b/w per motherboard Socket F Opteron : 10.6GBs mem b/w per physical CPU Socket AM2 Athlon64: 10.6GBs mem b/w per physical CPU Memory performance increases with CPUs in AMD platforms, decreases in Intel platforms. That's the incredibly naive version, anyway. Interesting how this gives a rather different view of memory bandwidth than that: http://www.tomshardware.com/2007/10/29/intel_penryn_4ghz_with_air_cooling/page32.html Seems the AM2 easily beats the core2 on either P35 or X38 chipset. Seems the AMD managed just under 9.2GB/sec using a 6400+, while the intel managed just under 6.4GB/sec using an overclocked QX9650 at 4GHz. Sure means the AMD gets much closer to the theoretical number, while the intel manages barely half of the theoretical number. Now if those are bandwidth between cpu and mainboard, then it makes more sense since the FSB on the intel does have more bandwidth then hyper transport. Putting it to actual use on the other hand is a different story. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Thu, Nov 08, 2007 at 10:31:56AM +0100, Bernd Petrovitsch wrote: ACK - in theory. ACK - and since that software (also) needs to be fixed. Therefor I'm counting this in practice as an non-issue. I don't consider it a real issue either, but it is still something. I am not sure why sparc tends to run 32bit for most programs and only 64bit for select cases where it helps. Certainly x86_64 seems to be better than i386 in just about all cases. Hmm, any better numbers on it (or links to places with them)? Well toms hardware had a test of the new intel 45nm quad core certainly showed that for memory bandwidth even the slowest AMD has quite a bit more bandwidth than the brand new top of the line intel. And that's for single socket. Every time you add a socket to an AMD server you get another complete memory controller with bandwidth, while on an intel system you get another cpu trying to use your existing front side bus bandwidth. This is probably the main reason the opterons scale past 2 socket systems and xeons do not. In a couple of years when intel gets their new interconnect implemented AMD will have a very big problem, which is rather unfortunate. I hope they come out with a way faster improved CPU before then. On FC6 (IIRC) it took 80 i386 RPMS just to install OOorg. The problem is not really the disk space for it (or the time and resources OOorg needs to start) but that `yum upgrade` also pulls new i386 packages which are not realy needed on the next update just because the x86_64 version is upgraded. So unless you cleanup regularly you end up with all of them (or you ignore i386 in yum.conf and temporarily add it if some dependency lib of OOorg wants to be updated - which is awkward too). I don't deal with RPM based systems anymore. I stopped doing that when RH6.0 kept crashing bind multiple times a day. :) That reminds me of a TYAN mainboard (Toledo i3100/S5207, Intel E6600 CPU on it IIRC[0], Ubuntu + self-compiled kernel on it IIRC[0]) bought in March 2007 which ran fine with 4GB but didn't even boot[1] with 8GB RAM (and RAM is on their recommend RAM list for that board) and stopped with an BIOS error not mentioned in the manual. The third BIOS update - to a beta version - (since March) seems[1] to make it work now. You would think board makers SHOULD test the bios with every OS out there not just the most popular one. Even testing with 64bit vista and the ram maxed out on the board would catch many bugs (like the MTRR bugs in intel bioses on the majority of their current boards). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Die, 2007-11-06 at 20:54 -0500, Douglas A. Tutty wrote: On Wed, Nov 07, 2007 at 12:05:26AM +0100, Bernd Petrovitsch wrote: [...] that probably doesn't hurt much. Fact is that I run pure 64bit Linux since months on my home desktop (though I'm not the typical desktop user;-). specific, just 64bit system specific), but other than that generally no disadvantages. I guess you could say that the fact the programs are slightly bigger (since all pointers become 8 bytes rather than 4) is a disadvantage, but on the other hand a lot of code runs slightly faster with 64bit, with a Yes, x86_64 has more registers than i386. few types of programs running much faster. A few very very pointer heavy programs might run slightly slower, although I don't know of any where this is the case. In short: FUD?! Len Sorensen knows a lot about running amd64. Consider that before you write off what he says as FUD. Well, without any real examples or details? I would have formulated the above paragraph differently (it it's actually a correct interpretation): Very pointer-heavy apps may run slightly slower. But since we don't know any real example, it is not an issue until someone comes with an convincing case. [...] The main missing programs seem to be things which are closed source, so adobe flash, acrobat reader, etc. Some of these do have more or less functional open source replacements. Video codecs can also be a Some browsers (konqueror, firefox as far as I've been told) allow to run 32bit plugins from the 64bit version. Since the flash-plugin and others is not really important for me, I don't really care. Well, you're wrong. In Lenny, there's a wrapper that does this but in Etch it doesn't exist and can't be backported. So flash in Etch needs the ia-32 chroot. I don't know if anything else does since I don't use them. Thanks for first hand information and details. Well, sooner or later Lenny will be stable and the problem vanishes ... Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Tue, Nov 06, 2007 at 08:54:17PM -0500, Douglas A. Tutty wrote: On Wed, Nov 07, 2007 at 12:05:26AM +0100, Bernd Petrovitsch wrote: On Tue, 2007-11-06 at 13:35 -0500, Lennart Sorensen wrote: On Tue, Nov 06, 2007 at 06:58:15PM +0100, Jonas Meurer wrote: Do you have any reasons for that suggestion? Which disadvantages does the amd64 port have on system with up to 2GB of RAM? A few programs still don't compile or work on 64bit systems (not amd64 Any real-world examples? Even OpenOffice runs as 64bit since months. The only which I remember rumors are grub. But being a bootloader, Grub on Etch amd64 works just fine. Not just fine. In particular, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423235 is quite annoying. -- Rob signature.asc Description: Digital signature
Re: Intel Core2Duo (T7400)
Jonas Meurer wrote: On 07/11/2007 Jerome BENOIT wrote: the issue with grub is that it does not yet support EFI64 Can you point me to some documentation which explains EFI64? I searched for it with google, but the only real information I got, was that for booting a EFI64 kernel, the bootloader needs to support it. What is an EFI64 kernel? Is EFI64 a CPU flag? This is not a CPU flag, but the possibility to boot your computer through EFI as OS X does. Currently, you can boot 32bit kernel via EFI provided that the kernel was built with some EFI (EFI32) stuff. In this case, on Mac Intel computers, you do not need to install BootCamp and to play with `refit': nevertheless some information expected from the BIOS are no more furnished (in particular X stuff) --- this approach can be used when you box is meant to be a server or a number cruncher. With last kernel withs favour (?) mm come some documentations. You may look for `elilo' as well. greetings, Jerome greetings, jonas -- Jerome BENOIT jgmbenoit_at_mailsnare_dot_net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Wed, Nov 07, 2007 at 12:05:26AM +0100, Bernd Petrovitsch wrote: Any real-world examples? Even OpenOffice runs as 64bit since months. The only which I remember rumors are grub. But being a bootloader, that probably doesn't hurt much. Fact is that I run pure 64bit Linux since months on my home desktop (though I'm not the typical desktop user;-). I know people were working on openoffice, but it has been sufficiently unstable both 32bit and 64bit that it's hard to ever tell when openoffice is really working right. :) How is mplayer with w32codecs doing on 64bit? How about java plugin? flash v9 plugin? Yes, x86_64 has more registers than i386. That probably doesn't really matter, since all modern i386 systems have register file renaming and other tricks that avoid going to memory for many stack operations so not really likely to matter. Exterminating MMX and x87 on the other hand speeds up context switches and makes floating point way faster than it is on i386. In short: FUD?! No, theoretically you could have code with so many pointers that the doubling of size of pointers actually costs enough memory bandwidth to make a difference. I hope nobody writes code like that. I was just trying to be thorough on any disadvantages too. Probably irrelevant on an AMD, but might hurt on a multi cpu intel since they still have much more limited memory bandwidth available. Some browsers (konqueror, firefox as far as I've been told) allow to run 32bit plugins from the 64bit version. Since the flash-plugin and others is not really important for me, I don't really care. Well they are important to a lot of people. The new ability to run 32bit plugins certainly helps too. Or install 32bit libs and run a 32bit browser/application on the x86_64 installation. Except that is a bit of a pain and doesn't fit dpkg/apt very well. Yes, but that implies Vista there and God knows how compatible (even to pre-Vista Windoze) the result will be. Well there was 64bit xp although few used it (often due to lack of drivers for their hardware. Hooray for closed source drivers!), and certainly a number of programs do not officially support 64bit vista yet even though they support 32bit vista and 32 and 64bit XP. I guess in a year or two when people start wanting to use 4 or 8GB ram on their desktops they won't have a choice anymore and things might start working in 64bit windows world. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Wed, Nov 07, 2007 at 02:34:20PM +0100, Jonas Meurer wrote: Can you point me to some documentation which explains EFI64? I searched for it with google, but the only real information I got, was that for booting a EFI64 kernel, the bootloader needs to support it. What is an EFI64 kernel? Is EFI64 a CPU flag? EFI is intels replacement for the legacy BIOS. intel Macs use EFI for example. Since it isn't a BIOS it uses a different partition table format (GPT = GUID Partition Table) instead of the old DOS partition table. GPT supports partitions larger than 2^32 sectors, which the DOS format does not so we will have to switch within a few years on new machines given disks are approaching the multi TB size. EFI also has a different interface and boot method, so a boot loader would have to know how EFI works to boot at all on such a machine. Supposedly vista will get EFI support in SP1, at which point it should technically be possible to boot and install directly on an intel Mac (and other EFI intel systems) without any bootcamp or other trickiness involved. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Wed, Nov 07, 2007 at 09:41:23AM +0100, fred wrote: povray 3.6 ? Isn't there a 3.7 beta that is supposed to be 64bit safe? -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Wed, Nov 07, 2007 at 02:38:27PM +0100, Jonas Meurer wrote: Ok, the fact that pointers and long/double variables on 64bit systems do take twice as much RAM as on ia32 systems sounds reasonable. Thanks for information. Pointers do. long's happen to be defined as 64bit on x86_64 while they are defined as 32bit on i386. Any program that uses longs better be aware that sizeof(int) != sizeof(long) on all systems. doubles are 64bit in all cases as far as I remember. I think there is a new 128bit floating point format available with 64bit that wasn't there on 32bit systems. I don't deal with floating point enough to be sure. 30% is quite a lot. Can you point me to postings/articles/etc. which claim to have discovered this? Well here is a randomly picked example: rceng02:~# ls -l /data/.chroot/debian-pure64/bin/ls -rwxr-xr-x 1 root root 85536 Jan 30 2007 /data/.chroot/debian-pure64/bin/ls rceng02:~# ls -l /bin/ls -rwxr-xr-x 1 root root 77352 Jan 30 2007 /bin/ls So /bin/ls appears to be 10% larger. rceng02:~# ls -l /bin/gzip -rwxr-xr-x 4 root root 52672 Sep 19 2006 /bin/gzip rceng02:~# ls -l /data/.chroot/debian-pure64/bin/gzip -rwxr-xr-x 4 root root 60216 Sep 19 2006 /data/.chroot/debian-pure64/bin/gzip So /bin/gzip appears to be 14% larger. I seem to recall gzip also runs quite a bit faster on 64bit. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On 07/11/2007 Jerome BENOIT wrote: Douglas A. Tutty wrote: On Wed, Nov 07, 2007 at 12:05:26AM +0100, Bernd Petrovitsch wrote: On Tue, 2007-11-06 at 13:35 -0500, Lennart Sorensen wrote: On Tue, Nov 06, 2007 at 06:58:15PM +0100, Jonas Meurer wrote: Do you have any reasons for that suggestion? Which disadvantages does the amd64 port have on system with up to 2GB of RAM? A few programs still don't compile or work on 64bit systems (not amd64 Any real-world examples? Even OpenOffice runs as 64bit since months. The only which I remember rumors are grub. But being a bootloader, Grub on Etch amd64 works just fine. the issue with grub is that it does not yet support EFI64 Can you point me to some documentation which explains EFI64? I searched for it with google, but the only real information I got, was that for booting a EFI64 kernel, the bootloader needs to support it. What is an EFI64 kernel? Is EFI64 a CPU flag? greetings, jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On 06/11/2007 Basile STARYNKEVITCH wrote: Jonas Meurer wrote: On 06/11/2007 Hartmut Manz wrote: The correct debian port for INTEL Core2Duo is amd64 or i386. If your system has not more than 2 GB of memory installed I would recommend to still use the 32bit Linux (i386), If you have more memory installed use the 64-bit Linux (amd64) Do you have any reasons for that suggestion? Which disadvantages does the amd64 port have on system with up to 2GB of RAM? a 64 bits system consume more memory than a 32 bits system for each pointer and long (going from 32 bits = 4 bytes to 64 bits = 8 bytes) and also have higher alignment requirements. Ok, the fact that pointers and long/double variables on 64bit systems do take twice as much RAM as on ia32 systems sounds reasonable. Thanks for information. Rumors say that most processes consume about 30% more RAM Hence the hint (even if the 2Gb RAM threshold is arbitrary) 30% is quite a lot. Can you point me to postings/articles/etc. which claim to have discovered this? greetings, jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On 06/11/2007 Lennart Sorensen wrote: On Tue, Nov 06, 2007 at 06:58:15PM +0100, Jonas Meurer wrote: Do you have any reasons for that suggestion? Which disadvantages does the amd64 port have on system with up to 2GB of RAM? A few programs still don't compile or work on 64bit systems (not amd64 specific, just 64bit system specific), but other than that generally no disadvantages. but at least that doesn't depend on the RAM you use ;-) I guess you could say that the fact the programs are slightly bigger (since all pointers become 8 bytes rather than 4) is a disadvantage, but on the other hand a lot of code runs slightly faster with 64bit, with a few types of programs running much faster. A few very very pointer heavy programs might run slightly slower, although I don't know of any where this is the case. With 64bit you can memory map much bigger files than with 32bit which can make implementing some programs much simpler and probably more efficient too, so there seems to be many good reasons to move to 64bit. that's the relevant information here ;-) Thanks for pointing me to it. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On 11/07/2007 02:30 PM, Lennart Sorensen wrote: Well here is a randomly picked example: rceng02:~# ls -l /data/.chroot/debian-pure64/bin/ls -rwxr-xr-x 1 root root 85536 Jan 30 2007 /data/.chroot/debian-pure64/bin/ls rceng02:~# ls -l /bin/ls -rwxr-xr-x 1 root root 77352 Jan 30 2007 /bin/ls So /bin/ls appears to be 10% larger. On my Fedora 7 systems, /bin/ls is 5% larger on 32-bit than 64-bit: [EMAIL PROTECTED] ~]$ ls -l /bin/ls ; file /bin/ls -rwxr-xr-x 1 root root 99468 2007-06-13 10:06 /bin/ls /bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped [EMAIL PROTECTED] ~]$ [EMAIL PROTECTED] ~]$ ls -l /bin/ls ; file /bin/ls -rwxr-xr-x 1 root root 95056 2007-06-13 10:31 /bin/ls /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped [EMAIL PROTECTED] ~]$ rceng02:~# ls -l /bin/gzip -rwxr-xr-x 4 root root 52672 Sep 19 2006 /bin/gzip rceng02:~# ls -l /data/.chroot/debian-pure64/bin/gzip -rwxr-xr-x 4 root root 60216 Sep 19 2006 /data/.chroot/debian-pure64/bin/gzip So /bin/gzip appears to be 14% larger. I seem to recall gzip also runs quite a bit faster on 64bit. gzip is about 5% larger on 64-bit (67120 bytes) than 32-bit (64116 bytes). Go figure. -Mark -- Mark Komarinski [EMAIL PROTECTED] Sr. Research Systems Architect http://ritg.med.harvard.edu Research IT Group Harvard Medical School -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Wed, Nov 07, 2007 at 11:54:48AM -0700, Rob Sims wrote: On Tue, Nov 06, 2007 at 08:54:17PM -0500, Douglas A. Tutty wrote: Grub on Etch amd64 works just fine. Not just fine. In particular, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423235 is quite annoying. I never noticed it since I have everything I need right in the menu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On 06/11/2007 Hartmut Manz wrote: The correct debian port for INTEL Core2Duo is amd64 or i386. If your system has not more than 2 GB of memory installed I would recommend to still use the 32bit Linux (i386), If you have more memory installed use the 64-bit Linux (amd64) Do you have any reasons for that suggestion? Which disadvantages does the amd64 port have on system with up to 2GB of RAM? greetings, jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
Jonas Meurer wrote:
On 06/11/2007 Hartmut Manz wrote:
The correct debian port for INTEL Core2Duo is amd64 or i386.
If your system has not more than 2 GB of memory installed I would recommend
to still use the 32bit Linux (i386), If you have more memory installed use
the 64-bit Linux (amd64)
Do you have any reasons for that suggestion? Which disadvantages does
the amd64 port have on system with up to 2GB of RAM?
a 64 bits system consume more memory than a 32 bits system for each
pointer and long (going from 32 bits = 4 bytes to 64 bits = 8 bytes) and
also have higher alignment requirements.
Rumors say that most processes consume about 30% more RAM
Hence the hint (even if the 2Gb RAM threshold is arbitrary)
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Tue, Nov 06, 2007 at 06:58:15PM +0100, Jonas Meurer wrote: Do you have any reasons for that suggestion? Which disadvantages does the amd64 port have on system with up to 2GB of RAM? A few programs still don't compile or work on 64bit systems (not amd64 specific, just 64bit system specific), but other than that generally no disadvantages. I guess you could say that the fact the programs are slightly bigger (since all pointers become 8 bytes rather than 4) is a disadvantage, but on the other hand a lot of code runs slightly faster with 64bit, with a few types of programs running much faster. A few very very pointer heavy programs might run slightly slower, although I don't know of any where this is the case. With 64bit you can memory map much bigger files than with 32bit which can make implementing some programs much simpler and probably more efficient too, so there seems to be many good reasons to move to 64bit. The main missing programs seem to be things which are closed source, so adobe flash, acrobat reader, etc. Some of these do have more or less functional open source replacements. Video codecs can also be a problems since many are 32bit windows code only. Some people just run the few problem programs in a 32bit chroot and deal with it that way, which seems to make a lot of sense. I suspect pretty soon these problems will go away, although it may not happen until windows users finally get with the program and start doing 64bit there. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Tue, 2007-11-06 at 13:35 -0500, Lennart Sorensen wrote: On Tue, Nov 06, 2007 at 06:58:15PM +0100, Jonas Meurer wrote: Do you have any reasons for that suggestion? Which disadvantages does the amd64 port have on system with up to 2GB of RAM? A few programs still don't compile or work on 64bit systems (not amd64 Any real-world examples? Even OpenOffice runs as 64bit since months. The only which I remember rumors are grub. But being a bootloader, that probably doesn't hurt much. Fact is that I run pure 64bit Linux since months on my home desktop (though I'm not the typical desktop user;-). specific, just 64bit system specific), but other than that generally no disadvantages. I guess you could say that the fact the programs are slightly bigger (since all pointers become 8 bytes rather than 4) is a disadvantage, but on the other hand a lot of code runs slightly faster with 64bit, with a Yes, x86_64 has more registers than i386. few types of programs running much faster. A few very very pointer heavy programs might run slightly slower, although I don't know of any where this is the case. In short: FUD?! [...] The main missing programs seem to be things which are closed source, so adobe flash, acrobat reader, etc. Some of these do have more or less functional open source replacements. Video codecs can also be a Some browsers (konqueror, firefox as far as I've been told) allow to run 32bit plugins from the 64bit version. Since the flash-plugin and others is not really important for me, I don't really care. problems since many are 32bit windows code only. Some people just run the few problem programs in a 32bit chroot and deal with it that way, Or install 32bit libs and run a 32bit browser/application on the x86_64 installation. which seems to make a lot of sense. I suspect pretty soon these problems will go away, although it may not happen until windows users finally get with the program and start doing 64bit there. Yes, but that implies Vista there and God knows how compatible (even to pre-Vista Windoze) the result will be. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Wed, Nov 07, 2007 at 12:05:26AM +0100, Bernd Petrovitsch wrote: On Tue, 2007-11-06 at 13:35 -0500, Lennart Sorensen wrote: On Tue, Nov 06, 2007 at 06:58:15PM +0100, Jonas Meurer wrote: Do you have any reasons for that suggestion? Which disadvantages does the amd64 port have on system with up to 2GB of RAM? A few programs still don't compile or work on 64bit systems (not amd64 Any real-world examples? Even OpenOffice runs as 64bit since months. The only which I remember rumors are grub. But being a bootloader, Grub on Etch amd64 works just fine. that probably doesn't hurt much. Fact is that I run pure 64bit Linux since months on my home desktop (though I'm not the typical desktop user;-). specific, just 64bit system specific), but other than that generally no disadvantages. I guess you could say that the fact the programs are slightly bigger (since all pointers become 8 bytes rather than 4) is a disadvantage, but on the other hand a lot of code runs slightly faster with 64bit, with a Yes, x86_64 has more registers than i386. few types of programs running much faster. A few very very pointer heavy programs might run slightly slower, although I don't know of any where this is the case. In short: FUD?! Len Sorensen knows a lot about running amd64. Consider that before you write off what he says as FUD. [...] The main missing programs seem to be things which are closed source, so adobe flash, acrobat reader, etc. Some of these do have more or less functional open source replacements. Video codecs can also be a Some browsers (konqueror, firefox as far as I've been told) allow to run 32bit plugins from the 64bit version. Since the flash-plugin and others is not really important for me, I don't really care. Well, you're wrong. In Lenny, there's a wrapper that does this but in Etch it doesn't exist and can't be backported. So flash in Etch needs the ia-32 chroot. I don't know if anything else does since I don't use them. problems since many are 32bit windows code only. Some people just run the few problem programs in a 32bit chroot and deal with it that way, Or install 32bit libs and run a 32bit browser/application on the x86_64 installation. May or may not work, depending on the code and what all libs it needs. which seems to make a lot of sense. I suspect pretty soon these problems will go away, although it may not happen until windows users finally get with the program and start doing 64bit there. Yes, but that implies Vista there and God knows how compatible (even to pre-Vista Windoze) the result will be. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
Douglas A. Tutty wrote: On Wed, Nov 07, 2007 at 12:05:26AM +0100, Bernd Petrovitsch wrote: On Tue, 2007-11-06 at 13:35 -0500, Lennart Sorensen wrote: On Tue, Nov 06, 2007 at 06:58:15PM +0100, Jonas Meurer wrote: Do you have any reasons for that suggestion? Which disadvantages does the amd64 port have on system with up to 2GB of RAM? A few programs still don't compile or work on 64bit systems (not amd64 Any real-world examples? Even OpenOffice runs as 64bit since months. The only which I remember rumors are grub. But being a bootloader, Grub on Etch amd64 works just fine. the issue with grub is that it does not yet support EFI64 that probably doesn't hurt much. Fact is that I run pure 64bit Linux since months on my home desktop (though I'm not the typical desktop user;-). specific, just 64bit system specific), but other than that generally no disadvantages. I guess you could say that the fact the programs are slightly bigger (since all pointers become 8 bytes rather than 4) is a disadvantage, but on the other hand a lot of code runs slightly faster with 64bit, with a Yes, x86_64 has more registers than i386. few types of programs running much faster. A few very very pointer heavy programs might run slightly slower, although I don't know of any where this is the case. In short: FUD?! Len Sorensen knows a lot about running amd64. Consider that before you write off what he says as FUD. [...] The main missing programs seem to be things which are closed source, so adobe flash, acrobat reader, etc. Some of these do have more or less functional open source replacements. Video codecs can also be a Some browsers (konqueror, firefox as far as I've been told) allow to run 32bit plugins from the 64bit version. Since the flash-plugin and others is not really important for me, I don't really care. Well, you're wrong. In Lenny, there's a wrapper that does this but in Etch it doesn't exist and can't be backported. So flash in Etch needs the ia-32 chroot. I don't know if anything else does since I don't use them. problems since many are 32bit windows code only. Some people just run the few problem programs in a 32bit chroot and deal with it that way, Or install 32bit libs and run a 32bit browser/application on the x86_64 installation. May or may not work, depending on the code and what all libs it needs. which seems to make a lot of sense. I suspect pretty soon these problems will go away, although it may not happen until windows users finally get with the program and start doing 64bit there. Yes, but that implies Vista there and God knows how compatible (even to pre-Vista Windoze) the result will be. -- Jerome BENOIT jgmbenoit_at_mailsnare_dot_net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Tuesday, 6. November 2007 18:58, Jonas Meurer wrote: On 06/11/2007 Hartmut Manz wrote: The correct debian port for INTEL Core2Duo is amd64 or i386. If your system has not more than 2 GB of memory installed I would recommend to still use the 32bit Linux (i386), If you have more memory installed use the 64-bit Linux (amd64) Do you have any reasons for that suggestion? Which disadvantages does the amd64 port have on system with up to 2GB of RAM? I am running debian 64bit on my office PC while I am running 32bit kubuntu on my home pc. Since both machine are 64bit capable, the only reason is multimedia and internet. With a 32bit version it's much simpler to have a full working machine for that purposes since flash player, acrobat reader or some codecs could be installed without any pain. Hartmut Manz greetings, jonas -- Gott spricht: Siehe, ich will ein Neues schaffen, jetzt wächst es auf, erkennt ihr's denn nicht? Jesaia 43, 19a
Re: Intel Core2Duo (T7400)
On 11/6/07, Wolfgang Mader [EMAIL PROTECTED] wrote: I want to by a MacBook which ist powered by an Inter Core2Duo (T7400). I was not able to figure out which debian port is the right. Is ist IA64 (the Intel 64-bit port) or amd64. The Intel Core2 Duo implements EM64T, which is basically Intel's name for amd64 (also called x86-64). You should definately pick the amd64 port (or maybe i386) for your MacBook. The IA64 port is for Intel's Itanium processors. Frederik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
Thanks for this REALLY fast replies! You have helped me a lot! Am Dienstag 06 November 2007 08:26:16 schrieb Wolfgang Mader: Hello list, I want to by a MacBook which ist powered by an Inter Core2Duo (T7400). I was not able to figure out which debian port is the right. Is ist IA64 (the Intel 64-bit port) or amd64. Can you please help me out? Thank you in advance. W. Mader -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Tuesday, 6. November 2007 08:26, Wolfgang Mader wrote: Hello list, I want to by a MacBook which ist powered by an Inter Core2Duo (T7400). I was not able to figure out which debian port is the right. Is ist IA64 (the Intel 64-bit port) or amd64. The correct debian port for INTEL Core2Duo is amd64 or i386. If your system has not more than 2 GB of memory installed I would recommend to still use the 32bit Linux (i386), If you have more memory installed use the 64-bit Linux (amd64) For you Information: IA32 is the traditional 32 bit INTEL and AMD CPU architecture for PC's, the corresponding debian port is i386. AMD64, INTEL64 or EM64t are the architcture names for the 64-bit architectures which are an enhancemant of the IA32 architecture. the corresponding debian port is amd64. IA64 is the architecture name for INTEL ITANIUM CPU's. They are used in large server architectures but not in PC's or Mac's, the corresponding debian port is ia64 . Can you please help me out? Thank you in advance. W. Mader -- Gott spricht: Siehe, ich will ein Neues schaffen, jetzt wächst es auf, erkennt ihr's denn nicht? Jesaia 43, 19a
Re: Intel Core2Duo (T7400)
It's a amd64 2007/11/6, Wolfgang Mader [EMAIL PROTECTED]: Hello list, I want to by a MacBook which ist powered by an Inter Core2Duo (T7400). I was not able to figure out which debian port is the right. Is ist IA64 (the Intel 64-bit port) or amd64. Can you please help me out? Thank you in advance. W. Mader -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Pere Nubiola Radigales Telf: +34 656316974 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
