Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD CEO: The Next Challenge Is Energy Efficiency

spectrum.ieee.org

Post reply on HN
Print view View original

241–250 of 328 posts

Re: AMD CEO: The Next Challenge Is Energy Efficiency

#241

Post by Taek »

madmax96 wrote: post #225

This is not a completely hashed-out thought. But I'll share it and see what others think. My impression is that the simplest way to improve energy efficiency is to simplify hardware. Silicon is spent isolating software, etc. Time is spent copying data from kernel space to user space. Shift the burden of correctness to compilers, and use proof-carrying code to convince OSes a binary is safe. Let hardware continue mana…

I like this idea, and given today's technology it feels like something that could be accomplished and rolled out in the next 30 years.

If the compiler (like rust) can prove that OOB memory is never accessed, the hardware/kernel/etc don't need to check at all anymore.

And your proof technology isn't even that scary: just compile the code yourself. If you trust the compiler and the compiler doesn't complain, you can assume the resulting binary is correct. And if a bug/0day is found, just patch and recompile.

Re: AMD CEO: The Next Challenge Is Energy Efficiency

#242

Post by daemontus »

madmax96 wrote: post #225

This is not a completely hashed-out thought. But I'll share it and see what others think. My impression is that the simplest way to improve energy efficiency is to simplify hardware. Silicon is spent isolating software, etc. Time is spent copying data from kernel space to user space. Shift the burden of correctness to compilers, and use proof-carrying code to convince OSes a binary is safe. Let hardware continue mana…

A good reason why memory virtualization has not been "disrupted" yet seems to be fragmentation. Almost all low level code relies on the fact that process memory is continuous, it can be extended arbitrarily, and that data addresses cannot change (see Rust `Pin` trait). This is an illusion ensured by the MMU (aside from security).

A "software replacement for MMU" would thus need to solve fragmentation of the address space. This is something you would solve using a "heavier" runtime (e.g. every process/object needs to be able to relocate). But this may very well end up being slower than a normal MMU, just without the safety of the MMU.

Re: AMD CEO: The Next Challenge Is Energy Efficiency

#243

Post by smoldesu »

datadeft wrote: post #151
apatheticonion wrote: post #86

From the perspective of a consumer, my MacBook Pro is basically the perfect laptop, at least in theory. I love the battery life and performance of the hardware, not to mention the unrivaled build quality of the MacBook (screen, trackpad, keyboard). In practice, however, MacOS limits the capabilities of the hardware such that I cannot daily drive my MacBook Pro as a work or personal computer (poor containerization sup…

> poor containerization support I use UTM and Docker on a daily basis and it is extremely smooth. What exactly is missing? > an annoying development toolchain What are you talking about exactly? For example most Python and Rust builds just work out of the box. > no _real_ support for video games https://docs.unity3d.com/Manual/Metal.html These claims look like a bit of an exaggeration.

> What exactly is missing?

Kernel integration and a virtualized filesystem that isn't bottlenecked by APFS. Docker is excruciating on Darwin systems.

> What are you talking about exactly?

Apple makes hundreds of weird concessions that are non-standard on UNIX-like machines. Booting up a machine with zsh and pico as your defaults is not a normal experience for most sysadmins, nevermind the laundry-list of MacOS quirks that make it a pain to maintain. For personal use, I don't think I'd ever go back to fixing Mac-exclusive issues in my free time.

> no _real_ support for video games

Besides Resident Evil and No Man's Sky (this generation's Tomb Raider and Monument Valley), nobody writes video games for Metal unless Apple pays them to.

For a while, MacOS had a working DirectX translation stack for Windows games, too. Not since Catalina though.

Re: AMD CEO: The Next Challenge Is Energy Efficiency

#244

Post by tsss »

madmax96 wrote: post #225

This is not a completely hashed-out thought. But I'll share it and see what others think. My impression is that the simplest way to improve energy efficiency is to simplify hardware. Silicon is spent isolating software, etc. Time is spent copying data from kernel space to user space. Shift the burden of correctness to compilers, and use proof-carrying code to convince OSes a binary is safe. Let hardware continue mana…

eBPF does this, but its power is very limited and it has significant issues with isolation in a multi-tenant environment (like in a true multi-user OS). Beyond this one experiment, proof-carrying code is never going to happen on a larger scale: holier-than-thou kernel developers are deathly allergic to anything threatening their hardcore-C-hacker-supremacy and application developers are now using Go, a language so stupid and backwards it's analog to sprinting full speed in the opposite direction of safety and correctness.

Re: AMD CEO: The Next Challenge Is Energy Efficiency

#245

Post by esskay »

I dont think Intel or Nvidia got the memo on this. Both are pumping out seemingly more and more desparate products where their solution to more performance is just to throw more power at it, causing obscene levels of heat in the process.

Meanwhile down at the mid-end you've got Apple chipping away at them with ultra efficient ARM chips.

Re: AMD CEO: The Next Challenge Is Energy Efficiency

#248

Post by tsegratis »

madmax96 wrote: post #225

This is not a completely hashed-out thought. But I'll share it and see what others think. My impression is that the simplest way to improve energy efficiency is to simplify hardware. Silicon is spent isolating software, etc. Time is spent copying data from kernel space to user space. Shift the burden of correctness to compilers, and use proof-carrying code to convince OSes a binary is safe. Let hardware continue mana…

A problem to consider:

Arbitrarily complex programs makes even defining what is and isnt a bug arbitrarily complex

Did you want the computer to switch off at random button press; did you want two processes to swap half their memory. Maybe, maybe not

A second problem to consider is that verification is arbitrarily harder than simply running a program -- often to the extent of being impossible, even for sensible and useful functionality. This is why programs that get verified either don't allocate or do bounded allocations. But unbounded allocation is useful

It is possible to push proven or sanboxed parts across the kernel boundary. Maybe we should increase those opportunities?

Also separate address spaces simplify separate threads -- since they do not need to keep updating a single shared address space. So L1 and L2 cache should definitely give address separation. Page tables is one way to maintain that illusion for the shared resource of main memory... Probably a good thing

That's not to say there isn't a lot of space to explore your idea. It is probably an idea worth following

One final thought: verification is complex because computers are complex. Simplifying how processes interact at the hardware level. Shifts the burden of verification from arbitrarily long running and arbitrarily complex and changing software; to verifying fixed and predefined limitations on functionality. That second one has got to be the easier to verify

Re: AMD CEO: The Next Challenge Is Energy Efficiency

#249

Post by verdagon »

plq wrote: post #235
madmax96 wrote: post #225

This is not a completely hashed-out thought. But I'll share it and see what others think. My impression is that the simplest way to improve energy efficiency is to simplify hardware. Silicon is spent isolating software, etc. Time is spent copying data from kernel space to user space. Shift the burden of correctness to compilers, and use proof-carrying code to convince OSes a binary is safe. Let hardware continue mana…

This sounds like an exokernel design. What forces you to use the compiler that generates the trusted code to replace the MMU?

Perhaps instead of distributing program executables, we can distribute program intermediate representations and then lazily invoke the OS's trusted compiler to do the final translation to binary. Someone suggested a Vale-based OS along these lines, it was an interesting notion.

Re: AMD CEO: The Next Challenge Is Energy Efficiency

#250

Post by vlovich123 »

Fordec wrote: post #37
vlovich123 wrote: post #7

When I was an undergrad, one of my professors was exploring “approximate” computation (forget what it was technically called). The gist was that you build mathematical circuitry that approximates an answer instead of giving you a concrete answer (kinda like floating point but also applied to Boolean algebra, integer math etc). The reasoning was that the approximation could let you reduce the power. I wonder where tha…

It's used inside Google's TPUs[0]. Useless for regular logic programming (You've wouldn't want a nuclear power plant, or your payment processor to approximately work), but has found a use case in scaling ML pipelines where the accuracy of individual values is less important compared to billions of parameters in aggregate. [0] https://ieeexplore.ieee.org/document/9264836

I don’t know that it’s “useless” for logic programming. I agree it’s less likely to be used for normal everyday stuff but it could see more proliferation (eg video decoding). I think TPUs are an interesting first step but the holy grail (which indeed may be impossible) is to be able to reduce large scale programs to run on approximate circuitry. For example, if chrome used a fraction of the memory, CPU, and power, that would be significant even though no one would notice that the page renders slightly imperfectly if executed well. As the paper notes TPUs are the first application although I think what we’re doing there is probably quite primitive be what the researchers in the area are working on long term.
Post reply on HN