Hacker Newsnew | comments | show | ask | jobs | submit | zurn's comments login

Do we know that Apple announces (and gets CVEs for) vulnerabilities that they find and fix internally? If not, the comparison is not meaningful.

The virtual addressing part might be fine now that the GPUs are doing it, and hypervisors support programmable passthrough using the x86 IOMMU (VT-d etc) features.

Though I'm convinced custom hardware is doomed here for the usual custom hardware reasons. Maybe GPUs have gotten good enough at pointer chasing to be usable here?


> Maybe GPUs have gotten good enough at pointer chasing to be usable here?

They haven't.


Custom hardware is actually flourishing in datacenters. My preferred architecture is Cavium Octeon III style of many-core RISC, accelerators for everything, plenty I/O, and hypervisor support. Selling like hotcakes. Adapteva's stuff outperforms CPU's & GPU's at performance-per-watt-per-area with sales to HPC people. There's similarly at least a few custom hardware companies in each segment doing something that's hard or not cost-effective with existing hardware or software.

I agree that the risk is high, though, to the point that one shouldn't depend on it. So, I'd advice selling system w/ services that's profitable which just happens to use such custom hardware. A high-performance, easy-to-manage, easy-to-integrate... already worth buying... platform that also has hardware-supported GC and/or memory safety. The sales of the system & licensing of the software subsidize hardware costs, which are structured to be cheap anyway. Start with FPGA's, then S-ASIC's, then advanced S-ASIC's or finally ASIC's. The NRE stays as low as volume can support.

Relevant example of this model (and evidence for my GC idea) is Azul Systems Vega machines. Those are custom hardware for Java supporting native bytecodes, a bunch of RAM, a pauseless GC, and easy enterprise integration. So, while we're all speculating, they're selling custom hardware w/ pauseless GC's. I'm just trying to work out a different, cheaper design hopefully integrating with Intel/AMD.

http://www.azulsystems.com/products/vega/overview

Note that they support a whole range of hardware, software, and services to diversify income. Any one thing shouldn't sink them, esp unfavorable hardware. That's the model to copy.


In addition to the cyclic references problem, rc has a high constant overhead (memory traffic from constant manipulation of rc fields) and a problem with pauses (cascading deallocations). Also it precludes efficient shared memory concurrent access of managed objects.

Or possibly saves power, if work is being offloaded from the CPU.

Firefox has a pretty good reputation among users and web developers, despite risks of hitting bad extensions. Their problem amont end users is more the relative obscurity vs the big 3 commercial browsers. IE on the other hand has been a swear word for years.

This is the Racket library in question for context, it provides a framework for doing world simulation in a FP way.

http://docs.racket-lang.org/teachpack/2htdpuniverse.html


Just get the right hardware with good Linux support, it all just works then. You won't find any lasting happiness by digging deeper into the third party drivers swamp. (all-Intel for wifi and graphics is the safest bet)

Yes, registers and the belt are just ISA features. Register renaming is a behind the scenes implementation tech to mitigate the problems of register semantics. It has unwanted costs that a belt machine doesn't have to pay, and it's incorrect to say that Mill does register renaming in the traditional sense of the word.

Indeed that's what the #1 paragraph at https://millcomputing.com/docs/belt/ says: "A large fraction of the power budget of modern superscalar CPUs is devoted to renaming registers: the CPU must track the dataflow of the executing program, assign physical registers and map them to the logical registers of the program, schedule operations when arguments are available, restore visible state in the event of an exception—all while avoiding register update hazards."


The article says userspace ASLR is used, and indeed presented a speed bump along the way.

I think it's unlikely they would fork from the upstream FreeBSD kernel that much without contributing ASLR back. They would end up having to repeat it all again for Playstation 5.

Stranger things have happened, though.


Can you give references to these experimental results? I'm interested to know what they were measuring, was system they compared against etc.
More

Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: