On Feb 22, 2008, at 4:07 PM, Christian Jaeger wrote:

I wonder whether the (not interrupts-enabled) is a good idea: I expect that if you're handling huge strings, interactivity of other threads will suffer.

Marc has convinced me that disabling interrupts is not a good idea; a few tests show that it doesn't improve performance on those small, tight loops where you're (currently) sure you don't allocate any memory (probably because Gambit now uses __builtin_expect to tell gcc that those POLLs are unlikely to be taken), and in other cases it's not clear that the performance difference is caused by anything more than a different code alignment, etc.

So I've gone through the benchmarks and re-enabled interrupts. The only program it makes a difference in is fannkuch, of a little less than 20%.

Brad

On Feb 22, 2008, at 4:40 PM, Guillaume Cartier wrote:

Did you do some tests on code size too? We have to be carefull about that too as Gambit is already fairly bloated when it comes to generated code size.

On Fri, Feb 22, 2008 at 3:12 PM, Bradley Lucier lucier@math.purdue.edu wrote:

...

It cuts about 5% off some benchmarks.

It reduces code size because it gets rid of POLLs in some tight loops in Gambit's runtime library. It has no effect on the size of user- compiled code. If you want to make the gambit runtime smaller, I suggest

(##define-macro (use-fast-bignum-algorithms) #f)

in lib/_num.scm and then stripping the executables.

As to Christian's comments about unresponsiveness---there are already many tight loops in the gambit runtime that disable interrupts to gain performance. I think if you want to throw around strings that are hundreds of megabytes long then you are willing to accepts some unresponsiveness.

Brad

On Feb 23, 2008, at 3:21 PM, Christian Jaeger wrote:

Be aware that this is untested: I wanted to test it, but couldn't figure out how to compile Gambit from Mercurial.

The Page http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/ How_to_Contribute suggests this should work:

$ make bootstrap

You need to do this with a clean 4.2.2 installation, before any of the .scm files have been modified. Then

hg pull make update make

and perhaps iterate the last two. (I haven't yet worked out precisely how to pass through a 4.X level version number change.)

+;; Global tweaking knobs:

+(##define-macro (macro-not-interrupts-enabled-for-speed)

• '(##declare (not interrupts-enabled)))

That's a really good idea. (It's in the same spirit as "(##define- macro (use-fast-bignum-algorithms) #t)" in _num.scm, which trades off speed for space.) Any loops in the bignum library that are linear in the size of the bignum have interrupts disabled for speed; disabling interrupts may not be so important since Marc started using the builtin_expect form to tell gcc that it is unlikely that interrupts will be taken at POLLs.

There are a number of places in _std.scm where raw "memmove"s are used for speed. I suppose one could audit all uses of (not interrupts-enabled) in the runtime to see why each of them was put there.

+(define-macro (combine a b)

• `(let ((a ,a)

• (b ,b))
  

• (##fixnum.bitwise-and
  

•  (##fixnum.* (##fixnum.+ a (##fixnum.arithmetic-shift-left b 1))
  

•   331804471)
  

•  (macro-max-fixnum32))))
  

That's not a bad idea either. Perhaps if it's not local to these functions it could be renamed hash-combine or something like that.

Brad