I thought I saw someone else publish specmarks to corroborate this assertion, but i can't find it right now.
1,645 karma · joined March 11, 2018
I thought I saw someone else publish specmarks to corroborate this assertion, but i can't find it right now.
I mean, emulating your core for development is a good approach in general, but at some point you may want to run your code on actual silicon.
So sure, an Intel i9 or ARM Mac is probably going to be faster than a 4 core U74 SoC, but if you're using a RISC-V core for some embedded application, having a RISC-V system to test with is probably a good idea.
And it's cool you can get a RISC-V SBC for a couple hundred bux. It wasn't too long ago that you paid $2k for a 4 core U54 SoC with minimal peripherals. And if you can stuff it in a laptop form factor, it's portable.
SiFive's U74 cores aren't as inefficient as their earlier cores, but ops per megahertz still isn't on par with high end Intel or ARM cpus.
But if you're going for RISC-V, you're likely interested in it for something other than peak performance.
When I did my time in the RISC-V ecosystem, I thought we would never see catalog parts, so its good to see yet another RV64GC board using a catalog part.
And I salute United's courageous strategy of annoying their customers. It's been a while since I've seen as clear a target for a short sale.
Spirit and Ryan Air, which already operate a rock-bottom fare structure, could get away with this. Those airlines have already identified customers who will trade annoyance for a lower fare. I had always thought of United as a "premium" brand. Clearly, United management does not see themselves that way.
So then I had a smartphone with android crapware and a very bad UI.
It did keep me from doomscrolling at the bus stop, so there is that.
I suspect the "iPhone of modern dumbphones" hasn't been invented yet. My gut feeling is there are about as many reasons people want to use dumbphones as there are people using dumbphones so getting "one dumbphone to rule them all" the same way the apple and Samsung have is a ways off.
And it's unsuited for many roles because it has eschewed reverse compatibility. Sure, you can write an operating system in Rust, but you'll have to re-write it (and possibly introduce new bugs) in five years or so.
I'm not the world's biggest C fan, but there are programs I wrote in the late 70s that still compile and do what you think they should do.
But I can't figure out what the scam is here. Why make up a story like this? Maybe it's some weird way to train a 3rd party LLM? It finds some text on the internet and just includes it into its training set. Months later it barfs out sentences about "calling" PayPal? Seems like a lot of work.
The linked article is a bit wordy, but I think what he's trying to say is: write tests exercising the behavior of interfaces because you may want to change your implementation some day. The drawback of this approach is we don't have a universal way to express Bertrand-Russell-esque contracts on interfaces, so testing behavior when you provide "unsupported" inputs is rather ad hoc.
It would be nice to get the black box data, but Alaska mishandled the box and allowed it to write over data from the flight in question. Oops.
I don't think PR is an added bonus, I think it's the entire point.
also, have you seen lazyjs? Also very cool.
Also, sooner or later people will notice difficulties in communicating exceptional events up and down the chain and they would be greatly served by how Erlang/Elixir handles errors and process trees. Even if you want to stay in c# or f#, there's still wisdom to be gained by looking at how things work in functional languages and applying what you can in non functional languages.
But yeah, it was weird hearing about this "new" idea I've been using for 30 years.
I worry that lazy evaluation will wind up as "filter based programming" next year.
But if it puts it in a form python or c# programmers can readily consume, it's probably okay.
Also nice to see someone doing something with f#.