This perspective makes scifi stuff like "smart dust" seem a lot more feasible. Ubiquitous computing, what will it bring us?
Empirically it seems that software simply doesn't scale as well as hardware does. I feel like this overhead would make "smart dust" impractical.
Or I guess I could put it that way: one hand hand you could be impressed that a modern light bulb can run Doom, on the other you could be alarmed that you need a Doom-capable computer to run a modern light bulb.
So the RoI is just different.
The trick is that you probably don't need all, or even most, of that power to run the light. Sure the Zigbee protocol is _probably_ being done via software, and not a dedicated chip, but even then. The big thing is that this chip is most likely so cheap, especially in bulk, that it doesn't make sense to get the "cheaper" variant, even if that was still available. This is kind of supported by the "new" Trådfri having an updated chip, even though the Trådfri line never changed it's capabilities, it was probably cheaper to get the new more powerful chip and/or they could no longer get the old one with a five year supply guarantee.
If you're intentionally disabling functionality in order to sell at a lower cost, you're not actually saving any money because you still have to manufacture the thing. It also (I assume) opens up a risk to someone finding out how to "jailbreak" the extra cores and now you can buy an i7 for the price of an i3. Is the cost of having three different manufacturing processes so large that it's not worth switching? Is the extra revenue from having three different versions of the same physical chip enough to justify the jailbreak risk?
If you just have one price, you cut out people who can't afford it and people who can afford to pay more get away with more of the surplus.
If you have several prices and create just enough difference in the product that it doesn't change the expense much, you can suck dry every class of user.
Bit of an MBA trick.
We are talking about chips here so not the same bottle of soap with different labels, I'd call that a trick.
Instead of assuming, it's easy enough to confirm that CPU binning is real.
See here: http://isca09.cs.columbia.edu/pres/09.pdf
Also here: https://www.anandtech.com/show/2721
“When AMD produces a Phenom II die if part of the L3 is bad, it gets disabled and is sold as an 800 series chip. If one of the cores is bad, it gets disabled and is sold as a 700 series chip. If everything is in working order, then we've got a 900.”
Hmm, but what if 3 cores are defective? If that can happen(?), then it seems one extra functional core is disabled to get to an even core number.
Apple's M1 GPUs are the first where I've seen the choice between 7 and 8 cores (as opposed to 6/8 or 4/8).
It gets sold as a coaster
Perhaps there is fault tolerance hidden elsewhere, e.g. the neural engine might have 17 physical cores and one is always disabled. Although this seems unlikely as it would probably waste more silicon than it would save.
So the best chips which have the least errors in the manufacturing process are sold as top tier. The ones which have more mistakes in them get their defective parts disabled and then get sold as lower tier ones
Either they just accept the fluctuations in order to maximize output of high end chips, or they would have to cripple fully functional ones to maintain a predictable supply. Interesting business.
The primary purpose is market segmentation: extracting value from customers who would pay more while not giving up sales to more price sensitive clients who nevertheless pay more than the marginal cost of production.
I cannot say this for certain in CPUs but I know in other electronics with PCBs that this is how it is done. Sometimes lower-end SKUs are made by opening a higher-end one and cutting a wire or a trace.
The real reason IMHO, is to have a larger range of product prices so you can cater for specific audiences.
It seems people are confusing cost with price. Those two things are orthogonal.
At this point, yes they may lock down perfectly good high end CPUs to a midrange model spec to meet a production quota.
After manufacture, they test the individual components of their chips. These chips are designed in such a way that once they identify parts of a chip that are defective, they can disconnect that part of the chip and the others still work. (I believe they physically cut stuff with lasers but my knowledge is out of date). This process can also includes "burning in" information on the chip itself, like setting bits in on-die ROMs, so that if your OS asks your CPU for its model number it can respond appropriately.
Interesting side note: The same thing happens when manufacturing even basic electronic components like resistors. All the resistors that are within 1% of the target resistance get sold as "±1%" resistors, which means it's pretty likely that if you buy the cheaper "±5%" resistors and test them, you'll find two clusters around -5% and +5% and very few at the target value.
EEVblog did some tests[1][2] some time ago on ±1% resistors, and found that while his samples were fairly Gaussian and within the spec, the ones from his second batch were consistently low. That is, none were above the rated value.
So yeah, don't assume a perfect Gaussian distribution when using resistors.
And yes, I’m aware that there are also those with the chops, who are not permitted by their money masters (or alternately by their master, money) to write performant software.
If you want to know how the world would be like without video game programmers, just like at internal corporate software and how slow it is.
How many other advances are we tossing away because people don’t know how to optimize and code for speed and fun!
Of course, I'm over here with my poky 6 minute mile...
That's my prediction.
If the specifications are human-generated, then they're just a form of high-level source code, and your prediction boils down to future programming languages simultaneously improving programmer productivity and reducing resource usage. That's not a controversial prediction.
If I understand you correctly, I think you're correct that over time, we'll see an increase at the abstraction level at which most programming is done. I think the effort put into making compilers better at optimizing will largely follow market demand, which is a bit harder to predict.
One interesting direction is the Halide[0] domain-specific language for image/matrix/tensor transformations. The programs have 2 parts: a high-level description, and a set of program transformations that don't affect results, but make performance tradeoffs to tune the generated code for particular devices. The Halide site has links to some papers on applying machine learning to the tuning and optimization side of things.
I can imagine a more general purpose language along these lines, maybe in the form of a bunch of declarative rules that are semantically (though perhaps not syntactically) Prolog-like, plus a bunch of transformations that are effectively very high-level optimization passes before the compiler ever starts looking at traditional inlining, code motion, etc. optimizations.
At some point, maybe most programmers will just be writing machine learning objective functions, but at present, we don't have good engineering practice for writing safe and reliable objective functions. Given some of the degenerate examples of machine learning generating out-of-the-box solutions with objective functions (throwing pancakes to maximize the time before they hit the ground, tall robots that fall over to get their center of mass moving quickly, etc.), we're a long way from just handing a machine broad objectives and giving it broad leeway to write whatever code it deems best.
I suspect in the medium-term, we'll see a 3-way divergence in programming: (1) safety/security-critical programs generated from proofs (see Curry-Howard correspondence, and how the seL4 microkernel was developed) (2) performance-critical programs that are very intensive in terms of human expert time and (3) lots of cookie-cutter apps and websites being generated via machine learning from vague human-provided (under-)specifications.
No, Google's AI is floorplanning[0] (basically routing and layout) human-designed logic in 6 hours. That headline is misleading.
It's kind of like having a compiler will billions of optimization flags and using AI to select a pretty near-optimal set of flags for a particular human-generated source file. We wouldn't call the output an AI-designed program, even though such AI would be really helpful.
Google is using AI as a heuristic for decently fast approximate solutions to the floorplanning problem, where (IIRC) optimal solutions are NP-hard.
It's an important step forward, and presumably a big time saver, but they're nowhere near giving the AI an instruction set spec or examples of inputs and outputs ad having the AI generate the logic.
[0] https://en.wikipedia.org/wiki/Floorplan_(microelectronics)
There is no reason to optimize the language that programmers work in when such optimizations can better be done on the generated machine code.
Once we attain the limits of what we can do in 2 dimensions, we aren't that many exponential growth events from what we can achieve in 3. Or once we achieve the limits of silicon technology, we aren't that many exponential growth events from the limits of photonics or quantum or any other possible computing substrate. Unless we somehow unlock the secret of how to use things smaller than atoms to compute, and can keep shrinking those, we're not getting very much farther on a smooth exponential curve.
What we're seeing now is massive parallelism, which means if your task is embarrassingly parallel, then Moore's Law is very much alive and well. Otherwise, no.
One of my favorite dad jokes is that if Smart Water was so smart, why did it get trapped in a bottle?
More seriously, I see this argument all the time: that we are just squandering our advances in hardware by making comparably more inefficient software! Considering that efficiency used to be thought of on the level of minimizing drum rotations and such: the whole point is that we're now working at a much higher level of abstraction, and so we're able to build things that would not have been possible to build before. I for one am extremely grateful that I don't have to think about the speed of a drum rotating, or build web applications as spiders' nests of CGI scripts.
Are there modern websites and applications that are needlessly bloated, slow, and inefficient? Certainly - but even those would have been impossible to build a few decades ago, and I think we shouldn't lose sight of that.
> we are just squandering our advances in hardware by making comparably more inefficient software
> we're able to build things that would not have been possible to build before
We get that not only are we able to build things that weren't possible before, but we can build things that are more inefficient than was possible before.
We can expect in the future to see new levels of inefficiencies as hardware developments give us more to waste.
Without something to balance this out, we should expect to see our text editors get more and more bloated in cool and innovative ways in the future.
It makes me think of fuel efficiency standards in cars.
CPUs are getting faster, and yet paradoxically, performance is worse, especially in the world of web browsers.
The original DOOM ran at 30 fps in 320x200, which meant it rendered 1,920,000 pixels per second with only a 33 Mhz CPU. That's less than 18 clock cycles per pixel, and even that's assuming no CPU time spent on game logic. If DOOM were written today with a software renderer written in C#, Python, or JS, I'd be surprised if it could get anywhere near that level of clocks/pixel.
These days, the basic Windows Calculator consumes more RAM than Windows 98, and that's just inexcusable.
Also keep in mind that the smaller chips get, the more power-efficient they become; so it can actually cost less in terms of both wall-clock time and watt-hours consumed, to execute a billion instructions on a modern device, than it did to execute a thousand instructions on a 1990s device. No matter how inefficient the software, hardware is just that good.
> These days, the basic Windows Calculator consumes more RAM than Windows 98
The Windows Calculator loads a large framework (UWP) that gets shared by anything else that loads that same framework. That's 99% of its resident size. (One might liken this to DOS applications depending on DOS — you wouldn't consider this to be part of the app's working-set size, would you?)
Also, it supports things Windows 98 didn't (anywhere, not just in its calculator), like runtime-dynamically-switchable numeric-format i18n, theming (dark mode transition!) and DPI (dragging the window from your hi-DPI laptop to a low-DPI external monitor); and extensive accessibility + IME input.
I think the more amicable solution here is to just have higher standards. I might not have given up on Windows (and UWP) if it didn't have such a big overhead. My Windows PC would idle using 3 or 4 gigs of memory: my Linux box struggles to break 1.
On a machine that doesn't have as much memory, the frameworks don't "use" as much memory. (I would note that Windows IoT Core has a minimum spec of 256MB of RAM, and runs [headless] UWP apps just fine! Which in turn goes up to only 512MB RAM for GUI UWP apps.)
Really, it's better to not think of reclaimable memory as being "in use" at all. It's just like memory that the OS kernel is using for disk-page caching; it's different in kind to "reserved" memory, in that it can all be discarded at a moment's notice if another app actually tries to malloc(2) that memory for its stack/heap.
> No matter how inefficient the software, hardware is just that good.
Hardware is amazing. Yet, software keeps eating all the hardware placed in front of it.
And my point was that, by every measure, there's no point to worrying about this particular distinction: the more-powerful CPU + the more-bloated code has the same BOM cost, the same wattage, the same latency, etc. as the microcontroller + less-bloated code. (Plus, the platform SDK for the more-powerful CPU is likely a more modern/high-level one, and so has lower CapEx in developer-time required to build it.) So who cares?
Apps running on multitasking OSes should indeed be more optimized — if nothing else, for the sake of being able to run more apps at once. But keep in mind that "embedded software engineer" and "application software engineer" are different disciplines. Being cross that application software engineers should be doing something but aren't, shouldn't translate to a whole-industry condemnation of bloat, when other verticals don't have those same concerns/requirements. It's like demanding the same change of both civil and automotive engineers — there's almost nothing in common between their requirements.
If I could easily upload my code to this smart bulb and leverage it either for creative or practical endeavors then I wouldn't necessarily consider it wasted potential.
But here you have this bloated tech that you can't even easily leverage to your advantage.
I do agree with the general point that the progress we've made over the past few decades is mind blowing, and we shouldn't forget how lucky we are to experience it first hand. We're at a key moment of the evolution of humankind, for better or worse.
Subjective. Questionable to you. Nobody is bloating dd
There is definitely bloated software but it's not a huge issue. If it were, then the customer would care. If the customer cares the business would care.
What is the minimal computer you can both compile and run Doom on?
That would be WebGL and Javascript, I presume?
I tried running a Quake port in that vein, but sadly none of the computers I own were able to play it without stuttering.
DOOM ran in 320x200 at 30 fps on a 33 Mhz CPU, which gives it less than 18 clock cycles per pixel rendered. I doubt Python could get anywhere close to that.
It was certainly impressive, but it was aso a case of often design having to give way to such hacks, such as the fact that many older first person shooter games had to have their entire level design work around the idea that the engines could not support two walkable surfaces vertically above each other for performance reasons or the famous Duke Nukem 3D “mirror” hack.
An ESP8266 microcontroller can be bought in low quantity for less than a dollar. I means sure any cost reduction at scale is meaningful, but at that point I don't think the silicon is the expensive part at that point. It just doesn't make sense to give WIFI devices anything less than that performance, the gains in silicon space will be meaningless and you'll spend more managing that than anything.
That works both ways though. The highly qualified software devs did indeed squander some of it away.
But I'm a rather bad dev that writes really inefficient code (because it's not my primary concern, I'm not a programmer, I just need custom software that does the things I need done that can't be done by software other people write).
All this overpowered hardware allows my code to work very well.
I've been in situations where I could pick between "learn to program properly and optimize my code" or "throw more hardware at it" and throwing more hardware at it was definitely the faster and more efficient approach in my case.
"A few" is underselling it somewhat. I would posit that >95% of popular modern websites contain functionality that was not plausible in 1996.
The person operating the console only has to click an option or fill in some text field, same as 20 years ago. But today, with added slowness.
Knowing the amazing advances in hardware in the meantime, this hurts me.
Ads, propaganda and surveillance.
I believe it is creeping back in now. But it can be done.
The main adversary will be the cookie monster.
https://en.wikipedia.org/wiki/The_Game_(Star_Trek%3A_The_Nex...
I do enjoy Dark sci-fi also every now and then but I generally like my heroes to be scientists, explorers, to solve ethical questions.
(Yes, Discovery season 3 is a thing I know about.)
The only thing more disturbing and sad about this is how much consumer demand there is and will be for deception, misinformation, and manipulation.
Very much to their credit, though, the Trådfri hub doesn't depend on a cloud service just to operate. If that ever happens, thus endeth my foray into smart lighting. I've put my foot down: if it needs Somebody Else's Computer to function, I don't want it.
Ads, obviously.
Mine don't, and I first owned an AtariST with a 68000 CPU.
These are "smart bulbs". We are still in the .com bubble of IoT, so there are going to be a lot of silly things we can run Doom on for a while until it dies down. Lights don't need computers to operate, but that doesn't stop people trying to add "features" to lights with computers.
Such a machine would be nowhere near as efficient as a CISC computer in terms of work per clock cycle, but what if our "silicon" in the future can run an almost arbitrary frequency? We would be able to emulate any instruction set natively in real time. The perfect FPGA.
Ads.
Oh, and spying/tracking.
The future sucks.
These are around 20 MIPS. The Apollo guidence computer had around 1 MIPS.
It seems likely they are using something similar. It's difficult to find a cheaper chip, broadly available chip these days.
You can find Z80 clones, but even they are generally upgraded and therefore more powerful than the Apollo computer.
Do people really think the Apollo computer is more powerful? And have any evidence? I'd be surprised if you can get a microcontroller with as little processing power these days.
Music cards use dedicated chips, they are not general purpose, and they don’t really do much computation aside from a few counters. AFAIK.
Now, in DIY tutorials they show microcontrollers, because they are easier to obtain, but it doesn’t mean that they are used in the commercial products.
The cheapest, smallest (15s storage) "chip corder" (which is what these cards use) has GPIO, SPI, the ability to trigger different messages etc. There's no way this is under 12,000 transistors![2]
[1] https://en.wikipedia.org/wiki/Transistor_count#Transistor_co...
[2] https://www.datasheets.com/en/part-details/isd2115ayyi-nuvot...