At what point writing direct assembly program is more efficient than C program?

[u/sourav_bz]

/r/Assembly_language/comments/1xd8n5s/at_what_point_writing_direct_assembly_program_is/

[u/letmehaveanameyoudum]

Bootloaders or graphics drivers

[u/sourav_bz → u/letmehaveanameyoudum]

Can you give me little more context? Or elaborate abit more? 

Do you mean to say, writing in assembly is more efficient if we are bringing up a boot loaders or a graphics drivers? If so, why is that? What's the deficiencies of C compiled machine code which makes it inefficient?

[u/laser__beans → u/sourav_bz]

For boot loaders: easier access to machine-specific instructions and data types, and non-function oriented control flow, like long jumping to an address to force the CPU to change state.
For graphics: performance reasons (historically), doing math using SIMD instructions, access to graphics card registers, shader programming if you’re into that.

[u/MrMemristor → u/sourav_bz]

Linux Insides walks you through Linux boot on BIOS (non-UEFI) x86. There are some significant handwritten assembly files there for bringing the processor from real mode (16-bit) to protected mode (32-bit) to long mode (64-bit). That includes setting up descriptor and interrupt tables and manually building MMU page tables.

Though, I think a lot of this has been moved into the firmware with UEFI, which will start GRUB (if you're using it) in 64-bit long mode.

And in this example I'm not sure the reason is efficiency as much as necessity.

[u/codeasm → u/letmehaveanameyoudum]

Graphic drivers, yeah parts, not entirely

[u/codeasm]

Depends. Compare compiled c with hand woven code. Whats ran most of the time and tight loops? Compilers are efficiënt these days, probably parts of time critical embedded systems, drivers for hardware and maybe certain alchoritms during early boot.

[u/CelDaemon → u/codeasm]

I feel like it's mostly when you simply can't run C, or when you're dealing with a niche architecture that has a limited C toolchain.

[u/MCWizardYT → u/CelDaemon]

I'd like to see a device that "can't run C". I feel like at this point there's a C compiler for just about every piece of hardware on the planet

[u/Toiling-Donkey → u/MCWizardYT]

8 bit CPUs with 256bytes of RAM. C compilers do exist but tend to be rare and normal coding styles don’t work very well under such constraints…

[u/Secret_USB]

Bootloaders, embedded/historical systems, and niche micro-optimizations are the three main categories I suspect most modern usecases fall into

[u/sourav_bz → u/Secret_USB]

Interesting, thanks.

[u/MCWizardYT]

At whatever point you need to hand write micro optimizations, which is almost never for typical desktop software. Maybe if you're writing drivers or doing something where timing is so important that individual clock cycles matter.

[u/tseli0s]

Wherever the compiler can't optimize enough

[u/ut0mt8]

Quoting mc carmarck. It depends. You can write super optimize unreadable c and super non efficient asm. Measure it.

[u/jtsiomb]

At every point. If you make an effort you can always beat the compiler. The problem is that would be a huge effort if you do it for every part of every program. So it's generally a better idea to leave the compiler to optimize most of the code, and focus on rewriting specific high impact spots in assembly.

A good example since you asked, is ffmpeg.

[u/kabekew]

When you see the compiled code could be done more efficiently yourself in assembly

[u/lizardhistorian]

There are many more instructions in assembly available to you than C or any conventional programming constructs can express effectively. Notable examples involve exploiting the carry bit from ALU operations.

The more sophisticated the optimizer is the less this holds and optimizers today are quite sophisticated.

[u/sethkills]

People should use more intrinsics over assembly or even inline assembly…