[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.

More information about the logback-dev mailing list