4 ms·

I don't understand — isn't the speed mostly limited by network or disk access? Is there a significant improvement by having the underlying code in Assembly? A

by jbm 3y ago

I don't understand — isn't the speed mostly limited by network or disk access? Is there a significant improvement by having the underlying code in Assembly? A very cool application regardless, I haven't seen Assembly since college now.

alberth 3y ago
The website being only 65kb in total size, all inlined with no additional downloads, plays a massive role in its performance no doubt. Regardless of what language is serving up the request. Still neat though.
- jacquesm 3y ago
  That means it fits in cache in its entirety. I've found this often to be the biggest factor: reduce the size of the 'hot' set so it fits in cache and you can see crazy speed improvements.
  - deleted 3y ago
    [deleted]
- lost_tourist 3y ago
  if cpu is the bottleneck, then sure, if it's network/db then it won't make much of a difference at all.
jacquesm 3y ago
That depends. If you do more complex stuff you can easily be CPU bound, but if you're just pumping data then likely the network will be your first limit. Caching should take care of the disk as a limitation (besides that, SSDs are wicked fast).
- chefandy 3y ago
  What computationally complex operation would a forum application regularly do? I can't think of any but I've never written a forum application.
  - jacquesm 3y ago
    Database joins for instance. Ranking articles.
    - jbm 3y ago
      Wouldn't these happen in the DB? I can see some algorithms for showing related articles being complex — but writing them in Assembly also invites other challenges (them being difficult to update and improve, concentrating on memory issues rather than algorithm, etc...). I still think it's a cool project mind you.
      - jacquesm 3y ago
        Keeping any assembly codebase up and running, especially through changes in requirements is a massive challenge, requires extreme hygiene and will be very, very costly. My largest assembly projects were around the 16K object code mark (the size of the largest EPROM) and I hope to never ever have to do stuff like that again. But the kind of performance you can get out of very modest hardware is amazing.
      - 10000truths 3y ago
        The DB in this case is SQLite, which is embedded.
        chefandy 3y ago
        Would that not still result in a disk IO bottleneck? Also, DB code is pretty well optimized. Are we sure that remaking that functionality in assembly will be dramatically better?
  - layer8 3y ago
    Figuring out which posts to display on page 853 in threaded view.
    - chefandy 3y ago
theamk 3y ago
yes, the speed is mostly limited by network/disk; no, there is no improvement from writing entire thing in assembly (optimizing a few hot functions is a different story) I have not looked at this at this software in particular, but the few assembly web engines I have looked at in the past had worse performance that C versions due to making a much higher number of syscalls. For example, multiple send calls per response; lack of pool allocators; etc...
epcoa 3y ago
> This is an engine for web based message board (forum) implemented entirely in assembly language, using FastCGI interface and SQLite database as a storage. A lot of heavy lifting isn't even done in Assembly. Not to say anything of what it's using for a TCP stack. I don't know where in the Amdahl's distribution the assembly part falls, but I'm guessing it ain't much. Edit: Also now that I perused the link, I wonder how many people commenting here are confused and are actually commenting on the speed of the Fossil browser vs the actual forum.
okaleniuk 3y ago
You are right. The site is not fast because of Assembly, it is simply well designed. Assembly, however, pushes towards healthier design choices. You have to keep things simple since you are the one who pays for the complexity, not a third-party library providers who use several third-party libraries themselves.

by jbm 3y ago

alberth 3y ago

The website being only 65kb in total size, all inlined with no additional downloads, plays a massive role in its performance no doubt. Regardless of what language is serving up the request. Still neat though.

jacquesm 3y ago
That means it fits in cache in its entirety. I've found this often to be the biggest factor: reduce the size of the 'hot' set so it fits in cache and you can see crazy speed improvements.
- deleted 3y ago
  [deleted]
lost_tourist 3y ago
if cpu is the bottleneck, then sure, if it's network/db then it won't make much of a difference at all.

jacquesm 3y ago

That depends. If you do more complex stuff you can easily be CPU bound, but if you're just pumping data then likely the network will be your first limit. Caching should take care of the disk as a limitation (besides that, SSDs are wicked fast).

chefandy 3y ago
What computationally complex operation would a forum application regularly do? I can't think of any but I've never written a forum application.
- jacquesm 3y ago
  Database joins for instance. Ranking articles.
  - jbm 3y ago
    Wouldn't these happen in the DB? I can see some algorithms for showing related articles being complex — but writing them in Assembly also invites other challenges (them being difficult to update and improve, concentrating on memory issues rather than algorithm, etc...). I still think it's a cool project mind you.
    - jacquesm 3y ago
      Keeping any assembly codebase up and running, especially through changes in requirements is a massive challenge, requires extreme hygiene and will be very, very costly. My largest assembly projects were around the 16K object code mark (the size of the largest EPROM) and I hope to never ever have to do stuff like that again. But the kind of performance you can get out of very modest hardware is amazing.
    - 10000truths 3y ago
      The DB in this case is SQLite, which is embedded.
      - chefandy 3y ago
        Would that not still result in a disk IO bottleneck? Also, DB code is pretty well optimized. Are we sure that remaking that functionality in assembly will be dramatically better?
- layer8 3y ago
  Figuring out which posts to display on page 853 in threaded view.
  - chefandy 3y ago

theamk 3y ago

yes, the speed is mostly limited by network/disk; no, there is no improvement from writing entire thing in assembly (optimizing a few hot functions is a different story) I have not looked at this at this software in particular, but the few assembly web engines I have looked at in the past had worse performance that C versions due to making a much higher number of syscalls. For example, multiple send calls per response; lack of pool allocators; etc...

epcoa 3y ago

> This is an engine for web based message board (forum) implemented entirely in assembly language, using FastCGI interface and SQLite database as a storage. A lot of heavy lifting isn't even done in Assembly. Not to say anything of what it's using for a TCP stack. I don't know where in the Amdahl's distribution the assembly part falls, but I'm guessing it ain't much. Edit: Also now that I perused the link, I wonder how many people commenting here are confused and are actually commenting on the speed of the Fossil browser vs the actual forum.

okaleniuk 3y ago

You are right. The site is not fast because of Assembly, it is simply well designed. Assembly, however, pushes towards healthier design choices. You have to keep things simple since you are the one who pays for the complexity, not a third-party library providers who use several third-party libraries themselves.