The flat assembler (which assembles this project) is worth checking out if you haven't already: https://flatassembler.net. I first played around with it almost 20 years ago and it was noticeably more ergonomic and productive than masm, nasm, to say nothing of gas. I imagine it was designed for human programmers rather than primarily compiler front ends, so it's a popular choice for hand-written assembly projects.
I wouldn't personally say it's better, so I can't speak for OP; but generally people that use FASM prefer it for two reasons: 1) it's self-compilable (vs NASM, which is C) and 2) they like its macro system.
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 one of the reasons I really like the Mikrotik network gear, because of the Winbox application for management. It's Windows Forms (GDI) in the MDI style of most Windows apps of circa 2000. Lightning fast, responsive, and with nice touches like being able to drag files on/off the interface to upload/download and the ability to copy/paste entries like they were lines in a text file.
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.
Also unusable by many people - I see mostly macbooks around me, with some Linux laptops or Chromebooks. Windows is for those super-low-privileged users who cannot be trusted with their own system and need IT to manage them; or for gamers.
And yes, I can probably run the management software in wine, but I will avoid it if I can.
They recommend and 'support' running it in Wine. I haven't tried, but I'm sure it works fine given Wine tends to work best with no frills Win apps from a decade ago.
> 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.
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.
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.
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.
> 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).
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").
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...).
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.
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?
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?
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.
Real-time notifications give a sense of activity, nice for building a community. Reminds me of http://listen.hatnote.com/ showing live wikipedia edits, but more integrated. Some anonymity, or mention of a group, e.g. anonymous users, forum member, admin, would be better. Too much and too specific sharing of activity makes this feel stifling--more like chat with read notifications, less like email or forum where people take time to compose replies.
People do this all the time. The world is littered with assembly code written by people who believe that modern x86 uarches are just like the Pentium IV they cut their teeth on, or that an M2 is just a fancy Cortex-A53, meticulously hand ordering instructions while entirely missing the big picture.
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.
If you're inclined to write fast code in assembly, you will. If not - not.
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.
Have you tried measuring the actual impact of this?
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.
You have to measure. It's a contextual optimization, no compiler in existence measures contextual optimization for you. Even the profile-based optimization is a spray and pray thing.
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.
Kolibri OS was written entirely in Assembly. I think the performance was pretty poor compared to C operating systems. Much easier to write optimized algorithms in high level languages.
https://kolibrios.org/en/
Cost? Please explain why writing programs in assembly is supposed to be *cheaper* than writing programs in a higher level language? The same goes for convenience: Since when is writing an application in assemlby more convenient than writing an application in a modern language?
No, it is more expensive. And less convenient. For some reason you interpreted both of these the wrong way around. I wasn't answering the question, I was giving examples of those reasons. Which are pretty obvious.
How about security? I would never want an app written entirely in assembly to be allowed to take in arbitrary user input from the public internet.
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.
>How about security? I would never want an app written entirely in assembly to be allowed to take in arbitrary user input from the public internet.
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?
> 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".
> But what I don't understand is why most programmers today think that is a bad thing?
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.
Yeah, let’s leave it up to people to allocate registers, they are surely consistently good at it throughout whole code bases /s
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.
In principle, this amounts to giving a gift to society: the programmer spends more time on their work so that society as a whole consumes fewer resources.
Often, the opposite happens: the programmer transfers their productivity gain into an additional cost for society (usually by contributing to e-waste and added resource requirements).
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.
I'm not sure how to make sense of this analogy without assuming that assembly language programming self-evidently produces superior programs than programming in high-level languages, and it's exactly that claim that the comment you're replying to is challenging.
Your executables will be a small fraction of the size that you expect, you will likely be able to fit the whole thing in cache and you will consume less power because you will be happy with a smaller cycles budget so you can run the cpu much slower.
Of course this all comes at a price: decreased programmer efficiency.
I don’t think that’s actually true. Compilers write machine code that’s often much more efficient than anything you could think up by hand, and the bulk of the disk space/memory used by a modern executable is for resources/strings, not instructions. Stereotypical assembly code - extremely lean routines that accept minimal user input and don’t create human-readable output - is indeed smaller than a stereotypical compiled executable, but you’d have trouble beating the compiler 1:1 on the same problem.
But you won't be writing the same code as the code that you would write in a high level language, and that is sort of the point. You're going to do your utmost not to write such code because then you might as well break out the C compiler.
Assuming that such code is suitable or even feasible for the problem you're attempting to solve. High-level languages were created specifically for the purpose of writing large, complex software systems. We don't see assembly being used for those systems. Isn't there an argument that high-level languages are simply more fit for that purpose?
Yes you will. Because you can't afford to write code like a modern optimizing compiler. You're going to have the same kind of linecount that you have in your high level language projects and those lines will compile down to a few bytes each at most.
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.
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.
> Compilers are handicapped by ABIs and language semantics, they must adhere to calling conventions, alignments, paddings, exceptions/stack unwinding, etc.
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.
I remember claims that compilers are going to emit better machine code than humans when pipelined and speculative execution was first implemented in intel processors.
It turned out to not be true.
It is still not true as of today. Humans are still better at this, and still by humongous margin. LLMs are going to change that soon however.
Rather than argue about it, why don't you find an equivalent demo bit of code in both ASM and any other language you choose, and compile both into a static (no linking of libraries) binary?
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.
Surely we are talking about real applications not toy educational snippets. Or are you claiming that what works for the dozen or so lines in a typical Rosetta code example works just as well for million line, multi-user, multithreaded, object oriented simulators and optimizers of electrical machines?
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?
Many instructions in assembly is simply “logistics” of where should this or that byte go. Machines are eons better at it at large scopes than humans, you surely don’t have enough hair to sit through and carefully examine every register. Also, will you decide on a case by case basis to “inline” a function’s body? What if the function’s body changes? Will you go back to every “inlined” part? What if that makes a more efficient register allocation possible, rewrite the whole function where the inline happened?
I’m sure it would be very fast at booting and fast at crashing as well. However, on the Android side it’s probably what’s needed to compete with Apple hardware and software.
assembly? the current standard is kotlin or swift which while reasonably performant, leave a lot on the table. i'd love to have first class support for writing android and ios applications in rust. plenty fast enough for me. my day job is elixir but the memory requirements are a bit high for mobile apps (though I'm sure the guys at nerves would disagree)
While this is mainly a technical discussion forum, I am a bit disappointed to see the comment linking to the author’s political views posted on their own forum as being flagged. This is relevant information for people deciding whether to support, use, or be affiliated with this project.
Agreed. That comment doesn't seem to break any rules. Is "flagged" something that just means enough people downvoted it, or does it require moderator intervention?
Thanks for posting. In the .Net world we had the whole Moq library drama recently. Now I check the social media of library creators before I use the library. I'm sorry but I cannot trust deranged people's code in production systems.
to each his own, but I can't really use a computer without implicating myself with software written by people with totally different ethics/philosophy/politic than myself; in fact I think that no one can.
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.
I don't think it's a black-or-white thing. You weigh pros and cons. Linus can be a bit of a jerk but the Linux kernel is immensely useful to me, so I use it in spite of some misgivings. This software, on the other hand, is mostly a fun curiosity and the author is promoting actual genocide. So in this case I'll say no thanks.
It's an indication that someone can be a good programmer while still lapping up Putin's propaganda.
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.
You mean his stance on the whole nuclear war thing? At least with that I can kind of see where he was coming from, but this forum guy just seems delusional.
as someone who spent 3 months in ukraine in 2020, I agree. I have nothing but nice things to say about the Ukrainian people. I'm not white and I was never once disrespected. I have no idea what this guys is talking about when it cones to "nazis in ukraine." I never once came across such people.
Nazis are all over Eastern Europe, it's something that happened to a certain segment of young men after the end of communism, was born largely from imported racist material from the US and Western Europe, and was fed by inspiration from UK and Italian football hooliganism (Casuals, Ultras, etc.) and "National Socialist Black Metal" which is actually a genre of music. People involved in these scenes formed gangs that developed into militias, some of the people in these militias were the children of oligarchs and politicians, and they used those gangs to enforce local collection rackets and to commit political violence. This isn't a story about just Ukraine, it's more a story about Russia, Ukraine, and Poland.
Having oligarchs connected to Nazi militias was an ideal way for the US to get money and arms into Ukraine to fuel the 2014 coup. It was simply a marriage of convenience, but one that propelled Nazis into a lot of power on the ground and in some of the institutions of Ukraine. Ukrainian Nazis think of Russians as a racially mongrelized people, and were happy to help wage war on Russian speakers in Ukraine as a war of racial cleansing. Also, their newly heroic status in some of the conservative mainstream quarters of Ukraine (combined with the forcing of Russian speakers to the East), allowed them to racialize Ukrainian identity. As we poured money and arms into the country, the Nazi militias became more and more official, and more and more the direct recipient of those arms.
The rise of the Nazis has largely been inflicted on Ukraine by US manipulation. They're just another instance of "freedom fighters" and "moderate rebels" that we fund to get what we want. When Ukraine voted for an actor who played the president on TV, they were taking the same desperate stand against the powers-that-be (in this case Russia and the US) as the US was when they elected Trump (against the Democrats and Republicans.) They were voting for peace, and an end to corruption. It didn't go well.
Bingo. Choosing forum software is choosing a long-term commitment.
Someone expressing such views is not just of a different political spectrum, he has a fragile mind.
Making a forum in assembler probably requires such a mind, but I would rather choose greedy, drugs-dependant but reasonsbly normal Drupalers than this dude.
Yep. When someone holds a view like that, they come off as an unstable or delusional person. Using a product from such a person can quickly become a liability.
I don't understand this all or nothing rebuttal. You can avoid supporting an individual that you don't like without doing background checks on everyone involved with everything you use.
Also, not supporting the Russian invasion of Ukraine is not about not supporting communism.
If the only classification you have for supporting the brutal genocide of a people is "wrong political opinion", then you have woefully inadequate mental models for the world around you.
Garbage collecting interpreters are (mostly) for wimpy scripting kiddies. The obvious historically documented exceptions are the "Symbolic AI Researchers."
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).
