Messages in this thread | | | Date | Mon, 1 Nov 2004 15:42:00 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: Semaphore assembly-code bug |
| |
On Mon, 1 Nov 2004, linux-os wrote: > > No. You've just shown that you like to argue. I recall that you > recently, like within the past 24 hours, supplied a patch that > got rid of the time-consuming stack operations in your semaphore > code. Remember, you changed it to pass parameters in registers.
... because that fixed a _bug_.
> Why would you bother if stack operations are free?
I didn't say that instructions are free. I just tried (unsuccessfully) to tell you that "lea" is not free either, and that "lea" has some serious problems on several setups, ranging from old cpu's (AGI stalls) to new CPU's (stack engine stalls). And that "pop" is often faster.
And you have been arguing against it despite the fact that I ended up writing a small test-program to show that it's true. It's a _stupid_ test-program, but the fact is, you only need a single test-case to prove some theory wrong.
Your theory that "lea" is somehow always cheaper than "pop" is wrong.
> It's not a total focus. It's just necessary emphasis. Any work > done by your computer, ultimately comes from and goes to memory.
Not so.
A lot of work is done in cache. Any access that doesn't change the state of the cache is a no-op as far as the memory bus is concerned. Ie a store to a cacheline that is already dirty is just a cache access, as is a load from a cacheline that is already loaded.
This is especially true on x86 CPU's, where the lack of registers means that the core has been highly optimized for doing cached operations. Remember: a CPU is not some kind of abstract entity - it's a very practical piece of engineering that has been highly optimized for certain usage patterns.
And the fact is, "lea" on %esp is not a common usage pattern. Which is why, in practice, you will find CPU's that end up not optimizing for it. While "pop"+"pop" is a _very_ common pattern, and why existing CPU's do them efficiently.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |