7 ms·
Yes, but that's pretty much how it goes. Jonathan Blow had a rant on release of the M1 Macs saying it literally didn't matter because computers were already rea
by 0xCMP 6y ago
Yes, but that's pretty much how it goes. Jonathan Blow had a rant on release of the M1 Macs saying it literally didn't matter because computers were already really fast and the problem has been, and will continue to be, that if the processor/system is faster then software will be written slower to hit the magical response time expected.
Kind of a cynical take... but is he wrong?
- pushrax 6y agoCarmack famously also has declared "I would rather have magic software over magic hardware" - the context being that we're using current hardware to a small fraction of its potential. Still, I feel there's a lot of software I use that is hard to optimize or no longer developed, and I'm certainly happy to have it run faster given new hardware. As a programmer I also like being able to be lazier and still have usable software. Higher level languages, GC, less thinking about access patterns and debugging prefetch problems, etc.
- ATsch 6y agoGiven it's Jonathan Blow, I feel compelled to say yes. More seriously, while program overheads have undoubtedly gotten higher, that's always been in exchange for something else, even if non-technical, like a better developer experience and platform support. Nobody writes slow programs on purpose, but people are very willing to trade it off for things that are more important in the grand scheme of things. Low level programmers love to smugly pretend that those tradeoffs do not exist but they do.
- ChrisMarshallNY 6y ago> Nobody writes slow programs on purpose No, but we are in a place where most development projects are really "stitching" dependencies together, and those dependencies can get heavy. On the other hand, this may help apps written in things like Ionic to speed up like crazy, because WebKit is now insanely fast.
- ATsch 6y ago> we are in a place where most development projects are really "stitching" dependencies together Is there anything wrong with that, though? If there's any common thread in the history of computing, it's that progress happens when things become abstracted enough to allow for another layer of building blocks. That's not to say that those layers don't have a cost, or we don't need to learn how to do them well, but gluing together components is really all software development has ever been.
- ChrisMarshallNY 6y agoIt's both good and bad; depending on how much care is taken in selecting dependencies. It's hard to use a lot of dependencies, regardless of their quality, without introducing bloat. Lots of redundancies. For example, each dependency may have its own messaging or thread management system, or its own memory management system. Or it may include other dependencies that have their own "special sauce." For myself, I use lots of little packages; mostly written by Yours Troolie, and only occasionally use third-party dependencies. Each of my packages is usually crafted towards a certain discrete function, and has its own project lifecycle. I think that's a good thing about using dependencies. I believe that modules with encapsulated lifecycles are a good way to ensure quality (or not, if I "choose poorly," as the Knight Templar said in the Indiana Jones movie).
- zamfi 6y ago> Nobody writes slow programs on purpose, but people are very willing to trade it off for things that are more important in the grand scheme of things Wait, of course they write slow programs on purpose, because "premature optimization is the root of all evil," right? A developer might use Electron because it's "fast enough" and halves your development time, and "fast enough" is always a perceptual metric, and not a technical one. Faster hardware means even less optimization is needed before something is shippable -- great for developers! -- and a recipe for software continuing to feel just as slow as before, because we only optimize until it's "fast enough". And despite the M1, or any of the advances of the last decade, the perceptual line that is "fast enough" hasn't changed. EDIT: Yes of course Knuth was talking about optimizing noncritical paths, but the sprit he’s espousing lives on in system design: use electron, or something else that makes your product more maintainable and easier to understand (because you didn’t build your own bespoke cross-platform app scaffold, and electron is well-documented, etc.), until you’re sure you can’t anymore. Well, the bar for “can’t” is raised every time there’s more cpu to support rapid, maintainable, “nonoptimal” development, and here we are.
- Apocryphon 6y agoOne wonders if VC-funded startups or "move fast and break things" firms like Facebook or Uber (as opposed to say '90s Microsoft or Sun or IBM or Bell Labs) becoming the vanguard advancing the cutting edge of some categories of software has created perverse incentives that reward this behavior. A cultural shift in Silicon Valley software development.
- ATsch 6y agoPeople used to talk about Java in the same way people talk about electron now so I feel like that's a definite no.
- nalekberov 6y agoPrograms written in Java runs on top JVM. On the other hand programs written for Electron comes bundled with Chromium. And we all know how it manages memory.
- deleted 6y ago[deleted]
- eivarv 6y agoMore seriously, while program overheads have undoubtedly gotten higher, that's always been in exchange for something else, even if non-technical, like a better developer experience and platform support. Software architecture usually entails trade-offs in many directions, between NFRs, etc. – but it feels to me like the intepretation of the performance-scale (as well as developer experience, really) is warped by two things: - Many devs aren't familiar with the real breadth of possibilities and discount some approaches without understanding them (using "developer experience", "platform support", and "too low level" as excuses), thereby skewing towards familiarity and preference. As most devs are familiar with web tech, this tends to win out. Other legitimate issues might not be even be understood (HCI, attack surface, accessibility, etc.) - The performance hit might not be significant enough to notice on a dev-grade machine (e.g. M1-processor, 32GB of RAM, etc.) and/or in isolation, but will become noticable when regular users run several apps built using the same heavy stack. The latter is particularly apparent if you try to run multiple Electron-apps simultaneously on a low-to-medium specced laptop – which I find pretty egregious as a user, as multitasking computer systems has been a thing for a while now. My interpretation is that many people (or companies) will usually write software that's no more performant than what they can get away with – which can be summed up, if cynically, as "users won't see any major performance gain or increase in capability in their day-to-day usage because of shitty software."
- 0xCMP 6y ago> Given it's Jonathan Blow, I feel compelled to say yes. This is also how I felt watching the video, but on the other hand I have a really hard time finding serious faults with his point. HN keeps things light. My personal website is super light. But the product I work on? What's a few MB gzipped down to less than a MB? 100ms? 300ms? Who can tell the difference[0]. [0]: I can, but certainly not the people who the feature matters to much of the time.
- hadsed 6y agoAnd even if you could, you're getting more value by getting that thing sooner. Or an even better argument: in the end, maybe it took just enough resources at the quality you got to even be born in the current market. Yeah most things are frivolous... you can survive without a better camera in your phone for another year. But that ham-fisted implicit cultural aspect is what also brings people medical devices 5-10 years sooner than it could have. We all know these gains compound over time. So maybe it's ok if our programs are a little slow. We buy the truly mission critical technology faster with that frivolity. But I'll also say, I still get mad at my phone and throw it pretty often. Just the way it is.
- sudosysgen 6y agoIt's not an either or. Cutting edge technology has always been a bit slow and rough around the edges. That's not an excuse for your chatroom client to use 450MB of RAM.
- curyous 6y agoSlow code is usually written due to ignorance rather than choice. Lots of people only know OOP, which is slow and unoptimisable by default.
- zarkov99 6y agoThe thing is the tradeoff makes more sense for the developer, who gets his job done quicker, than to the customer who pays for the sloppy bloat every time he uses the software.
- geodel 6y ago> Nobody writes slow programs on purpose, Well problem is developers are not writing fast programs on purpose. That they did not write slow on purpose but it nevertheless turned out to be slow is real problem to me as a user.
- flohofwoe 6y ago> Nobody writes slow programs on purpose True, but nobody writes fast programs on purpose either, only "fast enough" programs. The optimization work stops as soon as it "feels" fast enough and, this "feels fast enough" has been the same over the last few decades no matter how fast the underlying hardware is. Any advance in hardware will ineviatably be eaten by software within a year or two. That's why running old software on new hardware feels so increadibly fast. I also disgree that we got better developer- or user-experience out of the "deal". Most commercially developed applications have a "peak version", but still continue to be stuffed with new features that nobody asked for. E.g. name one feature that was added to Microsoft Word, Outlook or Excel in the last two versions which really added to the "user experience".
- sigotirandolas 6y agoNot just old software, but with a lot of open source software you usually have a spectrum of choice between more basic, lightweight software and more elaborate, heavyweight software. Think LXDE vs XFCE vs KDE vs Gnome as desktop environments, or nano vs Sublime vs Code/Atom vs IntelliJ as text editors, for example. However, when it comes some software areas prone to capture, there's not only no choice, but rather a multitude of incompatible-by-design options. Due to WFH, I need to have four different bloated chat/videoconference software on all the time which all offers the same features to me. When I want to watch a live stream, I need to open YouTube or Twitch or Facebook Live which all offer the same basic functionality but no one is interested in standardizing their interface so I can just point my familiar video player to it (at least without it breaking all the time due to cat-and-mouse fights between the platform and open source developers). I'm not generally in favour of regulation, but mandating some basic degree of interoperability so platform and software can compete separately seems like the only option.
- will_pseudonym 6y agoThe software being written being slower is of course enabled by those hardware improvements, but 1) the slow software is due to those technical inefficiencies making software easier/less expensive to produce, and 2) we can still make fast software by not using those inefficient means. That said, there's something of a problem with that though, because by making 1) more and more prevalent, it makes 2) more expensive due to fewer people choosing to work in that manner. Similar to how consumer technology goods get much less expensive, but have many more defects and issues. That "race to the bottom" makes cheap things cheaper, but makes more expensive things more difficult to make. I don't know what that phenomenon is called specifically, but it's definitely something I've been frustrated by in nearly every industry and product category.
- Apocryphon 6y agoI think you're definitely onto something, and what you're describing is a reoccurring pattern of modern society chasing after quick gains and optimizing certain metrics (e.g. short-term profit) over other considerations. It's not that people or organizations were necessarily more considerate or contemplative in the past, it's just that the processes or technological improvements (e.g. better hardware) weren't there to allow those races to the bottom. And maybe the systems we were living under didn't reward that behavior as much.
- markstos 6y agoThere's also a counterculture of projects that are lightweight alternatives: Sway as a lightweight window manager (among many lightweight WMs), musl vs libc, libressl vs openssl, gemini vs http, Alpine Linux vs Ubuntu, Alacritty as a blazing fast terminal. This software culture is visible on Linux than macOS, but it's alive and thriving.
- zarkov99 6y agoA little wrong. It does matter that the thing is always cool to the touch and it can run all day, even under heavy load. That is pretty new to my knowledge.
- throw0101a 6y agoPerhaps x86 has been 'fast enough' for most people, but the M1 is as fast (or faster) using less power. Even if the M1 was 'only' as fast as other chips, then it's performance-per-watt would still be impressive. Further, as someone who deals with HPC at $WORK, our (medical) researchers always want faster.
- x3sphere 6y agoYeah, sorta wrong. Sure, computers are already really fast, but the big thing with the M1 Macs for me is that they've finally came out with a laptop that doesn't heat up like crazy when I'm using it for moderately demanding tasks. Also every laptop I've had prior, would get pretty hot or the fan would get quite loud when connected to an external display. This M1 is completely silent when doing that AND it doesn't throttle.
- pushrax 6y agoWe have had passively cooled high performance devices for a while. M1 Macs are a great step, but it's more useful to compare them with previous gen mobile devices (iPad Pro 2018 ran faster than the 13" MBP at the time). Bringing ARM SoCs to laptops is also not new (e.g. Surface Pro X from Oct 2019), but I agree it's worth noting that Apple is doing a great job of it. Best x86 translation out there.
- samatman 6y agoWe used to have a saying "Moore giveth, and Gates taketh away". But I see two reasons why the M1 is a big deal, even given the bloat tax. One is simple power efficiency. These chips run cool and fast, and Intel laptop chips don't. No amount of hyperefficient code is going to get you a real 18 hours of battery life on last year's MacBook Air. The other one is Apple's proven track record of integrating custom hardware and software, into something which is greater than the sum of its parts. Ever since I got an iPad Pro, I've been quietly frustrated with the user interface of MacBooks. It's just not physics-smooth, and the iPad just is. I just got one of the 16" MacBook Pros for work, and it's pretty loaded, and it's a good computer— by the standards previous to the M1. Battery life could be better; overheats sometimes with serious fan noise, for no good reason, although each update to Catalina appears to substantially reduce this. I figured I could get five years on this rig. No way. I might make it to 2022, but I know terminal gearlust when I see it. Whatever Apple sticks in the next release of the 16", I'm craving it already.
- computing 6y ago"What Andy giveth, Bill taketh away" (Andy Moore, Bill Gates) https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law
- dreamcompiler 6y agoAndy Grove. Moore's first name is Gordon.
- computing 6y agoGrove, my bad.
- Betelgeuse90 6y agoWow man I'm really feeling that. I also have a great 16" and I'm experiencing similar issues with it. The new M1 MacBook Air is already as fast as my machine and costs less than half. It's bonkers. I use two external monitors however and the Air doesn't support that, so that's one thing keeping me away from the new M1. I imagine the new 16" MacBook Pros will support more than one external monitor, and I don't think I'd be able to stop myself from getting one.