Re: [Texmacs-dev] [Announce] nogencc-0.6

[David Allouche]

I just read your last answer before posting the announce for nogencc-0.7.
So sorry if it is inconsistent.

On Sunday 05 May 2002 18:22, Joris van der Hoeven wrote:
> On Sun, 5 May 2002, David Allouche wrote:
> > > >   operator-> defined in basic.h are now const-correct.
> > >
> > > Please let us deal with the const problem after the change.
> >
> > Again, this only affect code I have rewritten anyway. I really do not
> > see the point in postponing that particular change.
>
> Please do not put any const's in the code yet.
> I want to postpone *all* changes which do not *directly*
> have to do with removing gencc. When making profound changes,
> one has to be patient and rigourous. I do not want to repeat
> this hundred times. In any case, you can make a backup of
> what you have done and make the change later.

If you really want, I will do it, anyway that is only a small change to 
do. But really, I think you are pushing incrementality a bit too far.

> > In future releases, I will include a script which renames all
> > files back the original name, so diff would not be confused.
>
> Yes, please do so. And maybe a script for the opposite direction too.

I will do the script for the opposite transform.

> > In that case, it may even be useful to compile
> > everything in one big monster compilation unit to get the best out of
> > the optimizer.
>
> We would have to check this last point.

Roger. Look for nogencc-0.8.

> > I will not disable automatic template instanciation. Once the
> > .rpo files have been generated, that cause no increase in compilation
> > time. Actually, it even decrease compilation time since only needed
> > template methods are instanciated. And the .rpo files can be
> > generated rather quickly by using a first pass of non-optimizing
> > compilation, and they could even be included in the distribution,
> > since they are platform independant and compatible across versions of
> > g++2.
>
> Yes, but it may also affect the runtime performance and
> the size of the executable. Please test these issues.

Unless you provide your benchmarking tools, I cannot test runtime 
performance reliably. About the size of the executable, it will not be 
affected. Anyway, compiling C++ without automatic templates is a pain and 
I am not willing to go through this.

> > My reimplementation of reference counting, resources and events used
> > a lot of useless indirections. That had probably no impact on
> > generated code since that used only one-line inline methods, but it
> > did have a mesurable impact on compilation time.
>
> I do *not* want you to reimplement reference counting yet.
> Again, such changes have to be postponed after removing gencc.

Sorry, That was the first thing I did. The new implementation provides a 
much better encapsulation. Especially with abstract classes, the derived 
pointer class no longer have the responsability of incrementing the 
reference count in constructors. That design was bad, very error prone...

Moreover, the new implementation allows for better containers which would 
share implementations for a given type of counted pointer. That would 
reduce the size of the code and even probably reduce compilation times.

Since you obviously have strong opinions against that, I will remove the 
new reference conting just before you integrate the nogencc change. 

Removing that change will not be very easy, and then, the new 
implementation will be much harder to maintain. At the moment, the new 
refcounting is implemented with code in several hand-rewritten files, and 
in the conversion filter.  I do not want the new implementation to lag 
behind, so I am keeping it in a living body of code.

When I will rip it off for inclusion of nogencc in the mainline, I will 
create a new branch just for the new refcounting implementation. Since I 
do not want to maintain several branches, I will probably base my new 
developments on that branch.

Making a backup of a part of code is useless. Code on which one work is 
living. When you cut a part away, you generally cannot expect to be able 
to merge it back in a few weeks. Changes you ask me to remove are twice a 
waste of time for me because I have to throw them away. If I just make a 
backup, when time to put it has come, I will realize half a dozen 
modifications had been done on the master, so the backup will be 
basically useless. Actually it will just be error prone because what was 
appropriate in the old code may be wrong in the new code.

> > > You probably did not remove the Emacs comments in the right way
> > > at the end of the files.
> >
> > I will have a look. Weirdly, I have no such error here.
>
> Yes, but that is precisely one illustration why changes like removing
> gencc are dangerous: it affects the stability of the system
> in a different way on each platform.

That is fixed now. Really, I am not conviced yet, a warning about missing 
newline is not what I call a stability problem.

I do not say there are not still bugs around, but, damn! experimental 
versions are here to break things, and to get feedback to find breakage 
faster.

> >        version \ optim  | none        medium      high
> > ------------------------+--------------------------------------------
> > TeXmacs-1.0.0.1         | 1m55.820s   13m7.290s   12m47.790s
> > nogencc-0.6 (SEPARATE)  | 3m22.500s   13m54.550s  13m59.570s
> > nogencc-0.6 (AGGREGATE) | 1m41.090s   13m52.910s  14m10.760s
> >
> I obtained quite different timings: 35m for nogencc-0.6 and
> 14m for the official distribution (using gcc 2.96 on a 1GHz laptop).

Weird... I got those timing on a PIII 700 with 384 megs of RAM.
Could someone help us explain that?

By the way, I could not find any gcc-2.96 on GNU's website. I guess you 
are using the infamous and notoriously broken RedHat compiler...

> > I am currently working on a version which actually compiles faster
> > than the official one in all cases but unoptimized separate
> > compilation.
>
> That is cool, but please don't cheat by modifying the source code:
> as you understand by now, this should be done after removing gencc.

All changes were made in Basic/Types/basic.hh, 
Window/Event/event_codes.hh and Resource/resource.hh. Only parts I had 
rewritten anyway. No cheating. Just removal of needless indirections.
-- 

                                  -- David --