LLVM
-
Great optimisation, awwwful compile times.
New kid on the block, roc, has it right by splitting application code from "platform"/framework code, precompiling and optimising the platform, then using their fast surgical linker to sew the app code to the platform code.
Platforms are things like cli program, web server that kind of thing. Platforms provide an interface of domain specific IO primitives and handle all IO and memory management, and they also specify what functions app code must supply to complete the program.
It's pretty cool, and they're getting efficiency in the area of systems programming languages like C and Rust, but with none of the footguns of manual memory management, no garbage collection pauses, but yet also no evil stepparent style borrow checker to be beaten by. They pay a lot of attention to preventing cache misses and branch prediction failures, which is his they get away with reference counting and still being fast.
A note of caution: I might sound like I know about it, but I know almost nothing.
-
Yeah, I think Go's compiler is so fast partially because it doesn't use LLVM
That would work!
-
New kid on the block, roc, has it right by splitting application code from "platform"/framework code, precompiling and optimising the platform, then using their fast surgical linker to sew the app code to the platform code.
Platforms are things like cli program, web server that kind of thing. Platforms provide an interface of domain specific IO primitives and handle all IO and memory management, and they also specify what functions app code must supply to complete the program.
It's pretty cool, and they're getting efficiency in the area of systems programming languages like C and Rust, but with none of the footguns of manual memory management, no garbage collection pauses, but yet also no evil stepparent style borrow checker to be beaten by. They pay a lot of attention to preventing cache misses and branch prediction failures, which is his they get away with reference counting and still being fast.
A note of caution: I might sound like I know about it, but I know almost nothing.
wrote last edited by [email protected]That sounds pretty great. My impression is that relatively little code actually runs that often.
but with none of the footguns of manual memory management, no garbage collection pauses, but yet also no evil stepparent style borrow checker to be beaten by.
That part sounds implausible, though. What kind of memory management are they doing?
-
This post did not contain any content.
That's like... It's purpose. Compilers always have a frontend and a backend. Even when the compiler is entirely made from scratch (like Java or go), it is split between front and backend, that's just how they are made.
So it makes sense to invest in just a few highly advanced backends (llvm, gcc, msvc) and then just build frontends for those. Most projects choose llvm because, unlike the others, it was purpose built to be a common ground, but it's not a rule. For example, there is an in-developement rust frontend for GCC.
-
That sounds pretty great. My impression is that relatively little code actually runs that often.
but with none of the footguns of manual memory management, no garbage collection pauses, but yet also no evil stepparent style borrow checker to be beaten by.
That part sounds implausible, though. What kind of memory management are they doing?
wrote last edited by [email protected]Reference counting.
They pay a lot of attention to preventing cache misses and branch prediction failures, which is how they get away with reference counting and still being fast.
-
New kid on the block, roc, has it right by splitting application code from "platform"/framework code, precompiling and optimising the platform, then using their fast surgical linker to sew the app code to the platform code.
Platforms are things like cli program, web server that kind of thing. Platforms provide an interface of domain specific IO primitives and handle all IO and memory management, and they also specify what functions app code must supply to complete the program.
It's pretty cool, and they're getting efficiency in the area of systems programming languages like C and Rust, but with none of the footguns of manual memory management, no garbage collection pauses, but yet also no evil stepparent style borrow checker to be beaten by. They pay a lot of attention to preventing cache misses and branch prediction failures, which is his they get away with reference counting and still being fast.
A note of caution: I might sound like I know about it, but I know almost nothing.
-
Reference counting.
They pay a lot of attention to preventing cache misses and branch prediction failures, which is how they get away with reference counting and still being fast.
Oh, you just mean it's a kind of garbage collection that's lighter on pauses. Sorry, I've had the "my pre-Rust pet language already does what Rust does" conversation on here too many times.
-
Oh, you just mean it's a kind of garbage collection that's lighter on pauses. Sorry, I've had the "my pre-Rust pet language already does what Rust does" conversation on here too many times.
To be fair, the drop/dealloc "pause" is very different from what people usually mean when they say "garbage collection pause", i.e. stop-the-world (...or at least a slice of the world).
-
This post did not contain any content.wrote last edited by [email protected]
GCC is adding cool new languages too!
They just recently added COBOL and Modula-2. Algol 68 is coming in GCC 16.
-
That's like... It's purpose. Compilers always have a frontend and a backend. Even when the compiler is entirely made from scratch (like Java or go), it is split between front and backend, that's just how they are made.
So it makes sense to invest in just a few highly advanced backends (llvm, gcc, msvc) and then just build frontends for those. Most projects choose llvm because, unlike the others, it was purpose built to be a common ground, but it's not a rule. For example, there is an in-developement rust frontend for GCC.
that’s just how they are made.
Can confirm, even the little training compiler we made at Uni for a subset of Java (Javali) had a backend and frontend.
I can't imagine trying to spit out machine code while parsing the input without an intermediary AST stage. It was complicated enough with the proper split.
-
that’s just how they are made.
Can confirm, even the little training compiler we made at Uni for a subset of Java (Javali) had a backend and frontend.
I can't imagine trying to spit out machine code while parsing the input without an intermediary AST stage. It was complicated enough with the proper split.
I can imagine;
-
Oh, you just mean it's a kind of garbage collection that's lighter on pauses. Sorry, I've had the "my pre-Rust pet language already does what Rust does" conversation on here too many times.
wrote last edited by [email protected]It's a post rust language.
By your definition any automatic memory management is garbage collection, including rust!
Did you think rust doesn't free up memory for you? That would be the biggest memory leak in history! No! Rust does reference counting, it just makes sure that that number is always one! What did you think the borrow checker was for?
In roc, because the platform is in charge of memory management, it can optimise, so that a web server can allocate an arena for each client, a game loop can calculate what it needs in advance etc etc.
But like I say, they do a lot of work on avoiding cache misses and branch mispredictions, which are their own source of "stop the world while I page in from main memory" or "stop the pipeline while I build a new one". If it was doing traditional garbage collection, that would be an utterly pointless microoptimisation.
Rust isn't a religion. Don't treat it like one.
When it was very new a bunch of C programmers shit on its ideas and said C was the only real systems programming language, but rust, which was pretty much Linear ML dressed up in C style syntax came from hyper weird functional programming language to trusted systems programming language. Why? Because it does memory management sooooo much better than C and is just about as fast. Guess what roc is doing? Memory management soooooo much better than C, and sooooo much less niggly and hard to get right than the borrow checker and is just about as fast.
Plenty of beginners program in rust by just throwing clone at every error the borrow checker sends them, or even unsafe! Bye bye advantages of rust, because it was hard to please. Roc calculates from your code whether it needs to clone (eg once for a reference to an unmodified value, each time for an initial value for the points in a new data structure), and like rust, frees memory when it's not being used.
Rust does manual cloning. Roc does calculated cloning. Rust wins over C for memory safety by calculating when to free rather than using manual free, totally eliminating a whole class of bugs. Roc could win over rust by calculating when to clone, eliminating a whole class of unnecessary allocation and deallocation. Don't be so sure that no one could do better than rust. And the devXP in rust is really poor.
-
This post did not contain any content.
Isn't Zig working on their own backend?
Also, pretty excited about the cranelift project.
-
GCC is adding cool new languages too!
They just recently added COBOL and Modula-2. Algol 68 is coming in GCC 16.
cool new languages
COBOL
-
Reference counting.
They pay a lot of attention to preventing cache misses and branch prediction failures, which is how they get away with reference counting and still being fast.
I wish more languages used ref counting. Yes, it has problems with memory cycles, but it's also predictable and fast. Works really well with immutable data.
-
I wish more languages used ref counting. Yes, it has problems with memory cycles, but it's also predictable and fast. Works really well with immutable data.
Roc uses immutable data by default. It performs opportunistic in-place mutation when the reference count will stay 1 (eg this code would satisfy the borrow checker without cloning or copying if it were rust - static code analysis).
-
It's a post rust language.
By your definition any automatic memory management is garbage collection, including rust!
Did you think rust doesn't free up memory for you? That would be the biggest memory leak in history! No! Rust does reference counting, it just makes sure that that number is always one! What did you think the borrow checker was for?
In roc, because the platform is in charge of memory management, it can optimise, so that a web server can allocate an arena for each client, a game loop can calculate what it needs in advance etc etc.
But like I say, they do a lot of work on avoiding cache misses and branch mispredictions, which are their own source of "stop the world while I page in from main memory" or "stop the pipeline while I build a new one". If it was doing traditional garbage collection, that would be an utterly pointless microoptimisation.
Rust isn't a religion. Don't treat it like one.
When it was very new a bunch of C programmers shit on its ideas and said C was the only real systems programming language, but rust, which was pretty much Linear ML dressed up in C style syntax came from hyper weird functional programming language to trusted systems programming language. Why? Because it does memory management sooooo much better than C and is just about as fast. Guess what roc is doing? Memory management soooooo much better than C, and sooooo much less niggly and hard to get right than the borrow checker and is just about as fast.
Plenty of beginners program in rust by just throwing clone at every error the borrow checker sends them, or even unsafe! Bye bye advantages of rust, because it was hard to please. Roc calculates from your code whether it needs to clone (eg once for a reference to an unmodified value, each time for an initial value for the points in a new data structure), and like rust, frees memory when it's not being used.
Rust does manual cloning. Roc does calculated cloning. Rust wins over C for memory safety by calculating when to free rather than using manual free, totally eliminating a whole class of bugs. Roc could win over rust by calculating when to clone, eliminating a whole class of unnecessary allocation and deallocation. Don't be so sure that no one could do better than rust. And the devXP in rust is really poor.
wrote last edited by [email protected]There is no reference counting if the count is always one.
The defining feature of reference counting is that its a runtime check. Which in turn results in a runtime performance.
If there is no in memory counter at runtime, nobody calls that reference counting.
-
Isn't Zig working on their own backend?
Also, pretty excited about the cranelift project.
Yes, and it’s now default for x86_64
-
cool new languages
COBOL
It's new to gcc!
-
There is no reference counting if the count is always one.
The defining feature of reference counting is that its a runtime check. Which in turn results in a runtime performance.
If there is no in memory counter at runtime, nobody calls that reference counting.
It's not as simple as that.
Roc does static reference counting too, otherwise it wouldn't be able to do opportunistic in place mutation. It can do static reference counting up to a known compile time bound, whereas rust can only count to one. Both of them can do runtime reference counting, but it's implicit in roc and explicit with Rc and Arc in rust.
For example, consider the pseudocode
{
h = "Hello, "
hw = h + "world."
hm = h + "Mum!"
}In real life, this could be something less swervable.
Roc counts, at compile time,
1,2,3,0, drop. No problem.Depending on how you declare these variables (with what additional keywords, symbols, string types and concepts), rust counts, at compile time,
1,release,1,2! No no no stop broken! Bad programmer!This was in this case an unnecessary premature optimisation. That's what I mean by rust counts references, but only counts up to 1.The borrow checker is a static reference counter with an arbitrary number of immutable references that you must declare explicitly and a maximum of one mutable reference that you declare explicitly with mut or let under different circumstances. Arc and Rc are runtime reference counters that you declare explicitly. This is essentially all tracked in the type system.
Roc does the static reference counting and if the total doesn't rise above rust's maximum of 1, uses in place mutation (as opposed to the default immutability). If it is bounded it can use static (compile time) reference counting so that when, for example, all four local references fall out of scope, the memory is dropped. If the number is unbounded (eg parameter passing recursion that can't be tail-cpseudocode ilarly removed), runtime reference counting is used. This is all essentially tracked in the runtime system, but calls to clone are automated in roc. A beginner absolutely can write a memory hog in roc, but the same beginner is likely to overuse clone in rust and write a similar memory hog.
