Hacker News Reader

Comment by jbm | Hacker News Reader

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.

View on HN

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...

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.

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.

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.

if cpu is the bottleneck, then sure, if it's network/db then it won't make much of a difference at all.

> 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.

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).

What computationally complex operation would a forum application regularly do? I can't think of any but I've never written a forum application.

Database joins for instance. Ranking articles.

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.

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.

The DB in this case is SQLite, which is embedded.

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?

Figuring out which posts to display on page 853 in threaded view.

I can't think of a situation where that wouldn't be a slice of an array based on an integer post ID. Even with an embedded DB the IO should crush that gain, right?

Depends on the data structure. Since new replies may have to be inserted in tne middle, it may not be organized as a linear array.

> a slice of an array based on an integer post ID

Can't see how that works when you've got threading going on.

e.g. You have posts 1-10 and pages of size 5. 1, 2, 5 are top level posts. 3, 4 are replies to 1. 6, 7, 8, 9 are replies to 5. 10 is a reply to 2. Which means page 1 contains 1, 2, 3, 4, 10 and page 2 is 5, 6, 7, 8, 9.

Oh threading— yeah that's true. I still think of forums in the old school model.

Deeply/truly threaded forums are definitely computationally intense. You have to leverage something to recreate the necessary tree from it's database structure (preorder tree traversal, adjacency lists, etc) while applying ACL methods, view transformations, etc on the dataset. This is much less of a problem nowadays though (compared to when forum software was "in vogue").

Reply on news.ycombinator.com