[Openmcl-devel] Alpha-testing 0.14

[Sven Van Caekenberghe]

On Saturday, March 1, 2003, at 01:58 AM, Gary Byers wrote:

> On Fri, 28 Feb 2003, Sven Van Caekenberghe wrote:
>
>> I did some test of 0.14 (latest CVS update of today).
>>
>> My xml-rpc code all compiled and ran fine (as far as I could tell):
>> this means that simple MP usage has remained unchanged.
>>
>
> I'll try to port paserve; I think that it'd be a good example and
> could serve as the basis for a porting guide.

I would certainly like to help: I have been using paserve on a project 
the last month: it did ran fine on openmcl and should keep on running 
well, it is excellent stuff.

Do you plan to start your porting effort on the latest CVS version or 
the latest released version 1.12.2c ?
On openmcl 0.13.4 I have only been using 1.12.2c, the CVS version 
didn't load/compile well the last time I tried (and will have another 
look when I find time). On cmucl I have been using both versions 
(actually only the CVS version worked fine there).

>> I also ran Eric Marsden's cl-bench Benchmarks, comparing 0.13.4 to
>> 0.14, on my PowerBook G4 / 667 (Gigabit Ethernet, thus no L3 cache).
>> All benchmark code compiled and ran OK (or so it seemed).
>>
>
> With the exception of the hash-table tests (which now have to deal with
> OS-level locking), I'd expect things to be slightly faster in 0.14; I
> don't know that I'd even expect that difference to be measurable.
>
> It's surprising that there seems to generally be a measurable 
> difference
> in the other direction.

Maybe the benchmarking conditions were not perfect, I will send you a 
tarball with my code (I made some little changes some time ago the 
first time I tried running cl-bench on openmcl, but I can't remember 
exactly which ones, I did send them to eric though). Anybody else 
interested in the code, just ask.

> I'd have expected STAK to be slightly faster in 0.14 (for fairly
> obscure reasons related to how special binding/reference work now).  I
> tried it a moment ago on a 700MHz eMac; 100 iterations of (STAK 18 12
> 6) took a little less time (both real-time and run-time) in 0.14 than
> in 0.13.4, which is consistent with my expectations.  I wouldn't
> expect a 2X difference in either direction, and I wonder how Eric's
> code obtained that result.
>
> I -think- that things should be a little faster in most cases, because
> the "background noise" associated with the cooperative scheduler has
> been eliminated.  (Try running "top" in the shell when the lisp is 
> idle;
> I think that it overstated the background noise in 0.13, but it doesn't
> seem to indicate that the lisp is working very hard to do nothing in 
> 0.14.)
>
> It's probably more important to worry about getting things right at 
> this
> stage than to worry about making them fast, but if there is some source
> of overhead I'd like to better understand what it is.
>
>> All this seems quite nice for an alpha version: I was trying to find
>> some bugs ;-)
>
> Please don't get discouraged: I think that we're still at the point 
> where
> just compiling and running code exposes bugs in parts of the system 
> that
> haven't been exercised ...

I'll keep on trying. I will try turning the benchmark in a stress test: 
run each test once in a loop multiplied by a number of threads... I'll 
let you know how that goes.

Sven


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel