Hacker News Reader

Comment by amedvednikov | Hacker News Reader

From my experience in this area, it's still possible to produce a lot more efficient and compact machine code in ASM.

You just have to be careful, because in a lot of cases good algorithms have much higher effect that raw performance.

Case in point: I saw a web forum once, written entirely in assembly language. The author claimed high performance, but looking at the sources, I saw that it uses no buffering, and even a simple webpage results in thousands of write syscalls. Whatever they saved in more efficient function prologues, they lost back in wasted context switches.

I'd also be really concerned about security in that application. Web applications tend to do a lot of string processing, and naïve assembly implementations of string processing routines are likely to be vulnerable to all the same errors as a naïve C implementation -- buffer overflows, off-by-one errors, null byte injection...

Exactly. Compile a C or C++ application with -Os and the highest size optimisation settings, and you'll almost certainly still end up with a binary that's several multiples if not an order of magnitude or more larger than if you had written it in Asm with the equivalent functionality. Compilers can do SIMD tricks and such to get close in speed, but they are still pretty horrible at size optimisation.

You could try to "decompile"(!) this project into a higher level language and compile the result if you were really curious and wanted to try this exercise in the opposite direction. I suspect a lot of the things done in this code aren't even representable in a HLL or something a C compiler could be coerced to generate (without cheating and using inline Asm.)

I disagree with almost every aspect of this post. I've never seen any evidence of your claim about binary size being the case. It's a spurious claim. There's always the possibility that a user could write slightly more efficient assembler by hand, but orders of magnitude? Maybe in the 80s this could have been correct.

Your claim about compilers using "SIMD tricks" to "get close in speed" makes no sense either. If the HLL is using SIMD instructions and this magic assembler that you're talking about isn't, how would their performance ever be equivalent?

How much of an effect would linking shared / static libraries have on binary size?

Would someone writing assembly tend to avoid using external libraries unlike with HLL?

Linking a static library into your program will increase your binary size, linking to a shared library will not. Smaller binary size is one of the benefits that shared libraries offer.

That decision is entirely up to the developer and the project requirements. If you're not writing a bare-metal program there's no reason why not to use external libraries. It's still perfectly possible.

There are some (x86) demos with sounds, graphics and input. Size is measured in a few hundred bytes (https://www.youtube.com/watch?v=pcdHY-eJVIY for a 256 bytes example or anything here really : http://olivier.poudade.free.fr). Is any C compiler able to generate this few code ?

No, but those are extreme outliers, and not relevant at all to discussion about large scale programs.

You can absolutely not write a program much larger than 256 bytes in the style you use to write those. It would be utterly incomprehensible and unmaintainable. The small size actually works in your favour here, and allows you to use incredibly questionable tricks.

I think you are underestimating the ability of humans.

I remember back in the day where I was following a small amateur indie game scene (1998-2002), a guy released a game he'd written entirely in assembler, just for fun. He could have easily have written it in C instead, but he didn't.

The binary was significantly smaller and the game really smooth.

You don't write assembler the same way you write C or C++.

A compiler is working under various constraints, for instance regarding interoperability. When you craft everything by hand, you really have no constraints other than your imagination. You can benchmark stuff and learn and adapt. Compared to that a compiler is a sophisticated idiot.

That doesn't mean all of us should start working in assembler. But don't look down at people that do - instead find inspiration, and perhaps try to make the compilers less dumb.

That was twenty years ago. Compiler technology has not exactly stood still in all those years.

http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_dens...

See figure 7.

how would their performance ever be equivalent?

The majority of general-purpose code can't use SIMD because it's really branchy, mundane "business logic" type of code, and that's where handwritten Asm's code density really shows an advantage.

I see that you claim to have "written lots of bare-metal assembly" and have posted a link to your OS in Asm, so I looked at the code...

You are not using Asm the way Asm is supposed to be written. You are writing code like a compiler, which totally misses the point of using Asm. Now it is obvious why you don't understand --- because you've never seen what "real Asm" looks like.

To elaborate, one thing that stands out is lots of stack manipulation, barely using the registers at all. Putting everything on the stack is what stupid compilers do. This is no good for speed nor size.

I have been reading and writing Asm for a few decades. See some of my other comments if you'd like to learn more... here's a quick sampling:

https://news.ycombinator.com/item?id=8248172

https://news.ycombinator.com/item?id=12332672

https://news.ycombinator.com/item?id=12356450

https://news.ycombinator.com/item?id=15721322

https://news.ycombinator.com/item?id=17948475

Program bloat is not due to poor compiler optimization. It’s due to runtime size and a lack of effort to make runtimes smaller. In particular the c runtime.

Reply on news.ycombinator.com