7 ms·

How might software development have unfolded if CPU speeds were 20x slower?

118 points by EvanWard97 2y ago

I was pondering how internet latency seems to be just barely sufficient for a decent fast-paced online multiplayer gaming experience. If human cognition were say, 20x faster relative to the speed of light, we'd be limited to playing many games only with players from the same city. More significantly, single-threaded compute performance relative to human cognition would effectively be limited to the equivalent of 300 MHz (6 GHz / 20), which I suspect makes it a challenge to run even barebones versions of many modern games. This led me to wondering how software development would have progressed if CPU clock speeds were effectively 20x slower. Might the overall greater pressure for performance have kept us writing lower-level code with more bugs while shipping less features? Or could it actually be that having all the free compute to throw around has comparatively gotten us into trouble, because we've been able to just rapidly prototype and eschew more formal methods and professionalization?

throwitaway222 2y ago
A lot more chess games online instead. Probably higher IQ as the IQ lowering social media we use would barely work.
- theGeatZhopa 2y ago
  Everything is optimized for efficiency, size and speed. Like it was in the early days. With sparkles in creativity for finding a way to achieve O(n) I think the only solution to the problem is to keep the memory and disks space very low.
- EvanWard97 2y ago
  Sounds right to me. Without being able to rely on flashy visuals and low-latency so much, games would've had to be somewhat more strategic and intellectual to sell (although I imagine graphics would eventually catch up due to its fitness for parallel processing). Even if brain rotting visual spectacles were just pushed 7 years down the line, they still would probably have a more sophisticated flavor that might be cemented with time (e.g. this counterfactual TikTok might have given users much more direct control over their feed algorithm).
  - stavros 2y ago
    We had DOOM and Quake and Fallout 2 long before CPUs were 20x slower than today.
- alpaca128 2y ago
  Looking at average benchmarks, current consumer CPUs are about 20x faster than in 2007-2008 [0]. That means games like Call of Duty 4 and Crysis. Likely not much more online chess than today. And in tflops the RTX 4090 is 20x faster than the GTX 970 from just 10 years ago. But it's easy to overlook that progress if you just look at the performance of the average app. [0] https://www.cpubenchmark.net/year-on-year.html https://www.cpubenchmark.net/year-on-year.html
andsoitis 2y ago
> If human cognition were say, 20x faster relative to the speed of light What would that even mean, being 20x faster than the speed of light? What does it imply?
- joegibbs 2y ago
  'Relative to' rather than 'faster than', as in the speed of light being 20x slower or human perception and reflexes being 20x faster, or some mix of the two. If people were thinking way faster then the lag would be unbearable, and there would be no way around it.
  - deleted 2y ago
    [deleted]
ggm 2y ago
We'd still be using triple-DES to protect data, arguing that the NIST time to break it was still far out beyond. And hash functions would be like the CRC32 in TCP, not the modern stuff. CISC computers which did more in parallel per instruction would be common because they existed for concrete reasons: the settling time for things in a discrete logic system was high, you needed to try and do as much as possible inside the time. (thats a stretch argument. they were what they were, but I do think the DEC 5 operand instruction model in part reflected "god, what can we do while we're here" attitudes) -We'd probably have a lot more Cray-1 like parallelism where a high frequency clock drove simple logic to do things in parallel over matrices, so I guess thats GPU cards.
- EvanWard97 2y ago
  20x more compute isn't much in terms of cryptographic security concerns, no? Ah but triple-DES was recently depreciated. Definitely sounds right that we'd get an earlier, heavier emphasis on parallelism and hardware acceleration. I'm guessing the slower speed of causality also applies to propagation delay and memory latencies, so there wouldn't be new motivation for particular architectural decisions beyond "God please make this fast enough for our real-time control systems or human interaction needs". If we got deep learning years or decades earlier, that also seems scary for AI existential risk, as we are just barely starting to figure out how the big inscrutable matrices work, and that's with the benefit of more time people have had to sound the alarm bells and attract talent and funding for AI interpretability research.
- tgma 2y ago
  Fun fact: 3DES is slower than modern standards, namely AES.
- deleted 2y ago
  [deleted]
farseer 2y ago
More C/C++ based business apps that run locally. Cloud would be less relevant. No large browser engines, which means a lot less JS and of-course no Electron :)
- EvanWard97 2y ago
  Good points. Somehow typing latency might actually be better, lol. V8 might just invent like 3 more execution engines though, 1 of which uses an external TPU (open source though!) to run code JITed to HVM (Higher Order Virtual Machine) that everyone is eventually compelled to adopt, one can't be too sure JS will lose. /s
- sloowm 2y ago
  There would be way more language and tool development around more efficient languages because more people would be required to use them. So C and C++ would probably be in a totally different state. There would be a huge amount of hate for people who use some C++ derivative with a framework on top of it using some program that allowed it to easily run on multiple systems.
deleted 2y ago
[deleted]
mkl95 2y ago
AAA games would still look like Quake. The web would be much more static.
bruce511 2y ago
One way to answer this question is to look at the software produced when clock speeds were 20x slower. The limitations, and features we had then are a minimum starting point. So I'm thinking around the era of a 486 100mhz machine. We'd have at least that (think mylti-player Doom and Quake era as a starting point.) We had Windows, preemptive multi threading, networks, internet, large hard drives, pretty much the base bones of today. Of course cpu-intensive things would be constrained. Voice recognition. CGI. But we'd have a lot more cores, and likely more multi-thread approaches to programming in general.
- deleted 2y ago
  [deleted]
- Retric 2y ago
  Even modern cellphone chips a far more than 20x the speed of a 100Mhz 486 outside of extremely pathological workloads. At minimum we’re still talking 64 Bit chips. However, IMO simply thinking in terms of actual chips that existed isn’t that interesting. What would computing look like if the PIII was a 12 CPU at 500 MHz. That’s a little closer to 5% of modern chips and something nobody worked with. Alternatively what the 486 era would have looked like with gigabytes of RAM and an SSD?
  - mywittyname 2y ago
    I can't buy into the idea of 486s but also SSDs. Why doesn't the speed limitation of CPUs extend to controllers, busses, SoC, transistor sizes, etc? If the 2GHZ CPU is now 10Mhz, then presumably the memory bus is no longer 100Mhz, but 5Mhz.
    - Retric 2y ago
      I think the basic assumption is some kind of change to the laws of physics and thus transistor frequency scaling otherwise it’s effectively just asking what it was like in the past. So dropping 6GHz 64 bit chips to 300 MHz doesn’t imply everything else is the same and where just using 32bit PII era hardware. Similarly rather than NVMe 2TB SSD’s at 6000 MB/s we could have 2TB SSD’s at 300 MB/s. Which then opens the door for even more extreme differences. If the “PIII was a 12 ^core^ CPU at 500 MHz” that’s quote odd by historic standards.
moshegramovsky 2y ago
I write C++ for high-performance Windows desktop applications that are used on a wide variety of form factors. This means that I still optimize a lot of things, such as what happens when a user edits a property in an edit box. How can that edit be minimized? How do I make sure that commands operate in less than a second? How can we hide latency when a long execution time can't be avoided? 99% of the time, optimizations are about doing less, not doing something faster or with lower-level code. You'll never write faster code than code that doesn't run. I think the GPU would do a lot more work in most applications than it does today. If a process needs to be super fast, when applicable, I write a compute shader. I've written ridiculous compute shaders that do ridiculous things. They are stupidly fast. One time I reduced something from a 15 minute execution time to running hundreds of times per second. And I didn't even do that good of a job with the shader code.
- iKlsR 2y ago
  Tangential but funny story from some years ago, did the same on a virtual reality app (Qt, Oculus SDK) so talking multi-threaded renderer, tons of background activity, even spawned a mini helper server to process tasks and such and did custom hacking (registry, window flags) to override windows features to make the app snappy. Distinctly remember spending weeks on startup time to get the app to consistently drop the user into a session between 250 - 500ms even from cold launch which involved something like a mini page file to capture state and other things only for my boss at the time to come and say the app was "too fast", users couldn't see the splash screen so we added a random(1.f, 3.f) second sleep...
  - moshegramovsky 2y ago
    LOL, you just can't make all the people happy all of the time, right? I have done similar things with timers, for the same reasons.
- w4rh4wk5 2y ago
  Do you happen to have any pointers or recommendations regarding C++ for desktop applications? Especially towards state-management and user-interaction? I am primarily doing game development and HPC; I am decently familiar with C++, but desktop UI has been a pain point for me so far. Most GUI tools I write in C++ are using ImGui, or they are written in C#.
eterm 2y ago
I'm not sure I understand the premise, because CPU speeds were 20x slower. Just go back a decade or two. They weren't some halcyon days of bug-free software back then, quite the opposite.
- stavros 2y ago
  Software wasn't bug-free, but it was responsive.
  - eterm 2y ago
    Not all of it was, some of it was very laggy and slow. Indeed the whole OS would frequently freeze up.
    - stavros 2y ago
      Sure, but nowadays all of it is laggy and slow. I cringe every time I'm faster than Slack, a text chat program.
      - vendiddy 2y ago
        Yep exactly. If we're talking about a cutting-edge app, I get the sluggishness. But IRC used to respond instantly. Feels like apps are doing roughly the same thing but more slowly despite having computers that are orders of magnitude faster.
    - Ratiofarmings 2y ago
      Be careful not to mix slow CPUs with not having SSDs. A OS freezing up is almost always because something is broken or because it's waiting for a HDD to spin up.
  - amelius 2y ago
    Windows 3.1 was based on async programming, and wasn't responsive every now and then.
koliber 2y ago
No electron apps.
Am4TIfIsER0ppos 2y ago
I'd probably be out of a job because we wouldn't be doing this crap in software. You wouldn't have people wasting cpu cycles on pointless animation. You'd have people thinking about how long it takes to follow a pointer. You'd have people seriously thinking about whether the Specter and Meltdown and subsequent bugs really need to be worked around when it costs you 50% of the meager performance you still have. I might ask if everything else is 20x times slower too. GPU speeds, memory bandwidth, network bandwidth.
JaumeGreen 2y ago
> Might the overall greater pressure for performance have kept us writing lower-level code with more bugs while shipping less features? Are you living in the same world as the rest of us? Nowadays programs are shipped with plenty of bugs, mostly because patching them afterwards is "cheap". In the old days that wasn't as cheap. So having lower powered computers would have made us write programs with less features, but also less bugs. Formal coding would be up, and instead of moving fast and break things most serious business would be writing coq or idris tests for their programs. Bootcamps also wouldn't be a thing, unless they were at least a couple of years long. We'd need people knowing about complexity, big O, defensive programming, and plenty of other things. And plenty of things we take for granted would be far away. Starting with LLMs and maybe even most forms of autocomplete and automatic tooling.
- iKlsR 2y ago
  1. Get it working 2. Get it right 3. Make it fast ... pretty Weird observation and from personal exp a good percentage of development stops at 1 with periodic blips to 3 when issues popup (of course with an eventual rewrite coming when new people come onboard) as a consequence of not focusing on 2 due to how we build today.
r0ckarong 2y ago
HN answer: To stick with your analogy: There would be more optimization and the rate of releasing stuff would be slower because it would have to be tested. That's it. Remember catrdige based console games? How many patches or day one updated did you have to install there? How many times would they crash or soft-lock themselves? People tested more and optimized more because there were constraints. Today we have plenty of resources and thus you can be wasteful. Managers trade speed over waste. If you can make it work unoptimized, ship a 150 GB installer and 80 GB day1 patch do it NOW. Money today, not when you're done making it "better" for the user. Sci-Fi answer: We wouldn't be playing the same type of games. Why would we have to rely on something like our representation of graphics? If the cognition would be 20x faster and more powerful we probably wouldn't need abstractions but would have found a way to dump data into the cognition stream more directly. I think the idea that 20x faster cognition would just mean "could watch a movie at 480fps" is too limited. More like you could play 24 movies per second and still understand what's going on.
- sloowm 2y ago
  For the Sci-Fi answer our language would be optimized for extremely fast communication, maybe making sounds from our mouths alone would be way to inefficient. We probably would have easily made stuff that caught up with our cognition. The current hardware and software is more a representation of human limits than other limits. I think the frame of wasteful is not correct. It's wasteful not to use resources if other resources are restricted and can be substituted by the plentiful. Of course the allocation of current resources can be debated but that is not caused by extra CPU performance, storage and RAM that is available.
deleted 2y ago
[deleted]
mnw21cam 2y ago
One thing to consider is that the resolution and colour space of your computer's display also depends on available clock speed, so if you reduce that by a factor of 20, you'll also have to reduce the number of pixels in your display by the same factor. So, we'll have worse displays as well as worse compute. As with all else - just look back to computers about 20 years ago, and that'll give you a good idea of what it'd be like. I guess the main difference is that we might have still been able to miniaturise the transistors in a chip as well as we do now, so you'd still have multi-core computers, which they didn't really do very often 20 years ago.
- throwup238 2y ago
  Don’t ICs have faster internal PLLs than the advertised clock speed? As long as those signals don’t need to move too far. They could probably figure out a less efficient parallel bus with lots more leads rather than the pixel, line, and frame sync we have now, at least once we moved on from CRTs (I don’t know how those work wrt phosphors). It’d change the cost tradeoffs and mean more chips nearer the display but not really put us back, as long as other components kept up. I.e. pcie line rate is developing much faster than display size/framerate/bandwidth so limiting factor is the panel development and connection standards.
amelius 2y ago
We wouldn't have AI.
red_admiral 2y ago
I feel like every time CPU speeds double, someone comes up with a Web UI framework that has twice as much indirection. With 20x slower compute, we might not have UIs that fire off an event and maybe trigger an asynchronous network request every time you type a character in a box, for example. Windows 95 could do a decently responsive desktop UI on an 80386. Coding was a lot less elegant in one way - C code that returns a HWND and all that - but with the number of levels of indirection and abstraction these days, we've made some things easier at the cost of making other things more obfuscated.
- josephg 2y ago
  I saw a talk about tigerbeetle the other day - which is a small, fast database for handling financial transactions that apparenty runs orders of magnitude faster than Postgres. The database binary has no dependencies and compiles to 500kb. Its authors were joking they could distribute it on floppy disks if they wanted. It’s written in Zig, not C. But that style of programming is still available to us if we want it. Even in more modern languages. Honestly I’m really tempted to try to throw together a 90s style fantasy desktop environment and widget library and make some apps for it. There’s something about that era of computing that feels great.
  - red_admiral 2y ago
    Back when Java had just introduced Swing to supplement/complement AWT, I remember you had a set of components (that you could even style in different ways with themes), a fairly object-oriented approach, and with the open-source MiG layout manager (that still exists today) a powerful way of laying out forms with constraints to adapt to changing screen/window/font sizes. I feel like UI framework progress from Windows 3.1 to Swing+MiG was much greater than anything I've seen since.
    - josephg 2y ago
      I feel that way about the old Interface Builder for macos, back in the Xcode 3.x days. VB6 was pretty good too.
Taniwha 2y ago
Only 20x? I started my career programming on a mainframe system with a 1MHz memory cycle time (think of this as it's 'clock speed') - it had 3 megabytes of memory and supported 40 timeshare users (on terminals) and batch streams. At one point we upgraded by adding 1.5Mb, it cost $1.25M Compared to a modern CPU it was maybe 5000x slower, the early Vax systems that Unix ran on were maybe 6 times faster. People certainly wrote smaller programs, we'd just stopped using cards and carrying more than a box around (1000) was a chore. You spent more time thinking about bugs (compiling was a lot slower, and they went in a queue, you were sharing the machine with others). But we still got our work done, more thinking and waiting
Ratiofarmings 2y ago
We're definitely prioritizing features and just more applications and use cases over optimization. If CPUs were 20x slower, we'd probably see quite a few of the things that are possible right now. But with a lot more well optimized custom solutions rather than bloated frameworks. And in some cases, multi-threading would be the only way to do things. Where right now, single-threaded file copy, decompression or draw-calls are largely a thing because it's way easier to do and there is no need to change it outside professional applications. Also, some things might actually be better than they are right now. Having to wait for pointless animations to finish before a UI element becomes usable should not be a thing. If there was no CPU performance for this kind of nonsense, they wouldn't be there. Please don't mix clockspeeds with performance. A Athlon™ 5350 from 2014 is >20x slower single threaded than a Core i9-14900K. Yet it's 2 GHz vs. 5.8 GHz. Architecture, Cache and Memory Speed matter A LOT.
crubier 2y ago
Everything would be exactly the same, except 8.64years later. Moore's law show that CPU speeds double every 2years. 2years * log2(20) = 8.64years, so we'd just be 8.64years late, that's it, literally no reason for anything to be any different apart from that. 95% of comments seem to completely overlook this fact and go into deep explanations about how everything would be different. It's pretty surprising that even a pretty sciencey community like Hacker News still doesn't get exponentials.
- fifteen1506 2y ago
  Still think mine is even more general :) Obligatory XKCD: https://xkcd.com/435/ https://xkcd.com/435/ My comment: https://news.ycombinator.com/item?id=39977838 https://news.ycombinator.com/item?id=39977838
- planb 2y ago
  Moore's Law actually refers to the density of transistors on a chip doubling approximately every two years, not CPU speed. Yes, CPUs still get exponentially faster, but this affects multi core throughput, single thread performance improves way slower. For human perception and interactivity, this makes a huge difference. So it stands to reason if algorithms would have been parallelized earlier and better, but I doubt that the timeline would just be shifted a few years.
- The_Colonel 2y ago
  Arrogant and factually incorrect, a dangerous combination. But apparently you also didn't get the question - hardware would stay slow, but software would continue evolving, the question is how, given the hardware constraints. It would definitely not be "exactly the same, except 8.64years later".
  - wetpaws 2y ago
    [dead]
tuyiown 2y ago
Since people brought the "a few decade earlier was like that" response: Old software on older hardware was «responsive» because library they used came with much less built-in capabilities (nice ui relayout, nice font rendering, internationalization, ui scaling), and also, less code means less memory, and rotating disk swap meant huge slow downs when hit, so being memory hungry was just not an option. People that remember fast software was just people that could afford renewing their computer a year or so in the 20% top bracket prices, and don't realize that today mere inconvenient slugginess in 6-7 years computer was just impossible to imagine back then. For the «let's imagine current day from that past», I would say we would be mostly in the same place, without AI, with much less abondance of custom software, and more investments in using and building properly designed software stack. Eg, we would have proper few UI libraries atop of web/dom and not the utter mess of today, and much more native apps. Android might not have prevailed has it has, it relied a lot on cheap CPU improvements for its success. Still safe language like rust would have emerged, but the roadblock in fixing compiler performance would have slowed down things a bit, but interest would have emerge even faster and stronger.
rullopat 2y ago
We wouldn't have software that does the same things, at the same speed, but with 10000x faster hardware
fifteen1506 2y ago
Not to be a jerk but it's a question of allocation of resources, which is basically what capitalism does. It was used because it existed. If there is a prolonged economic slowdown (not crash, please!), then resources will be allocated to optimizing CPU cycles and all that hype-based developments will have less resources allocated to them. It can be for some of us an imperative to fight for efficiency but we shouldn't do it in a way which is in a all or nothing approach. Know its advantages and disadvantages and work within that knowledge-framework.
RetroTechie 2y ago
Problem is one of mentality, imho. See eg. the countless HN posts "hey look! I've used X to do Y" showing off some cool concept. The proper thing would be to take it as that: a concept. Play with it, mod it, test varieties. Like it? Then take the essential functionality, and implement in resource-efficient manner using appropriate programming language(s). And take a looong, hard look at "is this necessary?" before forcing it onto everyone's PCs/mobile devices. But what happens in practice? Proof-of-concept gets modded, extended, integrated as-is into other projects, resource frugality be damned. GHz cpus & gobs of RAM crunch trough it anyway, right? And before you know it, Y built on top of X is a staple building brick that 1001 other projects sit on top of. Rinse & repeat. A factor 20 is 'nothing'. And certainly not the issue here. Just look what was already possible (and done!) when 300 MHz cpus were state-of-the-art. Wirth's law very much applies.
mamcx 2y ago
I think more than the speed itself, it is how fast we get there. If instead of getting major hardware wins each year it will be a decade things will be much better because now there is pressure to make it so.
sydbarrett74 2y ago
One thing that slows down our machines is all the trackers that run in the background as we browse the web. Surveillance capitalism FTW! /s
divbzero 2y ago
That’s not a hypothetical, is it? Given Moore’s Law, just look back a decade or so and you’ll get a sense of what software development was like when CPU speeds were 20x slower. And if you take it even further, looking back six decades or so, you’ll see things like the Story of Mel that would never happen in software development today.
j45 2y ago
Maybe software would have been more efficient to do the same, and software developers would still begin with an understanding of hardware and what's happening at a lower level (Assembly) before sending it instructions in an interpreted language. The sharding of the developer has made things more inefficient in some ways.
ChrisArchitect 2y ago
Ask HN:
egberts1 2y ago
One word: DELIBERATELY.
oliwarner 2y ago
> internet latency seems to be just barely sufficient What? I played Quake 1-3, TFC over 56k with 300ms latency, on a CPU at least 20x slower than modern CPUs. Tribes 2 with 63 other players. Arguably more fun than the prescriptive matchmaking in games these days. Games are a product of their environment. You don't let a pesky think like lag stop people having fun.
mikewarot 2y ago
I think there are plenty of ways to make far better use of the hardware we currently enjoy. If you don't focus on web based stuff, but go with just what's possible in a Win32 environment, for example... it was all there in the late 1990s, VB6, Delphi, Excel, etc. We've had quite a ride from 8 bit machines with toggle switches and not even a boot rom, nor floating point, to systems that can do 50 trillion 32 bit floating point operations per second, for the same price[1]. Remember that Lisp, a high level language, was invented in 1960, and ran on machines even slower than the first Altair. The end of "free money" is over, as is the era of ever more compute. It's time to make better use of the silicon, to get one last slice of the pie. [1] The Altair was $500 assembled in 1975, which is $2900 today. I'm not sure how best to invest $2900 to get the most compute today. My best guess is an NVidia RTX 4080.
AirMax98 2y ago
Look no further than developers on Ethereum, who are still doing shit like voluntarily writing assembly for basic software to account for compute constraints. I can say from some brief experience, it’s a reality that I’m glad we don’t all occupy.
mbfg 2y ago
Didn't we have just that?, i'm sure there are tons of history that can fill in any gaps you may have in what it was like.
TrevorFSmith 2y ago
At any time there are platforms with 20x more or less speed or space than the average, from tiny embedded processors through PCs and on up to clusters and mainframes. So, to see how a 20x slower computing platform could be you can look at small and power limited device development.
pjmlp 2y ago
Easy, we would enjoy the software practices that were common with compiled languages until the mid-2010's, when people started using scripting languages for application development instead of OS scripting activities, with Zope, Django, Rails and friends, ending up in mostrosities like Electron, despite Active Desktop and XUL failure.
lulznews 2y ago
Same as now. Driven by incompetent management.
PeterZaitsev 2y ago
This would be modern version of Steampunk :)
fungiblecog 2y ago
I think a better question would be “how fast would our software be if it was programmed by people who didn’t waste all that cpu power on frameworks, terrible algorithms, and layer after layer after layer of cruft”

mjfisher 2y ago

> One time I reduced something from a 15 minute execution time to running hundreds of times per second That's too good a story not to have just a little more detail. Are you willing to share more?

moshegramovsky 2y ago
Sure. It was a fairly complicated image processing algorithm, but not necessarily something that you would want to go through a lot of trouble to implement on the GPU. At least not until you're desperate. And I should add, the results are pretty boring. It doesn't even generate anything interesting. I read the paper that described the algorithm and implemented code on the CPU, thinking, quite stupidly, that it would be fast enough. Not fast, but fast enough. Nope. Performance was utterly horrible on my tiny 128x128 pixel test case. The hoped-for use cases, data sets of 4096x4096 or 10000x10000 were hopeless. Performance was bad for a few key reasons: the original data was floating point, and it went through several complicated transformations before being quantized to RGBA. The transforms meant that the loops were like two lines total, with an ~800 line inner loop, plus quantization of course (which could not be done until you had the final results). In GLSL there are functions to do all the transformations, and most of them are hyper-optimized, or even have dedicated silicon in many cases. FMA, for example. So I wrote some infra to make it possible to use a compute shader to do it. And I use the term 'infra' quite loosely. I configured our application to link to OpenGL and then added support for compute shaders. After a few days of pure hell, I was able to upload a texture, modify the memory with a compute shader, and then download the result. The whole notion of configuring workgroups and local groups was like having my pants set on fire. Especially for someone who had never worked on a GPU before. But OpenGL, it's just a simple C API, right? What could go wrong? There's all these helpful enumerations so the functions will be easy to call. And pixel formats, I know what those are. Color formats? Oh this won't be hard. But once everything was working, it only took a few more days to make the compute shader work. The hardest part was reconfiguring my brain to stop thinking about the algorithm in terms of traversing the image in a double nested for loop - which is what you would do on the CPU. Actually, the first time I wrote it, that's what I did, in the shader. Yes, I actually did that. And it wasn't fast all. Oh man, it felt like I was fucked. But in the end, it could process the 4096x4096 use case at 75 FPS, and even better, when I learned about array textures, I found that it could do even more work in parallel. That's how I got it from 15 minutes to hundreds of frames per second.

holsta 2y ago

if [ "$os" = "Darwin" ]; then arch="universal" os="macos" elif [ "$os" = "Linux" ]; then os="linux" else echo "Unsupported OS." exit 1 fi This is nothing to emulate.

josephg 2y ago
Why not? Does everything really need to be built in a cross platform way? I feel like that’s how we got into this mess.
- holsta 2y ago
  Yes, bugs are often found by running the same code on similar but not identical platforms. We've had this conversation multiple times. https://news.ycombinator.com/item?id=28978086 https://news.ycombinator.com/item?id=28978086 What mess are we in because of POSIX?
  - josephg 2y ago
    I’m talking about the mess of electron and friends. I’ve spoken to engineers who work on it. From their point of view, it’s the only sane way to build software that works across multiple operating systems. The nice thing about windows and macOS back in the day was that the programs we ran were all written with the same native UI toolkit. All the controls matched between applications. Applications were small and efficient - binary sizes and memory usage were in the megabyte range. Any program written like that today starts up instantly, and is incredibly responsive. But last I checked, Hello world in electron is ginormous. It uses about 100mb of memory. It takes time to start up. Vscode and Spotify are great but they don’t look or feel native. It is legitimately great that people now ship apps for Linux. But we’ve lost platform cohesion in the trade. So, so what if tigerbeetle is written for Linux? I’m ok with the developers choosing not to pay the cross platform tax.
arp242 2y ago
That's just the codepath from bootstrap.sh that downloads the binaries. I don't know if it will compile and run on, say, FreeBSD. It's quite possible no one tried.
- holsta 2y ago
  I did, but there are literal compile-time checks for various platforms. pub fn monotonic(self: *Self) u64 { const m = blk: { if (is_windows) break :blk monotonic_windows(); if (is_darwin) break :blk monotonic_darwin(); if (is_linux) break :blk monotonic_linux(); @compileError("unsupported OS"); };
  - arp242 2y ago
    That genuinely seems platform-specific. Should be easy enough to write a patch to add support for $other_system.
    - josephg 2y ago
      According to the talk I watched, tigerbeetle makes heavy use of io_uring on linux - which isn't part of POSIX. Adding freebsd support should be pretty easy. If it supports darwin, it'll probably already have an implementation built on top of freebsd's kqueue. Its probably just a case of wiring it up to use kqueue when built for freebsd.
      - arp242 2y ago
        Yes, that was my impression as well when I looked at it yesterday. The monotonic_linux() bit that's quoted is platform-specific because it uses CLOCK_BOOTTIME with clock_gettime(), but that seems supported on BSD systems as well. It's probably just that no one tried to run it, and no one spent any effort on it. I can't find a single mention of "BSD" in the issue tracker.
        josephg 2y ago
        > I can't find a single mention of "BSD" in the issue tracker. Sounds like this is something you can help with. If you care, open an issue.

laserbeam 2y ago

Keep in mind, the thing that matters most for tigerbeetle’s speed is they are domain specific. They know exactly upfront how data looks like. They don’t have to be general purpose. The style of programming does work for general purpose computing, but their requirements enable a significant % of “orders of magnitude faster than postgress”.

vendiddy 2y ago
While your take makes sense, I feel like even general purpose programming frameworks should be orders of magnitude faster for what they are doing.
- josephg 2y ago
  Yeah; and we have plenty of other general purpose databases which can run laps around postgres and sqlite. There's plenty of optimisations postgres and friends leave on the table. Like, the postgres client driver could precompile queries and do query planning on behalf of the database. It would introduce some complexity, because the database would need to send information about the schema and layout at startup (and any time it changed). But that would remove a lot of unnecessary, repeated makework from the database process itself. Application servers are much easier to scale than database servers. And application servers could much more easily cache the query plan. Weirdly, I think part of the problem is economic. I think there's a lot of very smart people around with the skills to dramatically improve the performance of databases like postgresql. Across the whole economy, it would be way cheaper to pay them to optimize the code than needing companies everywhere to rent and run additional database servers. But it might not be worth it for any individual company to fund the work themselves. Without coordination (ie, opensource funding), there's not enough money to hire performance engineers, and the work just doesn't happen.
  - gregw2 2y ago
    Would odbc/jdbc protocols have to change to support client-planned queries?
- laserbeam 2y ago
  Definitely! It's just your benefits aren't going to be "all" the orders of magnitude speedups, just some of them. And I agree, that's nothing to shy away from.

tetris11 2y ago

I do wonder about this often. Are these new UI frameworks iterating upwards towards some unknown featureset archetype, where if given another 10-20 years, the designers will say "Okay, we've reached diminishing feature returns, let's pack it up and optimize" Or, are we simply re-inventing the wheel each time, where the set of features over the last few decades really haven't change that much or cycles through featureset phases.

iforgotpassword 2y ago

VB6 had intellisense. sure it was much less powerful than today's, but you had a project with a dozen classes, and when you typed the name of an instance variable and then hit ".", it would immediately show you a list of accessible members of the according class and update the preselected member as you started typing. This was absolutely immediate, on a 133mhz machine with 32mb RAM. Even on 66mhz it was still usable. I remember switching to VB.NET on a 600mhz machine and the IDE was a sluggish piece of garbage.

ansgri 2y ago
Every IDE is a sluggish piece of garbage after Delphi 7.
- signaru 2y ago
  I'm curious if you've used Lazarus and what you think about it. I have not used enough similar IDEs to compare it (or maybe just forgotten how it was) and didn't have access to Borland tools back in the day. One crazy thing I remember about Lazarus is how it can compile the IDE quite fast (given its codebase size) when installing plug-ins.
  - ansgri 2y ago
    Unfortunately no, had no use case for it in an industry dominated by Python and C++. Wouldn't be surprised if Lazarus is very fast and pleasant to use, and I think the problem with more popular IDEs lies in underlying technology: C++ is traditionally very slow to compile and analyze, and many popular languages are too dynamic for reliable autocompletion to be feasible. When I briefly worked with C# and Java in 2000s the IDEs were very much fully functional (compared to C++ at the time), but sluggish enough to be unpleasant without a powerful PC which I did not have — and Delphi ran fast on cheap hardware.
ndiddy 2y ago
I'm used to newer computers, so Visual Studio 2008 was my favorite Visual Studio. With VS 2010 and later, Microsoft decided to scrap the existing Win32 based UI and rewrite it in WPF, which made it take 20 seconds to start instead of less than a second. Even after it's started, it's far less responsive than 2008. If only Microsoft offered a "Visual Studio 2008 but with modern standards support" product...

rubymamis 2y ago
I believe you have proved my point that you're speaking of very niche examples. Even Sublime Text won't load a 100GB instantly on a normal machine. And I consider it a very well-made app. While of course there might be apps that will load such files instantly, they are highly optimized for such a task. My point is that Qt is more than enough to replace all those Electron, and other web-based apps, while performing as good or even better than native apps. At the end of the day, Qt can also be just a wrapper for your highly optimized engine - for example, NotepadNext[1] is using the very performant Scintilla engine while its UI is written in Qt. From my (unscientific) tests, it's even vastly faster than Sublime Text. BTW, I'm not saying that rendering and creating your own UI is always a bad idea. Many people do it because it's fun and challenging, or to push the boundaries. That's what Vjekoslav Krajačić is doing with Disk Voyager - writing a file explorer in C from scratch[2][3]. But for many people, that's too much. I believe Qt C++ with QML is the best combo for most people, for most applications. [1] https://github.com/dail8859/NotepadNext https://github.com/dail8859/NotepadNext [2] https://diskvoyager.com/ https://diskvoyager.com/ [3]https://www.reddit.com/r/SideProject/comments/103b9fy/disk_voyager_im_writting_native_file_explorer/ https://www.reddit.com/r/SideProject/comments/103b9fy/disk_v...
- fizzynut 2y ago
  If everything you do stays in the rails of QT you're going to be fine. But you try to do something simple like load a 2GB file and everything starts to fall to pieces, then you're going to assume the people that wrote this are super clever and that a 2GB file is too complicated, too niche, too hard of a problem, it needs to be "highly optimised", etc. The reality is QT/whatever program/framework is doing 100 things you don't care about when loading/rendering a file. If we only care about 1 thing we can do that much better because we don't care about the 100 other things our naïve code we wrote in 5 minutes outperforms the standard element by a factor of 1,000.