On Wed, Dec 03, 2003 at 02:38:00AM -0800, Victor Pelt wrote: > While in practice one might not see much improvement, if one would > make even a couple of percent improvement on something like a context > switch one could see significant systen performance improvement (read > measurable as a large fraction of a percent)
My definition of significant is significantly larger than a percent. To knock this particular example down: let us pretend the overhead of a context switch lies in the number of instructions executed (low to mid hundreds of cycles on modern hardware) and not in cache, TLB, and BTB pollution. Let us also pretend that the context switching code is not blocks of assembly within a C skeleton (as my intuition and a quick read of arch/i386/kernel/process.c:__switch_to suggest) and is a candidate for optimization by icc. To achieve a percentage point system performance increase with a 5% context switch improvement, the system would have to spend 20% of its time in context switches! I am being disingenuous by using your example; a better compiler will speed up the average operation by some percentage, not just a specific one. Still, it takes some imagination to create a workload that spends a significant percentage (my definition, not yours) of its time within the kernel without being IO bound. If you are really interested in this sort of thing, search for "icc lmbench" in the lkml archives. My recollection is that icc usually gave a 0-20% improvement. Translating lmbench numbers into real-world numbers is an exercise left for the reader. > secondly it is intersting just from the perspective of having a kernel > with correct c code I suppose our interests differ; feel free to go on a conformance wild goose chase. Assuming one found even a simple compilation bug in Linux/icc, is Linux or icc to blame? Repeat for crashers, intermittent errors, and data corruption. While icc remains proprietary, how do know that it generates correct code, and more importantly, why do you care? -- Andrew Gaul http://gaul.org/ _______________________________________________ Siglinux mailing list [EMAIL PROTECTED] http://machito.utacm.org/mailman/listinfo/siglinux
