[logback-dev] svn commit: r1864 - logback/trunk/logback-core/src/test/java/ch/qos/logback/core/joran
Ceki Gulcu
listid at qos.ch
Thu Oct 23 16:14:40 CEST 2008
Ralph Goers wrote:
> I'm making a guess, but where I'd be looking is in SLF4J at
> bogoInstruction. It is using Random to presumably compute the speed of
> the processor. But many CPUs have optimizations for this while some
> don't. And the processor's efficiency in computing a random number
> probably has little to do with most of the work being done in Logback.
>
> Just a guess though.
I had similar hunch. Checking the code for Random.nextInt(int) on Windows, I see
protected int next(int bits) {
long oldseed, nextseed;
AtomicLong seed = this.seed;
do {
oldseed = seed.get();
nextseed = (oldseed * multiplier + addend) & mask;
} while (!seed.compareAndSet(oldseed, nextseed));
return (int)(nextseed >>> (48 - bits));
}
and on Linux, I see
protected synchronized int next(int bits) {
seed = (seed * multiplier + 0xbL) & ((1L << 48) - 1);
return (int) (seed >>> (48 - bits));
}
The Linux version of the next(int) method seems lighter and
consequently should run faster. Thus, the observed bogoIPS on the
Linux machine is higher. I also suspect that my Linux machine is in
reality slower because it is older and has a relatively slow AMD
CPU. BogoPerf, thinking that the Linux machine is faster, adjusts its
numbers in the wrong direction.
I will attempt to force BogoPerf to use the same Random.next(int)
implementation and see if things improve.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
More information about the logback-dev
mailing list