Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
On Sat, 1 Jan 2000 20:52:11 -0500, John Weiss wrote: >On Thu, Dec 23, 1999 at 10:56:46AM +0100, Andre' Poenitz wrote: >> >> And could have some more advantages. You could 'register' new functions >> at run time. You do not need a monolithic 2MB+ binary when you >> use only 10% of the functionality. >> Just load 'modules' dynamically on demand... > >Gawd, I wish I knew how to code that! If I did, I'd contribute >something using it to LyX. > An easy way: Use a DLL (perhaps a *.so?) and LOADONCALL flag (what's the equivalent in sysvr4?). Isn't this what shared code objects are made for? Happy Y2K, Arnd
Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> In particular you'll Allan> notice that Bullet.C takes 155 times longer to compile when Allan> using SGI's stl!!! This is all due to the static string arrays Allan> kept there. I'm sure I originally implemented it as const Allan> char*[] since its static and internal and constant. There is no Allan> need for fancy memory management at runtime and hence no need Allan> for using std::string here. I'm sure we've had this arguement Allan> before but I'll plow on regardless: Can someone give me a good Allan> reason why we should keep using string for the static const Allan> arrays? I agree with you: I do not how having objects in static arrays can make out life easier. JMarc
Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
On 23 Dec 1999, Lars Gullik Bjønnes wrote: > Allan Rae <[EMAIL PROTECTED]> writes: > > | Actually for me it's LyXAction that seems to be the "Compile Killer" but > | then maybe I've just left the room for a cup of tea by the time lyxfunc > | arrives on the scene. > > I thought that my recent changes to LyXAction reduced the compile > times quite a bit. They did I just hadn't noticed. Here's a couple of very interesting numbers for you recorded on a dual 552MHz bp6 (yes it's 400MHz celerys running at 92MHz FSB), I've included LyXAction because it used to be really slow but now is quite fast. All times in seconds, times in () are at 400MHz. Sorted in decreasing order of time when compiled with SGI's stl implementation. gcc-2.95.1 column is the times for just using the stl implementation that comes standard with that distro. The LyX codebase is a snapshot from Christmas Eve. Just used "make" not "make -j2" or anything else fancy other than CXX="time g++" gcc-2.95.1 SGI's STL 3.2 lyxfunc.C 24.04 328.23 (452.04) lyx_cb.C10.11 217.03 (291.35) buffer.C16.61 174.36 (240.33) Bullet.C 1.00 155.33 (215.94) lyxfont.C3.6198.80 (135.78) lyxrc.C 5.4531.38 (43.17) paragraph.C 7.4630.23 (41.41) filetools.C 2.7224.39 (33.68) lyx_main.C 4.3123.99 (33.28) filedlg.C4.2723.91 (33.17) LaTeX.C 5.3723.22 (31.97) figinset.C 5.8621.23 (30.31) LyXAction 11.2612.49 (17.06) That's the main group of files that take longer than 30 seconds to compile at 400MHz. As you can guess there is a huge cluster of files below this. I've just tried to list the main files that take forever ;-) when compiled with SGI's stl. BTW, this isn't meant as showing off how much faster I can compile than anyone else its to show the HUGE difference in compilation times when using SGI's stl. In particular you'll notice that Bullet.C takes 155 times longer to compile when using SGI's stl!!! This is all due to the static string arrays kept there. I'm sure I originally implemented it as const char*[] since its static and internal and constant. There is no need for fancy memory management at runtime and hence no need for using std::string here. I'm sure we've had this arguement before but I'll plow on regardless: Can someone give me a good reason why we should keep using string for the static const arrays? Allan. (ARRae) P.S. I didn't believe the Bullet.C times either so recompiled that file several times and all SGI stl times were within 0.5 seconds of the 155 figure. P.P.S. If I was really thorough I would repeat the tests using lyxstring instead of SGI's string implemenation for the SGI stl case. But I'm too lazy. Besides I've been pretending to be a kernel hacker for the last few days trying to get Linux working with the latest Abit bp6 bios release -- which Abit has officially removed from its FTP site earlier today and announced with deep regret to be a pile of sh!t.
Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
On 23 Dec 1999 20:22:39 +0100, Lars Gullik Bj°nnes wrote: >| >| Some time ago I suggested to use 'static inline' to break fn's up. I >| think this should work without of introducing fn call overhead. > >inlining is one of the fings that really slows a compilation... I see... Re-inlining fn's initially not split introduces an additional optimizing step. Here it generally optimizes faster if fn's are really huge. If they exceeded a certain crucial limit in size the swapping during the initial optimizing steps slows down compilation more than this additional final step costs. But this effect depends heavily on your actual system configuration. Happy new Y2K!!!
Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
> > And could have some more advantages. You could 'register' new functions > > at run time. You do not need a monolithic 2MB+ binary when you > > use only 10% of the functionality. > > Just load 'modules' dynamically on demand... > > Gawd, I wish I knew how to code that! If I did, I'd contribute > something using it to LyX. This is much easier than you'd expect. Have a look at the dlopen(3) man page for starters... However, I am not suggesting to actually start fiddling around with dynamic loadable modules in LyX. It could be a natural extension once LyX is no more Spaghett-yX ;-) Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
On Thu, Dec 23, 1999 at 10:56:46AM +0100, Andre' Poenitz wrote: > > And could have some more advantages. You could 'register' new functions > at run time. You do not need a monolithic 2MB+ binary when you > use only 10% of the functionality. > Just load 'modules' dynamically on demand... Gawd, I wish I knew how to code that! If I did, I'd contribute something using it to LyX. -- John Weiss
Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
"Arnd Hanses" <[EMAIL PROTECTED]> writes: | >And this is why it takes lyx two hours to compile on the new stdlib++, | >1 hour of that time is lyxfunc... | > | >reducing function size will speed up compilation time a lot. | | Some time ago I suggested to use 'static inline' to break fn's up. I | think this should work without of introducing fn call overhead. inlining is one of the fings that really slows a compilation... | And I agree with Andre' that cutting down radically the number of | classes and member fn's, simplifying class structure, merging similar | fn's to one uniform interface and even suppressing functionalities that | are not absolutely crucial (yes, reaching an agreement is impossible | here :^) are a top priority. Else LyX will soon become unmaintainable | and unchangeable... Several smart things can be done, and I think Andre has hit some of them. Lgb
Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
On 22 Dec 1999 14:33:03 +0100, Lars Gullik Bj°nnes wrote: >"Andre' Poenitz" <[EMAIL PROTECTED]> writes: > >| > of virtual memory. The gcc/egcs faq has very 'helpful' recommendations: >| > >| > >| >Optimize less (or dont't optimize at all), use only small >| > functions. >| >| Well. The second part *is* helpful... Hyphens only to indicate that the recommendations are quite trivial. You may remember me repeatedly complaining loudly of too large (unmaintainable) fn's and classes. > >And this is why it takes lyx two hours to compile on the new stdlib++, >1 hour of that time is lyxfunc... > >reducing function size will speed up compilation time a lot. Some time ago I suggested to use 'static inline' to break fn's up. I think this should work without of introducing fn call overhead. And I agree with Andre' that cutting down radically the number of classes and member fn's, simplifying class structure, merging similar fn's to one uniform interface and even suppressing functionalities that are not absolutely crucial (yes, reaching an agreement is impossible here :^) are a top priority. Else LyX will soon become unmaintainable and unchangeable... Arnd
Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
> So you'd like to ditch the giant switch statement and replace it with a > function table instead? A vector indexed by function number or a hash_map > perhaps? This is easy enough to implement. And could have some more advantages. You could 'register' new functions at run time. You do not need a monolithic 2MB+ binary when you use only 10% of the functionality. Just load 'modules' dynamically on demand... I'd even drop the kb_action enum and identify actions by name (i.e. a string instead) The speed penalty shouldn't be that high (especially when going from the linearly searched 'switch' statement to a map) and it would break quite a few dependencies... Andre' PS: If you trust your stomach, go and have a look at src/.deps ;-) -- André Pönitz . [EMAIL PROTECTED]
Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
Allan Rae <[EMAIL PROTECTED]> writes:
| > > function table instead? A vector indexed by function number or a hash_map
| > > perhaps? This is easy enough to implement.
No, not a function table... more a split into several despatchers,
LyX::dispatch, LyXView::dispatch, BufferView::dispatch
| At the time we had a discussion about breaking up the giant switch
| statement for performance reasons (my arguement) but I was soundly beaten
| back by Lars ("Look at the assembler output") and Asger ("Look at the
| profile -- it's nowhere in sight"). Now we have Lars complaining about
| compile times of the same code :P
inlined code using templates in huge functions...takes time to compile.
| Actually for me it's LyXAction that seems to be the "Compile Killer" but
| then maybe I've just left the room for a cup of tea by the time lyxfunc
| arrives on the scene.
I thought that my recent changes to LyXAction reduced the compile
times quite a bit.
Lgb
Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
On Thu, Dec 23, 1999 at 02:21:11PM +1000, Allan Rae wrote: > On 22 Dec 1999, Lars Gullik Bjønnes wrote: > > > And this is why it takes lyx two hours to compile on the new stdlib++, > > 1 hour of that time is lyxfunc... > > > > reducing function size will speed up compilation time a lot. > > So you'd like to ditch the giant switch statement and replace it with a > function table instead? A vector indexed by function number or a hash_map > perhaps? This is easy enough to implement. > > Actually, didn't Amir suggest something wonderful using a bunch of > separate functions last year? Where we could include the function pointer > and it's arguements in the undo/redo stack? Hmmm... I'll have to check my > archive. Me?! I know you're in a different time zone, but I can't imagine it's Friday there already. Why would I suggest something about the core C++ code? Or did you mean the other Amir? -Amir
Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
"Andre' Poenitz" <[EMAIL PROTECTED]> writes: | > of virtual memory. The gcc/egcs faq has very 'helpful' recommendations: | > | > | > Optimize less (or dont't optimize at all), use only small | > functions. | | Well. The second part *is* helpful... And this is why it takes lyx two hours to compile on the new stdlib++, 1 hour of that time is lyxfunc... reducing function size will speed up compilation time a lot. Lgb
Re: Compilers, exceptions, code size, etc. [was: Re: Cannot compile Lyx
> of virtual memory. The gcc/egcs faq has very 'helpful' recommendations: > > > Optimize less (or dont't optimize at all), use only small > functions. Well. The second part *is* helpful... Andre' -- André Pönitz . [EMAIL PROTECTED]
