Julia is amazing!
ok, there are too many Math inside and too many features for a “common” like “minimal” use, like in the web. just the bare minimal…
There is a way to “remove” undesirable packages, maybe compiling it by ourselves with some (many…) params like --without-math-extras --withou… --without …, like a slack way of compiling things?
thanks!
1 Like
Are you thinking of something more like Python, where you are required to import more things before using them? I’m sort of in favor of that. But, at this point, it would be difficult to achieve. You’d have to make your own fork of Julia and it would break packages. It imagine this topic will be considered for Julia v2.0.
1 Like
imho: in Julia 1.8: ~slim binary expected ; see this merged PR
JuliaLang:master ← JuliaLang:jb/separate_codegen
opened 07:59PM - 19 Aug 21 UTC
This is a follow-up to #39129. The current state of the PR is that by default, e… verything works as normal, except during the build we generate both libjulia-internal (which does not link against LLVM) and libjulia-codegen (which does). The loader attempts to load libjulia-codegen after libjulia-internal. If that fails, it populates the codegen entry points with fallbacks in libjulia-internal that do nothing. That means you can simply delete libjulia-codegen, start with --compile=no, and enjoy a compiler-free julia runtime (assuming you don't actually need the compiler of course :smile: ).
This probably still needs a bunch of cleanup, and it also tends to segfault with --compile=no, which I assume can be fixed.
All in all, the loader framework we have is quite a nice way to separate the system into multiple optional components, and I foresee doing more of that. The parser and front-end would be another logical component to separate (and then ultimately replace with a new implementation written in julia and separately compiled!). It would be nice if we could streamline adding plugins a bit --- naturally, we thought the loader would only ever load one thing, so a few too many places need to be modified to add another.
If you are interested for other compiler work ( ~ in the roadmap )
2 Likes
sashmit
November 24, 2021, 4:02pm
4
the “standard” way, at least in web circles, is compiler dead code elimination:
In compiler theory, dead-code elimination (also known as DCE, dead-code removal, dead-code stripping, or dead-code strip) is a compiler optimization to remove code which does not affect the program results. Removing such code has several benefits: it shrinks program size, an important consideration in some contexts, and it allows the running program to avoid executing irrelevant operations, which reduces its running time. It can also enable further optimizations by simplifying program structure...
or in other words, what you don’t use you don’t pay for
2 Likes
thanks!!!
