Is there any limit to how faster the code executes the lower level you get?

[Gat Pelsinger]

As a general rule in programming, no matter how optimized and efficient you make your program, the higher-level programming languages cannot compete with performance and lightness with the lower-level programming languages. So what? If you ever wanted the fastest and straightforward execution of your code, would you just have to program in binary? I know programming in binary isn't as easy as it sounds, but my question is for THE fastest performance, do you need to code in binary, or stepping up a level higher to like assembly yield the same results?

 

[Robchil]

4 minutes ago, NvidiaFirePro6900XXTX3DPRO said:

As a general rule in programming, no matter how optimized and efficient you make your program, the higher-level programming languages cannot compete with performance and lightness with the lower-level programming languages. So what? If you ever wanted the fastest and straightforward execution of your code, would you just have to program in binary? I know programming in binary isn't as easy as it sounds, but my question is for THE fastest performance, do you need to code in binary, or stepping up a level higher to like assembly yield the same results?

 

machine code? 

 

[porina]

Taking a high level view, even if you have perfectly optimised software, your performance will be limited by hardware. You need to know what the specific hardware can do, and make best use of it. You're not making general software at that point. How close do you want to get?

 

Hybrid approaches work to get the most performance with reasonable effort. An example is Prime95. The bulk of it is written in some derivative of C, but the performance critical parts of it are written in assembler. There are multiple code paths optimised for different CPU architectures and instruction sets.

 

There comes a point if performance is that important, you might consider not optimising the software but the hardware. Silicon designed to do a specific task can perform much faster than general uses.

[dcgreen2k]

Just to clarify one point, assembly instructions have a one-to-one mapping into binary, and so there is no performance difference between programming in the two formats. We only use assembly because the opcode mnemonics, register names, and immediate values are easier for humans to write and understand than raw binary. Theoretically, our programs would be the fastest if they were all written in assembly. This is not the case in the real world because of how difficult it is to write good assembly code. So, we made higher-level programming languages where the more complex parts, like interacting with the hardware, were abstracted away. This way, we could make programming easier and more productive while keeping acceptable performance.

 

Once you get to the actual instructions executing on the CPU, it mainly comes down to hardware. As far as I know, the highest possible throughput is one instruction executed per clock cycle, ignoring fancy things like superscalar architecture and having multiple cores. Many of the improvements we've made to CPUs to improve this range from simple things like increasing clock speed, to more complex topics like pipelined architecture and branch prediction algorithms.

 

As a side note, the only fields I know of that still use some assembly code is in embedded systems (like Arduino), and cybersecurity. It's sometimes needed in embedded systems because you're typically working with microcontrollers that have very low clock speeds and not much memory, although this need has decreased significantly. For reference, the Arduino Uno has a 16MHz processor and 2KB of RAM. In cybersecurity, assembly is used in reverse engineering malicious binaries. By looking at a program's assembly code in a tool like Ghidra, you can get a better understanding of how it works on the inside and figure out exactly what it does.

[Sauron]

2 hours ago, NvidiaFirePro6900XXTX3DPRO said:

As a general rule in programming, no matter how optimized and efficient you make your program, the higher-level programming languages cannot compete with performance and lightness with the lower-level programming languages. So what? If you ever wanted the fastest and straightforward execution of your code, would you just have to program in binary? I know programming in binary isn't as easy as it sounds, but my question is for THE fastest performance, do you need to code in binary, or stepping up a level higher to like assembly yield the same results?

This is a generalization that only sometimes holds true. All code is eventually reduced to binary instructions; it's perfectly possible a high level language ends up producing the fastest possible machine code for whatever you're trying to do, however it's usually the case that ultraoptimized use case specific machine code is faster. You should also bear in mind that using assembly or machine code directly does not automatically guarantee your code will be faster; outsmarting modern compilers is not easy. Further, depending on your machine architecture some instructions or ways of doing things may be faster than others even though in theory they should be equivalent; compilers know this, you might not.

[wasab]

the compiler does plenty of optimization already. e.g. recursions get converted into loops, static result like int x = 1 + 1 will get rewritten to just int x = 2 to save on the cpu cycle, ect. you can probably write better assembly code than the compiler if you are an expert at writing assembly but you are also likely to make a lot more human errors just because you are a human. i dont consider the time investment to be worth it for most purposes. 

[Eigenvektor]

10 hours ago, NvidiaFirePro6900XXTX3DPRO said:

As a general rule in programming, no matter how optimized and efficient you make your program, the higher-level programming languages cannot compete with performance and lightness with the lower-level programming languages.

That is true if, and only if, you are able to optimize your code to the same level a modern compiler does. Which requires a lot of in-depth knowledge about CPU architecture, memory models and so on. And you'd have a much higher chance to mess up than going with a higher level language.

 

Going with machine code/assembler only really makes sense for extremely performance critical sections where you know the compiler doesn't produce optimal code and where you've run extensive benchmarks to ensure your optimizations actually optimize the performance. And where you're certain you don't have to change the code around a lot.

[TizzyT566]

If we are talking about the same hardware, then yes like mentioned the limit is the hardware. If you plan to "program" the hardware itself then you would account for the time it takes for any fundamental interaction for the components, phase changes, propagation delays, etc. Essentially the limitations are the physical limits of our reality

[wasab]

on a side note, i have rarely seen anyone writes in machine code except malware creators and security researchers who write their exploits in hexadecimals, and even then, this is usually embedded inside a higher programming language like c or some other languages that act as the delivery vehicle or attack vector. E.g. this is a shell code for example(what arch and cpu idk). You can copy and paste this onto a hexdecimal to-binary converter to see what its machine code looks like

\x68\x21\x0a\x00\x00\x68\x6f\x72\x6c\x64\x68\x6f\x2c\x20\x57\x68\x48\x65\x6c\x6c\xba\x0e\x00\x00\x00\x89\xe1\xbb\x01\x00\x00\x00\xb8\x04\x00\x00\x00\xcd\x80

To embed it inside another language like c, you will do something like this

// char array of 50 bytes or however long your shell code is
unsigned char bytes[50] = "\x68\x21\x0a\x0 ... blah blah blah";

// cast the bytes to a function pointer 
void (*shellCodeFunctionPtr)() = ((void(*)())bytes);

// execute shell code
(*shellCodeFunctionPtr)();

This way you can pretty much write and embed machine code inside a higher language without the compiler making too many alternations to it during compilation. Another option would be to write a critical performance piece of code in machine/assembly and then compile it into a shared library. This can then be loaded and called by other higher languages like java/python/php or whatever at runtime. This is the most common approach. No one in this day and age is crazy enough to write their software in complete machine code or assembly.