On Tuesday 19 December 2006 15:49, John Andersen wrote: > On Tuesday 19 December 2006 14:28, Randall R Schulz wrote: > > Why on earth must you be so rude? > > Pot/Kettle.
Compounding the offense by accusing me of being rude. > But it wasn't my intent. What, then? > > And how, exactly, is the kernel that's running my system just > > fine, "wrong?" > > Its not the native kernel for that hardware. The hardware is equally i386 and x86_64. A 32-bit kernel is every bit as "native" as a 64-bit one. > As for your theory, a quick look at the clock times > will reveal that the 64bit registers load in the same number > of clocks as the 32. And the 64bit address registers, pointer > registers, etc also load in the same number of clocks as the 32 bit > registers. So moving stuff around in memory is faster doing so in > 64bit chunks. It's not about the processor, OK? It's about how much demand 64-bit everything places on the memory subsystem. Why fetch and store so many 64-bit quantities that don't make any use of the upper 32 bits? It's all a big waste of memory bandwidth. > The reason for 64bit processors is NOT simply address space. If one has no need for 64 bit anything, it's all a waste. > Drive controllers move data to memory at what ever speed and chunk > size they are designed to use, but your access to that data in 32bit > chunks that take just as long to load as 64bit chunks is slower > because it takes more clocks. Driver controllers are DMA. The processor is not involved in each individual data word transfered. > Look, I've done this exact same thing, loaded the i386 kernel on a > Pentium D (also a 64bit dual well processor, in spite of the Pentium > name). Why would results for an ancient Pentium-D imply anything for a Core 2 Duo, which is an entirely different implementation of the x86 architecture? > Since it was a new server with no mission data installed I > re-installed using the correct kernel, and it was significantly > faster with the 64bit kernel. Which leaves us with the original accusation--that I made a 32/64 choice. I just stuck the disc in and installed. > I did not bench long running applications, or time long compiles, > just running yast, kde, and some database loading. Since it runs at > init 3 most of the time the 32bit would have worked, and might > have gone un-noticed. But it was faster launching applications > in 64bit, and the time to load the sql database from raw files > was also faster, 37 minutes compared to 52. I don't care about those things. I care about CPU-intensive symbolic computations for which 64-bit words, including every single memory address, are dragging around 32 bits of useless zeroes. OK? RRS -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
