On Tue, 27 Mar 2001, Anton Altaparmakov wrote:
> At 09:35 27/03/2001, Ion Badulescu wrote:
> >Compile option or not, 64-bit arithmetic is unacceptable on IA32. The
> >introduction of LFS was bad enough, we don't need yet another proof that
> >IA32 sucks. Especially when there *are* better alternatives.
>
> Sorry, but why should it be unacceptable? It works, so what's the problem?
Because there are some of us who believe a CPU upgrade should server other
purposes than to just compensate for an increase in disk space...
Well, let me put it from a different perspective.
Suppose gcc had been implemented in such a way that it never uses 4 of the
8 general purpose registers on IA32. Would the generated code work? Sure
thing (ABI's not withstanding). Would you use this version of gcc? I
sincerely doubt it.
No, why wouldn't you use it? It works, right? Oh, could it be that you
*know* that it's a bad implementation and there are better ways to
implement it?
Same thing with the 64-bit device size: it's the suboptimal answer to a
real problem. As has been pointed out on the list, there are better
answers out there and people are aware of them.
> I would much rather have a performance hit, than have it not working at
> all.
I'd rather not have a performance hit than have it, when in both cases the
code "works".
> I am definitely putting 64-bit arithmetic into the new NTFS project as
> most of NTFS is 64-bit, and I find it quite acceptable.
Ok, so you don't have much of a choice. Just don't be very surprised if
people won't make NTFS their default filesystem on Linux. :-) Hey, don't
get me wrong, this is not directed at you in any way. You didn't design
NTFS, you're just trying to make it work on Linux -- a very commendable
work.
> So it will be a few % slower than with 32-bit,
Make that 4x slower. Not overall, obviously, but the 64-bit C code itself
will be about 4x slower than equivalent 32-bit C code.
> Anyway, what is this obsession with speed? Surely it is stability, and
> capability which is more important than speed?
They need to be properly balanced. People will not buy a very featureful
product which is slower than molasses. I know this from personal
experience, trying to sell/support such a featureful and slow product...
> I see the point why people with small systems would not want 64-bit, so I
> agree that a compile time option is a good idea. Where is your problem with
> that?
More fragmentation in the core ABI, and there is enough of it already. It
makes support hell (like it wasn't already...).
> I think you are forgetting that 64-bit maths is still on the CPU, which is
> fast, I/O speed is bound by the HD, not by the CPU, so whether the fs-code
> is a bit slower or not will not make any difference in the actual disk
> access case. (Cache access is of course a different matter.)
So it's the same thing to you if just accessing your disk, and not doing
any useful data processing, eats up 12% instead of 3% of your CPU? It
might not matter if that's _all_ the machine is doing, but that's rarely
the case in Unix.
> Just my 2p.
Likewise..
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
