There are two degrees of separation here though: The software vendors and then the linux distros.
If you sell software that requires your clients to upgrade their system-wide security stack, so they might not. If it is statically linked, no need for them to.
Thanks. Currently Odin would cache i on the stack for retrieval later, granting LLVM the ability to load it into a register if profitable with knowledge that after the read, `i` is constant, which bypasses the RAW hazard after the initial read.
My view is that undefined behavior is a trash fire and serious effort should be undertaken to fix the situation before it gets even more out of hand.
Thanks. I was thinking of strict-aliasing and the associated undefined behavior, which Odin forbids. Odin's atomic intrinsics model after C11 closely (and require the programmer to emit memory barriers when cache behavior must be controlled by instructions). I believe the final memory model will be platform defined. There is no built-in atomic data type in Odin. Only atomic operations are available, and most sync primitives are implemented in the standard library wrapping OS capabilities (WaitOnAddress), etc.
The parent comment said:
>then have a data race, it's functionally equivalent to undefined behavior
This is a matter of interpretation but there is a categorical difference between "this read is undefined so the compiler will silently omit it" and "this read will read whatever value is in the CPU cache at this address, even if the cache is stale". The difference is a matter of undefined behavior from the language versus the application being in an undefined state.
Obviously Odin does not use C's memory model. And in instances where LLVM optimizes Odin for UB, it is a bug, and not a feature. Odin explicitly opts out of all optimization passes that depend or leverage UB, but that's a moving target.
For example, as mentioned in the article, Odin does not leverage LLVM's poison value optimizations, which are derived from optimizations exploiting undefined behavior.
Sure, some code is slowed. But can you point to a well known and well used algorithm whose runtime characteristics depend upon exploiting UB? If you code goes fast because it's doing undefined things the compiler strips away, that's a structural bug in the application, in my view.
Odin allows type inference at the declaration level `foo := 1` for example, and a few other places, largely from the constant system. 1 can be an integer, float, or even a matrix, given the larger context.
What I meant was implicit type conversion. Integers do not automatically cast as booleans in Odin, as an example.
Built in bounds checking, slices, distinct typing, no undefined behavior, consistent semantics between optimization modes, minimal implicit type conversions, context system and the standard library tracking allocator combine together to eliminate the majority of memory bugs I found use for sanitizers in C/C++. Now I'm back to logic bugs, which neither Rust nor sanitizers can help you directly with anyway because they rely on program and not language semantics. Obviously these features together do not eliminate those classes of bugs, like Rust, but Odin chooses a different point on the efficient frontier to target, and does so masterfully.
To put the cherry on top, the sane package system, buttery smooth syntax, sensible preprocessor (the 'constant system'), generics, LLVM backend for debug info / optimization, open source standard library, simply build system, engaging and well intended community make day to day programming a pleasant experience.
Please quote the entire statement. And stop the needless "even owns up to it" FUD.
> Actually, SQLite will easily do 50,000 or more INSERT statements per second on an average desktop computer. But it will only do a few dozen transactions per second. Transaction speed is limited by the rotational speed of your disk drive. A transaction normally requires two complete rotations of the disk platter, which on a 7200RPM disk drive limits you to about 60 transactions per second.
As someone who programs professionally in C but writes Odin as a hobby, Odin contributes more like 1000% ease of use, comparatively. And I bet that scales up even more on a team as compared to C.
ASAN, complex build tools, undefined behavior, implicit type conversions, etc, each of these contribute substantial problems all on their own, and they basically don't ever arise in Odin from the start.
While I've been waiting for this kind of game, some approximation I've been able to whet my appetite with is the old classic Baldur's Gate (I and II) with the following mods / optional settings.
Sword Coast Stratagems (radically improves AI, making mages especially terrifying), INSANE difficulty
Double Damage (only damage dealt to your party is doubled)
No Reload ("hard core" mode. No save scrumming).
These combinations turn the game into a strategically deep, and tactically rich experience. And just the hell more memorable.
Algorithms II is typically a mathematical proof class about algorithms. At my university, it was used as a filter class, and quite demanding. I think it was also 4 credits.
If you sell software that requires your clients to upgrade their system-wide security stack, so they might not. If it is statically linked, no need for them to.