101–110 of 241 posts
Earlier quoted context omitted.
The cheapest MacBook Air is $1000, and it's more like $1500+ if you want a reasonable amount of RAM and storage. There are similarly expensive Windows laptops available that are fanless.
Mind linking some (genuinely curious, would like to checkout potential Linux machine for the next upgrade)
Earlier quoted context omitted.
That seems to not matter much nowadays. There's another great(according to my untrained eye) writeup of the lack of importance on chips and cheese. https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-...
Clam makes some serious technical mistakes in that article and some info is outdated. 1. His claim that "ARM decoder is complex too" was wrong at the time (M1 being an obvious example) and has been proven more wrong since publication. ARM dropped the uop cache as soon as they dropped support for their very CISC-y 32-bit catastrophe. They bragged that this coincided with a whopping 75% reduction in decoder size for th…
RVV does have significant departures from prior work, and some of them are difficult to understand:
- the whole concept of avl, which adds complexity in many areas including reg renaming. From where I sit, we could just use masks instead.
- mask bits reside in the lower bits of a vector, so we either require tons of lane-crossing wires or some kind of caching.
- global state LMUL/SEW makes things hard for compilers and OoO.
- LMUL is cool but I imagine it's not fun to implement reductions, and vrgather.
Earlier quoted context omitted.
MacBook Air is thin and fanless, so it can be done.
The cheapest MacBook Air is $1000, and it's more like $1500+ if you want a reasonable amount of RAM and storage. There are similarly expensive Windows laptops available that are fanless.
Such as?
Earlier quoted context omitted.
3. You can look up the papers released in the late 90s on the topic. If it was O(n log n), going bigger than 4 full decoders would be pretty easy. 6. Not all of those SIMD sets are compatible with each other. Some (eg, SSE4a) wound up casualties of the Intel v AMD war. It's so bad that the Intel AVX10 proposal is mostly about trying to unify their latest stuff into something more cohesive. If you try to code this stu…
I know the E-cores (gracemont, crestmont, skymont) have the multi-decoder setup; the first couple search results don't show Golden Cove being the same. Do you have some reference for that? 6. Ah yeah the funky SSE4a thing. RISC-V has its own similar but worse thing with RVV0.7.1 / xtheadvector already though, and it can be basically guaranteed that there will be tons of one-off vendor extensions, including vector one…
- broadcasting a loaded value: a stride-0 load can be used for this, and could be faster than going through a GPR load & vmv.v.x, but could also be much slower.
- reversing: could use vrgather (could do high LMUL everywhere and split into multiple LMUL=1 vrgathers), could use a stride -1 load or store.
- early-exit loops: It's feasible to vectorize such, even with loads via fault-only-first. But if vl=vlmax is used for it, it might end up doing a ton of unnecessary computation, esp. on high-VLEN hardware. Though there's the "fun" solution of hardware intentionally lowering vl on fault-onlt-first to what it considers reasonable as there aren't strict requirements for it.
Earlier quoted context omitted.
Clam makes some serious technical mistakes in that article and some info is outdated. 1. His claim that "ARM decoder is complex too" was wrong at the time (M1 being an obvious example) and has been proven more wrong since publication. ARM dropped the uop cache as soon as they dropped support for their very CISC-y 32-bit catastrophe. They bragged that this coincided with a whopping 75% reduction in decoder size for th…
Some notes: 3: I don't think more decoders should be exponentially more complex, or even polynomial; I think O(n log n) should suffice. It just has a hilarious constant factor due to the lookup tables and logic needed, and that log factor also impacts the critical path length, i.e. pipeline length, i.e. mispredict penalty. Of note is that x86's variable-length instructions aren't even particularly good at code size.…
Basically: determine end of instruction at each byte (trivial but expensive). Determine end of two instructions at each byte via end2[i]=end[end[i]]. Then end4[i]=end2[end2[i]], etc, log times.
That's essentially log(n) shuffles. With 32-byte/cycle decode that's roughy five 'vpermb ymm's, which is rather expensive (though various forms of shortcuts should exist - for the larger layers direct chasing is probably feasible, and for the smaller ones some special-casing of single-byte instructions could work).
And, actually, given the mention of O(log n)-transistor shuffles at http://www.numberworld.org/blogs/2024_8_7_zen5_avx512_teardo..., it might even just be O(n * log^2(n)) transistors.
Importantly, x86 itself plays no part in the non-trivial part. It applies equqlly to the RISC-V compressed extension, just with a smaller constant.
Earlier quoted context omitted.
Clam makes some serious technical mistakes in that article and some info is outdated. 1. His claim that "ARM decoder is complex too" was wrong at the time (M1 being an obvious example) and has been proven more wrong since publication. ARM dropped the uop cache as soon as they dropped support for their very CISC-y 32-bit catastrophe. They bragged that this coincided with a whopping 75% reduction in decoder size for th…
> With 50+ years of figuring the basics out, RISC-V won't be making any major mistakes on the most important stuff. RVV does have significant departures from prior work, and some of them are difficult to understand: - the whole concept of avl, which adds complexity in many areas including reg renaming. From where I sit, we could just use masks instead. - mask bits reside in the lower bits of a vector, so we either re…
Over masks it has the benefit of allowing simple hardware short-circuiting, though I'd imagine it'd be cheap enough to 'or' together mask bit groups to short-circuit on (and would also have the benefit of better masked throughput)
Cray-1 (1976) had VL, though, granted, that's a pretty long span of no-VL until RVV.
Earlier quoted context omitted.
That's what I'm thinking - they make trade-offs to reach peak performance in desktop designs that don't translate optimally to laptops and when you start from mobile designs you probably made the opposite trade-offs - that would be my guess for the discrepancy.
I'm pretty sure that M3 Max closely matches the 14900k in ST speeds but using something like 5 - 10% of the power.
Earlier quoted context omitted.
> With 50+ years of figuring the basics out, RISC-V won't be making any major mistakes on the most important stuff. RVV does have significant departures from prior work, and some of them are difficult to understand: - the whole concept of avl, which adds complexity in many areas including reg renaming. From where I sit, we could just use masks instead. - mask bits reside in the lower bits of a vector, so we either re…
How does avl affect register renaming? (there's the edge-case of vl=0 that is horrifically stupid (which is by itself a mistake for which I have seen no justification but whatever) but that's probably not what you're thinking of?) Agnostic mode makes it pretty simple for hardware to do whatever it wants. Over masks it has the benefit of allowing simple hardware short-circuiting, though I'd imagine it'd be cheap enoug…
Espasa discusses this around 6:45 of https://www.youtube.com/watch?v=WzID6kk8RNs.
Agree agnostic would help, but the machine also has to handle SW asking for mask/tail unchanged, right?
Earlier quoted context omitted.
The cheapest MacBook Air is $1000, and it's more like $1500+ if you want a reasonable amount of RAM and storage. There are similarly expensive Windows laptops available that are fanless.
Mind linking some (genuinely curious, would like to checkout potential Linux machine for the next upgrade)
Are there any mini PCs with Zen 5?