![]() Previously: when a generation (say 2) is collected, everything in gen 0 moves to gen 1 everything in gen 1 moves to gen 2 everything in gen 2 moves to gen 3 Now: when a generation (say 2 again) is collected everything in gen 0 moves to gen 3 everything in gen 1 moves to gen 3 everything in gen 2 moves to gen 3 So, some objects get a leap from young to old if they're lucky to be in the right time. Consequences: when an object is moved by the collector, we don't need to track old->new pointers and masks because all moved objects are clean now. This both simplifies the collector and makes it more efficient and might open the door for further optimization opportunities. For bootstrap time, we get about 5% overall saving and about 20% GC-time saving. Not bad. BEFORE: running stats for macro expansion: 45 collections 2558 ms elapsed cpu time, including 212 ms collecting 2576 ms elapsed real time, including 216 ms collecting 186972152 bytes allocated running stats for code generation and serialization: 86 collections 4365 ms elapsed cpu time, including 1444 ms collecting 4374 ms elapsed real time, including 1449 ms collecting 362819096 bytes allocated running stats for the entire bootstrap process: 131 collections 6928 ms elapsed cpu time, including 1657 ms collecting 6953 ms elapsed real time, including 1666 ms collecting 549818232 bytes allocated AFTER: running stats for macro expansion: 45 collections 2506 ms elapsed cpu time, including 169 ms collecting 2511 ms elapsed real time, including 171 ms collecting 186968056 bytes allocated running stats for code generation and serialization: 86 collections 4083 ms elapsed cpu time, including 1189 ms collecting 4085 ms elapsed real time, including 1191 ms collecting 362810904 bytes allocated running stats for the entire bootstrap process: 131 collections 6591 ms elapsed cpu time, including 1359 ms collecting 6599 ms elapsed real time, including 1362 ms collecting 549805944 bytes allocated Happy Happy Joy Joy |
||
---|---|---|
benchmarks | ||
benchmarks.larceny | ||
doc | ||
lab | ||
lib | ||
other-libs | ||
scheme | ||
src | ||
.bzrignore | ||
ACKNOWLEDGMENTS | ||
BUGS | ||
COPYING | ||
DEDICATIONS | ||
GPL-3 | ||
HOWTO-Contribute | ||
Makefile.am | ||
Makefile.in | ||
README | ||
aclocal.m4 | ||
compile | ||
config.guess | ||
config.h.in | ||
config.sub | ||
configure | ||
configure.ac | ||
depcomp | ||
install-sh | ||
missing | ||
mkinstalldirs |
README
Ikarus Scheme is an implementation of the Scheme programming language. The preliminary release of Ikarus implements the majority of the features found in the current standard, the Revised 6 report on the algorithmic language Scheme including full R6RS library and script syntax, syntax-case, unicode strings, bytevectors, user-defined record types, exception handling, conditions, and enumerations. Over 80% of the R6RS procedures and keywords are currently implemented and subsequent releases will proceed towards brining Ikarus to full R6RS conformance. The main purpose behind releasing Ikarus early is to give Scheme programmers the opportunity to experiment with the various new features that were newly introduced in R6RS. The most important of such features is the ability to structure large programs into libraries; where each library extends the language through procedural and syntactic abstractions. Many useful libraries can be written using the currently supported set of R6RS features including text processing tools, symbolic logic systems, interpreters and compilers, and many mathematical and scientific packages. It is my hope that this release will encourage the Scheme community to write and to share their most useful R6RS libraries.