bem94

> Preventing the user from doing this entirely is an easy but fairly disappointing "solution" to this problem.

For sure. And if individuals are happy with trading some security for some functionality/flexibility in their software, I'll support their right to make that choice.

It gets more complex when the people affected by that choice aren't the people making the choice. Which is more likely in the case of network programs.

> Usually, the hard part is not security per se, but identifying user intent. You want to come up with a process that ensures that the user who enables potentially dangerous interfaces knows what they are doing.

Indeed. I'd add identifying developer intent to that as well. What functionality am I trying to enable v.s. what else am I actually enabling? Coming up with that process is the herculean task there.

I agree that people would and do find such interfaces very useful in many of their programs and tools.

Those with nefarious purposes find them extremely useful too. It's a lot of work to secure those interfaces against abuse.

Hardware verification engineers call it "constrained random verification", but it's basically fuzzing. This has been the backbone of most commercial hardware verification flows for a long time.

I try to keep a list of useful open source hardware verification tools: https://github.com/ben-marshall/awesome-open-hardware-verifi...

> privacy was a temporary concept in society available for a limited period

Maybe, maybe not. But it's an easy and incongruous thing to say from a throwaway account.

Even easier if your life and/or livelihood doesn't depend on a degree of personal privacy.

> Much of this contradicts my N=1 experience. > I'm afraid this myth buster needs some of her myths busted.

I don't see anything you've written than contradicts the article author?

If you don't take insulin before a dessert, then of-course it will take days to get your sugars back to normal. That's a reason to take insulin if you can/want, not necessarily a reason to avoid sugars.

The author doesn't assert that too many sweets give you diabetes. Only that there are a complex set of factors, among which are sweets. The myth here is that it's as simple as "too many sweets give you diabetes".

There is an enormous range of experiences covered by diabetes 1 and 2. It's no surprise that general myth busting doesn't tally exactly with N=1 individuals, especially someone who has made such an extreme change to their diet to manage their sugars.

I find this as interesting as I do worrying. Given our tenuous grasp of shared facts and basis for (political) relality these days, making videos like this just seems irresponsible.

We don't need any more fuel for the fire: "They faked this Nixon Video, so they could have faked <X> too!"

We're still not even close for energy efficiency though. I can't remember the exact figures, but for most tasks the Brain is much more efficient per joule than any CPU.

Doesn't that assume that $18K will get you as far in one place as it does in another?

This is really interesting, but note the power increase seen inside the DRAM modules.

Anandtech have an excellent analysis: https://www.anandtech.com/show/14750/hot-chips-31-analysis-i...

> The operation itself [inside the dram module] actually requires 2x the power (20 pJ compared to 10 pJ [inside the main CPU]), but the overall gain in power efficiency is 170 pJ vs 3010 pJ, or just under 20x

> One thing that this slide states that might be confusing is the server power consumption – the regular server is listed as only 300W, but the PIM solution is up to 700W. This is because the power-per-DRAM module would increase under UPMEM’s solution.

I'm assuming that those numbers represent "peak" power, and that when idle the compute parts of the DRAM can be power/clock gated. The implication being that if you are doing lots of in-memory analytics, you'll get a power saving, but if you switch to "something else" and don't get good utilisation of the in-memory compute, you'll probably ruin your power/energy efficiency.

I guess that means the future improvements will involve bringing the power consumption of the modified DRAM modules back in line with their "normal" cousins.

I have so many questions:

- Where can I get the ISA specification?[1]

- Where can I get a compiler?

- Is there a link to the "softcore model"?

With RISC-V you can start very simple and small (micro-controller) and work your way up in understanding and implementation to a very large core (application class). POWER is a monster of an architecture, designed more for "big iron". I guess that might limit the "hobbyist" factor RISC-V has.

1. This I think, all 1200 pages of it: https://openpowerfoundation.org/?resource_lib=power-isa-vers...

> That way the work can be peer reviewed and the Scientific community has a chance to learn from it.

After trawling through so much peer reviewed work which in their view is utterly broken, I can understand why they'd be despondent/mistrustful of submitting it to a peer review process.

As others have said, this pre-dates RISC-V. The author built it as a teaching / learning aid and blogs about it excellently: https://zipcpu.com/

More generally, anyone building their own CPU and architecture just for kicks gets serious kudos in my book. It's not a shame, it's brilliant!

I recently emailed the Guardian (UK newspaper) to tell them that an element of their website caused one of my CPU cores to spike to 100% utilisation while it was in view. It happened on my laptop, work desktop and phone. If you're a visitor, it was the graphic next to the podcast banner which looked like a sound wave.

They've removed the element now and sent a very nice message saying they'd investigate.

I really think/hope that the next "big thing" in software engineering will be energy efficiency in some form or another.

I think it depends on how you interpret "reduced"

- Does it mean reducing the actual number of instructions in the ISA?

- Does it mean reducing the functionality of each instruction to it's absoloute minimum?

These are similar, and overlapping in places. You can also do one without the other.

I think that the base RISC-V ISA does both to a perhaps unhelpful degree. As soon as you want a RISC-V core to be competative with other peer ISAs, you need a bunch of the extensions, which minimises the value in calling it reduced in the first place. At the least, it exposes a possible dichotomy between "reduced-ness" and "usefullness".

To these I would add: lack of a rotate instruction in the base ISA, and unix standard extension groups. This makes symmetric key encryption and most hash functions much slower. The Bitmanip extension has a rotate instruction, but it should have been in the base ISA.

I'd also emphasise the lack of indexed load/store instructions again. It is a disaster for any sort of array indexing where you're addressing >1 array using the same index. I found this in the context of multi-precision arithmetic for crypto, but examples come from all over.

On the author's point about multiply and divide in the same extension: crypto is another good example. Lots of crypto really benefits from multiply, but doesn't need divide.

The most important thing about RISC-V is the idea behind it's openness as a standard and the ecosystem around that standard. The engineering of the ISA itself is not what makes it remarkable, and actually leaves a lot to be desired.

> Its almost like one of those Black Mirror episodes

I'd always thought of Black Mirror as a warning or reminder to consider the wider consequences of technology. Not as a motivator to develop it faster.

The thought of this kind of technology (no matter how far away it really is from being deployed) terrifies me. I certainly do not trust someone like Elon Musk to develop it responsibly and pause to consider what it will do to all of humanity. That's what is at stake here, the definition of humanity, for better and worse.

It's down for me (from the UK).

Edit: It's back up again a min later.

I'd really recommend moon dust; It humanises the astronaughts wonderfully. It's easier to appreciate the affect of the moon landings on humanity, but I really didn't appreciate the profound effect it had on the humans who went there until I read this.

It's things like this that make me think all engineers need more training on the social consequences of the tools they build.

This is an extreme case and I hope most engineers would look at this and understand how awful & damaging it could be; but given our influence on the world nowadays (as a class, if not always as individuals) we really need to be much more aware of what we're doing and how it affects people.

If there was one thing which was going to accelerate RISC-V development and adoption at Huawei, this would be it.

Edit: Though thinking about it, even though RISC-V is an open ISA, how much could it be considered a "US origin technology" given its roots at UC Berkley? Anyone more knowedgable care to weigh in?

Indeed. I was actually looking at very small / embedded cores which do lack SIMD. Think ARM M0/M3/RISC-V-IMC.

Thanks for pointing this out. He has his own set of candidate submissions to the NIST post quantum competition, so throwing shade at other candidates makes a bit more sense now.

I've done some analysis on one of his candidates and it was by far the slowest on cores which do not feature wide vector operations. My opinion is that you shouldn't just optimise for Intel (as many submissions do) for all the obvious reasons.

Edit: A quote from the slides by Nigel Smart which Bernstein criticises - "[We] Would caution NIST against putting too much emphasis on academic measures of performance of algorithms for this reason"

- I couldn't agree more.

> they’re doing expected work to anyone that has any idea how this all works

For sure. But lots of people dont't know how this stuff works and should not be expected too.

I wonder how many average consumers of Alexa products would feel differently about their purchase if it said on the box "some people at amazon are likely to listen to what you say". Sure, everyone agrees to the terms of use, but that doesn't seem to count for much in the way of "informed consent" these days. Maybe to the letter, but not the spirit.

There's a longer curated list of general HDL languages and tools here: https://github.com/drom/awesome-hdl

I have yet to hear a convincing argument for "resurrecting" the woolly mammoth. The entire enterprise seems to be an abominably cruel and misspent effort.

I've heard some argue we might need to resurrect a lot of species we're killing off in the next 100 years, so it's good practice. Better practice would be looking at those animals we expect to go extinct. Or, yanno, trying to stop the extinction in the first place.

Perhaps re-militarisation would be more accurate?

I would argue that yes it does. You're right, maybe not as much complexity, but enough to make arguments for their being simpler look thin.

Also, I don't know how the 500 ARMv8 instructions was reached. If there are 500 instructions in the entire ISA, that's an unfair comparison, since there might be functionality in there not directly present in RISC-V. E.g. SIMD functionality.

Ofcourse fewer instructions to implement are fewer instructions to verify, but I disagreed with how simple the article made it sound.

x86 is undoubtedly a very complex beast, so ARM/MIPS are fairer comparisons. Never mind the fact that a Xeon CPU is boggling complex on top of that. I think you are right about how problems are more likely to come from interractions with peripherals, especially the MMU. Most of these things are not architecturally specified, so it's an orthogonal problem to ISA complexity.

Bugs in instruction decoders are something of a false flag in my opinion. They are no less important than other bugs, but they are much easier to find as well, because the problem space is more manageable. A little more complexity in an instruction decoder is not, in my opinion, enough justification to exclude otherwise useful instructions or functionality.

There is so much to unpack in this article. I pick this claim: That RISC-V is a simple(r) architecture and therefore meaningfully easier to verify[0].

The base RISC-V ISA is indeed very small. However, to compete with ARM/MIPS/x86 usefully as an application core, one must include many standard extensions. All of which add comparable complexity to the ARM/MIPS feature which they ape. It feels wrong to assert then without some serious qualification that RISC-V is simpler or easier to verify. A RISC-V core is no more or less complex to verify than a comparably featured ARM/MIPS core.

That said, and open ISA like RISC-V can really lead the way in terms of shared verification IP. That is the benefit to an open ISA, not it's simplicity, but the fact that it becomes worthwhile for people to share their verification infrastructure. Unfortunately, I haven't seen much of this yet. riscv-formal is amazing, and the riscv-compliance suites are getting better, but proper constrained random stimulus generation and coverage collecton? Not yet, at least, not out there in the open source world. I really wish that Western Digital had included their verification infrastructure when they open sourced Swerv [1].

Really enjoyed the article otherwise!

0 - A reasonable person might disagree this claim is being so explicitly made, but that's what I took from it.

1 - https://github.com/westerndigitalcorporation/swerv_eh1