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

[David Allouche]

On Sun, Sep 08, 2002 at 11:26:10PM +0200, Joris van der Hoeven wrote:
> 
> > No I did not try to debug. But the fact is that the code is stable
> > without your allocation stuff and not without. I agree that does not
> > necessarily mean that the real problem is there.
> 
> What I can do is put the allocation stuff in a base class common
> to all TeXmacs data structures. It might be that certain programs
> have a problem with my global allocater.

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.

Generally, C++ loves locality: namespaces, member functions, etc...
I think that TeXmacs relies too much on the global namespace. That can
cause very subtle problems like, for one thing, breaking the one
definition rule, and for another thing, having different contexts for
overload resolution at the point of definition and at the point of
instanciation for templates.

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 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.

Anyway that might prove effective at least in helping to track
reference cycles...


> > My focus is on getting the Qt loop in and I noticed that removing your
> > allocation code solves the problem of immediate crash in that case.
> > And it appears that by the same removal TeXmacs seems more stable on
> > Mandrake cooker rc1 platform. It seems that with g++ the standard
> > allocation scheme is fast enough.
> 
> 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.

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.

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.


> > 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.

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.
 
> > 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...

You know that programmers can abuse a language. Different languages
promote different idioms. For example, Scheme tends to promote
functional programming and heap based memory allocation. Pascal tends
to promote stack based allocation, and procedural programming with
pass-by value semantics. C tends to promote procedural programming
with pass by reference (pointers) semantics.

Programming in real X (where X is any chosen language) is using the
language X with the idioms the language was designed to best support,
and which most programmers use. Using these idioms not only make the
code more accessible by most programmers, but it also reduce the
likeliness to run into rare bugs in the compiler and standard
libraries. And it helps to avoid weaknesses of the language.

I believe what Steph meant is that the idioms used in TeXmacs are not
really C++ idioms, and that he sees it as a problem.

However, I agree that it is not good to undertake major, non-localized
changes to the style of existing code, which suits best the most
active contributor, which you are.

But only as long as the current idiom is not obviously a deterrent to
new contributors (e.g. gencc templates) and does not cause integration
problems with other, useful, tools (e.g. namespaces, bool and global
allocators for Qt).


> > Sorry for this diversion, but I think we need to think and agree about
> > it. I think that david has already talked about that but I don't
> > remember exactly what.
> 
> Yes, he also wants to change everything, but I am getting tired of
> these discussions and there are many other important and urgent issues.
> Also, I certainly do not like ugly code and this is what const'ed code is 
> like.
> I tend to use few comments in my code, but this is counterbalanced by
> a certain notational elegance and coherence. I do not want to change this.

That is your point.

I will still try to push some deep changes (like replacing the
reference conting system) but only as long as they do not cause
performance loss (better if they improve performance) and only in
a breadcrumb-trail fashion.

I agree that code your maintain must fit best in you personal style.
After all, as long as you are the best person to fix problems in some
code it is a requirement that its style pleases you.


> > But this does not concern X libraries because they are C libraries.
> 
> Are you sure? And similarly for Guile?
> 
> 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?

I think none of us is a C++ compiler guru, but I tend to concur with
Steph. Incompatible changes in a C++ compiler's ABI are only related
to "intelligent" features of C++, like polymorphism, RTTI and
exceptions.

C++ object files must use the same ABI to allow functions with C++
linkage to interoperate properly. However, the C linkage is quite
dumb, so functions with C linkage (even if they use C++ behind the
scenes) could be expected to interoperate properly regardless of C++
ABI incompatibilities.

Yet, there seems to be a significant distinction between linking
object files (*.o) from different compilers and linking libraries.
That is quite understandable for shared libraries (*.so) since
run-time linking is done by tools independent from the compiler, but
that may seem a bit surprising for static libraries (*.a) since,
AFAIK, these are only *.o's in a package...


Not trying to flame, just contributing my two cents to the
conversation of ideas.

-- 
_.      _    .   GNU TeXmacs -- Writing is a pleasure.
 |\     |    |\       Home page -- http://www.texmacs.org
 | \ ,-.|,--.| \      Resources -- http://alqua.com/tmresources
 |  \|  |,-+||--\            TeXmacs is NOT a LaTeX front-end
-+--'`- \`-'\-   -           and is unrelated to emacs.