6 ms·
> And it's small. Currently the interpreter, JIT, GC, and stdlib clock in at about 10.3MB once compiled down to an executable. Oh how the definition of "small"
by copx 10y ago
> And it's small. Currently the interpreter, JIT, GC, and stdlib clock in at about 10.3MB once compiled down to an executable.
Oh how the definition of "small" has changed. I actually would like to know how they managed to make something like this so big.
To compare, LuaJIT is about 400 KB, and that includes the Lua standard library, a JIT almost certainly more advanced than Pixie's current one, an incremental GC, and a C FFI.
Neither compilers (well, except C++ ones), nor stuff you usually find in standard libraries, nor a GC should require much code to implement, relatively speaking (e.g. compared to a WYSIWYG word processor). These things are usually small. The compilers for almost every language were < 1 MB in size for the longest time.
I am not saying that Pixie being 10 MB in size is a problem. We have a lot more bandwidth and disk space nowadays, 10 MB is nothing. My point is that a "JIT, GC, and stdlib" package weighing this much cannot claim to be "small" for what it does.
- nine_k 10y agoI wonder if it's a stripped binary.
- vram22 10y agoYes, at least on Unixes, stripping could reduce the sizes of binaries by quite a bit.
- stcredzero 10y agoTo compare, LuaJIT is about 400 KB, and that includes the Lua standard library, a JIT almost certainly more advanced than Pixie's current one, an incremental GC, and a C FFI. Back in the day, Smalltalk was criticized as bloated because one ended up with stripped binary+image of about 2MB. Someone around that time got SqueakVM+image down to just under 400k. There were specialized Smalltalks in company R&D that got their image down to 45k.
- throwaway7645 10y agoInteresting historical note!
- beamatronic 10y agoDon't forget, even 2 MB was still a somewhat inconvenient size when floppy disks were only at 1.44 MB capacity.
- stcredzero 10y agoFloppy disks were well on their way out, and people were still complaining about a 2 MB footprint.
- timClicks 10y agoI thought Smalltalk's hayday was early-mid 80s. That would imply 5.25" floppies would still be in use and 3.5" floppies overtaking them circa 1988.
- stcredzero 10y agoI thought Smalltalk's hayday was early-mid 80s. My involvement with Smalltalk started in the 90's. Then it still had high penetration in the Fortune 500, and it was a niche language for complex financial programs. It was also used in Energy.
- oska 10y agoThe Oberon Operating System and compiler was 131 KB. [1] [1] http://users.cms.caltech.edu/~cs140/140a/Oberon/system_faq.html http://users.cms.caltech.edu/~cs140/140a/Oberon/system_faq.h...
- jlarocco 10y agoWell, for comparison "Hello World" in Common Lisp, using SBCL on x64 Linux creates a ~70 Mb binary, but nobody would ever claim it's small :-) Unfortunately, for an arbitrary CL program it's impossible to tell for sure how much of the CL compiler and standard library it will need at run time, so SBCL takes the easy route and just includes everything. Some of the commercial Lisp compilers are a lot smarter at stripping things out and and can create significantly smaller executables. I usually avoid the issue altogether by not building binaries and running most things from the REPL or using a "#!/usr/bin/lisp --script" shebang line.
- gkya 10y agoSBCL does not create binaries per se, but dumps the program image. While it practically is a binary, it's not equal to an executable that a conventional compiler/linker produces.
- SolarNet 10y agoExcept without a better way to package a binary it will be compared as one.
- jlarocco 10y agoThat distinction isn't important here, though. It is the reason the resulting file is so big, but for all practical purposes it's a binary that statically links the full CL runtime.
- throwaway91111 10y agoI wonder why tree shaking is so ineffective. Is that because any symbol could be accessed dynamically at runtime?
- jfoutz 10y agoeval is the root of all evil. String to symbol lets you introduce anything.
- haberman 10y agoI agree with your point completely. I just want to add that throwing out raw numbers like "10.3MB" or "400 KB" is not very precise. Binaries can vary immensely based on whether they have debug info, string tables, etc. or whether these have been stripped away. I wrote a size profiling tool that can give much more precise measurements (like size(1) on steroids, see: https://github.com/google/bloaty https://github.com/google/bloaty). Here is output for LuaJIT: $ bloaty src/luajit -n 5 VM SIZE FILE SIZE -------------- -------------- 74.3% 323Ki .text 323Ki 73.8% 12.5% 54.5Ki .eh_frame 54.5Ki 12.4% 7.6% 33.2Ki .rodata 33.2Ki 7.6% 2.2% 9.72Ki [Other] 12.9Ki 2.9% 2.1% 9.03Ki .eh_frame_hdr 9.03Ki 2.1% 1.2% 5.41Ki .dynsym 5.41Ki 1.2% 100.0% 435Ki TOTAL 438Ki 100.0% And for Pixie: $ bloaty pixie/pixie-vm -n 5 VM SIZE FILE SIZE -------------- -------------- 57.5% 4.39Mi .text 4.39Mi 44.7% 33.7% 2.58Mi .data 2.58Mi 26.3% 0.0% 0 .symtab 1.31Mi 13.4% 0.0% 0 .strtab 978Ki 9.7% 8.8% 688Ki [Other] 595Ki 5.9% 0.0% 8 [None] 0 0.0% 100.0% 7.64Mi TOTAL 9.82Mi 100.0% In this case, neither binary had debug info. Pixie does appear to have a symbol table though, which LuaJIT has mostly stripped. In general, I think "VM size" is the best general number to cite when talking about binary size, since it avoids penalizing binaries for keeping around debug info or symbol tables. Symbol tables and debug info are useful; we don't want people to feel pressured to strip them just to avoid looking bad in conversations about binary size.
- sabauma 10y agoIts worth noting that the design of the RPython JIT will always result in a large amount of static data in the resulting binary. The RPython translator basically generates a bytecode representation of most of your interpreter and bakes that into the binary. You can probably expect at least a 2x size increase in the size of your binary. As a reference point, after stripping [Pycket](https://github.com/pycket/pycket)'s https://github.com/pycket/pycket)'s binaries are 6.1Mi without the JIT and 16Mi with the JIT.
- ww520 10y ago10.3MB definitely is not small. I was expecting couple hundreds of K, or 1M.