Seems like if you want to migrate between big-little which they currently have then you can’t have things like differing avx widths…just a hunch.

Best decision we could have made. Wish it was done years ago. Only thing to do now is make darned sure we get out the people that helped the US and allies as quickly as possible. It’s not going to be easy, but it must be done.

Those past cowards couldn't do it like him and I agree we need to get everyone out that wants out. France is working towards this effort also. The Aussies and UK are admitting they can't help. This is a mess now and it sickens everyone on many levels. If we don't get the people out we will never get support from any locals ever again in any future war.

I mean- its not like we did the best job with the Kurds or the Hmong or the Mien.

The best outcome would be not doing any more occupying army stuff. It is not very productive.

But what about FPGAs or DSPs? I want one environment for all....

This is an utterly stupid move by ARM...if it's legit. Looks like it's a different domain registry than all the other ARM websites...not sure why, but that seems a bit fishy.

It might be the result of a PR firm doing something utterly inconsiderate and completely exceeding their mandate.

yes, it does.

I suspect there might be a wider market...we'll see. To keep costs down there would have to be a commercial pathway, but that'll probably mean just data center.

No need for paging for the most part with these. Current virtual memory systems won’t be able to deal...can’t wait to see what’s next.

Not surprising. Many “tech” companies enter the field with arrogance, thinking of course they can do health better. They unfortunately often have no comprehension of the regulatory regimes for the markets they enter and therefore the projects are doomed to failure before they start.

Found this after reading the tastes paper on front page. It’s the most fabulously long and complete GitHub issues post I’ve ever seen, almost a blog post in and of itself. I can definitely appreciate the details in the allocation process the authors of RaftLib have implemented after reading this. I’ve never seen garbage collection implemented in a dataflow framework before..actually, haven’t seen that many actual dataflow/channels implementations for C++...they typically die out quickly. Definitely going to check this out more.

Meh, for a retrospective paper, I think the authors probably provided more hints as to the future than they really needed to. I feel like they captured the exact reasons why ISA is so difficult to do right. As for “doing it wrong”, I didn’t take it that way. I think the authors lament the influence of what they seem to feel is a mantra that dictates the programmer must deal directly with the hardware versus providing a sufficiently abstract ISA. Building circuits for ML accelerators, etc. is actually damned easy, exposing those to the programmer in a portable way that does not require rearchitectng the program every time you change the accelerator is tough. I literally loathe porting for Intel b/c the AVX insn behave differently and are essentially architecting in the microarch, passing the complexity directly to the programmer. I’d much rather the Risc-V solution or the ARM solution.