Why does C not have inbuilt algorithms?

[Gat Pelsinger]

In my previous post, we saw that how low level programmers have created such awesome, fast and efficient code which destroys the normal code an ordinary programmer would write. The strlen implementation I wrote was a snail compared to the handwritten AVX2 accelerated assembly that the real strlen uses. So my question is, why aren’t there more of these functions and algorithms that we can use to make our code faster?
 

There are many such examples but one great one would be sorting algorithms. There are already so many sorting algorithms because one is faster than the other on a given data set, but imagine converting them into SIMD accelerated and multithreaded handwritten assembly. Sorting is a slow algorithm, but with this, wouldn’t it just become way faster, and upon that, we wouldn’t even need to write our own algorithms, right?

 

The if we say so, then C lacks so many of the modern algorithms and data structures we use today, like dynamic arrays (although C++ has vectors) and stuff like Hash Tables, which languages like Java have them inbuilt. Why is that so?

[porina]

C is old, from 1972. Over 50 years now, which in computing terms is practically an eternity. It has had updates and I guess if you do certain things a lot you'd likely end up with your own library of features. Even if not baked into the language itself, do modern offerings include newer libraries to help out?

 

C is the first language I seriously used at university then a minor part of later work. Dabbled with home computer BASIC before that but not in any significant way. I was so surprised when I looked at Python just how much quality of life stuff had been added. 

[Gat Pelsinger]

@porina That doesn't explain why even after so many updates these things are not added.

[FlyingPotato_is_taken]

C++ is for a reason called C++ and not ++C. Out in the wild you will always use C with some libarrys.

 

If you want to drive home how old C is: 

STRINGS ... null terminated.

[mariushm]

Because not all architectures work the same and have same performance.   And also, because sometimes you're willing to trade performance for lower power consumption.

 

Let's say you have an array of a 1 billion numbers that you need to sort .. your AVX sorting may take 10s and consume 15 watts of power, while the plain SSE or basic sort may take 11s but consume only 5-8 watts of power.

 

Not all processors have AVX, so you'll have to fall back to SSE 1 /2 / 3/ 3+ , whatever ... on some processors the SSE implementation may be faster than AVX (ex Ryzen 1st and 2nd generation could be slower on avx compared to sse, but from 3rd generation avx could be faster).. look for example in the git repository of x264 for example to see how many assembly optimizations are made for  various generations of processors, and how sometimes they revert to other instruction set paths because the performance increase is too small to justify the extra effort to maintain the assembly code or because there's  too few processors out there to be worth keeping that code (for example disabling any 3d now! assembly because you don't have k6-2 and k6-3 processors anymore in any significant number)

 

There are performance libraries made by intel and others one could use if they don't want to write super optimized code themselves.

 

As for your strlen issue ... that's C specific or specific to programming languages that define the end of a string by a null character or some other such silliness.

 

Pascal for example kept the length of a string at the start of the array. You could easily make your own strings implementation where you allocate from the start a few bytes to keep track of data (ex 4-8 bytes maximum string length, 4-8 bytes how many bytes used, 4-8 bytes pointer to next string (if there's two strings joined together etc )

 

Golang keeps the length of the string in the structure that holds the pointer to the byte array so you don't have to parse string to find their end : https://go101.org/article/string.html It also has fancy features to parse the string and get utf-8 sequences and other nice string related features.

 

 

[porina]

Part reason might be that C is more scalable downwards than modern languages. I haven't looked at what offerings are available these days, but C and close derivatives were popular in the microcontroller space.

 

That doesn't preclude add-on libraries but it wouldn't form a base part of the language as a whole.

[manikyath]

'just C' is an incredibly old and low-level programming language. you could go and find libraries for the things you want to do, and C yourself around implementing those.. but if that is what you want to do, good old C is not the place to be.

 

if you want the fancy more advanced stuff, you're kind of just by default headed towards the C++ space and/or similar derivatives.