HN user
A bit of clickbait. Brief explanation of why that huge perf gap on a well-solved problem:
1. The `memcpy` idea is trivial. I know it's there to serve a different argument. But saying "professional" can't think of `memcpy` is clickbait.
2. Having a bad char table makes a totally different algorithm. A "professional" should at least finish reading their textbook, instead of writing the naive algorithm in Version 3.
This page has some interesting ideas about "safety" without any pre-conditions.
As a starter, Java is safe. Probably safer than most of the C-based candidates on this list. And we are only speaking about Java without tooling vs C with tooling.
The open-sourced toolchain of RISC-V accepts any kind of extensions as long as they are in the reserved code space, basically out-of-the-box. The current ratifying body does not hold any special toolchain or legal influence other than its publicity, thus irrelevant in this comparison.
My Gosh, what was happening with this project? At first they target to ship in chrome 97, then 101, then 105, then 109, now 113. Are we building fusion reactors that are constantly four months away?
Well this is bad. Just checked the code, `RandomState` invokes `wasi::random_get()` on wasi target. It means virtually every std program in Rust would require random number generator privilege in the upcoming WASI unless the author intentionally avoid using default HashBuilder and somehow treeshake the stuff out(?).
This seems to be a fundamental conflict of interest between server-side programming and client-side sandboxing. Now the preventive security measures cost us not only performance on the table, but also privilege spam.
This article turned up with a valuable proposition. Although I would still argue open source software itself is as political as it can get (Forked code has no value. Communities of people behind the code matters), but I do agree that such thing should have some kind of process. It should not be the personal FM radio for the editor-of-the-day.
RISC no longer has the clear border as it had 30 years ago. Nowadays RISC just means an ISA has most of the following points: 1. Load/Store architecture 2. Fixed-length instructions or few length variations. 3. Highly uniform instruction encoding. 4. Mostly single-operation instructions.
These four points all have direct benefits on hardware design. And compressed ISA like RVC and Thumb checks them all.
On the contrary, "fewer instruction types", "orthognoal instructions" never had any real benefit beyond perceptual aesthetics, so as a result they are long abandoned.
Finally some updates after all these years. I'm just curious about the relations between the older "nanoprocess" and the now Component Model. Previously the nanoprocess model promised fine-grained containerization, I wonder if the Component Model still targets the same granularity?
On ISA design, it is just so wrong to endorse the opinion of a single person. ISA design has three significant parties of interest: IC designers, compiler authors, and software developers.
No one can master these three fields all at once. No one. Not even Linus (who would be a master software developer + a decent compiler specialist).
Chip and ISA are almost irrelevant stuff. No matter how you emphasize on end product performance, you cannot deny there SHOULD be a metric to compare ISA designs.
From my perspective, Rust does not belong in kernel. But meanwhile Linux kernel does not belong in modern infrastructure. Until the day a mature kernel-oriented language and an established kernel showed themselves, Frankenstein experiments will continue to trump both parties.
They seem to adopt a rapid iteration model closer to browser rather than typical language runtimes. So a browser 1.0 is nothing close to finished. I personally have no problem on it. But I think it is indeed strange that they sound so serious about correctness while constantly rolling new major versions.
Just curious, how would a high-level IR processor knows beforehand that a certain piece of code was longer/shorter than 4kB/1MB, if it do not try to compile it in pieces first.
Mainly because they can. They already have excellent team & experience in designing low power cores from the ground up, and also they have their great LLVM team for the compiler. Core plus compiler, that's all you need for a in-house processor. There are very few companies with this kind of combinations, and those who have them all chose to build their own hardware stack.
When you have the hammer, it becomes a crime to not hit the nail. Especially so when you find out you have a better hammer than your hammer contractor.
Hasn't looked into this. But definitely curious about the relationship between the two
Alongside with Windows long since 1.35 https://github.com/rust-lang/rust/pull/20367
For those who are wondering why the heck would a microarhitectural exploit would "work" on a ISA level as the title suggested:
No, it doesn't. This paper talks only about textbook RISC-V BOOM cores. Interesting work, but clickbait title.
I've been tracking this since May. I'd say it's disappointing that it did not make itself into 1.62 in the end.
This sounds suspiciously like using risc-v for web-assembly businesses.
Any advantage for this method vs non-JIT wasm? (perfromance or platform compatibility?)
I would say the current state of RISC-V is complete but still lacks the final kick. Yes, you can now build an application core out of it, given that V, B, K extensions are now ratified under RVA22. However most high-performance u-archs are not built for client applications -- they are usually built for server/professional market and then derive down to the client side. (Edit: or if not in the Apple and ARM case, curated computing also needs something beyond regular client applications)
For server/professional market, RISC-V still lacks a selling point. Perhaps something like a pointer masking, memory tagging, or transactional memory in the J and T extensions which are still in very early stages.
Then write up an actually meaningful array processing function and translate it into asm is even less rocket science.
The author starts with a apparently meaningless `int x = a[i];`, but did not ask an obvious question before digging in: what usually goes before and after this statement and together what will they produce? A formal RISC-V code analysis usually does not go like this.
`int x = a[i];` is the kind of expression that strikes you as useful at the first glance, but then nothing. If you visit an array, then on x64/ARM/RISC-V, they are all compiled down to 2 instructions per iteration. Not 1 vs 2 vs 3 as suggested by the article. RISV-V may have one or two more instructions outside the loop but that's it.
Yes it is negligible. The problem is that indexed load/store is a non-issue. There are ready-to-use simulation data that shows indexed load/store has minimal impact on dynamic code size.If someone uses an overkill feature to explain a non-issue, then it seems like nonsense.
Imaging someone uses quantum gravity to explain why Australians stand upside down on a globe.
Yes, the author's defence for Myth #1 does not strike me as a correct defence from the RISC-V perspective. Going to compressed instruction and compressed macro-op fusion is way overkill for the very basic indexed load/store problem.
There is also the problem of binary layout. RPC values on binary size, and IPC values on latency with zero ser/des. The two binary layouts are simply incompatible. You can do zero copy with RPC, but that does not help with ser/des. FIDL uses a full uint64 just for a discriminated union tag, which is just crazy for any protocol that is going through a cable.
Sync and async are all about cooperatively yielding control flow. However, in many cases, you may want to yield control on IPC, or to hold onto control on RPC. Yielding control depends on the sender logic. IPC/RPC depends on receiver characteristics. They are very orthogonal concepts.
In the V-extension, they have an instruction named "vrgather".
But that instruction is not a gather load instruction. This instructoin is just a shuffle instruction.
I think on the contrary, x86's permute/shuffle/gather naming is a horrible legacy mess (plus broadcast and other stuff). The channels width, the source selection, the IMM encoding, all basically nonsense and horrifically non-orthogonal.
`vrgather` is literally "gather from register, vector". In risc-v, you can gather from 8 consecutive vector registers (maximum size of a vector register group). That means 1024bits on a bare minimum Zv128b machine. This channel width blows out the 256bits/128bits channel nonsense even in AVX512 and deserve a name closer to memory gather.
Cool to hear it comes with concurrent mode support. Are there any other Rust UI toolkits that introduced concurrent mode? I would like to try out more of them in the future.
I would personally describe memory safety as "all memory accesses to variables are guaranteed to yield a valid value under the type specified by the variable".
So that immediately rules out buffer overflows, use-after-free, double-free, non-atomic data race, dangling pointers, wrong cast, etc.
Some people think memory leaking counts, but I have the same view as Rust. Memory leaking does not corrupt the correctness of a program. And there is no accepted method to universally define "memory leaking" in the first place.
RVA22 Profile: https://github.com/riscv/riscv-profiles/blob/main/profiles.a...
Zba and Zbb are both mandatory extensions. Zbc, Zbkb, Zbkc, Zbkx are all supported extensions. Zba and Zbb contain most useful bitmanip instructions. For example, POPCOUNT is in Zbb.
Implementations are free to choose their extension combinations and go out of standard profiles. But doing so will void them from mainstream *nix support.
Edit: Also for the already sold units, there is a RVA20 profile without any bitmanip which most of them will match. You can assume no newer application uarch will use RVA20 since year 2022.
The problem is that, when people say "math", they usually refer to HPC, or sometimes machine learning, or in very rare occasions, symbollic math. They usually don't mean arbitrary-precision math. In fact, I'm not aware of a single serious computation field that must depend on arbitray-precision math. Usually in HPC or ML, if your model overflows, then your model just overflowed.
So for those scenarios, I haven't heard of code-size problem argument against RISC-V.