On 18 Dec 2005 at 17:42, James Chacon wrote:
> > on linux/i386/amd64 and for a kernel compilation (say 20 minutes of
> > gcc/ld/as traffic) it's basically in the noise, hard to produce
> > reliable numbers that show a definitive impact one way or another.
> 
> I beleive he asked for benchmarks. "Compiling up a kernel" is not a serious
> benchmark.

is it not? do you know what a benchmark is? [1]

benchmark measures things you're interested in. in this case,
you want to know the performance impact of randomized address
space layouts. that means your benchmark has to create address
spaces (the more the better) and execute code in them (the more
address manipulation and memory accesses the better). tell me
what satisfies both better than compiling thousands of files
(all cached after the first run, to eliminate disk i/o by the
way)? you get lots of address space creation (that's where the
randomization related kernel changes play a role), and lots of
userland pointer activity (if you know what gcc does internally).
if you want a different macrobenchmark, feel free to suggest one
(as long as it's open source). and in any case, the question was
'order of magnitude' of performance impact, not impact with ppm
precision, you get the latter after you will have implemented
this code on NetBSD.

> Has this had a real benchmark suite run across a system with
> it not compiled into the system vs running on a system?

define 'real' (and open source) and i'll give you numbers.

[1] http://dictionary.reference.com/search?q=benchmark