Question about gcc internal library

[lassar]

I am thinking about using assembly in the gcc internal libray to speed up gcc output binaries.

It seems to me that all the internal library is done in c code, and none in assembly.

I found out, in speeding up RadioTelephone Tutor, I had to redo the most simple routines in assembly.

And example of this would be string "equal" and "not equal".

Where is the gcc internal library located, and what is the name of it?

And how would one go about recompiling the source to the internal library?

[St_W]

Do you really mean the gcc runtime? Or rather the FreeBasic runtime library (which is written in C) ?

Any way, rewriting methods in Assembler won't get you any performance improvement for the c standard library because that is already heavily optimized. It is similar for the FB runtime, although it is not optimized as much. You need very good assembly programming skills to take any advantage of coding in assembly language.

I'd rather suggest to enable compiler optimizations if you're already using the gcc backend of FreeBasic.

[vdecampo]

I'd rather suggest to enable compiler optimizations if you're already using the gcc backend of FreeBasic.

Another suggestion would be to optimize your algorithms.

-Vince

[caseih]

I don't know what this "gcc internal library" is that your'e talking about. There is a library called libgcc, which might be what you're referring to. There's also the C standard runtime which all executables link against. The standard C runtime library is called libc, and the default version that GCC links against is usually, but not always, glibc. While it might be possible to make it faster using straight assembly language, the gains would be minor compared to the downsides. There's always room for improvement, but I'm not convinced assembler is the answer. There are lighter-weight standard C libraries you can use as well, such as newlib, some might even have a lot of assembler in them.

As they say, premature optimization is the root of all evil. Before rewriting anything in assembler you'll want to profile the code and find out where the execution time is spent. Then you can focus on those areas that are consuming the most amount of time. Once every ounce of speed is squeezed out of an algorithm, then maybe there's a case for assembly as an optimization.

[lassar]

I am talking about the gcc runtime library, not the freebasic runtime.

There are several programs in linux that uses lots of string compares, and string functions.

Examples of these are bash, awk, sed, and python.

Inline assembly for string operations are about 10 to 20 times faster, than regular c code.

There's also the C standard runtime which all executables link against. The standard C runtime library is called libc, and the default version that GCC links against is usually, but not always, glibc.

Caseih sounds like you know quite a bit about the gcc compiler.

Question is libc part of the executable or is it a separate library in linux?

[marcov]

(Note on terminology:

gcc runtime : libgcc
c runtime : (g)libc

libgcc is part of gcc and mostly only architecture dependent. libc is the C language runtime, and usually part of the OS. The Linux implementation is GNU's, glibc, Android has various implementations (the original one was called Bionic iirc. The various BSDs and OS X have their own libc, and Windows has msvcrt as OS C language runtime, though 3rd party libc can be installed )
)

[caseih]

I am talking about the gcc runtime library, not the freebasic runtime.

Again, you'll have to be more specific as to what you're referring to. See Marcov's comment. Seeing as you are talking about string manipulation, probably the routines you have in mind are in libc, not libgcc.

There are several programs in linux that uses lots of string compares, and string functions.
Examples of these are bash, awk, sed, and python.

Inline assembly for string operations are about 10 to 20 times faster, than regular c code.

I guarantee that awk, sed, grep and friends are all written in C without assembler, and they are blazingly fast, nearly as fast as is possible. Speed comes from the algorithms. C is only slightly above assembler, and the compiler is smart enough to recognize certain operations that can benefit from specific platform CPU instructions and uses them.

Caseih sounds like you know quite a bit about the gcc compiler.

Question is libc part of the executable or is it a separate library in linux?

libc is not usually part of the binary. It's almost always dynamically-linked, unless you explicitly perform a static compile, in which case libc is embedded in the binary. Like Marcov said, libc is not actually part of the compiler, though the compiler depends on it, and on some platforms it ships with the compiler, such as Visual Studio. Also you can use other libc's if you want. libc's are mostly written in C, since C is as fast as assembler when used properly.

[marcov]

And there are multiple libcs, and most libcs are a balance between performance and architecture independence.

The gigantic differences between C and assembler, are only between optimized assembler and a C implementation usually so naive that it is only written to benchmark against.

Many primitives can furthermore be reduced to a few basis primitives like

- move a block memory
- compare a block of memory (sometimes a special case of subtract blocks of memory)
- search for a byte/word/dword in a block of memory

which are more architecture dependent and typically assembler, while the actual libc calls are mostly C. Some like strlen are often not library functions at all, but intrinsics, so that e.g. strlen (literal_string) can be optimized, since known compiletime and e.g. memcpy so that for a move with small constant value, inline code can be generated. There is usually a library function that is called if these special cases don't apply though, and since it is compiler called, it is in libgcc not glibc.

glibc is more a construction kit than a clear thing though. There is an awful lot of things that can be tuned depending on minimal architecture and required compatibility.

Of course in the C case, there is a complication called null terminated strings, which means that search for a byte has to search two different values( the byte to search, but also keep an eye for \0), while most languages store the length separately.

[sean_vn]

Typically the only situation you will do better than the c compiler ( or Java's hotspot just in time compiler) is when doing something complex/clever using the SIMD instructions like haddps xmm0,xmm1. Even there modern compilers will autovectorize simple loops with the SIMD instructions if they are straightforward enough. Sometimes though you benefit from access to specific instructions or the flags. You can always go look at the assembly outputted by FB with the -RR compile option anyway. And don't forget
-O 3.

[TeeEmCee]

I believe fbc optimisation flags like -O 3 only have an effect when using -gen gcc?

Sorry for going off topic...

The Linux implementation is GNU's, glibc, Android has various implementations (the original one was called Bionic iirc.

It still is called bionic, but it has changed a lot. Originally it was mostly written from scratch, was very incomplete and buggy and basically it was by far the worst libc implementation in serious use. They literally didn't think that anyone needed a real libc implementation since to begin with only Java was supported, so they didn't provide one, even long after native apps were introduced!
Since then they've improved it immensely by replacing most of bionic with code from OpenBSD, NetBSD and FreeBSD libc's (as well as jemalloc). (It's interesting that they used all three; though mostly OpenBSD).
bionic is one of the only libc's written in C++ (MSVCRT would probably be another, since MS apparently don't use C for anything)

[St_W]

I believe fbc optimisation flags like -O 3 only have an effect when using -gen gcc?

yes

[...] enable compiler optimizations if you're already using the gcc backend of FreeBasic.