bem94

I understand this is nitpicking, but it's not accurate to say "RISC-V has speculative execution" or "ARM has OoO execution" and that they therefore suffer from spectre and friends.

RISC-V/ARM are specifications of instruction sets, for which there exists an enormous domain of possible implementations. Spectre/Meltdown are not inherent features of Instruction set architectures. They are emergent properties of certain implementations of those instruction set architectures.

For example, the BOOM implementation of RISC-V does out of order execution. The Rocket chip implementation does not. Both implement the RISC-V architecture.

I'm not replying to you specifically. But I see this sort of thing on HN all the time and I feel like it's an important distinction to make.

> Particularly when you plan to build a series of chips, the continuous approach taken by software is massively preferable.

For sure. I think continuous integration and cataloging of things like coverage collection is something hardware development really benefits from.

The things that hardware development can learn best from the software world are (in my opinion) mainly down to developing and maintaining verification environments, because they are (mostly) just big software projects. The constrained random variety are anyway.

> 2) writing tests is awful. Testbenches are crazy confusing. Much better would be some sort of unit testing system that does a better job of segregating of what constitutes "testing code" versus the "language of the gates". You would have a hard time doing something like, say, property testing using verilog.

SystemVerilog makes this distinction between RTL (language of the gates) and verification environment code (wrt. testing, they are different things in my experience) very clearly. SystemVerilog inherits much of what people dislike about Verilog, but it makes writing large verification environments much easier. Again, not without lots of potential pain points, but you can do an awful lot that way.

On a slight aside - it worries me (though perhaps unreasonably) about the different approaches to functional verification which come from the software world v.s. the hardware world.

Software verification seems to (generally) be a much more continious affair, while for hardware, there is an extremely intense period of verification before the product is delivered to a customer (as IP) or physically manufactured. This arises because fixing software bugs is cheap by comparison to fixing hardware (again, please accept my generalising!).

It makes me shiver a little to hear people applying software "testing" strategies and terms to verifying actual hardware. I don't know if this is reflected by their actual practice ofcourse. There is a lot of potential for the hardware community to make use of so many software development practices in their verification environments (Big systemverilog testbenches are giant class hierarchies which are far more akin to straight up software), but I'm yet to be convinced about hardware itself. The development constraints are so different, and the possiblity for continuous development is hindered by the hard cut off point (manufacture).

Depending on what I eat, I need different ammounts of insulin, and adjust the dose acordingly using my insulin pen and needle.

How does one adjust the dose in a pill? Do I take more or fewer pills?

They mention the insulin is "freeze dried". What does this mean in practice? Do I need to carry around a climate controlled box with my insulin in?

I don't think that is universally the case. I transitioned back into academia after being in industry. Admittedly, I was only out in industry a couple of years and I've not found academia to my liking.

My background is microelectronics, and in my experience there is still a big skills gap inside academia which I think only people from industry can really fill. There is no substitute for practical/applied engineering experience, and that experience goes a very long way in informing how realistic or implementable a piece of new research is.

If professors are insightful enough to see the skills which engineers from industry can offer academia, then it's a benefit to everyone.

I'd assume that by "moving parts" they mean transistors. Ofcourse this is somewhat confusing to people who know how computers are composed of transistors and what transistors are. But if you just want to convey to the lay person the complexity of the component, I'd say it's a reasonable way to do it.

This is such an important point. Engineering does so much to shape society and the lives of individuals. But we give zero training to new engineers in these issues. Worse, so many engineers I speak to are willfully ignorant or disdainful of the humanities. Engineers mustn't loose sight of who we work for: humanity.

"Everything is worth what its purchaser will pay for it." - Publilius Syrus, ~100 BC

Nor is there any accounting for taste. Looked at purely logically, it is absurd to spend 1K on a phone. Humans aren't always logical. We don't need a 1K phone, some people just want one.

Whoa. This is very impressive!

It does seem to hilight an increasing unease I have with riscv. Implementations are many and cheap, but reusable verification is rare and people don't use what is out there. They have maybe the riscv-tests set working. But that's not enough to call your new CPU usable for anything other than a hobby project.

Fwiw, the riscv-formal package from Clifford wolf is the closest thing to a turn key solution to verifying a riscv core, even if people must remember it doesn't cover everything.

So yeah, I guess they aren't "impossible" to live with out in the strictest sense. But having lived with them for some years and then going cold turkey becomes impractical to the point of impossible the next time you organise some get together and dont have a way to coordinate with a large group of people. Don't get me wrong, that is a really excellent feature of FB/Google tools, which is what keeps people around in spite of the creepyness.

Like you say, lots of people get by fine without, but is that because you have never really used them so much as to become dependent on them? The world worked without the internet, but try taking it back to that place now and you'd be laughed at!

> Most people do not subscribe fully or exclusively to the ideals embedded in the smart-tech utopian vision, yet they’ll have no choice but to live by those ideals.

All too true. The kinds of comment like "but they can just not use X" always appear in the context of Facebook/Google (often when they appear on HN). But that's like saying you should just "not use CCTV". I'm not a user of FB/Google/Smart Tech, it uses me, and when it is deployed pervasively, it becomes by definition, impossible to avoid. I can't stop my friends getting an Alexa / Siri / Google Home thing, so I can't help coming into contact with them.

We can't have it both ways. Making tech / apps / etc addictive or indispensable or "impossible to live without" (once you've had it a few weeks and so do your friends), and then asserting people can "just not use it" is contradiction 101. As a corpus of people, I think we engineers need to look much harder at the world we are building and the constraints / motivators that are causing us to do it.

Do you think that humanity is well placed to be responsible wielders of quantum computing as a tool, and what do you feel your role (as a scientist with a large public following) is in shaping those future perceptions of responsibility?

Beauty is in the eye of the beholder I guess.

I remember reading somewhere that the control room at the Chernobyl nuclear plant looked like someone had taken a grab bag of knobs and dials and thrown them at the wall. The report concluded that the design of the control room made safe management of the plant more difficult.

Ah, Thanks.

Context: MIPS and Wave are owned (mostly) by the same VC firm, Tallwood. The head of Tallwood, Dado Bannato sits on the board / is the interim CEO of Wave and MIPS.

Please excuse my brevity, I'm on a phone.

I think you are right about the "coalition" between liberals and leftists. I've noticed it falling apart for a while but not really been able to describe it. Talking with friends I previously considered liberal and being shushed for questioning or simply not knowing the current vogue in social justice discourse has been a really horrible experience.

Worse, I've seen that experience turn others into frothing radicals who then do the same thing to other people. It's a forward feedback loop of people entrenching their existing preconceptions.

It's a mess.

This is an excellent expression of the kinds of conversations I want to be able to have with conservatives and liberals without being called one by the other.

We need more nuanced discussions like this. I hope to have, hear and see more of them.

Good luck HN.

Player piano by Kurt Vonnegut. Essential reading for anyone who forgets how powerful and often out of touch engineers are as a class of professionals.

I think this is going to be one of the biggest challenges in the field of AI going forward. How do we make sure that as an extremely powerful tool, it gets used responsibly. Also, acknowledging that like all tools, AI will be misused or applied in some truly heinous ways (examples across the internet if you're interested), how should the AI field respond and learn from this? This article is certainly evidence of people pushing in the right direction, even if some of the answers are a little woolly.

Ultimately, I think that the best answer is for AI Devs themselves to be extremely clued up on the potential social impacts of what they are working on and treat that with the same reverence as staying up to date on the latest literature. Only then do the kinds of "specific impacts" which the article brings up become clear enough to act upon and plan around. From there, one can work on safeguards, due diligence, or whatever else you want to call "making sure my tool doesn't hurt people".

You need to bridge the gap as much as possible between engineers sat in a plush office in SV, and the individual who is going to have their life affected by those engineers (and their AI imbued tools). Otherwise, it's just too easy to loose touch with what you & your tools do to the world and the people in it.

In practice and in principle, this is horrifying. I don't trust the people buying these systems, and I especially don't trust the engineers building them. Nor do they give me any reason to trust them.

Is this sort of thing what we became engineers for? To facilitate the end of privacy? Cmon, we're better than this.

The problem (in my understanding) is not with the specification of the x86 ISA, but with the implementation of the speculative execution micro-architecture and probably the memory sub-system as well. That is why Intel is so badly affected by the problem, but not AMD, despite them both implementing the same instruction set.

RISCV has already had to fix its memory consistency model, so it is not without problems. But it that is a spec bug, not an implementation bug. Whether there is an out of order, speculative execution RISCV core in the wild which suffers from this is as far as I know very unlikely. If there is, no doubt it's designers have had a busy time lately.

It's sad that the author has felt the need to take this down after the HN induced whirlwind of comments. Some of the replies could have been a lot more constructive / supportive. For someone starting out with FP (myself included) this sort of thing is really off putting. Things like "point-by-point" rebuttals are for debates and attacks which affect one personally, not for responding to someones opinions on a programming language / scheme.

I couldn't agree more. Engineers are often so far (physically and metaphorically) from the actual impact of what they work on, it can be really easy to miss the damage it does.

People who work for Facebook must have to work very hard to remember the people they are experimenting on are people, not just "users", and that they don't have cart-blanch with how they treat them. Especially if they are building addiction into their service!

Also, Weapons of Math Destruction is a fantastic book.

I can't wait for the people building and deploying AI / Machine Learning tools on a large scale to become aware of the broad societal implications of what they are helping to do. Or, if they are, impress that knowledge loudly and clearly onto their peers.

Not change, or stop nessesarily. Just be aware. This is going to be one of the enablers for the biggest "behind the scenes" changes in how we work as a society in our generation. As Devs, we should take some responsibility for how we act in that regard. I don't see enough of that attitude at the moment.

I read the guardian frequently and long since learned to ignore the clickbait headlines you point out.

Remember that columnists don't write their own headlines. The content of an article is usually more nuanced and thought out that the headline might suggest. Emphasis on the usually.

I don't think comparing the Guardian to britebart is fair at all, but that's another debate.

I'm not saying newspaper columnists don't live in a bubble. Just a different one from the silicon valley / HN bubble. If they get an impression of the tech world that causes them to think nationalisation is the way forward, the tech world needs to respond to that. Undermining the publication or author (as opposed to considering their argument, and separating it into causes - surveillance capitalism - and proposed effects - nationalisation) does not change the fact people are rightly suspicious of Facebook/Google/Amazon etc and they will react accordingly.

I think a lot of the "oh my gosh nationalisation is such an awful idea" / "not in my free society" comments are missing the point.

I too believe nationalisation is a bad idea in this case, but given the enormous reaction it would bring, can you imagine how awful the situation appears to be from the authors (any many other non-tech-bubble) peoples perspective to even contemplate such a thing? Let alone write an opinion piece in a national news paper. You can argue it is a bad idea all you like, but ultimately, Facebook Google and Amazon are building something that scares people. Scared people do stupid things.

If the tech bubble does not look at articles like this as symptoms of a growing scepticism, or a check on the implicit (and often abused) trust of their users, then the backlash is only going to grow. The tech bubble inhabitants will have only themselves to blame.

You can argue all you like about whether people are logically correct to fear the big three. What matters is that they are fearful, and how the bubble reacts to that.

I don't understand why so many discussions about this in the context of engineering / software jump to the idea that diversity is just have 50:50 of characteristic X and characteristic Y. Or why everyone makes assertions about what we know to be a very important and divisive issue without first stating what our own understanding of the words we are using actually is.

I think I have a very different idea of what equality and diversity means to this person (or that soon to be ex-googler), so I'd like the opportunity to talk about it with them, reach the same page of understanding, then talk some more.

In my view, it isn't as simple as 50:50 men and women in the room. It's about removing all barriers to that being a possibility that we can. Specifically, making sure we all have the same equality of opportunity, burdens of expectation and freedom of expression. Recognising some groups lack one or more of those things is a good start. Recognising some groups (deliberately or accidentally) monopolize those things to the detriment of others is a better start.

I guess people will bend further to justify the status quo than they will to better it.

I guess that if there was a special "Open backdoor" instruction which was undocumented, then yes I guess it could find it.

Backdoors tend to be separate systems which pry into something larger though (like the intel managment engine being a small, separate core which probes the main system). This means you normally need other means of access to the system other than the standard instruction sequence. Again, the IME needed network access to be abused I think, rather than instructions running on the main processor itself.

Implementing backdoors is stupid. Opening / accessing them with an undocumented instruction is moronic, but distressingly possible.

>> "several million" undocumented instructions.. is that right?

Bear in mind that doesnt really mean that there are several million operations / opcode mnemonics which are undocumented but each distinct instructions.

It is more likely they are "loose" decodings of other instructions, where changing a single bit of the opcode still causes the CPU to decode the same instruction.

Toy example: If I encode my (imaginary ISA) 8bit instruction for "ADD EAX EBX" as 0101_X000 where X is "don't care" then regardless of whether the core gets 0101_0000 or 0101_1000 , it will still execute the ADD instruction.

Now imagine your instructions can be upto 16 bytes long, and you see how loose decoding can lead to a lot of instructions which are undocumented, but that the processor is perfectly happy to execute.

And people like that are why we can't have nice things.

I'm not saying that education / provoking thought will stop everyone doing something (else) monstrously stupid with AI. Just that we should be doing that educating / provoking more than we currently are.