Re: 2.6.0-test6
On Fri, 3 Oct 2003 08:02:43 -0500
"Paul" <paul@techcenter3000.com> wrote:
> Ok, I'll happily concede that 64 bit Sparcs are faster (in general) then 32
> bit sparcs. BUT, I think that has more to do with better/more
> [cache|architecture|MHz|optimizations|processor design] than with simple
> '64-bittedness'.
I didn't say that 64-bit sparcs performed better because they
of thier 64-bittedness. I don't know where you got that from.
> Now, the kernel may be the only thing that executes 64 bit code.
> If so, there are two issues that would harm performance:
> 1) The kernel talks to the hardware. So, let's take a 16 gig IDE drive in
> PIO mode (simply because it IS a shoddy interface).
Stop there, if you're using an IDE interface in PIO mode you don't
care about performace.
> IDE can do at best a 16
> bit transfer per cycle, only 16 bits are available on the physical
> interface. Now, the kernel, it wants to use 64 bits. So, either we 'pad' 48
> bits, or we do 4 transfers and combine them into one 64 bit 'word'. This
> operation would happen at LEAST twice per operation, once for 'seek LBA' and
> once for 'read sector'. Apply this to to (most) common 32 bit PCI bus. Apply
> this to, even worse, printer I/O. (Ok, so we do offload a lot of this onto
> sub-processors, but the point remains the same)
> How many applications do you run that do not EVER access ANY hardware? I
> can't think of any except a no-op loop. even a number crunching app has to
> talk to memory, and the kernel controls that.
Actually, in IDE PIO mode you can only transfer a maximum of 32-bits
to or from the IDE device at once time, this is because the IDE data
register is 32-bit in size.
I don't think you understand much of this technology very well, and this
is making this discussion beyond frustrating :(
> I think our issue here may come from the fact that UltraSparc I and II at
> least are capable of running perfectly happily with 32bit kernels.
There is not 32-bit Linux kernel for 64-bit Sparc chips, the hardware
(especially the MMU) is very awkward to program with a 32-bit kernel
so I never tried to implement that. Only Sun was foolish enough to
ship something like this :)
> (I have
> these procs, among others) So why wouldn't I keep the raw speed of a fast
> 64bit processor that happens to be capable of running either 32 _or_ 64 bit
> kernels AND wipe out the overhead I believe is incurred by the 64 bit kernel
> by running a 32 bit kernel.
Actually, many of the native data types used in the Unix kernel are
64-bit (loff_t, block numbers, page numbers, physical addresses,
etc.), and you still have to do the 64-bit operations on these datums
in the 32-bit kernel.
Also, with the 32-bit kernel it's several orders of magnitude harder
to support more than a few GB of physical memory in the Linux kernel.
With a 64-bit it's trivial.
> I'm honestly not sure if the 64 bit kernel requirement for UltraSparc III's
> mentioned below is a hardware driven issue or a decision by Sun to disallow
> 32 bit kernels on III's.
> (Please, can anyone shed light on this?)
Sun woke up and finally figured out how utterly stupid it was to have
to support and fix bugs in two different kernels for the same exact
pieces of hardware.
> 2) Userland is mostly 32 bit, if not completely. So what happens when I make
> a 32 bit call to the kernel that wants to receive 64 bits, and return 64
> Bits? The kernel has to either assume 32 bitness and pad in at least one
> direction, or decide whether it is 32 or 64 and pad, which would add even
> more overhead.
The 32-bit Sparc application ABI has ways to deal with 64-bit types just like
x86 or any other 32-bit processor. When system calls are made, the 32-bit
system call is translated into the types the 64-bit kernel natively wants.
This translation process is surprisingly inexpensive and most of the
time is not needed at all.
> 2) Majority reported that running a 32-bit application on the 64-bit kernel
> requires more cycles to do alignment and byte packing operations. Thus it is
> reasonable that 32-bit code would run slower on the 64-bit kernel than the
> 32-bit kernel.
That's total bullshit.
Look I've written OS's for every processor Sun has ever produced, and
I've been doing this for 6 or 7 years. And all I can say is that everything
you've said here is total BS, in particular this crap coming from the
Sun managers list.
> I hadn't thought about the half sized cache issue(#3), but heck, doubling
> your cache rarely HURTS performance.
Many of the cache arguments are total bullshit because the kernel has
to keep track of a significant number of datums using 64-bit
types even in the 32-bit kernel.
> On the flip side of this, I have to say, if you're doing heavy graphics
> work, almost without a doubt 64 bit is for you. (Gee, the bus width of UPA
> for example is..taadaa-> 64 bits..theoretically one transfer)
All of the creator3D support I wrote is 32-bit and takes full advantage
of the UPA bandwidth. 64-bits or not makes no difference wrt. to this,
so your ignorance is showing again... The bus bandwidth of UPA
is 64-bytes in one transfer, not 64-bits. The 64-bit transfers are
accomplished using the UltraSPARC block load and store instructions
that move 64-bytes at a time in and out of the floating point registers.
These instructions are fully available in 32-bit mode.
> Again, if I'm wrong, please explain to me how and/or why. I'm learning every
> day, and I'll learn from anybody that can/will teach me.
Yes, you're wrong in just about everything you're talking about
here.
Again I am reminded of why I don't post on mailing lists much
anymore, because I always hit one of these idiotic threads...
The part I hate the most about threads like this is that if I don't
waste my time sitting here correcting you, someone less knowledgable
is going to read your posting and think there is some truth to it.
Reply to: