suzanne.soy/racket
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

updated release_notes.stex to describe the recent fixes for bugs that

Browse Source 
dated back to Version 8.4 or before and to combine the three performance
subsections directly related to the new compiler back-end, since the
changes all occurred between publicly available releases.

original commit: 65df1d1f7c37f5b5a93cd7e5b475dda9dbafe03c
This commit is contained in:
dybvig 2016-05-06 23:04:44 -04:00
parent be6dbc08d8
commit 5718697d60
1 changed files with 50 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

86
release_notes/release_notes.stex
View File

@ -771,7 +771,7 @@ executed.
There is no mechanism for the programmer to view block counts, but
both block counts and source counts can now be saved after a sample
run of the generated code for use in guiding various optimations
run of the generated code for use in guiding various optimizations
during a subsequent compilation of the same code.
The source counts can be used by ``profile-aware macros,'' i.e.,
@ -1421,6 +1421,43 @@ in fasl files does not generally make sense.
%-----------------------------------------------------------------------------
\section{Bug Fixes}\label{section:bugfixes}
\subsection{\protect\scheme{string->number} and reader numeric syntax issues (9.4)}
\scheme{string->number} and the reader previously treated all complex
numbers written in polar notation that Chez Scheme cannot represent
exactly as inexact, even with an explicit \scheme{#e} prefix.
For such numbers with the \scheme{#e} prefix, \scheme{string->number}
now returns \scheme{#f} and the reader now raises an exception with
condition type \scheme{&implementation-restriction}.
Both still return an inexact representation for such numbers written without
the \scheme{#e} prefix, even if R6RS requires an exact result, i.e.,
even if they have no decimal point, exponent, or mantissa width.
Ratios with an exponent, like \scheme{1/2e10}, are non-standard and
now cause cause the procedure \scheme{string->number} imported from
\scheme{(rnrs)} to return \scheme{#f}.
When the reader encounters a ratio followed by an exponent while in R6RS
mode (i.e., when reading a library or top-level program and not following
an \scheme{#!chezscheme}, or when following an explicit \scheme{#!r6rs}),
it raises an exception.
Positive or negative zero followed by a large exponent now properly
produces zero rather than an infinity, e.g., \scheme{0e3000} now produces
\scheme{0} rather than \scheme{+inf.0}.
A rounding bug converting some small ratios into floating point numbers,
when those numbers fall into the range of denormalized floats, has
been fixed.
This bug also affected the reading of and conversion of strings into
denormalized floating-point numbers.
[Some of these bugs dated back to Version 3.0.]
\subsection{\protect\scheme{date->time-utc} ignoring zone-offset field (9.4)}
\scheme{date->time-utc} has been fixed to properly take into account the
zone-offset field.
[This bug dated back to Version 8.0.]
\subsection{\protect\scheme{dynamic-wind} mistakenly enabling interrupts (9.3.3)}
A bug causing \scheme{dynamic-wind} to unconditionally enable
@ -1793,14 +1830,19 @@ unprofiled run time.
(Unprofiled code is also slightly faster, but by less than 2\% in
our tests.)
\subsection{Improved compile times (8.9.5)}
\subsection{New compiler back-end (8.9.1, 8.9.2, 8.9.5)}
Due to a rework of the new compiler back-end, Version~8.9.5 compile
times are up to 20\% less in our tests, relative to Version~8.9.3,
with a corresponding reduction in memory allocation.
Compile runs that spend a significant portion of the time in macro
expansion will not benefit by as much.
Compile times are now reliably within a factor of two of Version~8.4.1
Versions starting with 8.9.1 employ a new compiler back end that is
structured as a series of nanopassees and replaces the old linear-time
register allocator with a graph-coloring register allocator.
Compilation with the new back end is substantially slower (up to a factor
of two) than with the old back end, while code generated with the new
back end is faster (14--40\% depending on architecture and optimization
level) in our tests.
These improvements are independent of improvements
resulting from cross-library constant folding and inlining
(Section~\ref{subsection:clcfai}).
The code generated for a specific program might be faster or slower.
\subsection{Open-coding of \protect\scheme{make-guardian} (8.9.4)}
@ -1841,32 +1883,4 @@ constructors created by a record definition in one library and exported
by another are inlined in the importing library, just as if the record
type were defined in the importing library.
\subsection{Faster generated code (8.9.2)}
The code generated by the new compiler back end
(Section~\ref{subsection:ncbe}) is faster.
In our tests comparing Versions~8.9.2 and~8.4.1 under Linux, Version~8.9.2
is faster on x86\_64 by about 14\% at optimize-level 3 and about 21\%
at lower optimization levels.
For x86, it is about 20\% faster at optimize-level 3 and about 25\%
faster at lower optimization levels.
Results for other operating systems should be about the same.
These improvements are independent of improvements resulting from
cross-library constant folding and inlining
(Section~\ref{subsection:clcfai}).
\subsection{New compiler back-end (8.9.1)\label{subsection:ncbe}}
Versions starting with 8.9.1 employ a new compiler back end.
As of Version~8.9.1, compilation using the new back end is approximately
2--3 times slower in our tests.
The code generated by the new back end for the x86\_64 is typically
about the same speed as code generated by the old back end, while the
code generated by the new back end for the x86 is typically faster,
by an average of around 13\% in our tests.
The code generated for a specific program might be faster or slower
on either processor.
The speed and effectiveness of the compiler should improve in subsequent
releases.
\end{document}