StaticCompiler.jl
oneAPI.jl
StaticCompiler.jl | oneAPI.jl | |
---|---|---|
16 | 4 | |
474 | 174 | |
- | 1.7% | |
6.9 | 8.7 | |
about 1 month ago | 9 days ago | |
Julia | Julia | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
StaticCompiler.jl
-
Potential of the Julia programming language for high energy physics computing
Yes, julia can be called from other languages rather easily, Julia functions can be exposed and called with a C-like ABI [1], and then there's also various packages for languages like Python [2] or R [3] to call Julia code.
With PackageCompiler.jl [4] you can even make AOT compiled standalone binaries, though these are rather large. They've shrunk a fair amount in recent releases, but they're still a lot of low hanging fruit to make the compiled binaries smaller, and some manual work you can do like removing LLVM and filtering stdlibs when they're not needed.
Work is also happening on a more stable / mature system that acts like StaticCompiler.jl [5] except provided by the base language and people who are more experienced in the compiler (i.e. not a janky prototype)
[1] https://docs.julialang.org/en/v1/manual/embedding/
[2] https://pypi.org/project/juliacall/
[3] https://www.rdocumentation.org/packages/JuliaCall/
[4] https://github.com/JuliaLang/PackageCompiler.jl
[5] https://github.com/tshort/StaticCompiler.jl
-
Julia App Deployment
PackageCompiler, but it' s a fat runtime and not cross compile. A thin runtime is currently not possible without sacrifices for feature as https://github.com/tshort/StaticCompiler.jl.
-
JuLox: What I Learned Building a Lox Interpreter in Julia
https://github.com/tshort/StaticCompiler.jl/issues/59 Would working on this feasible?
- Making Python 100x faster with less than 100 lines of Rust
- What's Julia's biggest weakness?
-
Size of a "hello world" application
I just read the project's documentation at https://github.com/tshort/StaticCompiler.jl. It does produce a "hello world" application that is only 8.4k in size đź‘Ť. I do like that it can work on Mac OS. Hopefully Windows support will come soon.
-
Why Julia 2.0 isn’t coming anytime soon (and why that is a good thing)
See https://github.com/tshort/StaticCompiler.jl
- My Experiences with Julia
-
Julia for health physics/radiation detection
You're probably dancing around the edges of what [PackageCompiler.jl](https://github.com/JuliaLang/PackageCompiler.jl) is capable of targeting. There are a few new capabilities coming online, namely [separating codegen from runtime](https://github.com/JuliaLang/julia/pull/41936) and [compiling small static binaries](https://github.com/tshort/StaticCompiler.jl), but you're likely to hit some snags on the bleeding edge.
-
We Use Julia, 10 Years Later
using StaticCompiler # `] add https://github.com/tshort/StaticCompiler.jl` to get latest master
oneAPI.jl
-
GPU vendor-agnostic fluid dynamics solver in Julia
https://github.com/JuliaGPU/oneAPI.jl
As for syntax, Julia syntax scales from a scripting language to a fully typed language. You can write valid and performant code without specifying any types, but you can also specialize methods for specific types. The type notation uses `::`. The types also have parameters in the curly brackets. The other aspect that makes this specific example complicated is the use of Lisp-like macros which starts with `@`. These allow for code transformation as I described earlier. The last aspect is that the author is making extensive use of Unicode. This is purely optional as you can write Julia with just ASCII. Some authors like to use `ε` instead of `in`.
- Writing GPU shaders in Julia?
-
Cuda.jl v3.3: union types, debug info, graph APIs
https://github.com/JuliaGPU/AMDGPU.jl
https://github.com/JuliaGPU/oneAPI.jl
These are both less mature than CUDA.jl, but are in active development.
-
Unified programming model for all devices – will it catch on?
OpenCL and various other solutions basically require that one writes kernels in C/C++. This is an unfortunate limitation, and can make it hard for less experienced users (researchers especially) to write correct and performant GPU code, since neither language lends itself to writing many mathematical and scientific models in a clean, maintainable manner (in my opinion).
What oneAPI (the runtime), and also AMD's ROCm (specifically the ROCR runtime), do that is new is that they enable packages like oneAPI.jl [1] and AMDGPU.jl [2] to exist (both Julia packages), without having to go through OpenCL or C++ transpilation (which we've tried out before, and it's quite painful). This is a great thing, because now users of an entirely different language can still utilize their GPUs effectively and with near-optimal performance (optimal w.r.t what the device can reasonably attain).
[1] https://github.com/JuliaGPU/oneAPI.jl
What are some alternatives?
julia - The Julia Programming Language
ROCm - AMD ROCm™ Software - GitHub Home [Moved to: https://github.com/ROCm/ROCm]
PackageCompiler.jl - Compile your Julia Package
Vulkan.jl - Using Vulkan from Julia
acados - Fast and embedded solvers for nonlinear optimal control
Makie.jl - Interactive data visualizations and plotting in Julia
GPUCompiler.jl - Reusable compiler infrastructure for Julia GPU backends.
AMDGPU.jl - AMD GPU (ROCm) programming in Julia
LoopVectorization.jl - Macro(s) for vectorizing loops.
Octavian.jl - Multi-threaded BLAS-like library that provides pure Julia matrix multiplication
KernelAbstractions.jl - Heterogeneous programming in Julia