Water usage may be a drop in the bucket nationally, but they tend to put datacenters in areas without much water (often because evaporative cooling is less expensive in arid regions) and the effects to those local water supplies can be extreme.
I feel like I've been in a recession economy since the day I entered the workforce 14 years ago. The movement of the stock market has had no effect on my reality. It's like two different universes inhabited by two different sets of people.
IMO, all the narratives we were exposed to around privilege before and after COVID were a cover up of this fact that we have a two-class system which is explicitly creating this condition. The issue is at the system design level and goes far beyond "technology putting people out of a job". The privilege narrative was classic communist-style "accuse your enemy of what you're doing yourself." It was literally the privileged few preemptively accusing the unprivileged masses of being unfairly privileged in order to take control that narrative before it was used on them.
Rewriting critical stuff like hand-written SIMD takes a long time (though not as long as it took ARM because ARM had to overcome everything being written in just one ISA). Even a decade in, there are still lots of low-hanging fruit in RISC-V compilation that is still being dealt with. There's quite a few really great talks about the progress here and I think we're going to continue to see major gains in RISC-V performance via compiler changes for quite a while longer.
If such an instruction is so obviously important, we'll see it start popping up as a custom instruction in some cores then it will get adopted as an official extension by other companies trying to stay competitive.
> The problem is that RISC-V is never going to win at the high end. RISC-V will never have as much money driving it forward as x86 and ARM. As such, the blocks and integration will always lag.
Qualcomm recently bought Ventana and are looking at paying ARM billions (in addition to their current billions) for the privilege of designing their own cores. They sit on the RISC-V consortium and made proposals like Znew.
We could be seeing a high-performance RISC-V release from Qualcomm quite soon (especially if they can simply swap out the ARM decode for RISC-V).
Qualcomm beat ARM in court and reportedly pays 2-3% royalties where ARM was demanding 5-10% royalties.
Qualcomm's ARM license expires around 2028 with an option to extend to 2033 (for some amount of money). If Qualcomm is locked into ARM when renewal comes up, ARM is going to not only name the higher price, but likely charge even more to recover their lost revenue.
Qualcomm is already designing their own cores and ARM is charging them billions for the privilege. Increasing net profits 2-3% for simply doing the thing you are doing seems like a very easy choice. Increasing net profits 5-10% (maybe more) after the price hike seems like a fiduciary responsibility.
This isn't just talk either. Qualcomm already proposed a RISC-V Znew extension (nearly 300 pages of changes to make the ISA more like ARMv8). They bought Ventana (a company already done with their second very wide RISC-V design). They partnered with other companies to make Quintauris for promoting RISC-V too.
There's a non-zero chance we see a RISC-V design from Qualcomm before 2028 and I believe a near 100% certainty of a RISC-V design before 2033.
> I will make one ISA propsal: x86_64 should have had 32 instead of 16 registers
APX proposes exactly this along with 3-register syntax and some other things.
There are two big issues IMO.
1. It will take at least 15 years before most software ships with this because unlike something like AVX where you typically just rewrite a small part of your code that needs AVX, APX requires a 100% rewrite to take advantage.
2. APX instructions require an additional byte each time you use them compared to current instructions. I think there are still savings to be found, but they won't be as big as it might seem at first.
Lack of serious incentive combined with decades-long rollout seems a recipe for non-adoption at a time when RISC chips offer these features now.
Not too long ago, the claim was that having multiple Phds worth of knowledge was the real value of AI, but now that's gone and it's suddenly a good thing.
64-bit instructions with 4 bits indicating instruction formats (60-bit, two 40+20-bit variants, 30+30-bit, 20+20+20-bit, three 30+15+15-bit variants, and 15+15+15+15-bit). Have each larger instruction type be a strict superset of the smaller instructions, but with larger immediates, more registers, and maybe additional instruction formats (eg, for SIMD).
Something like that would be even easier to decode (converting short instructions to long is simply a bit of wiring). Instruction density should increase due to 20-bit instruction type. Having properly-aligned instructions would help with fetching performance. Larger instructions means you can jump 4x further with the same immediate and 16-bit offsets. No need to have some of the V extension workarounds (from not wanting to add 48-bit instructions).
Not traditional VLIW per-se as packets wouldn't imply parallelism (though that's theoretically possible) and instruction count would vary.
2-register to 3-register also just involves different wiring and costs nothing. I think you'd see 15-bit stick with 2-register. 20-bit would more interesting. You could choose to spend 3 bits on a third register or you could widen 2-register instructions to access the 32 core registers (or something between where you do 3-register, but only on 16 registers). 20-bit also reduces some of the need for very large 15-bit immediates (especially jump which is upward of 10% of the total space on 32-bit designs) which could allow more 15-bit instructions further improving effective density.
Easy access to 40/60-bit instructions mean stuff like vsetvli could simply go away and very useful instructions like FMA4 (instead of FMA3) could be added. Vector masking is another big one. They don't have enough bytes for a full vector mask set resulting in some hacks.
The big question is about jumping and predicting inside packets. You can add 2 bits for what externally looks like 16-bit addressing (where the 2 bits indicate packet position to jump to) or have faster jumps that always hit the beginning of the packet (at the expense of code density due to nops). There might even be a hybrid approach where short jumps can jump within a packed, but long jumps must jump to packet boundaries (which makes sense as most compilers make functions align on cache line boundaries anyway). There is a point for eliminating 20-bit (and all that compression goodness) for 45+15-bit pairs instead) as branches inside packets are immediately calculable.
One thing I noticed with your clever encoding is that you can avoid some nops: instead of having 2 15 bits instructions followed by two nops, you could have two 30 bits instructions, saving maybe a little decoding energy.
Also the 60bit format will really help for loading immediates..
That said I wonder why normal ISA do not contain a 'Load Immediate on Next PC'?
And if you want to allow parallel decoding the first byte of the immediate would be a 'special noop' and the first immediate byte would be inside the Load Immediate Next PC instruction instead.
I think this has to do with parallel decoding. How do you tell that the immediate is an immediate instead of an instruction? You have to carve out a very large part of the encoding space and you still can't fit a full immediate (eg, if you decided that all instructions starting with 1 were immediates, you'd be dedicating half of your encoding space to immediates and still be one bit short).
RISC-V does a 20-bit LUI (load upper immediate) then a 12-bit addi to the same register for the lower bits. Having access to 40-60 bit immediates makes 32-bit immediates a lot easier (with 64-bit immediates being multi-step, but quite uncommon).
reply