> And the below is what percentage of time doing disk i/o? but most file operations don't do physical IO. > > it again! It doesn't scale well. The long long code is nearly 10 times > > slower! You can do `gcc -S -o xxx name.c` and see why. it's silly to talk about unoptimized code. and to spuriously inflate the memory traffic in this femto-benchmark. measured sanely, optimized with 2.95.2 on a celeron/450, long long costs ~2-3x as much. regards, mark hahn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
- Re: Large File support and bl... Alan Cox
- Re: Large File support and bl... Richard Henderson
- Re: Large File support and bl... Matthew Jacob
- Re: Large File support and bl... Michael Meissner
- Re: Large File support and bl... Matthew Jacob
- Re: Large File support and bl... Michael Meissner
- Re: Large File support and bl... Matthew Jacob
- Re: Large File support and bl... Richard Henderson
- RE: Large File support and blocks. Richard B. Johnson
- RE: Large File support and blocks. Linda Walsh
- Re: Large File support and blocks... Mark Hahn
- Re: Large File support and blocks. Stephen C. Tweedie
- 512 byte magic multiplier (was: Large File support and ... Daniel Phillips
- Re: 512 byte magic multiplier (was: Large File sup... Alan Cox
- Re: 512 byte magic multiplier (was: Large File sup... Alexander Viro
- Re: 512 byte magic multiplier (was: Large File... Daniel Phillips
- Re: 512 byte magic multiplier (was: Large ... Theodore Y. Ts'o