Hooking up a BananaPi to a keyboard+monitor is going to be quite a bit cheaper, and unlike with the framework laptop you can't re-use case, monitor, etc. with an upgraded board.
barsoap
joined 1 year ago
You can develop using it as an SBC, then put it into the laptop when you go to a conference to present your stuff. Or if you really want to code in the park it's not like it'd be a microcontroller, it is fast enough to run an editor and compiler.
But granted it's a hassle to switch out the mainboard. OTOH you can also use the x86 board as an SBC so when you're at home it doesn't really matter which board happens to be inside.
I guess from framework's POV there's not much of an argument, it's less "do people want potato laptops" but "do we want to get our feet wet with RISC-V and the SBC market". Nobody actually needs to use it in a laptop for the whole thing to make sense to them.
You don't need a laptop to use a framework mainboard, they run without battery and display and everything. So if you have a Framework 13 or are in the market for one this might actually be a very nice thing, especially if the price is comparable to other boards.
ARM prominently has an instruction to deal with Javascript. And RISC-V will have those kinds of instructions, too, they're too useful, saving a massive amount of instructions and cycles and the CPU itself doesn't really need any logic added, the insn decoder just has to be taught a bit pattern and which microops to emit, the APUs already can do it.
What that instruction will never do in a RISC CPU though is read from memory.
On the flipside, some RISC-V macroops are CISC, fusing memory access and arithmetic. That's an architecture detail, though, only affecting code to the degree of "if you want to do this stuff, and want it to run faster on some cores, put those instructions in this exact sequence so the core can spot and fuse them).
have variable width instructions,
compressed instruction set /= variable-width. x86 instructions are anything from one to a gazillion bytes, while RISC-V is four bytes or optionally (very commonly supported) two bytes. Much easier to handle.
vector instructions,
RISC-V is (as far as I'm aware) the first ISA since Cray to use vector instructions. Certainly the only one that actually made a splash. SIMD isn't vector instructions, most crucially with vector insns the ISA doesn't care about vector length on an opcode level. That's like if you wrote MMX code back in the days and if you run the same code now on a modern CPU it's using just as wide registers as SSE3.
But you're right the old definitions are a bit wonky nowadays, I'd say the main differentiating factor nowadays is having a load/store architecture and disciplined instruction widths. Modern out-of-order CPUs with half a gazillion instructions of a single thread in flight at any time of course don't really care about the load/store thing but both things simplify insn decoding to ludicrous degrees, saving die space and heat. For simpler cores it very much does matter, and "simpler core" here can also could mean barely superscalar, but with insane vector width, like one of 1024 GPU cores consisting mostly of APUs, no fancy branch prediction silicon, supporting enough hardware threads to hide latency and keep those APUs saturated. (Yes the RISC-V vector extension has opcodes for gather/scatter in case you're wondering).
Then, last but not least: RISC-V absolutely deserves the name it has because the whole thing started out at Berkeley. RISC I and II were the originals, II is what all the other RISC architectures were inspired by, III was a Smalltalk machine, IV Lisp. Then a long time nothing, then lecturers noticed that teaching modern microarches with old or ad-hoc insn sets is not a good idea, x86 is out of the question because full of hysterical raisins, ARM is actually quite clean but ARM demands a lot, and I mean a lot of money for the right to implement their ISA in custom silicon, so they started rolling their own in 2010. Calling it RISC V was a no-brainer.
Nah phishing is a 90s term though probably coined in reference to phreaking. That started up in the 60s and by the 80s even the US had mostly switched to out of band signalling for their telephone system so none of the stuff worked any more.
You can keep the array processors fed with low IPC and frequency by having absolutely massive vector lengths, the engineering for that kind of processor isn't in the pipeline, branch prediction etc. it's in the APUs and how to stream data into them. Much more like GPUs, in fact RISC-V has instructions for gather/scatter.
Performance level
Not good. That bench is from a BananaPi with the same SoC, via reddit (sorry).
Maybe about an A55. If you want a performant RISC-V you've gotta wait until stuff leaks out of the European Supercomputer stuff onto the market though that one probably won't have good IPC either unless it's vector, or maybe one of the big chip design companies will grace us with a chip with a RISC-V insn decoder.
Most FLOSS stuff will compile without issue. Practically all the portability issues got sorted out when x86_64 became a thing, stuff gets regularly build for arm32 and arm64, and basically all inline assembly has alternative generic code paths which actually won't be that bad because it's way easier for compilers to output good vector code than it is to output good SIMD code, less room for hand-optimisation.
Once the kernel and drivers are up and running you're good to go because the vast, vast, vast majority of code doesn't care a bit about what CPU it is running on.
There's also a thing called a retarder built into lorries and other heavy vehicles so they don't melt their brake pads, think engine breaking as the basic version, add special engineering sauce and you get something that is good at slowing stuff down without burning up, but not good at all at arresting it in place. The term is also used with railroads but those are actual breaks. Similar to the ones you see on roller-coasters.
Your notion that automatic transmissions “need” active cooling that they “don’t” have when in fact they do,
I'm saying that to pull heavy loads they need active cooling. And they do. They also have cooling when not designed for heavy pulling, but they don't need as much cooling because all the mechanics you literally agree with me over: More cooling is needed under heavier loads. This isn't some far-out concept it's physics, it's what happens when you put oil in essentially a blender, it gets hot.
Then, and this seems to get ignored by you: Americans aren't pulling heavy loads with cars. Why? Do you have an alternative explanation?
What’s the US spec rated tow capacity of a Crosstrek? Oh wow, it’s 1500 pounds.
1270 kg over here (with trailer brakes, 12% incline). That's nearly twice. Tongue weight: 80kg. That's less.
And that's a Japanese SUV. You can get VW Golfs with 1.8t towing capacity, that's a compact car. Also pure combustion ones, the Crosstrek is a hybrid it's easy to get low-end torque with one of those and transmission is a whole another topic.
This is because it is dangerous to tow a low tongue weight trailer at high speed. America has no such speed or tongue weight restriction, and we also have interstates with 85 MPH speed limits.
That's why trailer brakes exist and don't pretend 140km/h are fast... though with a trailer you're generally limited to 80 or 100 here, depending on make and whatnot. Maybe you should introduce speed limits, regulations for brakes on trailers, etc. Maybe you would if your small cars could even tow that much, physically. You should also start to use the left lane for overtaking only and get rid of those ludicrous amounts of stop signs and build your cities so that people can move in them, not just cars, but I'm digressing.
All three are kinda at least half-covered by the vector instructions which absolutely and utterly kills any BLAS workload dead. 3d workloads use fancy indexing schemes for texture mapping that aren't included, video I guess you'd want some special APU sauce for wavelets or whatever (don't know the first thing about codecs), neural nets should run fine as they are provided you have a GPU-like memory architecture, the vector extension certainly has gather/scatter opcodes. Oh, you'd want reduced precision but that's in the pipeline.
Especially with stuff like NNs though the microarch is going to matter a lot. Even if a say convolution kernel from one manufacturers uses instructions a chip from another manufacturer understands, it's probably not going to perform at an optimal level.
VPUs AFAIU are usually architected like DSPs: A bunch of APUs stitched together with a VLIW insn encoder very much not intended to run code that is in any way general-purpose, because the only thing it'll ever run is hand-written assembly, anyway. Can't find the numbers right now but IIRC my rk3399 comes with a VPU that out-flops both the six arm cores and the Mali GPU, combined, but it's also hopeless to use for anything that can't be streamed linearly from and to memory.
Graphics is the by far most interesting one in my view. That is, it's a lot general purpose stuff (for GPGPU values of "general purpose") with only a couple of bits and pieces domain-specific.