God Roko's Basilisk is the most boring AI risk to catch the public consciousness. It's just Pascal's wager all over again, with the exact same rebuttal.
The culture that brought you "speedrunning computer science with JavaScript" and "speedrunning exploitative, extractive capitalism" is back with their new banger "speedrunning philosophy". Nuke it from orbit; save humanity.
Oh hi Rachit, long time no see. I sadly didn't have time to submit something to LATTE this year as I've been spending all my time building infrastructure for SUS.
I think improving the safety of hardware design is a noble goal, and certainly there is much that can be improved over Verilog & VHDL's incredibly brittle baseline.
Though for dynamic latency safety, my intuition tells me the problem space is undecidable. Sure one could prove the correctness of various kinds of dynamic latency pipelines, and as research progresses you'll include more and more such constructs, but it'll always remain possible to construct a correct but unprovable dynamic pipeline.
Given that, shouldn't we take a leaf out of Rust's book, and instead give the user tools to build abstractions which internally contain unprovable but correct black magic, yet on their interface provide a safe, static latency count.
Take for instance SUS' SlowState. It abstracts over an internal state, and the user provides a pipeline to update this internal state. Now, if we were to update the state twice, before the change has had time to propagate through the pipeline, that would be an error. SlowState prevents you from doing so by statically measuring the length of the update pipeline, and only allowing updates once it has cleared.
Implementing SlowState requires some unsafe, but it can provide a safe interface upholding its requirement.
The article specifically mentions this optimization as not working with the compiler at that time, hence the need for the separate index variable.
> We will edit su.c to prevent the overflow by maintaining a counter, i, and verifying it against the buffer size during the read loop. I initially attempted a fix using pointer arithmetic, but the 1973 C compiler didn’t like it, while it didn’t refuse the syntax, the code had no effect. I settled on a simpler index-based check instead.
Well really, the language _is_ the difficulty of much of hardware design, both Verilog and VHDL are languages that were designed for simulation of hardware, and not synthesis of hardware. Both languages have of similar-but-not-quite ways of writing things, like blocking/nonblocking assigns causing incorrect behavior that's incredibly difficult to spot on the waveform, not being exhaustive in assigns in always blocks causing latches, maybe-synthesizeable for loops, etc. Most of this comes from their paradigm of an event loop, handling all events and the events that those events trigger, etc, until all are done, and advancing time until the next event. They simulate how the internal state of a chip changes every clock cycle, but not to actually do the designing of said chip itself.
I'm tooting my own horn with this, as I'm building my own language for doing the actual designing. It's called SUS.
Simple things look pretty much like C:
module add :
int#(FROM:-8, TO: 8) a,
int#(FROM: 2, TO: 20) b ->
int c {
c = a+b
}
It automatically compensates for pipelining registers you add, and allows you to use this pipelining information in the type system.
It's a very young language, but me, a few of my colleagues, and some researchers in another university are already using it. Check it out => https://github.com/pc2/sus-compiler
> miss the time when "confused" for a computer program was meant in a humorous way
Not sure what about this isn’t funny. Nobody died. And the notion that traffic lights going down would not have otherwise caused congestion seems silly.
> what about the emergency services not being able to reach their destinations?
Did they have documented problems?
This is akin to the Waymos honking at each other at 3AM. Annoying. Potentially dangerous in various circumstances. But ultimately just destructive in a way unlikely to repeat.
American cops, fire, and EMS will go upstream on a one way road, or use the sidewalk or the grass if they have to. The Blues Brothers film may even be the material used to train some of the more ambitious departments.
Have you seen how human drivers deal with traffic lights and emergency vehicles at the same time? Waymo made the right call to suspend service, they will probably update their playbook to suspend service during power outages in the future.
Humans certainly are imperfect and make mistakes, but will iterate with the understanding that doing nothing at all and blocking emergency vehicles is untenable.
At the least we will fall back to incentive/disincentive social behavior. People will supply ample friendly and unfriendly advice to try to unwind the knot.
Waymo should lose their operating license based on this experience. It's self-evidently dangerous to everyone to be incapable of basic iteration. There's a whole set of law driver's are supposed to follow for handling failed traffic lights. Why have lower expectations of an anonymous car than a human?
> Waymo should lose their operating license based on this experience.
Then everyone should lose their licenses as well by your draconian reasoning. Because…
> There's a whole set of law driver's are supposed to follow for handling failed traffic lights.
And they don’t, it’s chaos.
> Why have lower expectations of an anonymous car than a human?
You obviously have higher expectations for autonomous cars than humans, it is not the other way around for those of us who disagree with you. The only difference is that Waymo can get better with experience and humans generally don’t.
> > There's a whole set of law driver's are supposed to follow for handling failed traffic lights.
> And they don’t, it’s chaos.
Do you live in areas where traffic lights go out regularly?
Because for human driver it is a non-issue. It becomes an all-way stop and you take turns, it is easy. Traffic throughput slows down a bit, but nothing approaching chaos about it. If waymo can't deal with this, that's a problem.
Developing new technologies has risks. In the absence of anything really bad actually happening, I think we can solve the problem by adding new requirements to Waymo's operating license (and all self driving cars) rather than kneecapping the technology.
Regulation is about setting minimum standards for acceptance, not specifying exactly how.
This means that if I walk into a random croissant shop and buy a croissant, I don't subsequently have 2 days of food poisoning.
Arguably, healthier being the default is also good. The less I personally need to think about this, the more I can think about other more useful things.
Just now, I'm travelling through India, and today was particularily rough. (I'm trying to go from Delhi Airport to Agra). Multiple Ubers turned out bad (scams, no-show, or fucking with pickup point). I spent several hours in this limbo getting nowhere. I end up taking a train without ticket on advice of multiple people around me, since the counter refused to sell me one.
Turns out, wrong train, going slightly the wrong way. But a guy walks up to me in the train, asks me where I'm going, and starts to help me get to where I need to go. He arranged a bunk for me, talked to the conductor for me, bought(!) another train to Agra for me, called hostels in Agra, etc etc. I've had multiple such encounters here in India, of people going so far out of their way to help me here, something you would honestly never see in my country Germany. It's like a strange incongruence, with one fraction of the population hell-bent on fleecing you for all you've got, and another that will go way further out of their way for you than you could ever imagine.
This correlates with tourism. Low touristy places you standout and people treat you nicer than normal.
In touristy places you are just a target. It’s just different places have different strategies for fleecing you. For example in Japan you probably wouldn’t even know you got ripped off but India they are likely so obvious about it you never get fleeced.
If you find the sheer number of people too much, do visit either Himachal Pradesh or Uttarakhand! You will find THE kindest people there. Though be careful of leopard and bear attacks in Uttarakhand right now!!
Oh, I just came back from Shimla actually. I stayed in Narkanda for 2 days to do some hiking, and Shimla one day, though I didn't interact with many people there. My next stop is Kochi, hopefully things are also a little quieter there.
Kochi is also a very nice city, but if you're coming from Shimla or even Delhi you're going to find it sweltering hot probably. It's about 26⁰C (80⁰F) right now... (I'm close to Kochi and honestly in these temperatures it doesn't even feel like Christmas)
Ps, Kochi can be quite bustling. The more remote and rural towns (like Munnar) are a relatively safer bet.
Make sure you try to talk in English and see. Most people should know or atleast understand english there. And Kerala food can be spicy and it's hot out there. Make sure your drink enough water and stay hydrated.:)
Printing the hash of the result is a nice trick I've used a couple of times myself, but jumping through the hoops of making the inputs parametrizeable (a la env vars) is only going to make your benchmarks less reliable, not more. It could be that the request for the env var gets moved past you let start = now() call, and therefore you're now partly benchmarking std::env::get().
Instead, stick with std::hint::black_box for both inputs and outputs. Your benchmark will have no overhead from them, and you're benchmarking exactly what you intend. For low-level benchmarks, use repeats (again with std::hint::black_box on independent loops, or a proper microbenchmarking framework
