7 ms·
"This ×3 multiplier contains roughly 9000 transistors, a bit more than an entire Z80 microprocessor (1976). Keep in mind that the ×3 multiplier is a small part
by mjevans 2y ago
"This ×3 multiplier contains roughly 9000 transistors, a bit more than an entire Z80 microprocessor (1976). Keep in mind that the ×3 multiplier is a small part of the floating-point multiplier, which is part of the floating-point unit in the Pentium. Thus, this small piece of a feature is more complicated than an entire microprocessor from 17 years earlier, illustrating the incredible growth in processor complexity."
That's the pace of performance growth that lead software to become bloated today; next year's performance improvements would cover up most of the sins of failure to think critically about algorithms and data flow context / locality.
Today (as far as I've read) we're at the practical limit for what's reasonable to do with silicon semiconductor technology and our present understanding of physics. The pendulum needs to swing the other direction; it's time for computers to work smarter not harder.
- HPsquared 2y agoLuckily there is plenty room for improvement in most applications.
- ajsnigrutin 2y agoBut why would we waste thousands of hours of programmers time to optimize stuff, if we can instead waste millions if not billions of hours of users' time? /s
- dijit 2y agoyou know it’s funny, the first time I ever read a book about compiled languages- I think it might have even been K&R C… it talked about the fact that code is run significantly more often than it’s compiled, and read more often than it’s written. Thus we should optimise for runtime speed and afterwards readability. Yet on hacker news, the exact opposite sentiment is true. Employee hours are expensive, so optimise as much as you possibly can and push as much time onto the user as they will tolerate. Focus primarily on readability to the detriment of all other factors. Heck, even don’t bother compiling your program. Use an interpreter on the server. Keep your local cost down, your remote cost up… after all remote cost are not your cost, especially if every company is doing the same thing. It’s ironic that I could read a book and it be so wrong, yet that book is the foundation Bible for many people’s programming journey.
- joquarky 2y agoIt feels like companies care a lot less about delivering quality.
- pixl97 2y agoBecause quite often users buy products based on features and not quality of those features.
- cipheredStones 2y agoWell, programming is a tool, right? There are clearly incorrect ways to program, but that doesn't mean there's one correct way to program - because it depends on what you're trying to make. It's incorrect to make a bookshelf that can't hold the weight of books, but IKEA isn't incorrect to make a crappy-but-adequate bookshelf that will get given away when you move, and a master carpenter isn't incorrect to make an expensive-but-beautiful bookshelf that will be used for many decades. A seed-stage startup trying to see if anyone cares about their product at all should probably accept it being 100x slower than it theoretically could be. And the Linux maintainers should be working hard to shave milliseconds.
- tehjoker 2y agoThis is just the difference between rational design and capitalist design. Capital must externalize costs to achieve profits, but it's not a rational approach to system design. This appears everywhere in the economy as capitalist pressures override rationality.
- jjmarr 2y agoI've been told it depends on management's goals. If you are a startup (many HN readers are), employee hours are relatively expensive. The goal is to get a product out as fast as possible, and most of the time you fail at making a working product anyways. Meanwhile, you only have to spend money on servers once you have a successful product. Deferring the problem makes sense here. On the other hand, I personally write code that'll be near guaranteed to run millions of times in some factory somewhere, and there's little benefit if I ship my code before the factory starts making stuff. I'll take the time to write high-performance and high-quality software because there's now a financial benefit to doing so. But ultimately, it's my boss who gives me insight into what I should be doing. Not a book, because the book doesn't have context that [company] will lose tens of thousands of dollars every day that I don't fix [issue].
- Someone 2y agoBecause it saves lives. https://folklore.org/Saving_Lives.html https://folklore.org/Saving_Lives.html: "Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?”
- speed_spread 2y agoBy that logic, Electron apps kills people. Makes sense.
- HPsquared 2y agoSomewhere along the causal chain of "what went wrong leading to this death", almost certainly there will be some cases of a slow app indirectly (maybe even directly in some cases) causing deaths. It's a question of what we mean by "cause". That's not even counting loss of quality-adjusted life years from time spent staring at a screen waiting, like being stuck in traffic.
- ab71e5 2y agoThat assumes booting is a synchronous action instead of asynchronous, giving time to fetch a cup of coffee
- HPsquared 2y agoBillions of person-hours wasted... Windows Update.
- JumpCrisscross 2y ago> Today (as far as I've read) we're at the practical limit for what's reasonable to do with silicon semiconductor technology and our present understanding of physics We’ve been at that limit for decades.
- Joker_vD 2y agoDepends on what limit exactly you are thinking about: the size of a transistor is still shrinking.
- GrumpyYoungMan 2y agoThe fabs propped up the corpse of Moore's Law by throwing mountains of cash at expanding transistors into the third dimension: finFET, GAA, CFET, etc. That has kept the party going a little while longer than it would have lasted but it's a one-time deal since are no more dimensions to expand into.
- brookst 2y ago…but that’s how it’s always worked. Moore’a law is dead, we’re at the limit of everything, oh hey, Moore’s lawn limps by again because someone did something clever.
- light_hue_1 2y agoThat's never how it worked. Moore's law was never dead. People are just endlessly confused about what Moore's law is. What ended was Dennard scaling around 2006. Roughly that frequency would keep going up as feature size went down. But because so many people are confused about what is what, you see a crappy muddled message. Moore's law has been going strong. It must end eventually, current predictions are that it will be in a decade or two.
- perching_aix 2y agoIt's starting to get a bit old that whenever I see Moore's law mentioned, I'll usually also run into a spiel about how people have the wrong idea about what it actually refers to, and that it's holding up just fine. This is despite the gen-on-gen and year-on-year performance improvements of computer hardware very clearly tapering off in recent memory. Maybe debating what always-somehow-wrong law to cite should not be the focus? Like it's very clear to me that being technically correct about what Moore's law or the Dennard scaling refers to is leaps and bounds less important than the actual, practical computing performance trends that have been observable in the market.
- EncomLab 2y agoJonathan Blow has entered the chat...
- userbinator 2y agoOn the other hand, the multiplier is far more regular in structure than a Z80. The datapath on the Pentium is several times wider too.
- kens 2y agoA bit surprisingly, the Z80's datapath is 4 bits wide. The Pentium's FPU is more than 64 bits wide (extra bits for rounding and stuff). So, yes, there is a big difference in the datapath widths.
- Salgat 2y agoWhich is how it should be. There's a limited amount of resources in developing a chip, best to take advantage of the least costly route given those constraints.
- dlcarrier 2y agoThe speed of software bloat matching hardware improvement is known as Wirth's law: https://en.wikipedia.org/wiki/Wirth%27s_law https://en.wikipedia.org/wiki/Wirth%27s_law I think software bloat is growing faster, though.
- _carbyau_ 2y agoI think the software bloat is being more affected by the speed of light. If only every damn thing didn't need internet access with its associated lag - often variable in timing...
- dragontamer 2y agoThe internet has largely replaced CD Roms, Floppies and DVDs. The stuff you use a computer hard drive or Flash drive has remained consistent. Some items may have moved to the internet but most games, OS Utilities and whatnot are stored on local HDDs or SDDs. Always have and likely will remain so. I remember when data interchange meant burning a disc and walking a disc over to my buddy. XML will standardize that and simplify my workflow. /s
- eru 2y ago> Some items may have moved to the internet but most games, OS Utilities and whatnot are stored on local HDDs or SDDs. Always have and likely will remain so. Lots of Facebook and flash games are stored 'in the cloud' (but probably cached locally). For many games, a big part of the game logic runs on some server somewhere, especially multiplayer games.
- Someone 2y ago> Some items may have moved to the internet but most games, OS Utilities and whatnot are stored on local HDDs or SDDs. Always have and likely will remain so. With iCloud, your primary data lives in the cloud; your SSD caches recently used data, and the OS will delete it if it runs out of space. That’s millions of users for whom “whatnot” isn’t stored locally. (That’s how a 2TB iCloud subscription can make sense even if only used with a 500 GB SSD)
- acchow 2y agoHistory of function calls: - goto/jmp to instr - vtable lookup - hash and lookup in a dictionary - run a Large Language Model
- CamperBob2 2y agoOr, rather: - goto/jmp to instr - vtable lookup - hash and lookup in a dictionary - run everything through a universal approximator
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]