13 ms·

I like to point out that since ~1980, computing power has increased about 1000X. If dynamic array bounds checking cost 5% (narrator: it is far less than that),

by titzer 1y ago

I like to point out that since ~1980, computing power has increased about 1000X. If dynamic array bounds checking cost 5% (narrator: it is far less than that), and we turned it on everywhere, we could have computers that are just a mere 950X faster. If you went back in time to 1980 and offered the following choice: I'll give you a computer that runs 950X faster and doesn't have a huge class of memory safety vulnerabilities, and you can debug your programs orders of magnitude more easily, or you can have a computer that runs 1000X faster and software will be just as buggy, or worse, and debugging will be even more of a nightmare. People would have their minds blown at 950X. You wouldn't even have to offer 1000X. But guess what we chose... Personally I think the 1000Xers kinda ruined things for the rest of us.

_aavaa_ 1y ago
Except we've squandered that 1000x not on bounds checking but on countless layers of abstractions and inefficiency.
- pydry 1y ago
  Most of it was exchanged for abstractions which traded runtime speed for the ability to create apps quickly and cheaply. The market mostly didn't want 50% faster code as much as it wanted an app that didn't exist before. If I look at the apps I use on a day to day basis that are dog slow and should have been optimized (e.g. slack, jira), it's not really a lack of the industry's engineering capability to speed things up that was the core problem, it is just an instance the principal-agent problem - i.e. I'm not the one buying, I don't get to choose not to use it and dog-slow is just one of many the dimensions in which they're terrible.
  - fsloth 1y ago
    I don’t think abundance vs speed is the right lens. No user actually wants abundance. They use few programs and would benwfit if those programs were optimized. Established apps could be optimized to the hilt. But they seldom are.
    - pydry 1y ago
      >No user actually wants abundance. No, all users just want the few programs which they themselves need. The market is not one user, though. It's all of them.
      - skydhash 1y ago
        But each vendor only develop a few software and generally supports only three platforms -/+ one. It’s so damning when I see projects reaching out for electron, when they only support macOS and Windows. And software like Slack has no excuse for being this slow on anything other than latest gen cpu and 1gb internet connection.
        pydry 1y ago
        slack is shit along all sorts of dimensions (not just speed and bloat) because you're not the customer.
      - bluGill 1y ago
        Users only want 5% of the features of the few programs they use. However everyone has a different list of features and a different list of programs. And so to get a market you need all the features on all the programs.
    - infogulch 1y ago
      > They use few programs Yes but it's a different 'few programs' than 99% of all other users, so we're back to square one.
  - ffsm8 1y ago
    > Most of it was exchanged for abstractions which traded runtime speed for the ability to create apps quickly and cheaply. Really? Because while abstractions like that exist (i.e. a webserver frameworks, reactivity, SQL and ORMs etc), I would argue that these aren't the abstractions that cause the most maintenance and performance issues. These are usually in the domain/business application and often not something that made anything quicker to develop or anything, but instead created by a developer that just couldn't help themselves
    - tonyarkles 1y ago
      I think they’re referring to Electron. Edit: and probably writing backends in Python or Ruby or JavaScript.
      - Zak 1y ago
        The backend programming language usually isn't a significant bottleneck; running dozens of database queries in sequence is the usual bottleneck, often compounded by inefficient queries, inappropriate indexing, and the like.
        sgarland 1y ago
        Yep. I’m a DBRE, and can confirm, it’s almost always the DB, with the explicit caveat that it’s also rarely the fault of the DB itself, but rather the fault of poor schema and query design. Queries I can sometimes rewrite, and there’s nothing more satisfying than handing a team a 99% speed-up with a couple of lines of SQL. Sometimes I can’t, and it’s both painful and frustrating to explain that the reason the dead-simple single-table SELECT is slow is because they have accumulated billions of rows that are all bloated with JSON and low-cardinality strings, and short of at a minimum table partitioning (with concomitant query rewrites to include the partition key), there is nothing anyone can do. This has happened on giant instances, where I know the entire working set they’re dealing with is in memory. Computers are fast, but there is a limit. The other way the DB gets blamed is row lock contention. That’s almost always due to someone opening a transaction (e.g. SELECT… FOR UPDATE) and then holding it needlessly while doing other stuff, but sometimes it’s due to the dev not being aware of the DB’s locking quirks, like MySQL’s use of gap locks if you don’t include a UNIQUE column as a search predicate. Read docs, people!
  - pona-a 1y ago
    Did people make this exchange or did __the market__? I feel like we're assigning a lot of intention to a self-accelerating process. You add a new layer of indirection to fix that one problem on the previous layer, and repeat it ad infinitum until everyone is complaining about having too many layers of indirection, yet nobody can avoid interacting with them, so the only short-term solution is a yet another abstraction.
- grumpymuppet 1y ago
  This is something I've wished to eliminate too. Maybe we just cast the past 20 years as the "prototyping phase" of modern infrastructure. It would be interesting to collect a roadmap for optimizing software at scale -- where is there low hanging fruit? What are the prime "offenders"? Call it a power saving initiative and get environmentally-minded folks involved.
  - sgarland 1y ago
    IMO, the prime offender is simply not understanding fundamentals. From simple things like “a network call is orders of magnitude slower than a local disk, which is orders of magnitude slower than RAM…” (and moreover, not understanding that EBS et al. are networked disks, albeit highly specialized and optimized), or doing insertions to a DB by looping over a list and writing each row individually. I have struggled against this long enough that I don’t think there is an easy fix. My current company is the first I’ve been at that is taking it seriously, and that’s only because we had a spate of SEV0s. It’s still not easy, because a. I and the other technically-minded people have to find the problems, then figure out how to explain them b. At its heart, it’s a culture war. Properly normalizing your data model is harder than chucking everything into JSON, even if the former will save you headaches months down the road. Learning how to profile code (and fix the problems) may not be exactly hard, but it’s certainly harder than just adding more pods to your deployment.
  - mike_hearn 1y ago
    Use of underpowered databases and abstractions that don't eliminate round-trips is a big one. The hardware is fast but apps take seconds to load because on the backend there's a lot of round-trips to the DB and back, and the query mix is unoptimized because there are no DBAs anymore. It's the sort of thing that can be handled via better libraries, if people use them. Instead of Hibernate use a mapper like Micronaut Data. Turn on roundtrip diagnostics in your JDBC driver, look for places where they can be eliminated by using stored procedures. Have someone whose job is to look out for slow queries and optimize them, or pay for a commercial DB that can do that by itself. Also: use a database that lets you pipeline queries on a connection and receive the results asynchronously, along with server languages that make it easy to exploit that for additional latency wins.
- Gigachad 1y ago
  Am I taking crazy pills or are programs not nearly as slow as HN comments make them out to be? Almost everything loads instantly on my 2021 MacBook and 2020 iPhone. Every program is incredibly responsive. 5 year old mobile CPUs load modern SPA web apps with no problems. The only thing I can think of that’s slow is Autodesk Fusion starting up. Not really sure how they made that so bad but everything else seems super snappy.
  - mjburgess 1y ago
    People conflat the insanity of running a network cable through every application with the poor performance of their computers.
    - sgarland 1y ago
      Correction: devs have made the mistake of turning everything into remote calls, without having any understanding as to the performance implications of doing so. Sonos’ app is a perfect example of this. The old app controlled everything locally, since the speakers set up their own wireless mesh network. This worked fantastically well. Someone at Sonos got the bright idea to completely rewrite the app such that it wasn’t even backwards-compatible with older hardware, and everything is now a remote calls. Changing volume? Phone —> Router —> WAN —> Cloud —> Router —> Speakers. Just… WHY. This failed so spectacularly that the CEO responsible stepped down / was forced out, and the new one claims that fixing the app is his top priority. We’ll see.
      - mjburgess 1y ago
        Presumably they wanted the telemetry. It's not clear that this was a dev-initiated switch. Perhaps we can blame the 'statistical monetization' policies of adtech and then AI for all this -- i'm not entirely sold on developers. What, after all, is the difference between an `/etc/hosts` set of loop'd records vs. an ISP's dns -- as far as the software goes?
        sgarland 1y ago
- bitmasher9 1y ago
  The major slowdown of modern applications is network calls. Spend 50-500ms a pop for a few kilos of data. Many modern applications will spin up a half dozen blocking network calls casually.
- TiredOfLife 1y ago
  And text that is not a pixely or blurry mess. And Unicode.
  - anthk 1y ago
    Unicode worked since Plan9. And antialiasing it's from the early 90's.
- josefx 1y ago
  > on countless layers of abstractions Even worse, our bottom most abstraction layers pretend that we are running on a single core system from the 80s. Even Rust got hit by that when it pulled getenv from C instead of creating a modern and safe replacement.
ngangaga 1y ago
I don't think it's that deep. We are just stuck with browsers now, for better and worse. Everything else trails.
- slowmovintarget 1y ago
  We're stuck with browsers now until the primary touch with the internet is assistants / agent UIs / chat consoles. That could end up being Electron (VS Code), though that would be a bit sad.
  - scotty79 1y ago
    I don't think we are gonna go there. Talking is cumbersome. There's a reason, besides social anxiety that people prefer to use self-checkout and electronically order fastfood. There are easier ways to do a lot of things than with words. I'd bet on maybe ad hoc ai designed ui-s you click but have a voice search when you are confused about something.
    - deleted 1y ago
      [deleted]
    - bluGill 1y ago
      If you know what you want then not talking to a human is faster. However if you are not sure a human can figure out. I'm not sure I'd trust a voice assistant - the value in the human is an informed opinion which is hard to program, but it is easy to program a recommendation for whatever makes the most profit. Of course humans often don't have an informed opinion either, but at least sometimes they do, and they will also sometimes admit it when they don't.
      - scotty79 1y ago
        > the value in the human is an informed opinion which is hard to program I don't think I ever used a human for that. They are usually very uninformed about everything that's not their standard operational procedure or some current promotional materials.
vrighter 1y ago
Don't forget the law of large numters. 5% performance hit on one system is one thing, 5% across almost all of the current computing landscape is still a pretty huge value.
- titzer 1y ago
  It's about 5%. Cost of cyberattacks globally[1]: O($trillions) Cost of average data breach[2][3]: ~$4 million Cost of lost developer productivity: unknown We're really bad at measuring the secondary effects of our short-sightedness. [1] https://iotsecurityfoundation.org/time-to-fix-our-digital-foundations-a-new-report-on-memory-safety-and-secure-networking/ https://iotsecurityfoundation.org/time-to-fix-our-digital-fo... [2] https://www.internetsociety.org/resources/doc/2023/how-to-talk-to-your-manager-about-memory-safety/#8 https://www.internetsociety.org/resources/doc/2023/how-to-ta... [3] https://www.ibm.com/reports/data-breach https://www.ibm.com/reports/data-breach
  - timewizard 1y ago
    > Cost of cyberattacks globally[1]: O($trillions) That's a fairly worthless metric. What you want is "Cost of cyberattacks / Revenue from attacked systems." > We're really bad at measuring the secondary effects of our short-sightedness. We're really good at it. There's an entire industry that makes this it's core competency... insurance. Which is great because it means you can rationalize risk. Which is also scary because it means you can rationalize risk.
- pron 1y ago
  But it's not free for the taking. The point is that we'd get more than that 5%'s worth in exchange. So sure, we'll get significant value "if software optimization was truly a priority", but we get even more value by making other things a priority. Saying "if we did X we'd get a lot in return" is similar to the fallacy of inverting logical implication. The question isn't, will doing something have significant value, but rather, to get the most value, what is the thing we should do? The answer may well be not to make optimisation a priority even if optimisation has a lot of value.
fsloth 1y ago
The problem is 1000xers are a rarity. The software desktop users have to put up with is slow.
- HappMacDonald 1y ago
  You can always install DOS as your daily driver and run 1980's software on any hardware from the past decade, and then tell me how that's slow. 1000x referred to the hardware capability, and that's not a rarity that is here. The trouble is how software has since wasted a majority of that performance improvement. Some of it has been quality of life improvements, leading nobody to want to use 1980s software or OS when newer versions are available. But the lion's share of the performance benefit got chucked into the bin with poor design decisions, layers of abstractions, too many resources managed by too many different teams that never communicate making any software task have to knit together a zillion incompatible APIs, etc.
  - 3036e4 1y ago
    The sad thing is that even running DOS software in DOSBox (or in QEMU+FreeDOS), or Amiga software in UAE, is much faster than any native software I have run in many years on any modern systems. They also use more reasonable amounts of storage/RAM. Animations is part of it of course. A lot of old software just updates the screen immediately, like in a single frame, instead of adding frustrating artificial delays to every interaction. Disabling animations in Android (an accessibility setting) makes it feel a lot faster for instance, but it does not magically fix all apps unfortunately.
  - ryao 1y ago
    > The trouble is how software has since wasted a majority of that performance improvement. It has been sacrificed in the name of developer productivity, since hardware is cheap compared to the cost of writing efficient software outside of performance critical situations. The result is that the world is drowning in inefficient software.
justincormack 1y ago
Most programming languages have array bounds checking now.
- oblio 1y ago
  Most programming languages are written in C, which doesn't. Fairly sure that was OP's point.
  - ryao 1y ago
    Secure string handling functions like strlcpy() and strlcat() do have bounds checks. Not everyone uses them sadly.
    - oblio 1y ago
      And that again, is the point. That stuff should be built-in and almost non-negotiable. It should be a lot more work to do the unsafe thing (see: Rust).
      - ryao 1y ago
        They are negotiable in Rust too. Just use the unsafe keyword everywhere. If you want to use a language where they are non-negotiable, use JavaScript. Secure string functions are built into C these days. The older error prone ones are as well. You can ban the older functions from code bases, but it is hard to justify outright bans for all of them. If you audit string function usage in a non-trivial codebase, you likely will find instances where the old, error prone, string functions are used in safe ways and leaving them alone makes sense. This is particularly the case when constant length strings are used with constant length buffers. Here is an example where the old string functions are just as safe as the secure string functions: https://github.com/openzfs/zfs/blob/master/etc/systemd/system-generators/zfs-mount-generator.c#L449 https://github.com/openzfs/zfs/blob/master/etc/systemd/syste... I found it when I audited the string function usage in OpenZFS with the goal of removing all uses of the older string functions. While I replaced every instance old string function where the secure string functions mitigated even the slightest risk, I could not bring myself to remove these, since there was nothing wrong with them. After my patches, a few string functions were then banned from the codebase with a build system hack put in place to break the build process if someone tried to reintroduce the banned functions.
scotty79 1y ago
Since 1980 maybe. But since 2005 it increased maybe 5x and even that's generous. And that's half of the time that passed and two decades. https://youtu.be/m7PVZixO35c?si=px2QKP9-80hDV8Ui https://youtu.be/m7PVZixO35c?si=px2QKP9-80hDV8Ui
- jandrese 1y ago
  2005 was Pentium 4 era. For comparison: https://www.cpubenchmark.net/compare/1075vs5852/Intel-Pentium-4-3.06GHz-vs-Intel-i7-14700 https://www.cpubenchmark.net/compare/1075vs5852/Intel-Pentiu... That's about a 168x difference. That was from before Moores law started petering out. For only a 5x speed difference you need to go back to the 4th or 5th generation Intel Core processors from about 10 years ago. It is important to note that the speed figure above is computed by adding all of the cores together and that single core performance has not increased nearly as much. A lot of that difference is simply from comparing a single core processor with one that has 20 cores. Single core performance is only about 8 times faster than that ancient Pentium 4.
- voidspark 1y ago
  As the other guy said, top of the line CPUs today are roughly ~100x faster than 20 years ago. A single core is ~10x faster (in terms of instructions per second) and we have ~10x the number of cores.
  - topaz0 1y ago
    And the memory quantity, memory speed, disk speed are also vastly higher now than 20 years ago.
ngneer 1y ago
I agree with the sentiment and analysis that most humans prefer short term gains over long term ones. One correction to your example, though. Dynamic bounds checking does not solve security. And we do not know of a way to solve security. So, the gains are not as crisp as you are making them seem.
- HappMacDonald 1y ago
  You don't have to "solve" security in order to improve security hygiene by a factor of X, and thus risk of negative consequences by that same factor of X.
  - ngneer 1y ago
    I am not suggesting we refuse to close one window because another window is open. That would be silly. Of course we should close the window. Just pointing out that the "950X" example figure cited fails to account for the full cost (or overestimates the benefit).
- bluGill 1y ago
  Bounds checking solves one tiny subset of security. There are hundreds of other subsets that we know how to solve. However these days the majority of the bad attacks are social and no technology is likely to solve them - as more than 10,000 years of history of the same attack has shown. Technology makes the attacks worse because they now scale, but social attacks have been happening for longer than recorded history (well there is every reason to believe that - there is unlikely to evidence going back that far).
  - titzer 1y ago
    > However these days the majority of the bad attacks are social You're going to have to cite a source for that. Bounds checking is one mechanism that addresses memory safety vulnerabilities. According to MSFT and CISA[1], nearly 70% of CVEs are due to memory safety problems. You're saying that we shouldn't solve one (very large) part of the (very large) problem because there are other parts of the problem that the solution wouldn't address? [1] https://www.cisa.gov/news-events/news/urgent-need-memory-safety-software-products https://www.cisa.gov/news-events/news/urgent-need-memory-saf...
dist-epoch 1y ago
It's more like 100,000X. Just the clockspeed increased 1000X, from 4 MHz to 4 GHz. But then you have 10x more cores, 10x more powerful instructions (AVX), 10x more execution units per core.
noobermin 1y ago
The first reply is essentially right. This isn't what happened at all, just because C is still prevalent. All the inefficiency is everything down the stack, not in C.
card_zero 1y ago
I don't trust that shady-looking narrator. 5% of what exactly? Do you mean that testing for x >= start and < end is only 5% as expensive as assigning an int to array[x]? Or would bounds checking in fact more than double the time to insert a bunch of ints separately into the array, testing where each one is being put? Or ... is there some gimmick to avoid all those individual checks, I don't know.
- timbit42 1y ago
  You only need to bounds check once before a for loop starts, not every iteration.
  - card_zero 1y ago
    If they're all being inserted contiguously. Anyway that's a form of saying "I know by reasoning that none of these will be outside the bounds, so let's not check".
  - ryao 1y ago
    It depends on the loop. Here are a bunch of loops that need bounds checks on every loop iteration: https://github.com/openzfs/zfs/commit/303678350a7253c7bee9d6a3347ee1bcdf9cc177 https://github.com/openzfs/zfs/commit/303678350a7253c7bee9d6... You could argue otherwise and you would not be wrong since the codebase had not given this code inputs that would overrun the buffer. However, any case where you loop until the string is built needs a check on each iteration unless you can both prove that the buffer will always be long enough for any possible output and guarantee that future changes will preserve this property. The former is a pain (but doable) while the latter was infeasible, which is why the bounds checks were added. That said, something as innocuous as printing a floating value could print 308 characters where you only expected 10 or less: https://github.com/openzfs/zfs/commit/f954ea26a615cecc8573bb439482d9fd88019854 https://github.com/openzfs/zfs/commit/f954ea26a615cecc8573bb... Edge cases causing things to print beyond what was expected are a good reason why people should use bounds checks when building strings, since truncation is fail safe, while overrunning the buffer is fail dangerous. I am a fan of the silent truncation done in both patches, since in both cases, truncation is harmless. For cases where silent truncation is not harmless, you can use detect the truncation by checking the return value of `snprintf()` and react accordingly. It should be said that the scnprintf() function's return value does not permit truncation detection and `snprintf()` should be used if you want that. Note that I am the author of those two patches, so it is natural that I like the approach I used. They were written as part of an audit of the OpenZFS codebase I did when bug hunting for fun.
ricardo81 1y ago
>Personally I think the 1000Xers kinda ruined things for the rest of us. Reminds me of when NodeJS came out that bridged client and server side coding. And apparently their repos can be a bit of a security nightmare nowadays- so the minimalist languages with limited codebase do have their pros.
monkeyelite 1y ago
> If dynamic array bounds checking cost 5% (narrator: it is far less than that) It doesn’t work like that. If an image processing algorithm takes 2 instructions per pixel, adding a check to every access could 3-4x the cost. This is why if you dictate bounds checking then the language becomes uncompetitive for certain tasks. The vast majority of cases it doesn’t matter at all - much less than 5%. I think safe/unsafe or general/performance scopes are a good way to handle this.
- miloignis 1y ago
  It's not that simple either - normally, if you're doing some loops over a large array of pixels, say, to perform some operation to them, there will only be a couple of bounds checks before the loop starts, checking the starting and ending conditions of the loops, not re-doing the bounds check for every pixel. So very rarely should it be anything like 3-4x the cost, though some complex indexing could cause it to happen, I suppose. I agree scopes are a decent way to handle it!
  - monkeyelite 1y ago
    You’re describing a situation where I - or a very smart compiler can choose when to bounds check or not to make that intelligent realization.
- timbit42 1y ago
  Your argument is exactly why we ended up with the abominations of C and C++ instead of the safety of Pascal, Modula-2, Ada, Oberon, etc. Programmers at the time didn't realize how little impact safety features like bounds checking have. The bounds only need to be checked once for a for loop, not on each iteration.
  - monkeyelite 1y ago
    > The bounds only need to be checked once for a for loop, not on each iteration. This is a theoretical argument. It depends on the compiler being able to see that’s what you’re doing and prove that there is no other mutation. > abominations of C and C++ Sounds like you don’t understand the design choices that made this languages successful.
CyberDildonics 1y ago
Clock speeds are 2000x higher than the 80s. IPC could be 80x higher when taking into account SIMD and then you have to multiply by each core. Mainstream CPUs are more like 1 to 2 million times faster than what was there in the 80s. You can get full refurbished office computers that are still in the million times faster range for a few hundred dollars. The things you are describing don't have much to do with computers being slow and feeling slow, but they are happening anyway. Scripting languages that are constantly allocating memory to any small operation and pointer chasing ever variable because the type is dynamic is part of the problem, then you have people writing extremely inefficient programs in an already terrible environment. Most programs are written now in however way the person writing them wants to work, not how someone using it wishes they were written. Most people have actually no concept of optimization or what runs faster than something else. The vast majority of programs are written by someone who gets it to work and thinks "this is how fast this program runs". The idea that the same software can run faster is a niche thought process, not even everyone on hacker news thinks about software this way.
wustus 1y ago
And this is JavaScript. And you. are. going. to. LOVE IT!
billfor 1y ago
I made a vendor run their buggy and slow software on a Sparc 20 against their strenuous complaints to just let them have an Ultra, but when they eventually did optimize their software to run efficiently (on the 20) it helped set the company up for success in the wider market. Optimization should be treated as competitive advantage, perhaps in some cases one of the most important.
- MonkeyClub 1y ago
  > Optimization should be treated as competitive advantage That's just so true! The right optimizations at the right moment can have a huge boost for both the product and the company. However the old tenet regarding premature optimization has been cargo-culted and expanded to encompass any optimization, and the higher-ups would rather have ICs churn out new features instead, shifting the cost of the bloat to the customer by insisting on more and bigger machines. It's good for the economy, surely, but it's bad for both the users and the eventual maintainers of the piles of crap that end up getting produced.
AtlasBarfed 1y ago
I think on year 2001 GHz CPU should be a performance benchmark that every piece of basic non-high performance software should execute acceptably on. This is kind of been a disappointment to me of AI when I've tried it. This has kind of been a disappointment to me of AI when I've tried it. Llm should be able to Port things. It should be able to rewrite things with the same interface. It should be able to translate from inefficient languages to more efficient ones. It should even be able to optimize existing code bases automatically, or at least diagnose or point out poor algorithms, cache optimization, etc. Heck I remember powerbuilder in the mid 90s running pretty well on 200 mhz CPUs. It doesn't even really interpreted stuff. It's just amazing how slow stuff is. Do rounded corners and CSS really consume that much CPU power? My limited experience was trying to take the unix sed source code and have AI port it into a jvm language, and it could do the most basic operations, but utterly failed at even the intermediate sed capabilities. And then optimize? Nope Of course there's no desire for something like that. Which really shows what the purpose of all this is. It's to kill jobs. It's not to make better software. And it means AI is going to produce a flood of bad software. Really bad software.
- peatmoss 1y ago
  I've pondered this myself without digging into the specifics. The phrase "sufficiently smart compiler" sticks in my head. Shower thoughts include whether there are languages that have features, other than through their popularity and representation in training corpuses, help us get from natural language to efficient code? I was recently playing around with a digital audio workstation (DAW) software package called Reaper that honestly surprised me with its feature set, portability (Linux, macOS, Windows), snappiness etc. The whole download was ~12 megabytes. It felt like a total throwback to the 1990s in a good way. It feels like AI should be able to help us get back to small snappy software, and in so doing maybe "pay its own way" with respect to CPU and energy requirements. Spending compute cycles to optimize software deployed millions of times seems intuitively like a good bargain.
mikewarot 1y ago
The realization that a string could hold a gigabyte of text might have killed off null terminated strings, and saved us all a f@ckton of grief
hello_computer 1y ago
> the 1000Xers kinda ruined things for the rest of us Robert Barton (of Burroughs 5000 fame) once referred to these people as “high priests of a low cult.”
dijit 1y ago
Maybe since 1980. I recently watched a video that can be summarised quite simply as: "Computers today aren't that much faster than the computers of 20 years ago, unless you specifically code for them". https://www.youtube.com/watch?v=m7PVZixO35c https://www.youtube.com/watch?v=m7PVZixO35c It's a little bit ham-fisted, as the author was shirking decades of compile optimisations also, and it's not apples to apples as he's comparing desktop class hardware with what is essentially laptop hardware; but it's also interesting to see that a lot of the performance gains really weren't that great actually. he observes a doubling of performance in 15 years! Truth be told most people use laptops now, and truth be told 20 years ago most people used desktops, so it's not totally unfair. Maybe we've bought a lot into marketing.
nitwit005 1y ago
The cost of bounds checking, by itself, is low. The cost of using safe languages generally can be vastly higher. Garbage collected languages often consume several times as much memory. They aren't immediately freeing memory no longer being used, and generally require more allocations in the first place.

by titzer 1y ago

_aavaa_ 1y ago

Except we've squandered that 1000x not on bounds checking but on countless layers of abstractions and inefficiency.

pydry 1y ago
Most of it was exchanged for abstractions which traded runtime speed for the ability to create apps quickly and cheaply. The market mostly didn't want 50% faster code as much as it wanted an app that didn't exist before. If I look at the apps I use on a day to day basis that are dog slow and should have been optimized (e.g. slack, jira), it's not really a lack of the industry's engineering capability to speed things up that was the core problem, it is just an instance the principal-agent problem - i.e. I'm not the one buying, I don't get to choose not to use it and dog-slow is just one of many the dimensions in which they're terrible.
- fsloth 1y ago
  I don’t think abundance vs speed is the right lens. No user actually wants abundance. They use few programs and would benwfit if those programs were optimized. Established apps could be optimized to the hilt. But they seldom are.
  - pydry 1y ago
    >No user actually wants abundance. No, all users just want the few programs which they themselves need. The market is not one user, though. It's all of them.
    - skydhash 1y ago
      But each vendor only develop a few software and generally supports only three platforms -/+ one. It’s so damning when I see projects reaching out for electron, when they only support macOS and Windows. And software like Slack has no excuse for being this slow on anything other than latest gen cpu and 1gb internet connection.
      - pydry 1y ago
        slack is shit along all sorts of dimensions (not just speed and bloat) because you're not the customer.
    - bluGill 1y ago
      Users only want 5% of the features of the few programs they use. However everyone has a different list of features and a different list of programs. And so to get a market you need all the features on all the programs.
  - infogulch 1y ago
    > They use few programs Yes but it's a different 'few programs' than 99% of all other users, so we're back to square one.
- ffsm8 1y ago
  > Most of it was exchanged for abstractions which traded runtime speed for the ability to create apps quickly and cheaply. Really? Because while abstractions like that exist (i.e. a webserver frameworks, reactivity, SQL and ORMs etc), I would argue that these aren't the abstractions that cause the most maintenance and performance issues. These are usually in the domain/business application and often not something that made anything quicker to develop or anything, but instead created by a developer that just couldn't help themselves
  - tonyarkles 1y ago
    I think they’re referring to Electron. Edit: and probably writing backends in Python or Ruby or JavaScript.
    - Zak 1y ago
      The backend programming language usually isn't a significant bottleneck; running dozens of database queries in sequence is the usual bottleneck, often compounded by inefficient queries, inappropriate indexing, and the like.
      - sgarland 1y ago
        Yep. I’m a DBRE, and can confirm, it’s almost always the DB, with the explicit caveat that it’s also rarely the fault of the DB itself, but rather the fault of poor schema and query design. Queries I can sometimes rewrite, and there’s nothing more satisfying than handing a team a 99% speed-up with a couple of lines of SQL. Sometimes I can’t, and it’s both painful and frustrating to explain that the reason the dead-simple single-table SELECT is slow is because they have accumulated billions of rows that are all bloated with JSON and low-cardinality strings, and short of at a minimum table partitioning (with concomitant query rewrites to include the partition key), there is nothing anyone can do. This has happened on giant instances, where I know the entire working set they’re dealing with is in memory. Computers are fast, but there is a limit. The other way the DB gets blamed is row lock contention. That’s almost always due to someone opening a transaction (e.g. SELECT… FOR UPDATE) and then holding it needlessly while doing other stuff, but sometimes it’s due to the dev not being aware of the DB’s locking quirks, like MySQL’s use of gap locks if you don’t include a UNIQUE column as a search predicate. Read docs, people!
- pona-a 1y ago
  Did people make this exchange or did __the market__? I feel like we're assigning a lot of intention to a self-accelerating process. You add a new layer of indirection to fix that one problem on the previous layer, and repeat it ad infinitum until everyone is complaining about having too many layers of indirection, yet nobody can avoid interacting with them, so the only short-term solution is a yet another abstraction.
grumpymuppet 1y ago
This is something I've wished to eliminate too. Maybe we just cast the past 20 years as the "prototyping phase" of modern infrastructure. It would be interesting to collect a roadmap for optimizing software at scale -- where is there low hanging fruit? What are the prime "offenders"? Call it a power saving initiative and get environmentally-minded folks involved.
- sgarland 1y ago
  IMO, the prime offender is simply not understanding fundamentals. From simple things like “a network call is orders of magnitude slower than a local disk, which is orders of magnitude slower than RAM…” (and moreover, not understanding that EBS et al. are networked disks, albeit highly specialized and optimized), or doing insertions to a DB by looping over a list and writing each row individually. I have struggled against this long enough that I don’t think there is an easy fix. My current company is the first I’ve been at that is taking it seriously, and that’s only because we had a spate of SEV0s. It’s still not easy, because a. I and the other technically-minded people have to find the problems, then figure out how to explain them b. At its heart, it’s a culture war. Properly normalizing your data model is harder than chucking everything into JSON, even if the former will save you headaches months down the road. Learning how to profile code (and fix the problems) may not be exactly hard, but it’s certainly harder than just adding more pods to your deployment.
- mike_hearn 1y ago
  Use of underpowered databases and abstractions that don't eliminate round-trips is a big one. The hardware is fast but apps take seconds to load because on the backend there's a lot of round-trips to the DB and back, and the query mix is unoptimized because there are no DBAs anymore. It's the sort of thing that can be handled via better libraries, if people use them. Instead of Hibernate use a mapper like Micronaut Data. Turn on roundtrip diagnostics in your JDBC driver, look for places where they can be eliminated by using stored procedures. Have someone whose job is to look out for slow queries and optimize them, or pay for a commercial DB that can do that by itself. Also: use a database that lets you pipeline queries on a connection and receive the results asynchronously, along with server languages that make it easy to exploit that for additional latency wins.
Gigachad 1y ago
Am I taking crazy pills or are programs not nearly as slow as HN comments make them out to be? Almost everything loads instantly on my 2021 MacBook and 2020 iPhone. Every program is incredibly responsive. 5 year old mobile CPUs load modern SPA web apps with no problems. The only thing I can think of that’s slow is Autodesk Fusion starting up. Not really sure how they made that so bad but everything else seems super snappy.
- mjburgess 1y ago
  People conflat the insanity of running a network cable through every application with the poor performance of their computers.
  - sgarland 1y ago
    Correction: devs have made the mistake of turning everything into remote calls, without having any understanding as to the performance implications of doing so. Sonos’ app is a perfect example of this. The old app controlled everything locally, since the speakers set up their own wireless mesh network. This worked fantastically well. Someone at Sonos got the bright idea to completely rewrite the app such that it wasn’t even backwards-compatible with older hardware, and everything is now a remote calls. Changing volume? Phone —> Router —> WAN —> Cloud —> Router —> Speakers. Just… WHY. This failed so spectacularly that the CEO responsible stepped down / was forced out, and the new one claims that fixing the app is his top priority. We’ll see.
    - mjburgess 1y ago
      Presumably they wanted the telemetry. It's not clear that this was a dev-initiated switch. Perhaps we can blame the 'statistical monetization' policies of adtech and then AI for all this -- i'm not entirely sold on developers. What, after all, is the difference between an `/etc/hosts` set of loop'd records vs. an ISP's dns -- as far as the software goes?
      - sgarland 1y ago
bitmasher9 1y ago
The major slowdown of modern applications is network calls. Spend 50-500ms a pop for a few kilos of data. Many modern applications will spin up a half dozen blocking network calls casually.
TiredOfLife 1y ago
And text that is not a pixely or blurry mess. And Unicode.
- anthk 1y ago
  Unicode worked since Plan9. And antialiasing it's from the early 90's.
josefx 1y ago
> on countless layers of abstractions Even worse, our bottom most abstraction layers pretend that we are running on a single core system from the 80s. Even Rust got hit by that when it pulled getenv from C instead of creating a modern and safe replacement.

ngangaga 1y ago

I don't think it's that deep. We are just stuck with browsers now, for better and worse. Everything else trails.

slowmovintarget 1y ago
We're stuck with browsers now until the primary touch with the internet is assistants / agent UIs / chat consoles. That could end up being Electron (VS Code), though that would be a bit sad.
- scotty79 1y ago
  I don't think we are gonna go there. Talking is cumbersome. There's a reason, besides social anxiety that people prefer to use self-checkout and electronically order fastfood. There are easier ways to do a lot of things than with words. I'd bet on maybe ad hoc ai designed ui-s you click but have a voice search when you are confused about something.
  - deleted 1y ago
    [deleted]
  - bluGill 1y ago
    If you know what you want then not talking to a human is faster. However if you are not sure a human can figure out. I'm not sure I'd trust a voice assistant - the value in the human is an informed opinion which is hard to program, but it is easy to program a recommendation for whatever makes the most profit. Of course humans often don't have an informed opinion either, but at least sometimes they do, and they will also sometimes admit it when they don't.
    - scotty79 1y ago
      > the value in the human is an informed opinion which is hard to program I don't think I ever used a human for that. They are usually very uninformed about everything that's not their standard operational procedure or some current promotional materials.

vrighter 1y ago

Don't forget the law of large numters. 5% performance hit on one system is one thing, 5% across almost all of the current computing landscape is still a pretty huge value.

titzer 1y ago
It's about 5%. Cost of cyberattacks globally[1]: O($trillions) Cost of average data breach[2][3]: ~$4 million Cost of lost developer productivity: unknown We're really bad at measuring the secondary effects of our short-sightedness. [1] https://iotsecurityfoundation.org/time-to-fix-our-digital-foundations-a-new-report-on-memory-safety-and-secure-networking/ https://iotsecurityfoundation.org/time-to-fix-our-digital-fo... [2] https://www.internetsociety.org/resources/doc/2023/how-to-talk-to-your-manager-about-memory-safety/#8 https://www.internetsociety.org/resources/doc/2023/how-to-ta... [3] https://www.ibm.com/reports/data-breach https://www.ibm.com/reports/data-breach
- timewizard 1y ago
  > Cost of cyberattacks globally[1]: O($trillions) That's a fairly worthless metric. What you want is "Cost of cyberattacks / Revenue from attacked systems." > We're really bad at measuring the secondary effects of our short-sightedness. We're really good at it. There's an entire industry that makes this it's core competency... insurance. Which is great because it means you can rationalize risk. Which is also scary because it means you can rationalize risk.
pron 1y ago
But it's not free for the taking. The point is that we'd get more than that 5%'s worth in exchange. So sure, we'll get significant value "if software optimization was truly a priority", but we get even more value by making other things a priority. Saying "if we did X we'd get a lot in return" is similar to the fallacy of inverting logical implication. The question isn't, will doing something have significant value, but rather, to get the most value, what is the thing we should do? The answer may well be not to make optimisation a priority even if optimisation has a lot of value.

fsloth 1y ago

The problem is 1000xers are a rarity. The software desktop users have to put up with is slow.

HappMacDonald 1y ago
You can always install DOS as your daily driver and run 1980's software on any hardware from the past decade, and then tell me how that's slow. 1000x referred to the hardware capability, and that's not a rarity that is here. The trouble is how software has since wasted a majority of that performance improvement. Some of it has been quality of life improvements, leading nobody to want to use 1980s software or OS when newer versions are available. But the lion's share of the performance benefit got chucked into the bin with poor design decisions, layers of abstractions, too many resources managed by too many different teams that never communicate making any software task have to knit together a zillion incompatible APIs, etc.
- 3036e4 1y ago
  The sad thing is that even running DOS software in DOSBox (or in QEMU+FreeDOS), or Amiga software in UAE, is much faster than any native software I have run in many years on any modern systems. They also use more reasonable amounts of storage/RAM. Animations is part of it of course. A lot of old software just updates the screen immediately, like in a single frame, instead of adding frustrating artificial delays to every interaction. Disabling animations in Android (an accessibility setting) makes it feel a lot faster for instance, but it does not magically fix all apps unfortunately.
- ryao 1y ago
  > The trouble is how software has since wasted a majority of that performance improvement. It has been sacrificed in the name of developer productivity, since hardware is cheap compared to the cost of writing efficient software outside of performance critical situations. The result is that the world is drowning in inefficient software.

justincormack 1y ago

Most programming languages have array bounds checking now.

oblio 1y ago
Most programming languages are written in C, which doesn't. Fairly sure that was OP's point.
- ryao 1y ago
  Secure string handling functions like strlcpy() and strlcat() do have bounds checks. Not everyone uses them sadly.
  - oblio 1y ago
    And that again, is the point. That stuff should be built-in and almost non-negotiable. It should be a lot more work to do the unsafe thing (see: Rust).
    - ryao 1y ago
      They are negotiable in Rust too. Just use the unsafe keyword everywhere. If you want to use a language where they are non-negotiable, use JavaScript. Secure string functions are built into C these days. The older error prone ones are as well. You can ban the older functions from code bases, but it is hard to justify outright bans for all of them. If you audit string function usage in a non-trivial codebase, you likely will find instances where the old, error prone, string functions are used in safe ways and leaving them alone makes sense. This is particularly the case when constant length strings are used with constant length buffers. Here is an example where the old string functions are just as safe as the secure string functions: https://github.com/openzfs/zfs/blob/master/etc/systemd/system-generators/zfs-mount-generator.c#L449 https://github.com/openzfs/zfs/blob/master/etc/systemd/syste... I found it when I audited the string function usage in OpenZFS with the goal of removing all uses of the older string functions. While I replaced every instance old string function where the secure string functions mitigated even the slightest risk, I could not bring myself to remove these, since there was nothing wrong with them. After my patches, a few string functions were then banned from the codebase with a build system hack put in place to break the build process if someone tried to reintroduce the banned functions.

scotty79 1y ago

Since 1980 maybe. But since 2005 it increased maybe 5x and even that's generous. And that's half of the time that passed and two decades. https://youtu.be/m7PVZixO35c?si=px2QKP9-80hDV8Ui https://youtu.be/m7PVZixO35c?si=px2QKP9-80hDV8Ui

jandrese 1y ago
2005 was Pentium 4 era. For comparison: https://www.cpubenchmark.net/compare/1075vs5852/Intel-Pentium-4-3.06GHz-vs-Intel-i7-14700 https://www.cpubenchmark.net/compare/1075vs5852/Intel-Pentiu... That's about a 168x difference. That was from before Moores law started petering out. For only a 5x speed difference you need to go back to the 4th or 5th generation Intel Core processors from about 10 years ago. It is important to note that the speed figure above is computed by adding all of the cores together and that single core performance has not increased nearly as much. A lot of that difference is simply from comparing a single core processor with one that has 20 cores. Single core performance is only about 8 times faster than that ancient Pentium 4.
voidspark 1y ago
As the other guy said, top of the line CPUs today are roughly ~100x faster than 20 years ago. A single core is ~10x faster (in terms of instructions per second) and we have ~10x the number of cores.
- topaz0 1y ago
  And the memory quantity, memory speed, disk speed are also vastly higher now than 20 years ago.

ngneer 1y ago

I agree with the sentiment and analysis that most humans prefer short term gains over long term ones. One correction to your example, though. Dynamic bounds checking does not solve security. And we do not know of a way to solve security. So, the gains are not as crisp as you are making them seem.

HappMacDonald 1y ago
You don't have to "solve" security in order to improve security hygiene by a factor of X, and thus risk of negative consequences by that same factor of X.
- ngneer 1y ago
  I am not suggesting we refuse to close one window because another window is open. That would be silly. Of course we should close the window. Just pointing out that the "950X" example figure cited fails to account for the full cost (or overestimates the benefit).
bluGill 1y ago
Bounds checking solves one tiny subset of security. There are hundreds of other subsets that we know how to solve. However these days the majority of the bad attacks are social and no technology is likely to solve them - as more than 10,000 years of history of the same attack has shown. Technology makes the attacks worse because they now scale, but social attacks have been happening for longer than recorded history (well there is every reason to believe that - there is unlikely to evidence going back that far).
- titzer 1y ago
  > However these days the majority of the bad attacks are social You're going to have to cite a source for that. Bounds checking is one mechanism that addresses memory safety vulnerabilities. According to MSFT and CISA[1], nearly 70% of CVEs are due to memory safety problems. You're saying that we shouldn't solve one (very large) part of the (very large) problem because there are other parts of the problem that the solution wouldn't address? [1] https://www.cisa.gov/news-events/news/urgent-need-memory-safety-software-products https://www.cisa.gov/news-events/news/urgent-need-memory-saf...

dist-epoch 1y ago

It's more like 100,000X. Just the clockspeed increased 1000X, from 4 MHz to 4 GHz. But then you have 10x more cores, 10x more powerful instructions (AVX), 10x more execution units per core.

noobermin 1y ago

The first reply is essentially right. This isn't what happened at all, just because C is still prevalent. All the inefficiency is everything down the stack, not in C.

card_zero 1y ago

I don't trust that shady-looking narrator. 5% of what exactly? Do you mean that testing for x >= start and < end is only 5% as expensive as assigning an int to array[x]? Or would bounds checking in fact more than double the time to insert a bunch of ints separately into the array, testing where each one is being put? Or ... is there some gimmick to avoid all those individual checks, I don't know.

timbit42 1y ago
You only need to bounds check once before a for loop starts, not every iteration.
- card_zero 1y ago
  If they're all being inserted contiguously. Anyway that's a form of saying "I know by reasoning that none of these will be outside the bounds, so let's not check".
- ryao 1y ago
  It depends on the loop. Here are a bunch of loops that need bounds checks on every loop iteration: https://github.com/openzfs/zfs/commit/303678350a7253c7bee9d6a3347ee1bcdf9cc177 https://github.com/openzfs/zfs/commit/303678350a7253c7bee9d6... You could argue otherwise and you would not be wrong since the codebase had not given this code inputs that would overrun the buffer. However, any case where you loop until the string is built needs a check on each iteration unless you can both prove that the buffer will always be long enough for any possible output and guarantee that future changes will preserve this property. The former is a pain (but doable) while the latter was infeasible, which is why the bounds checks were added. That said, something as innocuous as printing a floating value could print 308 characters where you only expected 10 or less: https://github.com/openzfs/zfs/commit/f954ea26a615cecc8573bb439482d9fd88019854 https://github.com/openzfs/zfs/commit/f954ea26a615cecc8573bb... Edge cases causing things to print beyond what was expected are a good reason why people should use bounds checks when building strings, since truncation is fail safe, while overrunning the buffer is fail dangerous. I am a fan of the silent truncation done in both patches, since in both cases, truncation is harmless. For cases where silent truncation is not harmless, you can use detect the truncation by checking the return value of `snprintf()` and react accordingly. It should be said that the scnprintf() function's return value does not permit truncation detection and `snprintf()` should be used if you want that. Note that I am the author of those two patches, so it is natural that I like the approach I used. They were written as part of an audit of the OpenZFS codebase I did when bug hunting for fun.

ricardo81 1y ago

>Personally I think the 1000Xers kinda ruined things for the rest of us. Reminds me of when NodeJS came out that bridged client and server side coding. And apparently their repos can be a bit of a security nightmare nowadays- so the minimalist languages with limited codebase do have their pros.

monkeyelite 1y ago

> If dynamic array bounds checking cost 5% (narrator: it is far less than that) It doesn’t work like that. If an image processing algorithm takes 2 instructions per pixel, adding a check to every access could 3-4x the cost. This is why if you dictate bounds checking then the language becomes uncompetitive for certain tasks. The vast majority of cases it doesn’t matter at all - much less than 5%. I think safe/unsafe or general/performance scopes are a good way to handle this.

miloignis 1y ago
It's not that simple either - normally, if you're doing some loops over a large array of pixels, say, to perform some operation to them, there will only be a couple of bounds checks before the loop starts, checking the starting and ending conditions of the loops, not re-doing the bounds check for every pixel. So very rarely should it be anything like 3-4x the cost, though some complex indexing could cause it to happen, I suppose. I agree scopes are a decent way to handle it!
- monkeyelite 1y ago
  You’re describing a situation where I - or a very smart compiler can choose when to bounds check or not to make that intelligent realization.
timbit42 1y ago
Your argument is exactly why we ended up with the abominations of C and C++ instead of the safety of Pascal, Modula-2, Ada, Oberon, etc. Programmers at the time didn't realize how little impact safety features like bounds checking have. The bounds only need to be checked once for a for loop, not on each iteration.
- monkeyelite 1y ago
  > The bounds only need to be checked once for a for loop, not on each iteration. This is a theoretical argument. It depends on the compiler being able to see that’s what you’re doing and prove that there is no other mutation. > abominations of C and C++ Sounds like you don’t understand the design choices that made this languages successful.

CyberDildonics 1y ago

Clock speeds are 2000x higher than the 80s. IPC could be 80x higher when taking into account SIMD and then you have to multiply by each core. Mainstream CPUs are more like 1 to 2 million times faster than what was there in the 80s. You can get full refurbished office computers that are still in the million times faster range for a few hundred dollars. The things you are describing don't have much to do with computers being slow and feeling slow, but they are happening anyway. Scripting languages that are constantly allocating memory to any small operation and pointer chasing ever variable because the type is dynamic is part of the problem, then you have people writing extremely inefficient programs in an already terrible environment. Most programs are written now in however way the person writing them wants to work, not how someone using it wishes they were written. Most people have actually no concept of optimization or what runs faster than something else. The vast majority of programs are written by someone who gets it to work and thinks "this is how fast this program runs". The idea that the same software can run faster is a niche thought process, not even everyone on hacker news thinks about software this way.

wustus 1y ago

And this is JavaScript. And you. are. going. to. LOVE IT!

billfor 1y ago

I made a vendor run their buggy and slow software on a Sparc 20 against their strenuous complaints to just let them have an Ultra, but when they eventually did optimize their software to run efficiently (on the 20) it helped set the company up for success in the wider market. Optimization should be treated as competitive advantage, perhaps in some cases one of the most important.

MonkeyClub 1y ago
> Optimization should be treated as competitive advantage That's just so true! The right optimizations at the right moment can have a huge boost for both the product and the company. However the old tenet regarding premature optimization has been cargo-culted and expanded to encompass any optimization, and the higher-ups would rather have ICs churn out new features instead, shifting the cost of the bloat to the customer by insisting on more and bigger machines. It's good for the economy, surely, but it's bad for both the users and the eventual maintainers of the piles of crap that end up getting produced.

AtlasBarfed 1y ago

I think on year 2001 GHz CPU should be a performance benchmark that every piece of basic non-high performance software should execute acceptably on. This is kind of been a disappointment to me of AI when I've tried it. This has kind of been a disappointment to me of AI when I've tried it. Llm should be able to Port things. It should be able to rewrite things with the same interface. It should be able to translate from inefficient languages to more efficient ones. It should even be able to optimize existing code bases automatically, or at least diagnose or point out poor algorithms, cache optimization, etc. Heck I remember powerbuilder in the mid 90s running pretty well on 200 mhz CPUs. It doesn't even really interpreted stuff. It's just amazing how slow stuff is. Do rounded corners and CSS really consume that much CPU power? My limited experience was trying to take the unix sed source code and have AI port it into a jvm language, and it could do the most basic operations, but utterly failed at even the intermediate sed capabilities. And then optimize? Nope Of course there's no desire for something like that. Which really shows what the purpose of all this is. It's to kill jobs. It's not to make better software. And it means AI is going to produce a flood of bad software. Really bad software.

peatmoss 1y ago
I've pondered this myself without digging into the specifics. The phrase "sufficiently smart compiler" sticks in my head. Shower thoughts include whether there are languages that have features, other than through their popularity and representation in training corpuses, help us get from natural language to efficient code? I was recently playing around with a digital audio workstation (DAW) software package called Reaper that honestly surprised me with its feature set, portability (Linux, macOS, Windows), snappiness etc. The whole download was ~12 megabytes. It felt like a total throwback to the 1990s in a good way. It feels like AI should be able to help us get back to small snappy software, and in so doing maybe "pay its own way" with respect to CPU and energy requirements. Spending compute cycles to optimize software deployed millions of times seems intuitively like a good bargain.

mikewarot 1y ago

The realization that a string could hold a gigabyte of text might have killed off null terminated strings, and saved us all a f@ckton of grief

hello_computer 1y ago

> the 1000Xers kinda ruined things for the rest of us Robert Barton (of Burroughs 5000 fame) once referred to these people as “high priests of a low cult.”

dijit 1y ago

Maybe since 1980. I recently watched a video that can be summarised quite simply as: "Computers today aren't that much faster than the computers of 20 years ago, unless you specifically code for them". https://www.youtube.com/watch?v=m7PVZixO35c https://www.youtube.com/watch?v=m7PVZixO35c It's a little bit ham-fisted, as the author was shirking decades of compile optimisations also, and it's not apples to apples as he's comparing desktop class hardware with what is essentially laptop hardware; but it's also interesting to see that a lot of the performance gains really weren't that great actually. he observes a doubling of performance in 15 years! Truth be told most people use laptops now, and truth be told 20 years ago most people used desktops, so it's not totally unfair. Maybe we've bought a lot into marketing.

nitwit005 1y ago

The cost of bounds checking, by itself, is low. The cost of using safe languages generally can be vastly higher. Garbage collected languages often consume several times as much memory. They aren't immediately freeing memory no longer being used, and generally require more allocations in the first place.