For comparison in speed between C and Assembly language using bubble sort, which of it in general is faster?

248 Views Asked by At

I have researched bubble sort speed differences between C and Assembly language, and found that code optimization is one factor.

What other factors are there to consider for bubble sort speed differences between C and Assembly language and which tends to be faster?

3

There are 3 best solutions below

3
Ryley On

Practically, there really isn't much of a speed difference.

While it is true that Assembly allows you to directly access individual registers on the CPU and that this might allow you to make some small optimisations, humans typically aren't good at seeing such small optimisations.

For that reason, it's usually better (or at least, not slower) to just program in C and allow the compiler to optimise it. Even without very low-level access, C compilers typically can optimise a program better than a human could in Assembly.

13
Henrique Bucher On

C gets converted to assembly by the compiler and these days the compiler does a very good job, to the point of being faster than a very experienced human, even with infinite time in their hands.

It is not only a matter of which instructions to use but also their order. These days CPUs have multiple internal resources and the compiler knows how to optimize them such that it maximizes throughput. Memory loads and stores are also explicitly optimized.

In that sense, the assembly code that works the fastest for one CPU architecture, might be sluggish for another architecture, even inside the same family (eg Intel). So the C language works as a general template for algorithm correctness and all the hard work of optimization gets done by the compiler underneath. This optimization work is typically better done by a machine.

So overall Id say that apart from very specific cases like very SIMD heavy algorithms in audio/video or cryptography, C (with a modern compiler) is always the winner.

0
Peter Cordes On

CPUs run machine code. A C compiler can make machine code for you from C source, vs. with assembly language you're making all the important decisions yourself.


The most important factor is that Bubble Sort is a bad algorithm you should basically never use, especially when you care about performance (Why bubble sort is not efficient?). (Only sometimes if you care about tiny code size, like code golf Sort an Integer List).

Other than that, if you know exactly what you're doing in asm, it will never be slower than C, and you can control micro-optimization choices like the ones that led to GCC making a very slower bubble sort when trying to auto-vectorize. See Bubble sort slower with -O3 than -O2 with GCC for the details of that case.

But if you don't know asm and CPU architecture in that level of detail, you're unlikely to improve on compiler output. There is no "generally" that's true across all CPU (micro-)architectures and all programmer skill-levels.

Related: Why does C++ code for testing the Collatz conjecture run faster than hand-written assembly? - another example of the kinds of beginner mistakes that can make your asm even slower than a debug build of a C program.


If you cared about making a sort function run fast, the first thing you'd change would be the algorithm, to Insertion Sort or something. Or a SIMD sorting network, especially if you're writing in non-portable assembly language in the first place.

So this question only makes sense if there's something forcing you to use a bad algorithm like Bubble Sort. Or if you aren't aiming for performance in the first place and are making arbitrary choices of algorithm. Or don't know that Bubble Sort is slow, in which case we should definitely make pessimistic assumptions about programmer skill at assembly language. (Assembly language performance is even more sensitive than most languages to programmer skill at optimizing.)

But if someone forced you to spend time optimizing Bubble Sort, with asm you could probably optimize the case where an element bubbles a long way, maybe avoiding a store/reload as part of a loop-carried dependency chain. But you could probably do the same thing in C with a tmp variable, so IDK whether to count it.

You'd only think of doing that in C if you were aware of the asm / CPU-architecture reasons for it, but often you can get a compiler to generate the efficient asm you want by changing the C. That's usually best because it's still portable C.