On Mon, Feb 13, 2012 at 23:04, Steven Bosscher <stevenb....@gmail.com> wrote: > On Mon, Feb 13, 2012 at 7:20 PM, Janne Blomqvist > <blomqvist.ja...@gmail.com> wrote: >> Hi, >> >> the attached patch changes the low-level libgfortran IO dispatching >> mechanism to use shared vtables for each stream type, instead of all >> the function pointers being replicated for each unit. This is similar >> to e.g. how the C++ frontend implements vtables. The benefits are: >> >> - Slightly smaller heap memory overhead for each unit as only the >> vtable pointer needs to be stored, and slightly faster unit >> initialization as only the vtable pointer needs to be setup instead of >> all the function pointers in the stream struct. >> >> - Looking at unix.o with readelf, one sees >> >> Relocation section '.rela.data.rel.ro.local.mem_vtable' at offset >> 0x15550 contains 8 entries: >> >> and similarly for the other vtables; according to >> http://www.airs.com/blog/archives/189 this means that after relocation >> the page where this data resides may be marked read-only. >> >> The downside is that the sizes of the .text and .data sections are >> increased. Before: >> >> text data bss dec hex filename >> 1116991 6664 592 1124247 112797 >> ./x86_64-unknown-linux-gnu/libgfortran/.libs/libgfortran.so >> >> After: >> >> text data bss dec hex filename >> 1117487 6936 592 1125015 112a97 >> ./x86_64-unknown-linux-gnu/libgfortran/.libs/libgfortran.so >> >> >> The data section increase is due to the vtables, the text increase is, >> I guess, due to the extra pointer dereference when calling the IO >> functions. >> >> Regtested on x86_64-unknown-linux-gnu, Ok for trunk, or 4.8? > > Certainly not for trunk at this stage.
Fair enough. > For 4.8: So the trade-off is between faster initialization and smaller > heap vs. fewer pointer dereferences? From a performance perspective, yes. Also, a multi-threaded program may benefit slightly from fewer cacheline ping-pongs due to the read-only vtables being separated from the RW data in the stream struct. That being said, while there are a few performance issues lurking here and there in libgfortran, virtual function dispatch isn't one of them. I think you'd be hard pressed to come up with a benchmark where you could see a difference. The other advantage is that by putting the vtables in read-only pages, the chance of a buggy program getting a SIGSEGV instead of corrupting the library state is slightly increased. > Does this patch fix an actual > problem? Does it bring a killer feature? No, it's certainly not a "killer feature". In general, considering the maturity of gfortran, I think it's unreasonable to expect that a bordering-on-trivial patch would bring a killer feature. The patch came about as a small experiment I did, and as I considered the result an overall improvement (even if admittedly quite a minor one), I added a ChangeLog and submitted it. -- Janne Blomqvist
