SyslabCC: Suzhou-Tongyuan's proprietary Julia AOT compiler is now available for free use (personal & educational license only)

[thautwarm]

Well, Palli, the questions you asked are great. However, I might not respond them on the weekends. I will answer with more details in a GH repo, but now I just answer a few of them.

@Palli

The proprietary license is a con, that some would not touch

I’m just an employee, and I personally think there are tremendous benefits to open-sourcing this compiler: people could the static compiler to enable more use cases for Julia, and eases TTFX issues, which also greatly helps the company’s products which integrate some open-source Julia libraries. I did show my attitude to the managers multiple times, but that’s the fact. I’m not a decision maker, but I also understand the small company adopts Julia needs financial gain to continue.

@Palli

I understand you compile Julia to C++. I.e. all the licenses of your original code apply, e.g. if you have GPL source code, but the replacement runtime you provide is I assume at least royalty-free for all users. Or actually freely licensed? Since if it’s proprietary then it will conflict with GPL/copyleft.

Respecting licenses is the basic thing. In terms the compiler itself, several open-source libraries under MIT license are used (e.g., bdwgc). If users use our compiler to link shared libraries under GPL license or other licenses not compatible to MIT, the mechanisms should be similar to GCC or any other compiler.

@Palli

C++ uses RAII, it seems you can’t compile to such idiomatic C++ code, do you add a Boehm-style GC?

We uses bdwgc.

@Palli

I doubt your GC is the reason for the min. size of the compiled code you provide, I guess this is it:

That is not the reason. The AOT compiler achieves smaller size by trimming. Besides, we reimplement all Julia intrinsics, and write our own compilation pipeline based on code_typed_by_type. You can find some design details in my previous reply at this thread.

I will give the design later in a GH repo, with more detailed slides and code examples.

@Palli

Is the C++ code you generate readable? Does it compile to templated C++ code, since Julia’s code is generic?

Not readable if you compare with the source code. I did say that we started at the IR level.
The codegen target now needs templates and overloading due to our approach to transpile Julia intrinsics. Hence, we now need C++ or similar languages to be the target.

Can you then use any C++ compiler? I suppose, or not a Windows compiler (why that limitation)?

I think there is no hard restriction to the platform or the compiler. In the later version, we’ll produce pure C++ source code (but also shared libraries mentioned in ccall) with a CMake project. You can even build binaries for Android/iOS.

@Palli

I.e. current and future Julia syntax; and really all future Julia semantics (at least in Julia’s standard lib) assuming such Julia code type-stable, and compiling to same LLVM IR?

Right but no LLVM IR. We do want to target LLVM IR, which hugely reduces the tasks of implementing some intrinsics. Unfortunately, the internal goal of our compiler is to support C/C++ codegen. I don’t think LLVM CBE is production ready.

@Palli

only if const though this doesn’t seem like a huge limitation, you want globals const anyway, only do not do by accident, or maybe in exploratory/REPL programming.

I mean, when you do static compilation, you should avoid referencing them. Besides, we do can allow the occurrences of visiting non-const global variables, but it will throw when the execution path gets triggered.

We also support rand, not using Base.rand but a random algorithm developed by our Math group in Suzhou-Tongyuan, just to avoid non-const global variables and libuv tasks. Anyway, too many details to expand here, I’ll give more info in the GH repo.

@Palli

Is that a limitation, i.e. matrix division and anything more complex than +, * not supported, or were you just not specific? I.e. all of OpenBLAS is actually supported, and e.g. BLIS.jl if opting into that?

a * b may require BLAS in Julia, and our AOT compiler respects this.

In the default case, the generated binaries link to OpenBLAS. However, Thanks to JuliaLinearAlgebra/libblastrampoline, linking to other BLAS implementation needs only a few ccalls.

@Palli

Since you compile to C++ you could e.g. use your code from R I suppose (not just Python)? C++ is commonly used there, though I think with some special interface, so I do not expect a drop-in support, just a hypothetical. Or you think easy?

Well, we export function symbols, just like what we did in C with a C compiler.

See this code and you might get it immediately.

if @isdefined(SyslabCC)
    # we export the symbol `cfft`
    SyslabCC.static_compile(
        "cfft",
        myfft!,
        (Ptr{ComplexF64}, Ptr{ComplexF64}, Int32, Int32)
    )
end

@Palli

I do not see a good reason native Julia to be (faster or) slower than the speed of the compiled code with this compiler:

binary-trees - Which programs are fastest? (Benchmarks Game)

Unfortunately, binaries produced by the AOT compiler are usually slightly slower than Julia.

The main reason could be the GC. bdwgc can be too general, object boxing costs much. In some computation-intensive cases, we find the code get 50% slower without preallocation.

We might be faster on exception handling, but we finally figure out that is due to our simplification to the stacktrace.

@Palli

Can anyone try to compile some of the worse performing benchmarks, such as the one above? In that case it’s 156 times slower than some other languages, likely because of allocations (for a tree) and free deferred done by GC.

I’ll do this on Monday. It’s very interesting to have such comparison.