5 ms·

Makes you wonder... How fast would everything be if it was written in assembly. In audio dev it's very common for dsp code to be written in assembly.

by pier25 3y ago

geek_at 3y ago
Or if everything had been written by "ais523 - high effort answers"
xxs 3y ago
You dont need Assembly, you need to the code not to be terrible, which is generally hard with the amount of code/developers needed.
dumdumchan 3y ago
It wouldn't run at all since it wouldn't exist.
nickelpro 3y ago
Assembly is hardly the reason this is fast. It is necessary to this solution but by no means sufficient. Extreme algorithmic research combined with a high LOK of Linux syscalls and platform specific optimizations is what allows this to exist. To quote the author, Alex Smith, himself: > @chx: I already have a master's thesis. This was harder. This is in a different universe than what can be produced by simply "do it in assembly".
- wheelerof4te 3y ago
  "Extreme algorithmic research combined with a high LOK of Linux syscalls and platform specific optimizations is what allows this to exist." No, author's extreme boredom and/or free time allowed this to exist. Nothing else.
- moreati 3y ago
  What's LOK in this context? Search and Wikipedia didn't throw up anything. Thanks.
  - bonzini 3y ago
    Level of knowledge, I think.
    - nickelpro 3y ago
      Correct. It's one of those extremely-common-in-the-US-military-almost-no-usage-outside-it type things apparently, like behoove or tack (hyphen) or diggit (multi-tool), which I'll keep in mind in the future.
- bonzini 3y ago
  The second ranked solution (by me :)) shows that a more or less trivial assembly tight loop can get about 70% of the speed. The remaining 30% is... something else.
kryptiskt 3y ago
It would end up like Steve Yegge's tale of Geoworks: "OK: I went to the University of Washington and [then] I got hired by this company called Geoworks, doing assembly-language programming, and I did it for five years. To us, the Geoworkers, we wrote a whole operating system, the libraries, drivers, apps, you know: a desktop operating system in assembly. 8086 assembly! It wasn't even good assembly! We had four registers! [Plus the] si [register] if you counted, you know, if you counted 386, right? It was horrible. I mean, actually we kind of liked it. It was Object-Oriented Assembly. It's amazing what you can talk yourself into liking, which is the real irony of all this. And to us, C++ was the ultimate in Roman decadence. I mean, it was equivalent to going and vomiting so you could eat more. They had IF! We had jump CX zero! Right? They had "Objects". Well we did too, but I mean they had syntax for it, right? I mean it was all just such weeniness. And we knew that we could outperform any compiler out there because at the time, we could! So what happened? Well, they went bankrupt. Why? Now I'm probably disagreeing – I know for a fact that I'm disagreeing with every Geoworker out there. I'm the only one that holds this belief. But it's because we wrote fifteen million lines of 8086 assembly language. We had really good tools, world class tools: trust me, you need 'em. But at some point, man... The problem is, picture an ant walking across your garage floor, trying to make a straight line of it. It ain't gonna make a straight line. And you know this because you have perspective. You can see the ant walking around, going hee hee hee, look at him locally optimize for that rock, and now he's going off this way, right? This is what we were, when we were writing this giant assembly-language system. Because what happened was, Microsoft eventually released a platform for mobile devices that was much faster than ours. OK? And I started going in with my debugger, going, what? What is up with this? This rendering is just really slow, it's like sluggish, you know. And I went in and found out that some title bar was getting rendered 140 times every time you refreshed the screen. It wasn't just the title bar. Everything was getting called multiple times. Because we couldn't see how the system worked anymore! Small systems are not only easier to optimize, they're possible to optimize. And I mean globally optimize." http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html http://steve-yegge.blogspot.com/2008/05/dynamic-languages-st...
- sillysaurusx 3y ago
  Interestingly, AI might change this. Not that it would be a good idea to write everything in assembly, but at least it would be possible now. Some wonderful systems were written in assembly. Donkey Kong comes to mind.
tragomaskhalos 3y ago
I started in software dev in 1988; the only languages I knew were BASIC and Z80 assembly so, since everyone knew BASIC was kind of lame I naturally assumed I'd be a machine code programmer, albeit on slightly more exotic processors. Day one got handed a book on C -> mind blown.
jojobas 3y ago
It depends. You can write bubblesort in assembly and it will be pretty damn slow. I can imagine those assembly leaders could push out pretty fast C implementations as well.
MagicMoonlight 3y ago
Even if everything was just written in java we’d be better off than the current system of embedding chrome into a python instance and then running a webserver in javascript to render a document.
- pkolaczk 3y ago
  I don't think replacing one bad idea with another bad idea is a good idea ;) I'm also not sure if Java would be less bad in that case. At least JS has years of research that went into making it start fast, not only run fast after warmup.
  - selimco 3y ago
    Modern Java has Coordinated Restore at Checkpoint (CRaC) as well as ways to compile it to native binaries that can start very fast (GraalVM & Substrate VM). The former has the benefit of a JIT as well!
    - therealdrag0 3y ago
      Have you used any of these? I’m looking for ways to speed up start time of JVM, but almost options I’ve seen so far are “experimental” and not sure best route to take. For example was sad to see ahead of time compile being removed from JDK.
  - pulse7 3y ago
    Is this "years of research" the reason why most Electron apps still start slower than - for example - IntelliJ IDEA, which is written in Java and Swing?
  - dahfizz 3y ago
    Just imagine if those years of research went into a good language instead. Instead of expending a huge amount of effort making an inherently slow language perform reasonably, we could have taken a reasonable language like Rust and made it so good it would legitimately push computing forward. And then all you web devs could still compile rust to wasm. wasm is already faster than JS anyway. JS was a mistake.
actionfromafar 3y ago
I think an oft overlooked detail of more primitive languages yielding faster programs, is this: when it’s painful to progress even a little bit while coding, you try very hard to implement as little as possible resource constraint can give clarity of focus
- zokier 3y ago
  Shortest/smallest code is rarely the fastest. Loop unrolling and inlining make code larger, and occasionally faster as an trivial example
  - actionfromafar 3y ago
    Sure, but my comment meant to address systems thinking and application design, not micro optimisations.
XCSme 3y ago
Assembly is so far from the original code written today that it is not even feasible to think about. That being said, imagine how fast everything would be if the companies developing the software would actually care about performance. For like 99% of websites and software today, if anyone cared about the app performance, I am pretty sure most would be able to achieve at least 50% speed-ups through very basic changes (correct caching, optimizing assets, replacing bloated 3rd party libraries with a basic native call that does the same thing, configuring the servers and databases properly, etc.). EDIT: That being said, I am pretty sure in a few years AI would be able to provide one-click optimizations to a repository that would either apply best-practices or rewrite the original code in performant Assembly.
- jodrellblank 3y ago
  > "if anyone cared about the app performance, I am pretty sure most would be able to achieve at least 50% speed-ups through very basic changes" See https://danluu.com/octopress-speedup/ https://danluu.com/octopress-speedup/ > "This blog is a static Octopress site, hosted on GitHub Pages. Static sites are supposed to be fast, and GitHub Pages uses Fastly, which is supposed to be fast, so everything should be fast, right?" followed by > "I'm not sure what to think about all this. On the one hand, I'm happy that I was able to get a 25x-50x speedup on my site. On the other hand, I associate speedups of that magnitude with porting plain Ruby code to optimized C++, optimized C++ to a GPU, or GPU to quick-and-dirty exploratory ASIC. How is it possible that someone with zero knowledge of web development can get that kind of speedup by watching one presentation and then futzing around for 25 minutes? I was hoping to maybe find 100ms of slack, but it turns out there's not just 100ms, or even 1000ms, but 10000ms of slack in a Octopress setup. According to a study I've seen, going from 1000ms to 3000ms costs you 20% of your readers and 50% of your click-throughs. I haven't seen a study that looks at going from 400ms to 10900ms because the idea that a website would be that slow is so absurd that people don't even look into the possibility. But many websites are that slow!"
- winter_blue 3y ago
  > For like 99% of websites and software today, if anyone cared about the app performance, I am pretty sure most would be able to achieve at least 50% speed-ups through very basic changes (correct caching, optimizing assets, replacing bloated 3rd party libraries with a basic native call that does the same thing, configuring the servers and databases properly, etc.). I'd say a big factor to include here is the choice of language. Going from Python/Ruby to Kotlin/Rust/etc could probably yield a speed up of over 10x / over 1000%.

Makes you wonder... How fast would everything be if it was written in assembly. In audio dev it's very common for dsp code to be written in assembly.

by pier25 3y ago

Makes you wonder... How fast would everything be if it was written in assembly. In audio dev it's very common for dsp code to be written in assembly.

geek_at 3y ago

Or if everything had been written by "ais523 - high effort answers"

xxs 3y ago

You dont need Assembly, you need to the code not to be terrible, which is generally hard with the amount of code/developers needed.

dumdumchan 3y ago

It wouldn't run at all since it wouldn't exist.

nickelpro 3y ago

Assembly is hardly the reason this is fast. It is necessary to this solution but by no means sufficient. Extreme algorithmic research combined with a high LOK of Linux syscalls and platform specific optimizations is what allows this to exist. To quote the author, Alex Smith, himself: > @chx: I already have a master's thesis. This was harder. This is in a different universe than what can be produced by simply "do it in assembly".

wheelerof4te 3y ago
"Extreme algorithmic research combined with a high LOK of Linux syscalls and platform specific optimizations is what allows this to exist." No, author's extreme boredom and/or free time allowed this to exist. Nothing else.
moreati 3y ago
What's LOK in this context? Search and Wikipedia didn't throw up anything. Thanks.
- bonzini 3y ago
  Level of knowledge, I think.
  - nickelpro 3y ago
    Correct. It's one of those extremely-common-in-the-US-military-almost-no-usage-outside-it type things apparently, like behoove or tack (hyphen) or diggit (multi-tool), which I'll keep in mind in the future.
bonzini 3y ago
The second ranked solution (by me :)) shows that a more or less trivial assembly tight loop can get about 70% of the speed. The remaining 30% is... something else.

kryptiskt 3y ago

It would end up like Steve Yegge's tale of Geoworks: "OK: I went to the University of Washington and [then] I got hired by this company called Geoworks, doing assembly-language programming, and I did it for five years. To us, the Geoworkers, we wrote a whole operating system, the libraries, drivers, apps, you know: a desktop operating system in assembly. 8086 assembly! It wasn't even good assembly! We had four registers! [Plus the] si [register] if you counted, you know, if you counted 386, right? It was horrible. I mean, actually we kind of liked it. It was Object-Oriented Assembly. It's amazing what you can talk yourself into liking, which is the real irony of all this. And to us, C++ was the ultimate in Roman decadence. I mean, it was equivalent to going and vomiting so you could eat more. They had IF! We had jump CX zero! Right? They had "Objects". Well we did too, but I mean they had syntax for it, right? I mean it was all just such weeniness. And we knew that we could outperform any compiler out there because at the time, we could! So what happened? Well, they went bankrupt. Why? Now I'm probably disagreeing – I know for a fact that I'm disagreeing with every Geoworker out there. I'm the only one that holds this belief. But it's because we wrote fifteen million lines of 8086 assembly language. We had really good tools, world class tools: trust me, you need 'em. But at some point, man... The problem is, picture an ant walking across your garage floor, trying to make a straight line of it. It ain't gonna make a straight line. And you know this because you have perspective. You can see the ant walking around, going hee hee hee, look at him locally optimize for that rock, and now he's going off this way, right? This is what we were, when we were writing this giant assembly-language system. Because what happened was, Microsoft eventually released a platform for mobile devices that was much faster than ours. OK? And I started going in with my debugger, going, what? What is up with this? This rendering is just really slow, it's like sluggish, you know. And I went in and found out that some title bar was getting rendered 140 times every time you refreshed the screen. It wasn't just the title bar. Everything was getting called multiple times. Because we couldn't see how the system worked anymore! Small systems are not only easier to optimize, they're possible to optimize. And I mean globally optimize." http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html http://steve-yegge.blogspot.com/2008/05/dynamic-languages-st...

sillysaurusx 3y ago
Interestingly, AI might change this. Not that it would be a good idea to write everything in assembly, but at least it would be possible now. Some wonderful systems were written in assembly. Donkey Kong comes to mind.

tragomaskhalos 3y ago

I started in software dev in 1988; the only languages I knew were BASIC and Z80 assembly so, since everyone knew BASIC was kind of lame I naturally assumed I'd be a machine code programmer, albeit on slightly more exotic processors. Day one got handed a book on C -> mind blown.

jojobas 3y ago

It depends. You can write bubblesort in assembly and it will be pretty damn slow. I can imagine those assembly leaders could push out pretty fast C implementations as well.

MagicMoonlight 3y ago

Even if everything was just written in java we’d be better off than the current system of embedding chrome into a python instance and then running a webserver in javascript to render a document.

pkolaczk 3y ago
I don't think replacing one bad idea with another bad idea is a good idea ;) I'm also not sure if Java would be less bad in that case. At least JS has years of research that went into making it start fast, not only run fast after warmup.
- selimco 3y ago
  Modern Java has Coordinated Restore at Checkpoint (CRaC) as well as ways to compile it to native binaries that can start very fast (GraalVM & Substrate VM). The former has the benefit of a JIT as well!
  - therealdrag0 3y ago
    Have you used any of these? I’m looking for ways to speed up start time of JVM, but almost options I’ve seen so far are “experimental” and not sure best route to take. For example was sad to see ahead of time compile being removed from JDK.
- pulse7 3y ago
  Is this "years of research" the reason why most Electron apps still start slower than - for example - IntelliJ IDEA, which is written in Java and Swing?
- dahfizz 3y ago
  Just imagine if those years of research went into a good language instead. Instead of expending a huge amount of effort making an inherently slow language perform reasonably, we could have taken a reasonable language like Rust and made it so good it would legitimately push computing forward. And then all you web devs could still compile rust to wasm. wasm is already faster than JS anyway. JS was a mistake.

actionfromafar 3y ago

I think an oft overlooked detail of more primitive languages yielding faster programs, is this: when it’s painful to progress even a little bit while coding, you try very hard to implement as little as possible resource constraint can give clarity of focus

zokier 3y ago
Shortest/smallest code is rarely the fastest. Loop unrolling and inlining make code larger, and occasionally faster as an trivial example
- actionfromafar 3y ago
  Sure, but my comment meant to address systems thinking and application design, not micro optimisations.

XCSme 3y ago

Assembly is so far from the original code written today that it is not even feasible to think about. That being said, imagine how fast everything would be if the companies developing the software would actually care about performance. For like 99% of websites and software today, if anyone cared about the app performance, I am pretty sure most would be able to achieve at least 50% speed-ups through very basic changes (correct caching, optimizing assets, replacing bloated 3rd party libraries with a basic native call that does the same thing, configuring the servers and databases properly, etc.). EDIT: That being said, I am pretty sure in a few years AI would be able to provide one-click optimizations to a repository that would either apply best-practices or rewrite the original code in performant Assembly.

jodrellblank 3y ago
> "if anyone cared about the app performance, I am pretty sure most would be able to achieve at least 50% speed-ups through very basic changes" See https://danluu.com/octopress-speedup/ https://danluu.com/octopress-speedup/ > "This blog is a static Octopress site, hosted on GitHub Pages. Static sites are supposed to be fast, and GitHub Pages uses Fastly, which is supposed to be fast, so everything should be fast, right?" followed by > "I'm not sure what to think about all this. On the one hand, I'm happy that I was able to get a 25x-50x speedup on my site. On the other hand, I associate speedups of that magnitude with porting plain Ruby code to optimized C++, optimized C++ to a GPU, or GPU to quick-and-dirty exploratory ASIC. How is it possible that someone with zero knowledge of web development can get that kind of speedup by watching one presentation and then futzing around for 25 minutes? I was hoping to maybe find 100ms of slack, but it turns out there's not just 100ms, or even 1000ms, but 10000ms of slack in a Octopress setup. According to a study I've seen, going from 1000ms to 3000ms costs you 20% of your readers and 50% of your click-throughs. I haven't seen a study that looks at going from 400ms to 10900ms because the idea that a website would be that slow is so absurd that people don't even look into the possibility. But many websites are that slow!"
winter_blue 3y ago
> For like 99% of websites and software today, if anyone cared about the app performance, I am pretty sure most would be able to achieve at least 50% speed-ups through very basic changes (correct caching, optimizing assets, replacing bloated 3rd party libraries with a basic native call that does the same thing, configuring the servers and databases properly, etc.). I'd say a big factor to include here is the choice of language. Going from Python/Ruby to Kotlin/Rust/etc could probably yield a speed up of over 10x / over 1000%.