Re: benchmark results

["Dmitri Nikulin" <dnikulin@xxxxxxxxx>]

That referenced benchmark
(http://jeffr-tech.livejournal.com/6268.html) and its external
followup (http://ozlabs.org/~anton/linux/sysbench/) are more
interesting, I think. What we see there is that the typical glibc
malloc is broken, Google's malloc is better, and whatever malloc is in
FreeBSD 6+ is comparable to Google's.

It'd be very interesting to perform the same test on DragonFly on an
8-way system and see how it goes. That would make a nice benchmark for
a subset of contention problems.

I actually *am* surprised that DragonFly performed so similarly to
FreeBSD, because FreeBSD 6 now has very little in common with
DragonFly. DragonFly has made significant changes to almost every
major subsystem, and FreeBSD has done the same in a very different
way. I guess what it means is that right now, both perform similarly
on single CPUs. FreeBSD would probably do better on multiple CPUs,
which has not yet been a refinement focus of DragonFly.

I'm not sure how accurate the memory test is. That kind of huge
variation doesn't seem reasonable. You did say that those figures
(OpenBSD and Nexenta) were scaled up from another machine, so it seems
that the memory access does not scale as you would expect. I would
prefer to exclude that result entirely, rather than give a false
representation. In that case, FreeBSD would win, which makes enough
sense, but then... it's especially strange that Linux performed so
poorly on sysbench memory but so well on ubench memory. Something's
wrong there. It's obvious that if even synthetic benchmarks can't
agree, then real world uses are even more difficult to correlate.

---
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia