ANN: Larceny v0.962 "Fluoridation" (bug fix release; benchmarking)
William D Clinger
for download at http://larceny.ccs.neu.edu/
v0.962 fixes bugs in the v0.96 and v0.961 versions
of the "Fluoridation" release without adding much
in the way of new features. For details, see
http://www.ccs.neu.edu/home/will/Larceny/knownbugs.html
http://larceny.ccs.neu.edu/doc/
There now exist at least five implementations of
(most of) the R6RS: Larceny, Petit Larceny, PLT
Scheme 4.0.2, Ikarus 0.0.3, and Ypsilon 0.9.5
with update1. We have benchmarked those systems,
and the results give some insight into what they
do and don't do well:
http://www.ccs.neu.edu/home/will/Twobit/benchmarks2008.html
As always, we are happy to acknowledge those who
have contributed to the Larceny project. Today
we salute those who reported many of the bugs that
were fixed in v0.961 or v0.962: Ray Racine, David
Rush, Ken Dickey, Ryan Newton, Peter Keller, Jed
Davis, Jon Wells, and Martin Rodgers.
Thank you for your support.
William D Clinger
Felix S. Klock II
leppie
>
> There now exist at least five implementations of
> (most of) the R6RS: Larceny, Petit Larceny, PLT
> Scheme 4.0.2, Ikarus 0.0.3, and Ypsilon 0.9.5
> with update1.
You can include IronScheme too. http://www.codeplex.com/IronScheme.
This is a 100% .NET/C# implementation. It is also probably the slowest
of all the R6RS implementations.
How is the the Common Larceny port going for R6RS? It would be
interesting to compare apples to apples :)
Cheers
leppie
leppie
> You can include IronScheme too.http://www.codeplex.com/IronScheme.
> This is a 100% .NET/C# implementation. It is also probably the slowest
> of all the R6RS implementations.
I see your benchmarks are Unix based. While IronScheme does run and
can build itself on Mono, it is about 10 times slower than the .NET
framework on Windows.
Cheers
leppie
William D Clinger
> You can include IronScheme too. http://www.codeplex.com/IronScheme.
> This is a 100% .NET/C# implementation. It is also probably the slowest
> of all the R6RS implementations.
Thank you for the pointer and information.
> How is the the Common Larceny port going for R6RS? It would be
> interesting to compare apples to apples :)
Because Larceny's implementation of the R6RS is written
almost entirely in Scheme, and Common Larceny uses the
same code base as native Larceny and Petit Larceny, the
Common Larceny port is almost complete and has been for
some time. Larceny's command line parsing is written in
C, however, and the command line determines Larceny's
selection of R6RS mode. The main thing we have left to
do is to duplicate that C code in some combination of
C# and Scheme.
We do not intend to implement Scheme scripts for Common
Larceny, however, because Scheme scripts are biased toward
Unix and native Larceny already runs Scheme scripts on
Windows faster than Common Larceny would.
> I see your benchmarks are Unix based. While IronScheme does run and
> can build itself on Mono, it is about 10 times slower than the .NET
> framework on Windows.
Microsoft's license agreement for .NET used to (and
probably still does) forbid publication of benchmark
results. We had to get special permission from
Microsoft before we could publish just a few benchmark
timings for Common Larceny.
That's too much hassle. Until Microsoft's licensing
for .NET changes to permit benchmarking, I am unlikely
to benchmark systems using .NET.
Benchmarking IronScheme against Common Larceny on Mono
would provide an apples to apples comparison, so little
is lost by leaving .NET out of the picture.
Will
leppie
> Microsoft's license agreement for .NET used to (and
> probably still does) forbid publication of benchmark
> results. We had to get special permission from
> Microsoft before we could publish just a few benchmark
> timings for Common Larceny.
>
> That's too much hassle. Until Microsoft's licensing
> for .NET changes to permit benchmarking, I am unlikely
> to benchmark systems using .NET.
>
Hi
Thanks for the info :)
Microsoft has changed it's terms of the benchmarking clauses. From
what I can see this was only applicable to .NET 1.0 and 1.1, but both
have been updated and the limitations have been dropped.
More info here: http://msdn.microsoft.com/en-us/library/ms973265.aspx
Cheers
leppie
William D Clinger
> Microsoft has changed it's terms of the benchmarking clauses. From
> what I can see this was only applicable to .NET 1.0 and 1.1, but both
> have been updated and the limitations have been dropped.
>
> More info here: http://msdn.microsoft.com/en-us/library/ms973265.aspx
Thank you.
That's good news for everyone. Condition (3) is still
a little burdensome, in my opinion, as it looks like a
threat to sue anyone who publishes benchmark results for
.NET without reading and implementing "all performance
tuning and best practice guidance set forth in the product
documentation and/or on Microsoft's support Web sites" or
without installing all of "the latest updates, patches,
and fixes available for the .NET Component and the relevant
Microsoft operating system".
Although I have read some of Microsoft's product documentation
and some of the guidance provided by a few of their web sites,
I don't intend to read all of their product documentation and
web pages. Life is too short for that.
But a burdensome condition is better than a flat prohibition,
and I hope someone (such as the implementors of IronScheme)
will take advantage of Microsoft's current .NET license by
benchmarking .NET implementations of the R6RS and publishing
the results.
Will
George Neuner
wrote:
Mono is a few steps behind .NET and may not be as heavily optimized
yet. But the biggest factor is likely startup time - the .NET VM is
*always* running on Windows because the OS uses it. Mono generally is
not running on Unix and is started with the application.
Client Java VMs have the same liability in comparisons against .NET.
George
--
for email reply remove "/" from address
leppie
>
> Mono is a few steps behind .NET and may not be as heavily optimized
> yet. But the biggest factor is likely startup time - the .NET VM is
> *always* running on Windows because the OS uses it. Mono generally is
> not running on Unix and is started with the application.
The biggest bottleneck with Mono is the slow compile times for
dynamically generated code (Reflection.Emit).
Of course on Windows I have the liberty to 'ngen' the code, and make
startup time almost instant. 0.28 seconds for the REPL, which compares
well to other Scheme's :-)
I havent tried the AOT compiler in Mono though which is suppose to be
like NGen.
Cheers
leppie