5 ms·
I Waited 10B Cycles and All I Got Was This Loading Screen
- hyperhello 2y agoThis is like praising the reliability of modern automobiles while decrying the distance we have to travel for everything. You wouldn’t have fast computers without slow software.
- jebarker 2y agoThat doesn't feel correct. I think we push the boundaries on hardware because we aspire to scale up computation. If all those aspirational computations were faster we'd still develop faster hardware and have bigger ambitions. Unnecessarily slow software has no redeeming features.
- preyneyv 2y agoI think you have it backwards. We get away with longer distances because of faster automobiles. But imagine for a moment what would happen if we had faster automobiles and shorter distances: things would just be better.
- hyperhello 2y agoThey are both cause and effect: we accept longer distances because cars are reliable and we insist on reliable cars because they are necessary. You can’t get one without the other.
- jessriedel 2y agoThis is often explained as “cycles are cheap, programmers are expensive”. For the sake of argument, suppose LLMs are able to replace programmers for “laborious but straightforward work” like writing native versions of your app for every platform, and optimizing the hell out of it. Do we then expect all the apps we work with to become snappy again? Or are there red-queen-like dynamics that will prevent it?
- thrtythreeforty 2y agoI doubt it. The core logic remains unchanged: why have 1 feature that works well when you can have 10 features that don't work?
- jessriedel 2y agoBecause features require more human overhead to understand and manage than porting/optimizing does, by assumption of this hypothetical. Product managers and high-level architects aren’t free.
- preyneyv 2y agoThis is exactly the issue. We can do things faster => we can do more things worse!
- hansonkd 2y agoSnappy software requires the design of the system to be in sync with the engineering. Also the team needs to be aligned on snappiness being a priority. Product designers not understanding how adding certain UI elements, animations or requesting certain features is the main cause from my experience. The fastest way to speed things up in certain cases is to just remove some elements. I would expect the situation to get worse rather than better if LLMs can deliver any feature a product designer wants without limitation and if the product designer doesn't care about "snappiness"
- jessriedel 2y agoThe assumption of the hypothetical is not that they can deliver any feature, which I consider (maybe you disagree) more open-ended and less automatable than porting and optimization. If you think that’s an unrealistic assumption, please feel free to propose another!
- hansonkd 2y agoI'm saying that it doesn't matter how much porting and optimization the llms do if the person designing the product doesn't care about efficiency. Currently designers have pretty limitless ability to add features even without LLMs. LLMs will just compound that. The only way to get efficient code is to have the right mindset from the get go. Not as an after thought that you hope the LLM will optimize.
- ynniv 2y agoApathy
- ksec 2y agoPeople used to be ok with Webpacker before Esbuild came along and thought that was OK, until Bun show what is really possible. The same with Atom, VSCode, and now Zed. ( For a very long time people on HN claim VSCode is about as fast as Sublime ) I am hoping Vision Pro, Meta or VR / AR will finally have enough incentive to solve latency computing. Most of today's computing is very slow. From OS to Apps and Web. And I value Steve Jobs' opening the lid of a MacBook and it should be ready mentality. Sometimes I think if Steve Jobs was the yard stick on speed and smoothness of the Apple software platform. Because it has gone downhill since. Especially on Safari.
- jchw 2y ago> For a very long time people on HN claim VSCode is about as fast as Sublime The trouble is that "fast" is an insufficient word to describe a piece of software. As everyone has certainly realized by now, software feels "fast" when it is very responsive, e.g. the latency is low, and Sublime Text certainly felt "fast". However, Sublime Text regularly ran into problems where it had too much algorithmic complexity, e.g. when dealing with pathological cases like extremely long lines or something like that. Basic editing could become slow or you might even need to force close it. Not great. VSCode feels reasonably responsive, at least, it certainly feels more responsive than you'd expect what is effectively a web app strapped to a browser to feel. A lot of effort was put into the feel of Monaco and keeping the text editing relatively unblocked. But maybe most importantly, careful optimization made VSCode perform well in a lot of scenarios where even native code software like Sublime and Kate struggled, with very fast Find and Replace that could gracefully handle pathological cases and a document structure that was good at loading, displaying and editing large documents (and with some limits applied to try to prevent pathological cases from blowing up the user's editor window.) Zed is off to a good start because it takes a lot of learnings from VSCode and others. In my opinion though, it doesn't really feel dramatically better than VSCode, as the day-to-day UX is just less polished over all. It is, however, very promising, as it certainly feels better than VSCode did in the early days of it.
- preyneyv 2y agoHard agree on VR / AR latency requirements. It's the first consumer use case in a while that's ahead of the average user's compute power, and I really hope it will mean good things for performant software.
- torgoguys 2y agoOne eye-opening experience for me in this regard was when I installed an old version of Microsoft Excel--I think it was either the 2000 or the 2003 version--on modern hardware. The snappiness of every action was AMAZING. Every click, drag, keystroke felt instant. It's hard to describe because modern Excel doing typical actions doesn't feel slow and prior to this experience I would have said it was immediately responding to my inputs, but the difference experienced was obvious and felt GREAT even though it was probably only a small number of milliseconds.
- MichaelZuo 2y agoThe 2010 version of Excel is significantly faster than later versions even for pure number crunching, e.g. doing some calculation over a big sheet with a million rows and a thousand columns.
- jeroenhd 2y agoMicrosoft Excel is probably also a good example for another reason. Microsoft Office 2003 Standard Edition cost $400 new, or $239 per upgrade ($664 or $397 in today's money). If you wanted Excel alone, you could buy that, for $229 (or $109 if you upgrade from an earlier version). That alone would be $380/$181 in today's money. Keep in mind that features were released every two years at the very earliest. Two years of Microsoft Teams costs $96 and gets you hosting. The question of web vs native isn't "do you want fast software or slow software" but "do you want cheap software that brings lots of features or do you want expensive software that makes you pay again to keep up with the competition after two years". Of course enterprise pricing was more generous and piracy was another factor that doesn't really come into play with Teams, but I'm not surprised all software has moved to quickly evolving web apps these days. In a time where paying more than $60 for a video game is considered controversial, $660 office suites simply aren't viable. Another smaller issue with even modern Excel over old versions of Excel is that a lot of sandboxing has been added since, and even that is proving not to be sufficient by itself. The old happy-go-lucky Excels were a one-click way into infecting a whole network because no time was wasted on boundary checks where it was not absolutely necessary to prevent the program from crashing. Web apps especially have layers upon layers of security mechanisms to prevent viruses from spreading as trivially as they did twenty years ago.
- josephg 2y agoI couldn't upvote this enough. I find it utterly infuriating that across the world, we spend hundreds of billions (trillions?) of dollars on computing hardware. And almost all of the cycles (easily over 99% of them) are totally wasted doing stupid, totally unnecessary makework because programmers are too lazy. Tauri (an electron-like written in rust) used to have a page where they touted how efficient it is, boasting that it "only" took 300mb of ram to run a “hello world” app, and it started up in only ("only") 25000 syscalls. 300mb of ram is 2.4 billion bits. Just, how? The tauri benchmarks page has since been taken down - perhaps out of embarrassment. In comparison, the Super Nintendo had 128kb of RAM (2000x less than needed for tauri's hello world) and it ran all sorts of incredible games, including the legendary super mario bros. The Atari 2600 shipped with 128 bytes of ram, which is less than one tweet. (Though cartridges could contain extra ram chips).
- ryandrake 2y agoThe Apollo guidance computer had 4 kilobytes of core memory and took humans to the moon.
- jeroenhd 2y agoThe Super Nintendo didn't need to render mixed direction scripts from different languages at 120fps. It had zero mouse support, its keyboards lacked almost every key, and its audio output was simply terrible. I don't think it supported IMEs or screen readers either. When I'm doing desktop work, I'd take a 300MB browser application over a SNES any day. The laudable terms used in the Tauri benchmark was a tad silly (though it makes some sense, as Tauri competes with Electron, not with normal native toolkits) but modern GUIs require more processing power than those 160x120 GUIs from back in the way did. It also helps a lot that you can subscribe to modern app subscriptions for half a decade before you've paid the price of what software used to cost (software that would be outdated by next year, and you had to pay again to upgrade), and that old price didn't come with hosting of any kind either. Programmers have always been lazy, but the modern laziness when it comes to performance isn't because nobody cares; it's because nobody is willing to pay for the kind of responsiveness of yore anymore.
- 2y ago
- jawilson2 2y agoI'm finding it slightly ironic[0] that this site takes 162 MB RAM (according to hovering over the tab in chrome), scrolls incredibly slowly, and has hijacked the right-click menu so I can't open links in a new tab. I definitely agree with the content, though. I'm so glad I don't do webdev. [0] I think this is actually correct usage of "ironic."
- MichaelZuo 2y agoYou could run Far Cry 1 on a 1920x1200p screen within 162 MB of RAM…
- Retr0id 2y agoMaybe I'm being saved by uBlock but I didn't notice any scroll hijacking or right-click interference. Edit: uBlock is blocking one analytics script and there are no other scripts on the page. Disabling uBlock doesn't seem to affect page behaviour.
- jawilson2 2y agoEntirely possible, I'm on a work-issued laptop and I can't install extensions, because raw-dogging the internet is safer than letting employees block ads.
- jeroenhd 2y agoI'm guessing you're on Edge if you're in that predicament; in that case you should check if you can set tracker blocking to "strict". It doesn't work completely like an ad blocker (it doesn't hide broken elements for instance) but that may block loads of unwanted content without needing permission to install addons.
- alwayslikethis 2y agoOn mine, it shows about 30 MB, which is less than this HN thread. I don't see the right-click hijacking either. Am I missing something?
- 2y ago
- klysm 2y agoI think the right way to look at this is the trade off spaces that are maligned with performance. You can usually gain something by losing some performance, so those who gain but don’t go too far overboard on things being slow will win. I will say I share the authors sentiment that 9 billion cycles should be enough for anybody. Unfortunately for us, it’s usually somebody else’s computer that’s holding us up.
- jawilson2 2y ago> You can usually gain something by losing some performance This is a pretty canonical description of tech debt, right? "Get it working, ship it, we can worry about performance later."
- klysm 2y agoI’m not sure it’s even debt really. At a product level you can device to just tolerate the slowness indefinitely
- wyager 2y agoThe lower your performance requirements, the more you can loosen up what kind of programmers you hire. A dev who can only use <insert high level GC'd language known for being easy to use/easy to hire for> is relatively quite cheap! The language isn't necessarily the problem, but at the very least it correlates with the problem due to pricing. The code may suck, but most companies don't care, because most clients either don't care or there's not an incentive structure in place to communicate the care back up to the corpo decision-makers.
- Juden1488 2y ago[dead]
- devit 2y agoThe reason is that most developers have no clue and/or no interest about performance, and so they only optimize where there's a user-visible problem, which means that the program will consume resources proportional to speed of the developer's machine.
- msk-lywenn 2y agoBad performance is a user visible problem
- cozzyd 2y agoSlack is not a good example of a performant electron app (or, perhaps if it is, that is quite damning praise). I should never be able to type faster than it can put characters on screen...
- kleiba 2y agoCasey Muratori started a whole educational webseries about this - the fact that hardware is getting faster and faster but the user experience seems to be staying the same. https://www.youtube.com/watch?v=Ge3aKEmZcqY&list=PLEMXAbCVnmY4JbNByvpgEzWsLRKVaF_pk https://www.youtube.com/watch?v=Ge3aKEmZcqY&list=PLEMXAbCVnm... He also has a "performance-aware programming" series: https://www.youtube.com/watch?v=pZ0MF1q_LUE&list=PLEMXAbCVnmY7t29i_rd3mnALWu-aZr_42 https://www.youtube.com/watch?v=pZ0MF1q_LUE&list=PLEMXAbCVnm...
- preyneyv 2y agoooh these are excellent, thank you for sharing!
- tim333 2y agoI think a lot of it is that consumers don't care that much. A couple of seconds is still fairly quick regardless of how many cycles are going on in the background. With humans you don't say how can they take a couple of seconds to reply when they have 100 bn parallel neurons. The only thing that really bugs me computer speed wise these days is connecting to wifi. Why does that take a minute while you just want to read something?
- greatgib 2y agoMost people are “okay” with waiting 500ms for a right-click context menu to appear, It is maybe that most people have never experienced the world "before" where everything in term of UI was a lot faster than today when we were more using real native applications. I have often this debate with friends that think VSCode and co are awesome when for me it is barely usable to have an editor with so much latency on each key typed. Same effects with apps like mail clients. When you are in Gmail and struggle to select hundreds of spam in multiple pages to delete them, compare that to the instant click/drag select of emails with infinite scrolling in native applications like thunderbird.
- preyneyv 2y agoYeah, it's definitely one of those things where your eyes are "opened" when you use something faster. Kind of like headphones, what you have is good enough until you try something better.