Re: [Texmacs-dev] Mandrake (and thought about typing and ref counting)

[Joris van der Hoeven]

> I think that is indeed the best short term solution. Overriding the
> global allocator seems to me exactly the kind of things that can cause
> dormant bugs in other packages to show up.

Absolutely; I will change this as soon as I have time.

> Generally, C++ loves locality: namespaces, member functions, etc...
> I think that TeXmacs relies too much on the global namespace.

Right again. During the reorganization, I plan to put virtually all
global variables into a few dedicated classes.

> In the longer term I think there are very good ideas in Alexandrescu
> allocator to help improve TeXmacs allocator. For example, index
> caching may dramatically improve performance on batch
> allocations/deallocation by reducing CPU cache faults. See "Modern C++
> Design" for the specifics.

I don't know. I should have a look, but memory allocation and garbage
collection is a complicated topic and there are many available approaches.
Our current approach should be reasonably good, because we mainly allocate
objects of small sizes.

> > I also want to try with Hans Boehme's gc program once,
> > but this is bound to induce other problems on certain architectures
> > (especially in combination with shared libraries and with threads
> > (in the future)).
> 
> That may be nice, but one has to remember that garbage collection can
> cause non-predictible time performance. Garbage collection might
> impact the user experience by making the program less responsive.

Yes, but you can launch the gc only after a few seconds of non-response.
In general, garbage collection does not take so much time and
it efficiency increases as the data are already more or less OK.

> > Fast enough is not good enough. If we loose 10% that is a lot and
> > this is independent from using const's or not (which should also yield
> > an increase in efficiency for the current allocation system).
> 
> It would be nice if someone could dig up some specifics about that
> built-in allocactor.

I already did this at the time that I wrote my own allocater,
which, I repeat, should be much more (space & time) efficient for
the allocation of small objects.

> Built-in allocators are often based on the libc malloc (according to
> Alexandrescu), which is very time effective but whose space usage is
> optimized for C-style allocation (few big chunks) and thus is very
> space inefficient when used to allocate lots of small blocks.

No, it is *not* time effective for small objects
(at least when I looked at it).

> Anyway, unless someone find out some way to benchmark memory
> allocation in-situ (that is inside a running TeXmacs) we will lack any
> evidence required to promote radical changes.

Yes.

> > > If performance is your concern (which must be the case because you get
> > > out of you way to write allocation code), you can win big by 1/
> > > passing stuff by const references when we can; 2/ also removing
> > > reference counting would be good except if there is a strong
> > > motivation for it (Guile).
> > 
> > If one removes reference counting, then copying becomes very expensive.
> > This is certainly a bad strategy. I don't like consts either (dirty code),
> > but I would accept them in the most basic data structures.
> 
> I seems to me that you mistakenly keep on focusing on const...
> 
> Our point (steph's and I) here is that reference conting must not be
> abused, and especially that passing by value of counted pointers is
> horrendous. What is importand is PASSING CONTED POINTERS BY REFERENCE.

Yes, but putting const's everywhere in the code makes the code less readable.
I am very much attached to high readability, which does not withstand that
I understand your technical arguments.

> We promote passing by const reference because it preserves the pass by
> value semantics from the client code point of view. However the
> performance gains come from passing by reference, not from
> const-qualification.
> 
> Using const-qualification in order to provide more semantically rich
> source code is another issue. It is much deeper that just passing
> some parameters as const-references, and may require the use of
> several new C++ idioms.

Yes, and I want to delay this.

Before new radical changes, I propose that we first port TeXmacs
to a maximal number of systems and/or compilers. This will give us
a better understanding of what changes may be good and which changes
are too hacky. Also, I repeat that readability is a major issue;
changes which have a small technical advantage, but which make
the entire code essentially less readable should be discarded.

But *please* let us close this topic for a while.
We have done your nogencc change and applied Stéphane's bool patch.
Now it is time for some other stuff. So let us resume this discussion
after having ported TeXmacs to Windows and some other systems.

> > > I understand that for esthetic reasons one does not want to
> > > sprinkle code declaration with consts and non alphabetic chars but I
> > > am less and less sure this style is real C++.
> > 
> > Real C++ is what programmers do with C++.
> 
> Well... that might get us in yet another flame...

OK, so let us end it right now.

> > So is it sufficient for me to recompile gcc 3.2 and TeXmacs using gcc 3.2
> > in order to get a working version (modulo the bugs which were mentioned)?
> > Can it be that the bugs are precisely due to the fact that some libraries
> > were not recompiled using gcc 3.2?

In fact, the bug was due to the fact that I compiled with -ggdb,
which needs recompilation of some standard libraries with gcc 3.2.
After normal compilation, I managed to get TeXmacs working with gcc 3.2
and I did not experience any of the segfaults which have been mentioned.
So maybe that the persons who did experience them did not recompile or
reinstall gcc 3.2 in the right way.

Yours, Joris