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.
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.
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.
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.
One point the authors make is that registers are memory. I’m not sure they’re saying screw registers, just that they’re counter to portability and in general only a yet faster cache for programs to use. The other point they seem to make is that a secondary reason we have architected registers is that renaming over an arbitrarily large space was (and in some ways is still) difficult. By using graph coloring and reg allow in compiler, we narrow the encoding space before execution and give the hardware a much simpler problem. Recent research results on register less arch show that there are quite a few benefits. There’s a lie in calling it registerless though, it’s still there, just transparent and hence portable.
The problem with the US Social Security trust fund is that it's misnamed. It should be called the giant equity stash that the US Government can convert to bonds and borrow against. The fund should be flush with cash, however, that'd be fibbing. It would be flush with cash, if it weren't borrowed against for other things in one form or another. For example, the GW, Reagan, and Clinton used this to their benefit. src: http://www.nytimes.com/2005/03/08/politics/at-heart-of-socia... Given that these were bonds, the payments will come due back to the trust fund in one form or another....I'd suspect financed with more debt.
Problem with RISC-V is exactly what makes it strong. The lack of verified software ecosystem will keep it from being main stream for at least a decade(something that until recently has held back the Arm server market, well, that and not having a reasonable server core..fixed with the ThunderX2). The fact that you can add instructions quickly is another problem, well, that and the lack of a standardized verification suite for the ISA so that software devs know that implementations are up to spec when they write code for them. I can definitely see RISC-V accelerators taking off though, driven by a more stable x86/Arm/Power core. To me, that path for RISC-V makes a lot of sense.
I'm waiting for Intel to divest of either the arch/micro-arch business or the fab business. They can invest in one or the other, but what is crippling them is having to invest in both simultaneously. I can definitely see them doing something like HP and split off into Intel-Fab and just Intel. Would enable the arch/micro-arch to use all the fabs and allow the fab to focus on what it does best, processes research and development. Intel already fabs chips for other people (https://www.forbes.com/sites/jeanbaptiste/2013/10/29/exclusi...) why not expand that relationship to maximize their profits/capacity.
Yes. I recently mentioned to my partner how many days I have left in the form of sunsets. Not that many when we think about it. You know what, I approach everything with that attitude and make the most of what little time we have. That includes re-reading number theory books in my spare time :).