simcop2387

And I will note that the other poster didn't say they beat it, just that there are lots of chips being built. I'd imagine that the cores on the tenstorrent cards would blow all the other arm cores out of the water if you could run the benchmarks on them directly, given the much higher core speeds and memory bandwidth etc.

[0] https://youtu.be/vSKA6thLI1U?t=993

Comment · 2 months ago

> The main roadblock to the existence of fast RISC-V cores is the entrenchment of large x86 and arm ecosystems.

I'd disagree with that, their existence and decades of a head start mean they've been much more well invested but that's one of the things we're starting to see change, even if it's because of what would appear to be political motivations. We're starting to see a lot of investment into it in China because it looks like it's a reasonable way for tech sovereignty against the x86 monopoly. They've got licenses to some older (not sure about newer) AMD processor designs, I think around Zen2 architecture, for one of their major manufacturing firms but that won't easily let them move forward since they've got to do a lot of work to keep it up with compatibility and performance for newer ISA additions and such. That's one of the reasons they've been subsiding development of LoongSong64 and RISC-V to the point where for a while the larger LoongSong64 cores were illegal to export to some countries[0].

And then you've got a lot of other companies building faster RISC-V cores, for yes more embedded style designs but not the usual traditional embedded designs either. You've got TensTorrent working on AI work loads with real hardware out there that at least for ML stuff can compete on inference if you can get your software to run on it, and then you've got Bolt doing similar for GPU workloads[1]. While both of those are closer to embedded since you're not going to use them as a desktop, they're still making really fast RISC-V cores that could be theoretically turned into a standard RVA23 core by adding the missing extensions to make it work. That's of course not trivial but the entrenchment of x86 and arm aren't quite as daunting as they might have originally seemed.

It's still not as fast as I'd like, simply because I want to start seeing some RISC-V mini pcs get made that are fine for a daily driver office pc to happen.

[0] https://www.tomshardware.com/news/china-bans-exports-of-its-...

[1] https://bolt.graphics/

Comment · 2 months ago

Mostly so, it's got all the limitations of Manifest V3 which prevents it from doing a good bit of blocking, https://ublockorigin.com/#manifest-v3-section

In particular:

* Cannot use all filter lists simultaneously (rule limits apply)

* No cosmetic filtering in the default mode

* No scriptlet injection by default

* Limited dynamic filtering capabilities

* Requires broader host permissions upfront

But it's definitely still better than no adblockers

Comment · 3 months ago

Yep, first instance I know of was from back in 2009, https://www.theguardian.com/technology/2009/jul/17/amazon-ki... and the kind of thing keeps happening over the years. It'll continue to happen since you aren't paying for a book. You're paying for a license to read the book for as long as the publisher/owner allows you to do so and they can revoke the permission at any time.

I still find it hilariously ironic that the first instance that was widely reported (as far as I know) was it happening to 1984.

Comment · 3 months ago

It'll be very useful for even local setups when the data needs to be confidential. Look at the research related to medical training of llms (ignore their current lack of direct usefulness/trustworthiness, those are potentially solvable), with a homomorphically encrypted session, the large inference servers never see hipaa protected data in a way that exposes it if the server is compromised even if its an on premises setup in your doctors office processing the data, reducing risk of the data leaking anywhere.

Comment · 4 months ago

It's more than just for cryo-freezing and attacks like that, it also helps defend against row-hammer and other DRAM refresh related issues since the scrambling means that the host kernel or application can't determine what the physical bits on the chips are going to actually be and end up determining the layout in a way to flip specific bits. It might still be possible but it's yet another layer of defense against memory related security problems.

Comment · 4 months ago

The five command part isn't really possible but you can use custom diffs for merges, git diff, etc. pretty easily. There are projects like diffsitter ( https://github.com/afnanenayet/diffsitter ) for doing more intelligent diffs like this for supported languages.

EDIT: and then an example for the merge stuff I couldn't find while typing before: https://mergiraf.org/ and HN discussion a few years ago: https://news.ycombinator.com/item?id=42093756

Comment · 4 months ago

I think its one reason ive been happy with software based epub readers where upgrading is usually reasonable to do. Either on my phone or android based eink reader. That said if they change too much then yea nobody will produce the new standard and only support the old one if it isnt carefully designed for graceful degredation.

Comment · 4 months ago

Hows wolfie doing?

Comment · 9 months ago

Neat, definitely a part of history that I'm not familiar enough with myself since I was only ~6 or so around then when the article was published.

It definitely seems to reinforce the joke backronym of "People Can't Memorize Computer Industry Acronyms" for the whole thing given how badly it was all refered to. It's a lot like the whole Clippit/Clippy situation with the Microsoft Office assistants. Originally it was only named Clippit but Clippy got coined by everyone else and even Microsoft ended up giving in and using it in marketing materials not too long after the fact.