Hi Matthew,
On 8/1/2020 2:01 PM, Matthew Flatt wrote:
At Sat, 01 Aug 2020 03:56:36 -0400, George Neuner wrote:
> On Fri, 31 Jul 2020 20:20:05 -0700 (PDT),
> "wanp...@gmail.com"
> <wanpee...@gmail.com> wrote:
>
> >I noticed that the size of the CS version is 244% compare to BS
> >version. Wondering why it became so large. Does that mean Chez Scheme
> >runtime/vm 100 MB larger than the original one?
> >
> >Racket Mac OS X
> > 64-bit Intel 116.7 MB SHA1: 521b5a264afcfb3f390afacc682987268f650a25
> >
> >Racket CS Mac OS X
> > 64-bit Intel 285.8 MB SHA1: 060f311fc6621c5797a62f98b743499fa4277793
> >
> >https://pre-release.racket-lang.org/
>
>
> The CS version compiles to native code rather than portable bytecode,
> so pretty much everything in the distribution is somewhat larger. It
> adds up quickly.
That's still the best explanation I have, but I also think there must
be something more to it.
For example, the Chez Scheme boot files in uncompressed form add up to
about 8 times the size of compiled Racket BC executable, but Chez
Scheme doesn't have 8 times the functionality of the Racket BC
executable (so it should have 8 times as much machine code). The
machine code generated by Chez Scheme for its boot files is less
compact than machine code generated by GCC or LLVM for Racket BC's
implementation --- but, again, I don't think it's a factor of 8. So,
I'm optimistic that I've so far overlooked something that can make a
big difference.
I've concentrated more on understanding the difference in the run-time
memory footprints, and the difference there is not nearly so large.
Racket CS now sometimes has a smaller memory footprint than Racket BC
(e.g., peak memory use for a distribution build).
Matthew
I don't know details of the Racket bytecode, but I'm assuming that it is
a mix of simpler operations that map directly to one or a few native
instructions, and more complex operations that compile to (the
equivalent of) a small function. Probably some of these functions can
be inlined, but I expect there still would be some that can't.
To understand the difference in code size, you would need to look at the
lengths of bytecode instructions vs their native code equivalents, and
account for instances of those operations that can be inlined and for
calls to the functions for operations that can't.
As I said above, I don't know details of Racket bytecode, but a lot of
virtual machines use 8 or 16 bit opcodes and (allowing for immediate
operands) have average instruction lengths of 3..4 bytes. Contrast this
with, e.g., x86-64 code in which the average instruction is 5..6 bytes
[larger if many instructions require length prefixes (e.g., 32-bit ops
in 64-bit code)]. The difference can add up very quickly.
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/c3324f5f-19cd-1e0f-3d83-08787474bede%40comcast.net.
