GCC with Symbol Visibility patch => faster apps (KDE 3.4)

IceRAM · 2005-02-17 13:23:39

I've checked gcc CVS PKGBUILD and I can't seem to find this patch in it. The patch is already present in GCC 4.

What is this patch useful for? (quote from here)

1. It very substantially improves load times of your DSO (Dynamic Shared Object)
For example, the TnFOX Boost.Python bindings library now loads in eight seconds rather than over six minutes!
2. It lets the optimiser produce better code
PLT indirections (when a function call or variable access must be looked up via the Global Offset Table such as in PIC code) can be completely avoided, thus substantially avoiding pipeline stalls on modern processors and thus much faster code. Furthermore when most of the symbols are bound locally, they can be safely elided (removed) completely through the entire DSO. This gives greater latitude especially to the inliner which no longer needs to keep an entry point around "just in case".
3. It reduces the size of your DSO by 5-20%
ELF's exported symbol table format is quite a space hog, giving the complete mangled symbol name which with heavy template usage can average around 1000 bytes. C++ templates spew out a huge amount of symbols and a typical C++ library can easily surpass 30,000 symbols which is around 5-6Mb! Therefore if you cut out the 60-80% of unnecessary symbols, your DSO can be megabytes smaller!
4. Much lower chance of symbol collision
The old woe of two libraries internally using the same symbol for different things is finally behind us with this patch. Hallelujah!

What I've understood from that webpage is that, in order to turn this on, the applications must be compiled with some certain flags (this provides GCC backward compatibility, even with this patch applied, IMO).

A comment here states that KDE 3.4 (upcomming version) supports this compile flag and it's (a lot) faster.
I haven't seen the PKGBUILD of KDE 3.4 beta 2 to check if it uses "-fvisibilty=hidden", but I suppose it does not since GCC is not patched.

Fedora, MDK 10.2 and Gentoo have this patch applied to GCC 3.4 (and KDE 3.4 betas are compiled with fvisibility in those distros, according to the comments there.

There's also "-fvisibility-inlines-hidden" which does not require any support from the application, but I think that's overriden by -fvisibility flag.

Pajaro · 2005-02-17 14:07:44

you could make the PKGBUILD with the patch and explain how to apply this incredible boost when compiling new packages

phrakture · 2005-02-17 16:26:54

for the programmers out there:
this patch, while a good idea, allows you to make a method static without making it static - it's a workaround for lazy coders... that is, take:

static int foo() { return 37; }
int bar() { return 92; }

if compiled as a shared object, foo is not exported, where bar is

now, you can write:

__attribute__((visibility("hidden"))) int foo() { return 37;}
__attribute__((visibility("default"))) int foo() { return 92;}

and get the same results.

IceRAM · 2005-02-17 17:21:22

Pajaro wrote:

you could make the PKGBUILD with the patch and explain how to apply this incredible boost when compiling new packages

The page I've linked above (http://www.nedprod.com/programs/gccvisibility.html) describes the way to achieve this improvement.

For ArchLinux, all this sums up to the following:
1. make a patched GCC package (a simple patch line added to the current GCC PKGBUILD should be enough)
2. check if the program you want to package is coded (designed) to use this "symbol visibility" features
2.a. YES: add "-fvisibility=hidden" to the "make" line in the corresponding PKGBUILD - I think this is the right way (KDE 3.4 supports this)
2.b. NO: add "-fvisibility-inlines-hidden" to the "make" line = this is minor improvement compared to the first one

It basically doesn't affect the way the current programs work, unless they're specifically coded to take advantage of this feature, like KDE is.

IceRAM · 2005-02-17 17:40:12

A quick search through the Gentoo forums showed KDE 3.4 being compiled with BOTH "-fvisibility-inlines-hidden" and "-fvisibilty=hidden".

And.. it seems many Gentoo users use both of the above flags as Global CFLAGS. If something doesn't work on compilation, they remove them (old-style application). I might have been wrong about "-fvisibility-inlines-hidden" being overridden by "-fvisibilty=hidden".

I don't see support in GCC as something bad.
Support in the applications is a bit more delicate, since not many developers are willing to adapt that fast to an evolving GCC.

I believe KDE made a good step. Scanning the Gentoo forums, it seems that many apps support them... or.. don't break when they're compiled... Well, at least applications designed with support for it should benefit.

phrakture · 2005-02-17 18:34:04

the GCC patch can't harm anything, seeing as the default visibility is... well visible...
IceRAM, could you submit a feature request for the patch? Afterwards we can get library packages compiled in accordance (this only affects shared objects)...

Let's take it one step at a time

sarah31 · 2005-02-17 18:45:36

IceRAM wrote:

I believe KDE made a good step.

Supporting an unofficial patch?

Why do they insist on adding features such as and not modularizing their Desktop so that users can better define the size and functionality of their KDE install. While Arch developers bloat up KDE in order to be able to offer users the full capabilities of KDE there are many others who wish to have a slimmer DE.

KDE would be alot wiser to modularize features than look for speed bumps to cover their tracks.

phrakture · 2005-02-17 18:49:46

sarah31 wrote:

IceRAM wrote:
I believe KDE made a good step.
Supporting an unofficial patch?

well, it's an official patch in gcc4...
and gcc ignores extensions it doesn't understand... I could put __attribute__((youd_expect_this_to_break)) and nothing would happen... it'd probably give you a warning...

so one could say KDE was just preparing for gcc4

sarah31 · 2005-02-17 19:02:34

sure but do you really think KDE will build right off the hop with gcc4

and I still think they should be working on modularity and not speed... actually they could gain more speed having modularity.

but whatever.

phrakture · 2005-02-17 19:07:43

sarah31 wrote:

sure but do you really think KDE will build right off the hop with gcc4
and I still think they should be working on modularity and not speed... actually they could gain more speed having modularity.
but whatever.

yeah I agree
KDE does some things really great... but there's alot I don't need.

IceRAM · 2005-02-17 19:17:09

phrakture wrote:

IceRAM, could you submit a feature request for the patch? Afterwards we can get library packages compiled in accordance (this only affects shared objects)...
Let's take it one step at a time

Already done this.
FlySpray Task #2223.

IceRAM · 2005-02-17 19:21:06

phrakture wrote:

but there's alot I don't need.

I agree... but I have space...

... and MB is getting cheaper btw

sarah31 · 2005-02-17 19:44:22

IceRAM wrote:

phrakture wrote:
but there's alot I don't need.
I agree... but I have space...
... and MB is getting cheaper btw

true but for some people it is not space issues but the fact that they simply do not need certain things. It makes it much easier on downstream packagers too so that they do not have to face the posts on bloating packages of which there weas a few in the last month or so.

sweiss · 2005-02-18 09:44:01

sarah31 wrote:

IceRAM wrote:
phrakture wrote:
but there's alot I don't need.
I agree... but I have space...
... and MB is getting cheaper btw
true but for some people it is not space issues but the fact that they simply do not need certain things. It makes it much easier on downstream packagers too so that they do not have to face the posts on bloating packages of which there weas a few in the last month or so.

What do you mean by modularity? That instead of kdebase you would have a seperate package for konqueror and for all the other apps that are in the package?

sarah31 · 2005-02-18 16:16:41

Well there are plenty of non-kde and kde specific features that are supplied as extras and would only benefit those users that need them (cups, samba, etc) to the rest of the users who may not like, want, or need them they get them anyway right now because in order to not keep recompiling package to add features Arch maintainers add the features in right from the get go. Modularity means that the packages may be built to support such features but will run without the supporting packages and the feature only works or gets enabled when you install the supporting packages.

Take transcode for example it really only has about four true dependencies but it can support all sorts of features all one has to do is install what supporting packages it needs to use these features. thsi allows the user to use whatever features or codecs they like and not have to rebuild in order to use a specific feature. It makess the maintainer's jobs alot easier because they can build all support in with only the minimal dependencies in the end.

Modularity works for all level and need of the user. The developers of KDE have to know that many users will want it all and many will want a slim KDE that is the nature of the user base in linux. Modularity caters to both.

(Modualrity has been a standard in kernels for years and should be the standard for big projects like kde,gnome, etc.)

phrakture · 2005-02-18 19:37:44

sarah31 wrote:

(Modualrity has been a standard in kernels for years and should be the standard for big projects like kde,gnome, etc.)

It's also the basis of Unix Philosophy - make a whole bunch of little things, and use something else to "glue" it together...

for instance... why add word counting code into a text editor when you can just pipe the text to "wc"...

Arch Linux

#1 2005-02-17 13:23:39

GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#2 2005-02-17 14:07:44

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#3 2005-02-17 16:26:54

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#4 2005-02-17 17:21:22

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#5 2005-02-17 17:40:12

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#6 2005-02-17 18:34:04

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#7 2005-02-17 18:45:36

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#8 2005-02-17 18:49:46

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#9 2005-02-17 19:02:34

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#10 2005-02-17 19:07:43

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#11 2005-02-17 19:17:09

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#12 2005-02-17 19:21:06

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#13 2005-02-17 19:44:22

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#14 2005-02-18 09:44:01

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#15 2005-02-18 16:16:41

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

#16 2005-02-18 19:37:44

Re: GCC with Symbol Visibility patch => faster apps (KDE 3.4)

Board footer