headers
Bradley Lucier | 3 Jan 2005 03:01
Picon
Favicon

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Feeley | 5 Jan 2005 00:22
Picon

Gambit-C 4.0 beta 12

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

    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)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bradley Lucier | 5 Jan 2005 03:35
Picon
Favicon

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
> address:
>
>     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.

More comments later.

Brad
Permalink | Reply | 2 comments |
headers
Marc Feeley | 5 Jan 2005 15:22
Picon

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
Permalink | Reply | 1 comment |
headers
Bradley Lucier | 5 Jan 2005 16:01
Picon
Favicon

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.

Brad
Permalink | Reply | 0 comments |
headers
Bradley Lucier | 6 Jan 2005 23:42
Picon
Favicon

(unknown)

Marc:

As you guessed, once I downloaded the correct version of 
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Feeley | 7 Jan 2005 22:05
Picon

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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Marc Feeley | 10 Jan 2005 16:47
Picon

(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
Permalink | Reply | 5 comments |
headers
Marc Feeley | 10 Jan 2005 17:30
Picon

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
Permalink | Reply | 6 comments |
headers
Bill Richter | 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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane