3 Jan 2005 03:01

### Problems with benchmark software

Marc:

My bench/prefix-gambit.scm (admittedly perhaps modified) is

(##declare
(standard-bindings)
(extended-bindings)
(block)
(not safe)
;  (not interrupts-enabled)
;  (fixnum)
(inlining-limit 500)
)
;...
(define (run-bench name count run ok?)
(let loop ((i 0) (result (list 'undefined)))
(if (< i count)
(loop (+ i 1) (run))
result)))

then a whole bunch of define-macros that include, e.g.,

(##define-macro (def-macro form . body)
(##define-macro ,form (let () , <at> body)))

(def-macro (< x y)
(##fixnum.< ,x ,y))

The problem is that the macros don't seem to be used to expand the
operations in (the earlier-occuring) run-bench, so we're measuring the


5 Jan 2005 00:22

### Gambit-C 4.0 beta 12

A new beta of Gambit-C 4.0 is now available in source form at this

http://www.iro.umontreal.ca/~feeley/gambc40b12.tar.gz

Here are the main changes:

- The compiler now does constant folding and optimistic inlining of
predefined procedures.  Constant folding is performed for the call
(predef arg1 arg2...) when arg1, arg2... are constants (of the
right type) and predef is a global variable that is known to be
equal to a predefined procedure which does not have side effects
(i.e. when a "standard-bindings" declaration is used and predef
is not vector-set!, cons, etc).  So

(declare (standard-bindings))
(define pi (* 4 (atan 1)))

expands to

(define pi 3.141592653589793)

Note that "standard-bindings" is off by default.  A new
declaration, "run-time-bindings" (which is on by default), tells
the compiler that it should check at run-time if the variable
predef truly contains the corresponding predefined procedure,
and call the predefined procedure if it is, otherwise perform
a call using the global variable.  This is useful for improving
the performance of arithmetic in the absence of unsafe declarations.
For example the following definition of fib (with no declarations)


5 Jan 2005 03:35

### Re: Gambit-C 4.0 beta 12


On Jan 4, 2005, at 6:22 PM, Marc Feeley wrote:

> A new beta of Gambit-C 4.0 is now available in source form at this
>
>     http://www.iro.umontreal.ca/~feeley/gambc40b12.tar.gz

Marc:

After expanding on powerpc-darwin, I find that

1.  I had to make the configure script executable.

2.  There's no "clean" make target in web-repl.

3.  I had to "touch gsc/_gsc_.c" to get the timestamps right.


5 Jan 2005 15:22

### Re: Gambit-C 4.0 beta 12

> Marc:
>
> After expanding on powerpc-darwin, I find that
>
> 1.  I had to make the configure script executable.
>
> 2.  There's no "clean" make target in web-repl.
>
> 3.  I had to "touch gsc/_gsc_.c" to get the timestamps right.

Are you sure you are using the "latest" beta 12 (configure script
dated 17:55 Jan 4)?

Marc

5 Jan 2005 16:01

### Re: Gambit-C 4.0 beta 12


On Jan 5, 2005, at 9:22 AM, Marc Feeley wrote:

> Are you sure you are using the "latest" beta 12 (configure script
> dated 17:55 Jan 4)?

No, sorry.  I'll look at the "latest" beta 12 soon.


6 Jan 2005 23:42

### (unknown)

Marc:

gambc40b12.tar.gz, my previously reported problems go away.

I have a question now about the performance of applications built with
shared libraries on MacOS X.  When I configure gambit with
--enable-shared --enable-single-host I get on my 2GHz G5 running MacOS
10.3.6

[descartes:~/programs/gambc40b12/bench] lucier% ./bench gambit fft

Testing fft under Gambit-C
Compiling...
0.95 real         0.77 user         0.16 sys
-rwxr-xr-x  1 lucier  lucier  30512  6 Jan 17:26 fft
Running...
(time (run-bench name count run ok?))
3736 ms real time
3000 ms cpu time (2970 user, 30 system)
65 collections accounting for 29 ms real time (30 user, 0 system)
671999504 bytes allocated
no minor faults
no major faults
3.99 real         3.17 user         0.06 sys

(This is with the version of bench at

http://www.math.purdue.edu/~lucier/bench.tgz



7 Jan 2005 22:05

### Re: file-seek in Gambit.

> I can't seem to find a way to seek in and get the position in files
> using Gambit (4beta11).  Wouldn't this be a handy feature?

Yes, I have been planing this for a while and have just completed the
implementation and documentation.  Here it is:

<at> deffn procedure input-port-byte-position  <at> var{port}  <at> r{[} <at> var{position}  <at> r{[} <at> var{whence} <at> r{]} <at> r{]}
<at> deffnx procedure output-port-byte-position  <at> var{port}  <at> r{[} <at> var{position}  <at> r{[} <at> var{whence} <at> r{]} <at> r{]}

When called with a single argument these procedures return the byte
position where the next I/O operation would take place in the file
attached to the given  <at> var{port} (relative to the beginning of the
file).  When called with two or three arguments, the byte position for
subsequent I/O operations on the given  <at> var{port} is changed to
<at> var{position}, which must be an exact integer.  When  <at> var{whence} is
omitted or is 0, the  <at> var{position} is relative to the beginning of
the file.  When  <at> var{whence} is 1, the  <at> var{position} is relative to
the current byte position of the file.  When  <at> var{whence} is 2, the
<at> var{position} is relative to the end of the file.  The return value
is the new byte position.  On most operating systems the byte position
for reading and writing of a given bidirectional port are the same.

When  <at> code{input-port-byte-position} is called to change the byte
position of an input-port, all input buffers will be flushed so that
the next byte read will be the one at the given position.

When  <at> code{output-port-byte-position} is called to change the byte
position of an output-port, there is an implicit call to
<at> code{force-output} before the position is changed.



10 Jan 2005 16:47

### (unknown)

> I don't know if this is the right place for this bug report.  I'm not
> a great programmer, but I'm trying to whip some code into shape to
> cite in a Math paper.  It's gotta be at least as fast as C programs
> written on this subject 20 years ago :)  This code right now running
> on DrScheme is a lot slower than the 20 year old C records.

All tests passed on my development machine (a PowerBook running Mac OS
X).  I noticed the problem on Linux after releasing beta 12.  The
strange thing is that the segment violation disappears when the
program is run with "gdb", so I can't even figure out where it is
crashing.  My guess at this point is that my latest modifications of
the C-interface must be causing a problem when a garbage collection
occurs during a Scheme to C call.  I'm looking into it.

Marc

10 Jan 2005 17:30

### Re: gambit.el

> Hi Marc,
>
> FYI
>
> The file gambit.el in the latest (4b12) distribution has a comment
> line near the start
>
> ;; (setq scheme-program-name "gsi -:t")
>
> After pasting this line in my xemacs init.el the interaction window
> didn't work. Changing it to
>
> ;; (setq scheme-program-name "gsi -:d-")
>
> as described in the doc fixed it.
>
> Since others, like me, will be tempted to cut and paste from the
> gambit.el file comments to init.el it would be nice to fix the
> comment.
>
> Regards,

OK.

Marc

10 Jan 2005 21:17

### (unknown)

   > I'm not a great programmer, but [...]

My guess at this point is that my latest modifications of the
C-interface must be causing a problem when a garbage collection
occurs during a Scheme to C call.  I'm looking into it.

Thanks, Marc!  I've been having a crazy Emacs problem all morning, I
wonder if anyone else ever got that.  Finally I saw the problem in
DrScheme, and how to fix it with some Emacs. Possibly it was caused by
quack.el, but switching over to gambit.el didn't fix it.

So here's a simple file "hatA":

(define (memfÂ p alox)
(if (null? alox)
#f
(if (p (car alox))
alox
(memfÂ p (cdr alox)))))

(write (memf odd? '(2 8 2 3 5 4 1 2 3 4)))
(write (memf odd? '(2 8 2 30 50 4 10 2 30 4)))

(banach)lambdaGambit> gsi hatA
*** ERROR IN "hatA" <at> 8.9 -- Unbound variable: memf

By looking at the file in DrScheme, I saw I have a \hat{A} character
after memf.  I can see the \hat{A} character in this mail buffer.

I asked someone here, and he noted that my modeline was reading "u" on