On Fri, Feb 17, 2012 at 12:44 PM, Janne Blomqvist <blomqvist.ja...@gmail.com> wrote: > 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 cache line thing had crossed my mind, too. I'm not sure if that's a performance blocker for I/O in the end, though. > 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. Fair enough, that's a good reason to make this change. >> 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. Heh, I did not mean to be unreasonable. I really appreciate all the work you're doing on gfortran! :-) Ciao! Steven
