Only for some clocks (CLOCK_MONOTONIC, etc) and some clock sources. For VIRT/SCHED, the vDSO shim still has to invoke the actual syscall. You can't avoid the kernel transition when you need per-thread accounting.
Oh for some time after its introduction, CLOCK_MONOTONIC_RAW wasn't vDSO'd and it took some time and syscall profiling ('huh, why do I see these as syscalls in perf record -e syscalls' ...) to understand what was going on.
If you look below the vDSO frame, there is still a syscall. I think that the vDSO implementation is missing a fast path for this particular clock id (it could be implemented though).
&& in a shebang isn't portable, having more than one argument in a shebang isn't portable, subshell in a shebang isn't portable, semicolon in a shebang isn't portable, basename usage isn't portable, not littering the current working directory is important (it might not even be RW, or you might not have permissions to write to it), your usage won't work with symlinks or with the script added to $PATH, caching the compiled output is a nice speedup and reduces startup costs, correct (and optimal) cache invalidation is one of the known tricky problems in CS.
Shell scripts are ugly :)
(If you didn't mean to use them in a shebang but rather as the script body, that's fine but that wouldn't be possible without the polyglot syntax and #allow abuse I posted.)
Ironically Assembly is safer than C and languages that descend from it, because although CPUs might have undefined behaviour when given undocumented opcodes, or operation modes, the CPU doesn't rewrite your code without telling you about it.
Interestingly although all of C's other types are in fact just the machine integers wearing funny hats (e.g. char is just either a signed or unsigned byte depending on platform, float is just the 32-bit unsigned integers as binary fractions) the pointers are not actually just integers.
They could be, but it's much worse from a performance perspective if you just have these raw machine addresses rather than the pointers in the C language so actual C compilers haven't done that for many years. ISO/IEC TS 6010 describes the best current attempt to come up with coherent semantics for these pointers, or here's a Rustier perspective https://www.ralfj.de/blog/2020/12/14/provenance.html [today Rust specifically says its pointers have provenance and what that means, like that TS for the C language]
> float is just the 32-bit unsigned integers as binary fractions
Note that float and double are a bit particular because they can use different registers! But yeah, when stored in memory they are the same 32/63 bit integers.
The term was introduced so long ago, it's basically prehistoric now. Pointers are needed only for system programming language, they can be absent in systems programming language.
It's not due to a move to AI-enhanced workflows. The article speculates that it's caused by companies wanting to develop AI-related products, moving some workforce and culling the unwilling, just like my employer.
AMD processors have Upper Address Ignore (UAI) with 7 bits of ancillary data, for Intel there is Linear Address Masking (LAM) with 6 or 15 bits [1]. The latter has made it into Linux after some initial resistance [2].
It's a joke, as some Rust projects used to repetitively claim to be "memory safe & blazing fast", thus becoming a tongue-in-cheek phrase. I also anticipated language to be Rust, but it would be way too comical.
> But rust absolutely does not have any C/C++ compatibilty besides [..]
> In zig you _can_ actually start with a c codebase and rewrite it file by file in zig and you _can_ include c headers in your zig files verbatim. Both of these are not possible in rust.
You can. Either via FFI and bindgen-ing headers, or by using c2rust. The latter is not just a toy ambitious project, but actually a very impressive piece of engineering and does produce a result where you can transpile a project or file and start rewriting file-by-file or function-by-function.
c2rust is definitely cool, but it also supports transpiling to a single architecture, which often misses a lot of architecture dependent code and specialisations in real world c code. Especially because it has to do macro expansion and you only get the expanded code.
It also doesn't supportal a good amount of more complicated c features.
It's a help for sure, but the few times I tried I ended up just doing the rewrite by hand instead to actually cover all the cases.