Hacker News new | ask | show | jobs
by kevin_thibedeau 4151 days ago
> Without it, we would not have smartphones, tablets or laptops, including the device you are reading at this very moment.

Yes we would. All these things existed without Li-ion. The power/space budget would be more constrained but it was perfectly achievable. What wouldn't work is senselessly burning cycles running managed code in a VM with heaps of battery sucking DRAM. People today have no concept of how much computing power is wasted as excess heat because of modern software development practices.

6 comments

> People today have no concept of how much computing power is wasted as excess heat because of modern software development practices.

Or of how many new ideas are created because generous power/space ratios give us the luxury to develop quickly using abstractions higher than highly-optimized references and pointers. You can take a hit on optimal energy efficiency if it results in a larger ecosystem with more possibilities.

The real challenge is to get both.

But high level languages do not require VMs. Time for a rant.

We were lead down a collective rabbit hole by rabid VM and JIT enthusiasts. Notice the absence of those extolling the benefits of JIT compilation today. People used to claim that at some point Java would consistently outperform C due to the greater number of optimisations available to a JIT compiler. They've all become silent because it's quite obviously a load of baloney.

The irony is that we had the answer all the time, but nobody wanted to believe it.

Back in the day, languages like Haskell, early C++, early Objective-C and Scheme compiled to C. Compiling to C was great! No need to spend man-centuries building an optimising cross-compiler to compete with GCC (and fail), no need to screw around with GIMPLE.

In 2015, compiling to a mid-level language is back in style. Except we don't call it C, we call it LLVM-IR. If you squint it's the exact same thing we were doing 15+ years ago.

LLVM-based languages that look like Rust and Swift will eventually dominate, because they are universal. You can use Rust for the lowest level embedded programming. You can use Swift for the highest level architecture astronautics.

What is depressing is that we could have built them 15 years ago but we were too busy fannying around with a dead-end technology.

Also code produced by LLVM-based languages can be linked with low-level modules written in pure C/C++, or even assembly, if necessary. So one may quickly prototype and then slowly rewrite the software for performance, module by module. No such thing is possible for JIT-based languages or platforms.
As an embedded engineer, you and parent have put into words something that I've known but haven't been able to articulate.

I think I encountered the sentiment (on HN) before that because CPU and memory speeds have become so far out of whack and that increasing CPU speeds have power limits that engineers will start having to worry about optimization more and more. I suppose the difference is that before, we didn't have the boat-loads of memory that we have now (in a system).

In other words, yay for LLVM IR!

But I think it is energy efficient already. The modern smartphone replaces the radio, tv, newspaper, store, school, workplace, you don't need a clock, a walkman or a map any more. All o these consumed energy or cost money to buy and are heavy to carry around.
Rubbish! The CPU isn't the power hog that you think it is in smartphones, nor are the programming techniques. Things like the screen and the radio consume most of the power.
For most use-cases, yes, but there are some CPU-intensive (usually graphic-intensive, so maybe GPU-intensive) processes that will eat up your phone's battery life like crazy. I mostly find this in games--Ingress is the worst offender I've dealt with, but Kingdom Rush (which uses no GPS or radio) drained battery much more quickly than just having my screen on for, e.g., reading.
I still fondly remember how long my original Newton MP100 lasted on 4 AAA cells... An order of magnitude longer than my iPhone6 lasts on a charge.
And the original Macintosh Portable could get 12 hours on a charge… of its 2lb lead-acid battery.
We have devices nowadays that put effort into battery economy high up their list of priorities. Kindles are an example. Their common features: they tend to be single-purpose devices, they tend to have crappy displays like e-ink or black-and-grey LCD, and to the extent they are general-purpose, they aren't effective or much fun.

So they would never have been tablets or laptops. They would have stayed as e-readers and PDAs and so forth.

> Their common features: they tend to be single-purpose devices, they tend to have crappy displays like e-ink or black-and-grey LCD, and to the extent they are general-purpose, they aren't effective or much fun.

I like the fact that Kindles have e-ink and are single purpose. When I read on a backlit screen, it tires my eyes and its easy to get distracted from your book with SMS etc. E-ink is perfect for me, for distraction-free reading.

If it was possible to use a lot less power by programming that way without any other tradeoffs there would probably be a market for a device with a much longer battery life.
I agree, and hope new high-level but efficient languages like Rust could help here.