A forum engine written in Assembly
asm32.info
asm32.info
What in specific makes flat assembler better than NASM?
Not an issue for NASM, since it's written in C.
I am endlessly annoyed by slow interfaces. At $DAYJOB I have to use a web and desktop GUI for managing CheckPoint firewalls. These often will freeze for dozens of seconds, and generally make my computer crawl. I feel that this should not be acceptable in 2023.
This is probably not a problem of the principal slowness of the software. With a high likelihood (source: personal programming experience of my colleagues and me), the root cause when the GUI freezes in such situation is typically rather that some operation that needs a little bit of time (say, a server request) is done in the GUI thread, thus blocking the processing of any other event (message). Windows programming is very sensitive in this regard.
Sounds like its worse than that.
I know why the web for UI took over, but I sure do miss Windows forms-based applications. The web is fine for the UI to a bank or some other tool you don't interact with that often, but for tools where you can spend hours working inside, browser-based interfaces are terrible.
And yes, I can probably run the management software in wine, but I will avoid it if I can.
Also interesting that they host their code on Fossil, which itself has a builtin forum engine written in C.
A very cool application regardless, I haven't seen Assembly since college now.
Regardless of what language is serving up the request.
Still neat though.
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.
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.
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.
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...
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.
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.
Like can you be really good with Assembly and still not be certain your effort is actually worth not doing it in a higher language?
https://github.com/ArmageddonGames/ZQuestClassic/commit/0a78...
This optimization is so old, I'm not even sure if it's still worth the effort. It definitely worked in the 90s.
What you do here is you save on division, and lose on instruction cache. This might look good on a benchmark when all your code fits the cache nicely, but bite back in-vivo. You should try it out in an actual problem and see how it goes.
Division is really really slow in CPUs, as I understand it. Like, CPUs are just awful at it.
It being an old opt doesn't mean it is invalid. I'm not aware of CPUs getting meaningfully better at division.
CPUs are not getting better at division per se, but they are getting better at all the ALU operations compared to the memory latency. You can add more transistors on a chip, but you can't cheat the light speed and make signal travel 30 cm in less than a nanosecond. So you need to bring your data closer, you need caches. Code, unsurprisingly, is also data, and it also goes through the instruction cache.
This optimization is instruction latency vs. cache intake. It may or may not be beneficial depending on the rest of the program. I've already seen both Clang and GCC produce faster code with -Os rather than with -O3.
If you’re going to take the trouble of writing assembly, you should do it right; figure out the fastest you can theoretically go, and see if you can get within a few percent of that without using assembly. If you can, stop. If not, figure out why you can’t, file compiler bugs as applicable, and then write assembly where it’s necessary. Re-measure, and if you aren’t within a few percent, figure out why not, then go back to step 1.
The thing is, optimizing compilers don't actually do any optimization in the classical sense. They don't do run-measure-modify loop as programmers do so all they can apply to the code is the heuristics some other programmers taught them. Some things are trivial like loop unrolling or function inlining. Some are not, like trigonometric approximations.
In the long run, when a compiler stops, a person goes further. That's why empirically, hand-made code is still faster than the compiled one. Of course you can write slow code in Assembly, but if you already decided to go low, you'll optimize your thing until satisfied with the result.
One particular thing comes to mind, C is ridiculously bad with automatic superscalarization (try VTune's HPC characterization on any code you like and see). Sure, you can use intrinsics and implement things manually, but that would be essentially the same as writing in assembly.
There is another contender though. Spiral (https://spiral.net/) that actually do solve the optimization problem can in fact be as effective as a human programmer and at a fraction of the cost. Spiral is overly specialized, so it's not a threat to all the HPC, but a more generic thing may indeed become a gamechanger.
There is a reason (well actually there are many) that the vast majority of software development these days is done using more advanced languages.
Cross-platform support, which you might argue just falls under convenience, but if you're writing for a different CPU architecture, you've basically written 2 separate programs now and not one.
As opposed to one written in C, or a scripting language?
When you are coding every arithmetic operation by hand, it is trivial to detect e.g. integer overflows. And even produce the mathematically correct result for operations that temporarily overflow a 32/64 bit register.
(The exception is RISC-V, which seems designed exclusively as a target for C compilers and makes these operations more costly, thus guaranteeing that they won't be used even by compilers for safer languages)
Assemblers also won't remove any instruction you write because of reasoning about "undefined behavior". They won't change constant-time code into something that isn't.
There is a "soft limit" on the complexity of hand-written code, which encourages thinking more carefully about the design, and using data representations that are a good fit to both the problem and the machine.
Yes, all of that is more work, and requires specialized knowledge. But what I don't understand is why most programmers today think that is a bad thing?
Gotta love how when someone makes an wrapper around one feature of ffmpeg weighing over 100 MB, some say that's making great tools more accessible, and is saving the original dev so much time (and the gazillion people who will maintain it forever, because that's not the vanishingly small exception but the norm, The Thing That Must Be Planned For).
But when someone says the think making really tiny and bloat-free things by hand, and with 10x times the effort, the sky is falling, and people put more energy into denouncing what a human can achieve, vs. what modern compilers can do, than it would take to code the thing in brainfuck.
I think it's the corporate focus. Some people think doing something for money, and to multiply money, is intrinsically more "serious" than doing it for the love of it, or just for fun, and with no more of a goal in mind than skipping stones. And I think trauma plays a role, too: Someone mentions making a vanilla whatever (and it doesn't get more vanilla than assembly... it's the opposite of using a framework to be able to make 5 apps in 3 days), and people instantly come swarming to talk about the nightmare of inheriting that "code base".
I think it's a bad thing because I disagree with you that you'll write fewer bugs because you're coding everything by hand. In my experience how much manual work you need to do correlates 100% with how many bugs the software will have.
There isn't anything about assembly language that makes it inherently more effective or efficient than a high level language.
Of course this all comes at a price: decreased programmer efficiency.
No they won't. There is no way that you can write more compact code than a modern optimizing compiler for anything except the most extreme edge cases.
One low hanging fruit: Compilers are handicapped by ABIs and language semantics, they must adhere to calling conventions, alignments, paddings, exceptions/stack unwinding, etc.
If you don't have to care about any of that you can save a lot of useless instructions.
And secondly when it comes to size optimizations, compilers are pretty bad (or they tend to still value some speed over pure size). Wont find any modern compiler emitting lodsb/stosb (the non-rep kind) on x86 for example.
I believe most of these are only at potential “extern C” points. Usually these conventions are upheld because they don’t have a huge cost, but to give you a trivial example: inlining is literally about dropping all that in favor of optimizing at a larger scope.
Assembly language binaries tend to be extremely small compared to equivalent code written using a high level language. But: you'll easily spend 10x the time on them. The 'modern optimizing compiler' argument is at the function level: where you write a function using assembly and then write a similar function using a high level language (but still a compiled one, obviously). Yes, the compiler will probably win that race. But an assembly language programmer isn't going to write their code like that at all.
They will reduce the task to the point where it is manageable and that alone will save far more code than the compiler can ever remove. Assembly is (and assembly language based applications are) utterly bloat free, you do what you have to do and nothing more. You can use registers in ways that a compiler would never even think of because you can globally optimize.
No stack frames if you don't need them. No memory accesses if you don't need them.
But code that is hard to maintain and that likely will not be easy to work on with multiple people. 100 KLOC (including comments) -> 16Kb output. No high level language would even begin to approach that.
If they don’t even solve the problem, then it is no competition.
Humans are better at tiny hot loops. Not at all at anything larger than that.
And call me back once LLMs successfully solve a Sudoku first, before they attempt at spewing out code.
You should be able to use the Rosetta Code web site to find equivalents written in ASM and say, Rust or C++... then you can easily demonstrate that what you say is factually correct.
At risk of moving the goal posts, I suspect that actually writing such a program in assembler might well be impossible simply because it would probably take too long to write and debug.
If assembler tooling were improved perhaps this could change but who will do it. There have been assemblers with object oriented extensions, perhaps other developer aids could be created. But who will expend the effort?
It's easy to extrapolate this to other domains. Imagine that in order to enhance their productivity, aerospace engineers started buying off-the-shelf generic components and get them assembled as quickly as possible without seeking optimization. The airplanes will consume a lot more fuel, have a worse safety record and require constant upgrades and maintenance, but it doesn't matter much as the manufacturer can now hire fewer engineers, and it's other people's fuel you're wasting anyway.
I understand that seeking immediate profit is the norm, but I'm always a little disillusioned when I see selfless initiatives ridiculed.
Hmm. maybe there's a bug in one of the lines of someone's code.
Guess I better get started investigating it. 'Cause once I'm done I've got to start porting it to RISC-V.
If I had millions of person-hours to RE all the apps I hate, I'd just write them in Rust or something.
In general, writing something in assembly won’t be faster. Some expert can in certain cases come up with a better hot loop in asm, but for larger scopes we can’t be as diligent as a machine can be.
x86 only.
https://board.asm32.info/hi-johnfound-welcome-back.351/#1624...
board.asm32.info##div.info.toast
if you find a software stack that aligns itself perfectly with any single dogma (outside maybe TempleOS) then let me know, but right now that seems like a pipe dream.
I mean, just as food for thought, is there any common-use cryptography without major ties to war parties and national security groups?
aside: I can think of plenty of more practical reasons to avoid a net-facing forum software written in asm in 2023.
On a related note, I somewhat recently posted just the link to the very religious SQLite ethics page on Facebook - which immediately flagged it as some objectionable something or other. Just a link to a web page of one of the most popular open source packages on the planet which Facebook itself no doubt uses. They're so incredibly leftist that their algorithms can't even abide linking to a religiously oriented page.
In 1990, SQL (and dBASE and Excel) was a "computer language" for secretaries. Now in 2023, we suffer uneducated halfwits manically typing in endless repugnant "ad tech" and "SEO" with our "Bioinformatics Researcher" hacks inflicting delusions based on Excel #Err cells (look it up) upon an unwitting populace.
Somewhere, we went wrong. We have GREAT and WISE Software Engineering (Prescriptive and Historical) guidance available in the public domain now. Our mercenary "job hoppers) don't seem to be interested in accessing that.
Going forward, some combination of ASM and Forth in Open Source incarnations and with type-checking hints will wring the most computation out of energy resources (CPU cycles).