HN user
I wonder if NNs could be trained well enough with 1 bit weights (i.e. 0 and 1) with some layers doing addition, while others substraction (i.e. weight sign would be "hardcoded" into the network architecture). Or with zero-less weights (e.g. -1, -0.5, 0.5, 1).
Some people use cryptocurrency miners to heat their homes. It's certainly better than dumb resistive heating, but depending on various conditions it can cost more than installing a heat pump.
Because it's not economical, the required hardware is unlikely to pay for itself during its lifetime. The gradient is too small (~50C), which means low Carnot efficiency. Additionally, extraction of low-enthalpy energy involves obstruction of heat transfer, meaning lower cooling efficiency. It may have been a different story if we had computer hardware able to efficiently operate at 200-300C.
Even steel plants which deal with significantly higher waste heat gradients rarely bother with recovering energy.
There is no "objective" foundation to music.
Well, there is a number of "objective" factors which play a significant role. For example, see: https://www.youtube.com/watch?v=tCsl6ZcY9ag
Its capabilities all the way down.
IIUC one problem with such layering of capability processing is that each passed layer results in a context switch (i.e. switch of memory mappings, thrashing of caches, etc.) and its on top of the cost of passing through the kernel. In other words, you may need to pay cost of N syscalls for one multi-layered capability-based operation.
No, it's not. Launch windows [0] are about relative position of orbital bodies which enable use of more efficient transfer orbits.
Are we going to run out of space?
In a certain sense, we do. Pumping thousands satellites to LEO increases probability of triggering the Kessler syndrome. Luckily, LEO orbits are also self-cleaning on reasonable time scales (decades), so I think that some day we will trigger it (potentially, with some "help" from anti-satellite weapons) after which some kind of international regulation will be introduced to prevent repeating it in future.
For Rust we have Loom [0], but do not expect for it to work on your whole application.
Isn't it just a lawmakers' version of diff? :) You just can't conveniently apply it automatically to compile the resulting text.
Why the hell you not just rewrite the old law and bump the revision?
Because it's aimed at lawyers and judges who have to be up-to-date with all changes and its easier for them to remember "section 123 was amended in 2026", than to recall a whole new revision and mentally compute the difference.
It's also why you often can see skipped items (e.g. 1, 2, 4, 8, 9, 10). Because humans often think in terms of "<..> code, section 123", not "<..> code, revision 24, section 123, which was section 130 in revision 20", so when you remove a part, it's more efficient to leave an empty space and to not reuse it later.
it requires creating logical qubits with error rates that we are only now seeing companies report
And yet 21 was not factored on a real hardware.
There is linear engineering progress for getting from 32 bits to 256 bits being factored is my claim.
IMO it's a very bold claim until linear progress is demonstrated between 8, 16, and 32 bits. Not in theoretical papers. On a real hardware. With honest experiments using arbitrary integers.
It's easy to claim "QC will repeat Moore's law!" especially when your salary depends on it, but the practical evidence is quite lacking at the moment.
The underlying scaling needed to go to 32 bit requires only linear progress to get to 256
Nope. Firstly, for RSA you need to scale from 32 to 4096. Secondly, Shor requires N^2*log(N) quantum gates where N is number of bits in the integer, so the scaling is superquadratic. And it's very much an open question whether QEC protocols will continue to work with the same efficiency on the required scales.
Have they factored 21 yet? [0] IMO most of us can ignore such pieces until a practical factorization of arbitrary 32 bit integers is demonstrated on a QC. And even after this "easy" milestone is achieved, I think it will be at least a decade until QC will be a practical cryptographic threat. And it's generously assuming that a Moore-like scaling is possible for QC.
1 might be ok but introduces a bunch of opcode space waste.
I wouldn't call it "waste". Moreover, it's fine for misaligned instructions to use a wider encoding or be less rich than their aligned counterparts. For example, they may not have the immediate offset or have a shorter one. One fun potential possibility is to encode the misaligned variant into aligned instructions using the immediate offset with all bits set to one, as a side effect it also would make the offset fully symmetric.
I am not saying that RISC-V should mandate performance. If anything, we wouldn't had the problem with Zicclsm if they did not bother with the stupid performance note.
I would be fine with any of the following 3 approaches:
1) Mandate that store/loads do not support misaligned pointers and introduce separate misaligned instructions (good for correctness, so its my personal preference).
2) Mandate that store/loads always support misaligned pointers.
3) Mandate that store/loads do not support misaligned pointers unless Zicclsm/Oilsm/whatever is available.
If hardware wants to implement a slow handling of misaligned pointers for some reason, it's squarely responsibility of the hardware's vendor. And everyone would know whom to blame for poor performance on some workloads.
We are effectively going to end up with 3, but many years later and with a lot of additional unnecessary mess associated with it. Arguably, this issue should've been long sorted out in the age of ratification of the I extension.
So just use misaligned loads if Zicclsm is supported.
LLVM and GCC developers clearly disagree with you. In other words, re-iterating the previously raised point: Zicclsm is effectively useless and we have to wait decades for hypothetical Oilsm.
Most programmers will not know that the misaligned issue even exists, even less about options like -mno-strict-align. They just will compile their project with default settings and blame RISC-V for being slow.
RISC-V could've easily avoided all this mess by properly mandating misaligned pointer handling as part of the I extension.
Multiply and divide
And where it actually mattered they did not introduce a separate extension. Integer division is significantly more complex than multiplication, so it may make sense for low-end microcontrollers to implement in hardware only the latter.
As for `seed`, if you're running on a microcontroller you can just look up the data sheet to see if it's seed entropy is sufficient.
It's a terrible attitude to have towards programmers, but looking at misaligned ops, I guess we can see a pattern from RISC-V authors here.
Most programmers do not target a concrete microcontroller and develop every line of code from scratch. They either develop portable libraries (e.g. https://docs.rs/getrandom) or build their projects using those libraries.
The whole raison d'être of an ISA is to provide a portable contract between hardware vendors and programmers . RISC-V authors shirk this responsibility with "just look at your micro specs, lol" attitude.
Misaligned loads and stores are Zicclsm
Nope. See https://github.com/llvm/llvm-project/issues/110454 which was linked in the first issue. The spec authors have managed to made a mess even here.
Now they want to introduce yet another (sic!) extension Oilsm... It maaaaaay become part of RVA30, so in the best case scenario it will be decades before we will be able to rely on it widely (especially considering that RVA23 is likely to become heavily entrenched as "the default").
IMO the spec authors should've mandated that the base load/store instructions work only with aligned pointers and introduced misaligned instructions in a separate early extension. (After all, passing a misaligned pointer where your code does not expect it is a correctness issue.) But I would've been fine as well if they mandated that misaligned pointers should be always accepted. Instead we have to deal the terrible middle ground.
atomic memory operations are made mandatory in Ziccamoa
In other words, forget about potential performance advantages of load-link/store-conditional instructions. `compare_exchange` and `compare_exchange_weak` will always compile into the same instructions.
And I guess you are fine with the page size part. I know there are huge-page-like proposals, but they do not resolve the fundamental issue.
I have other minor performance-related nits such `seed` CSR being allowed to produce poor quality entropy which means that we have bring a whole CSPRNG if we want to generate a cryptographic key or nonce on a low-powered micro-controller.
By no means I consider myself a RISC-V expert, if anything my familiarity with the ISA as a systems language programmer is quite shallow, but the number of accumulated disappointments even from such shallow familiarity has cooled my enthusiasm for RISC-V quite significantly.
In some cases RISC-V ISA spec is definitely the one to blame:
1) https://github.com/llvm/llvm-project/issues/150263
2) https://github.com/llvm/llvm-project/issues/141488
Another example is hard-coded 4 KiB page size which effectively kneecaps ISA when compared against ARM.
Compilers also like to unnecessarily copy data to stack: https://github.com/llvm/llvm-project/issues/53348 Which can be particularly annoying in cryptographic code where you want to minimize number of copies of sensitive data.
The obvious next step is to do all the math in client-side code and just have the user enter the secret
https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
IIRC at least one of the `restrict` bugs found by Rust was reproduced on both LLVM and GCC.
LOL, nope. Those annotations must be part of the type system (e.g. `&mut T` in Rust) and must be checked by the compiler (the borrow checker). The language can provide escape hatches like `unsafe`, but they should be rarely used. Without it you get a fragile footgunny mess.
Just look at the utter failure of `restrict`. It was so rarely used in C that it took several years of constant nagging from Rust developers to iron out various bugs in compilers caused by it.
For a system programming language the right solution is to properly track aliasing information in the type system as done in Rust.
Aliasing issues is just yet another instance of C/C++ inferiority holding the industry back. C could've learnt from Fortran, but we ended up with the language we have...
I generally agree with this opinion and would love to see a proper well documented low-level API for working with GPU. But it would probably result in different "GPU ISAs" for different vendors and maybe even for different GPU generations from one vendor. The bloated firmwares and drivers operating on a higher abstraction level allow to hide a lot of internal implementation details from end users.
In such world most of software would still probably use something like Vulkan/DX/WebGPU to abstract over such ISAs, like we use today Java/JavaScript/Python to "abstract" over CPU ISA. And we also likely to have an NVIDIA monopoly similar to x86.
For all my skepticism towards using LLM in programming (I think that the current trajectory leads to slow degradation of the IT industry and massive loss of expertise in the following decades), LLM-based advanced proof assistants is the only bright spot for which I have high hopes.
Generation of proofs requires a lot of complex pattern matching, so it's a very good fit for LLMs (assuming sufficiently big datasets are available). And we can automatically verify LLM output, so hallucinations are not the problem. You still need proper engineers to construct and understand specifications (with or without LLM help), but it can significantly reduce development cost of high assurance software. LLMs also could help with explaining why a proof can not be generated.
But I think it would require a Rust-like breakthrough, not in the sense of developing the fundamental technology (after all, Rust is fairly conservative from the PLT point of view), but in the sense of making it accessible for a wider audience of programmers.
I also hope that we will get LLM-guided compilers which generate equivalency proofs as part of the compilation process. Personally, I find it surprising that the industry is able to function as well as it does on top of software like LLVM which feels like a giant with feet of clay with its numerous miscompilation bugs and human-written optimization heuristics which are applied to a somewhat vague abstract machine model. Just look how long it took to fix the god damn noalias atrtibute! If not for Rust, it probably would've still been a bug ridden mess.
we had about an inch of separation between our laser diodes and our photodiodes
Why can't you place them further away from each other using an additional optical system (i.e. a mirror) and adjusting for the additional distance in software?
`async` is in the type system.
No, it's not. `async` is just syntax sugar, the "effect" gets emulated in the type system using `Future`. This is one of the reasons why the `async` system feels so foreign and requires so many language changes to make it remotely usable. `const` is much closer to a "true" effect (well, to be precise it's an anti-effect, but it's not important right now).
Also, I think it's useful to distinguish between effect and type systems, instead of lumping them into just "type system". The former applies to code and the latter to data.
That feels dense.
Yes. But why `async` is more important than `alloc`? For some applications it's as important to know about potential allocations, as for other applications to know about whether code potentially yields or not.
Explicitly listing all effects would the most straightforward approach, but I think a more practical approach would be to have a list of "default effects", which can be overwritten on the crate (or maybe even module) level. And on the function level you will be able to opt-in or opt-out from effects if needed.
I think ideally it would be something readers could spot at first glance
Well, you either can have "dense" or explicit "at first glance" signatures.
I agree. But it should be done with a proper effect system, not a pile of ad hoc hacks built on abuse of the type system.