From 5718697d60f3d298b83c32be210fd678461acde4 Mon Sep 17 00:00:00 2001 From: dybvig Date: Fri, 6 May 2016 23:04:44 -0400 Subject: [PATCH] updated release_notes.stex to describe the recent fixes for bugs that 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 --- release_notes/release_notes.stex | 86 +++++++++++++++++++------------- 1 file changed, 50 insertions(+), 36 deletions(-) diff --git a/release_notes/release_notes.stex b/release_notes/release_notes.stex index d0ef07fbf9..3e08f1934f 100644 --- a/release_notes/release_notes.stex +++ b/release_notes/release_notes.stex @@ -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}