You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all: Thanks a lot for the positive reactions and thanks @vultix for this reddit post. Also thanks to all who donated.
Because I don't have a reddit account, I will reply to some of the comments here.
@cbmuser:
And I assume it’s x86_64 only.
to which @barsoap responded:
Also ARM and RISC-V.
At the moment Cranelift only supports x86_64 enough to use cg_clif I think. It may also support x86,
but I haven't tested it. ARM support is very incomplete and RISC-V support hasn't been tested by me.
@ClimberSeb:
Thanks for making me aware of this!
I thought bjorn3 was financed by Mozilla.
How close roughly is the project from being viable for integration / general use?
Once Cranelift supports TLS and Atomics
(both necessary for multi-threading) it should be possible to run most programs. For a non-exhaustive
list of programs which currently work please see bjorn3/rustc_codegen_cranelift#247.
I wholeheartedly applaud this effort, but in my experience the biggest slowdown in debug iteration builds for me is not compiling but linking. As soon as you get into projects with 500+ bigger dependencies linktimes are 30s+.
Switching to ld.lld helps a lot but we're still talking 10s+ per iteration. I keep wondering if there's a way to "cache linking" so a linker could skip most of the work when I change a single line impacting 2 variables...
I am aware of the linker time problem. It takes quite a lot of
time for the compilation of cg_clif itself. On MacOS the linker times are worse with cg_clif, but on
Linux cg_clif is more than twice as fast with linking. (on one benchmark)
Note: Only the cg_llvm and cg_clif (object + object sysroot) are relevant right anymore. I recently removed the faerie backend.
For those who want to try this: The latest nightly changed some internal api's. I haven't yet updated
cg_clif for this, because my fix crashed the linker. For now you will have to use rustc 1.42.0-nightly (175631311 2020-01-10). (rustup override set nightly-2020-01-09)
The text was updated successfully, but these errors were encountered:
First of all: Thanks a lot for the positive reactions and thanks @vultix for this reddit post. Also thanks to all who donated.
Because I don't have a reddit account, I will reply to some of the comments here.
@cbmuser
:to which
@barsoap
responded:At the moment Cranelift only supports x86_64 enough to use cg_clif I think. It may also support x86,
but I haven't tested it. ARM support is very incomplete and RISC-V support hasn't been tested by me.
@ClimberSeb
:Nope, I am a student. :)
@jadbox:
Once Cranelift supports TLS and Atomics
(both necessary for multi-threading) it should be possible to run most programs. For a non-exhaustive
list of programs which currently work please see bjorn3/rustc_codegen_cranelift#247.
@almindor:
I am aware of the linker time problem. It takes quite a lot of
time for the compilation of cg_clif itself. On MacOS the linker times are worse with cg_clif, but on
Linux cg_clif is more than twice as fast with linking. (on one benchmark)
Note: Only the
cg_llvm
andcg_clif (object + object sysroot)
are relevant right anymore. Irecently removed the
faerie
backend.For those who want to try this: The latest nightly changed some internal api's. I haven't yet updated
cg_clif for this, because my fix crashed the linker. For now you will have to use
rustc 1.42.0-nightly (175631311 2020-01-10)
. (rustup override set nightly-2020-01-09
)The text was updated successfully, but these errors were encountered: