Even if using the LLVM c backend?
Yes, why would that help? The LLVM C backend is not really useful unless you’re on a platform that has a C compiler but not an LLVM backend.
Two reasons. I assume more platforms have C compilers than LLVM backends (is this true?) you wouldn’t need LLVM patches or backend.
Also, Can’t one also precompile platform specific binaries from the C code?
This doesn’t really make any sense to me. How are you proposing to use the LLVM C backend?
I thought I recalled that the LLVM C backend converts LLVM bytecode to C? Perhaps i misunderstood
Yes, that’s what it does. How does that help the situation?
The issues are code size and portability.
C and or compiled C code are both more portable than Julia outputted LLVM bytecode and don’t require bundling LLVM patches. If the c code isn’t too bloated, I assume this would also reduce distribution size.
Aside from platforms where there is no LLVM backend, any situation in which you could use the C backend to generate C code and then compile that C code to produce a binary, you could just as easily just generate a binary directly. How does going through C help anything?
Aside from platforms where there is no LLVM backend
Is that a non marginal usecase?
Side discussion on LLVM C backend
you could just as easily just generate a binary directly.
I’m just surmising here: Would this require carrying LLVM patches? Do these patches have a non negligible affect on distribution size? Would the C generated code be smaller due to not requiring these patches?
If yes to all three questions, then going through C would seem to help to a valuable degree.
It is a very marginal use case.
Would this require carrying LLVM patches?
The LLVM frontend would still require the same patches it has now in order to function correctly and generate correct output, regardless of whether the output is native machine code or C code.
Do these patches have a non negligible affect on distribution size?
Distribution size of what? The patches are small. The main “negative” effect of requiring patches to LLVM is that we cannot use the “vanilla” LLVM libraries that distros ship so Julia has to include its own patched copy of libLLVM. I’m not entirely sure why anyone is upset about a 40 MB shared library in 2019.
Would the C generated code be smaller due to not requiring these patches?
No, it has no affect on the size of the generated output. The patches are required to generate correct code that doesn’t crash, however. We generally consider not crashing a good thing.
2 Likes
I think I’m referring to distributing code to users who don’t care about the source language or LLVM, and you are talking about the source machine, correct?
For example, it seems running the LLVM generated code on another Julia naive machine would require bundling the 40 mb llvm library.
No, not if the generated c code doesn’t need it.
1 Like
Yes, that’s my point. Using generated C code saves 40mb from the bundle when distributed to another Julia naive machine…hence the benefit of the LLVM c backend.
But what about memory management and generated functions?
No I’m saying that llvm generated binary code does not need llvm runtime to run either.
Ie there’s no saving.
Memory management and generated functions are completely irrelevant to the backend.
They’re irrelevant to the backend’s operation, but they’re not irrelevant to how the generated C code can actually be utilized by an end user. If I use llvm-cbe to compile down some Julia code to C, and that code relies on using Tasks, generated functions, etc., then what else will I have to ship with that C code to get the final application to build and run? That was the point of the original discussion that this thread was forked from.
Nothing you mentioned will be different if c back end is used. (If even usable)…
So to be specific, one would still have to ship libjulia and any dynamic libraries that are called by the compiled C code (like if it has non-precompiled generated functions, so codegen needs to be run). Is that correct?
Edit: If so, then the thing that the llvm-cbe backend gives us is not necessarily much better than what PackageCompiler gives us. We really only get the benefit of having (maybe readable) source that can be compiled locally, but the total size of a compiled application and shipped binaries may still be huge compared to other programs which compile down to a single static binary.
Since Julia is JITted these are the same unless you’re able to completely statically compile your program to something that doesn’t need JIT. If that’s the case you can generate a binary that doesn’t depend on libLLVM regardless of what backend it uses.
If the resulting program doesn’t need to be able to generate more code then you don’t need libLLVM regardless of which backend you use.
3 Likes
If you simply switch to the c backend, yes.
If you can remove that dependency when using c backend, then the same dependency can be removed when using other backend exactly the same way.
3 Likes