Boost Workshop at OOPSLA 2004

[Hyman Rosen]

I'd compile both the export-using version of the code and the
inclusion-using version of the code with the same compiler. That
way, compiler issues other than export would not come into play.

Yes. Notice that the highest savings from export shoudl occur for
those templates which are instantiated over the same types in many
compilation units. That is, if you have a dozen files which all use
map<string,int>, the export form should only need to instantiate the
template once, and would thus hopefully be faster.

 

[Hyman Rosen]

If DMC++ proves that it is still faster than another compiler using export,
then that demonstrates that export is NOT required for fast compiles. I'd
say that was a very meaningful result.

Well, of course export is not needed for fast compiles.
You can buy yourself a mainframe and your compilation
speed will go way up. (I seem to recall an anecdote from
the old days, when Unix was built on an Amdahl mainframe
it looked like someone was printing the Makefile instead
of running it, because the compiles were so fast.)

Non-export is to templates what inline is to ordinary
functions. It's plausible to believe that not forcing
template implementations to be compiled for every module
which uses them should be faster than forcing them to be
recompiled, but that is with respect to a particular
implementaton of a compiler and system.

 

[Terje Sletteb?]

use the statement:

import foo;

and the entire semantic content of foo.d is available to the compiler,
including whatever template and function bodies are in foo.d. So, is this a
burden the compiler labors under? Not that anyone has noticed, it compiles
code at a far faster rate than a C++ compiler can. I can go into the reasons
why if anyone is interested.

This seems like a strange blanket statement. Yes, I'd like to know why
you think you can assert that no C++ compiler can compile equivalent
code as fast as a D compiler, ever. Thoughts for the context: What if
there are processors or computer architectures that favours one over
the other? Another thought: Optimisations in C++ compilers you may not
have thought of, yet?

Regards,

Terje

 

[Terje Sletteb?]

You know, if the c++ committee had the cojones to make standardisation
over the full translation process, we might even see dynamic linking a
possibility for the next language revision.

First, I don't think this is a nice thing to say about the members of
the C++ standards committee, who work hard, _for free_ - even paying
to contribute, to give us a better language. If that doesn't mean they
have "cojones", I don't know what does.

Secondly, AFAIK, the C++ standard covers the _full_ translation
process - it just doesn't spefify _how_ something like linking is done
in detail. This gives the implementers flexibility.

Thirdly, it appears from the above that you're not familiar with
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1428.html.

Three strikes and you're out...

To conclude: The C++ standards committee _does_ have "cojones" to make
standardisation over the full translation process (from source code,
to executable), and there exists a dynamic linking standards proposal.

Regards,

Terje

 

[Francis Glassborow]

I suppose that's possible, but if so it's the first time I've heard of
it. I have heard (and can easily believe) that both are based on the
EDG front-end, but I've never previously heard of any relationship
beyond that.

No, I think you are right. I keep on mixing up which end is which.

 

[kanze]

Digital Mars has no such layers, and if you surf the DMC newsgroups,
you'll see I talk directly to the engineers who use it.

And Digital Mars isn't on the approved list of suppliers at my customer,
so I can't use it. Probably because you don't have such layers.
(Perhaps the biggest single advantage g++ has is that I don't have to go
through purchasing to get it.)

[...]

I invite you to the DM newsgroups (news.digitalmars.com) and you can
see for yourself what they're asking for <g>.

Which buys me what if you're not on our approved list of suppliers?

You can also surf the microsoft newsgroups, or the borland ones. Given
the sometimes very unkind messages posted there, I doubt any of them
are censored by their respective PR departments. You won't see such
issues here because they are OT for this forum.

They undergo the worse possible censorship. They're ignored by the
deciders. You may be able to get a small improvement in by convincing
the engineers, but you won't get export unless you can convince
purchasing in some of the large accounts to make it an issue.
(Microsoft actually seems better than most big firms here. Perhaps
because individual sales are a larger percentage of their customer base
than, say, at Sun.)

 

[kanze]

(e-mail address removed) (Jerry Coffin) wrote in message

news:<[email protected]>...

[ ... ]

The only input vendors can get from customers is desiderata.
There is hopefully a correlation between desiderata and
needs, but they are not the same things and some times by a
large margin especially in large corporation where usually
there are several layers (sometimes non technical or having
lost contact with state of the art) between the people who
could best express the needs and the one which is in contact
with the providers (each layer introducing some bias).

This really isn't accurate at all

It pretty much corresponds to my experience.

-- quite a few people who work directly on compilers at various
vendors monitor newsgroups extensively. Posts from people at EDG,
Microsoft, Dinkumware, etc. These aren't just non-technical people
either -- quite a few of them are the people who write code for these
companies. Of course, in some of those cases (e.g. EDG and Dinkumware)
the companies are small enough that there ARE hardly any non-technical
people there. Even in the case of Microsoft (about as big as software
companies get) technical people are easy to find on newsgroups. Most
of them tend more toward MS-specific newsgroups, but at least IMO,
that's not a particular surprise.

In the case of EDG, Dinkumware, and probably Digital Mars, I agree with
you. The companies are small, they listen, and the decision-makers are
the people listening (and are technically oriented). In the case of
larger companies, however, the situation is quite different. I know
people on the technical side in both Sun and Microsoft, I can send them
suggestions, and in some cases, they have even asked my opinion
proactively. But... they don't make the final decision, any more than I
make the final decision with regards to the compiler I use.

And I can't say that all of the fault is in the vendors. Why should
they listen to me, since I have very little, if any influence, in
purchasing? The problem is on both sides, but given the way the market
works, the incentive to correctly can really only come from the buyer's
side. As long as purchasing refuses to even consider Como/Dinkumware,
instead of Sun and Microsoft, because they are not on the approved list
of suppliers, Sun and Microsoft have no real motive to implement
features (like export) that Como/Dinkumware has, but they don't. And
they have every real motive to do whatever it takes to be on the
approved list of suppliers -- not being a specialist in corporate
management, I'm not sure what that is, but Sun and Microsoft apparently
do, and do it very well.

In any case, the bottom line is that in quite a few cases compiler
vendors get input directly from customers, and the people who work
directly on the compiler often receive that input _quite_ directly.

And in most cases, it doesn't matter, because the people who work
directly on the compiler have no, or very little, influence on the
priorities. Which is partially normal, because the people providing
them with the technical input don't control which compiler gets
purchased.

 

[tom_usenet]

It first tries to find an operator overload as a member of the left operand.
If there isn't one, it attempts to find a "reverse" operator overload member
of the right operand. This may sound odd at first, and it's a bit more
complex than I just described, but it works out quite nicely and neatly
avoids the need for ADL.

So that's operators covered, but how about non-member functions? There
are lots of idioms in C++ that rely on such things, such as "property
maps". Would it be possible to write something like the Boost graph
library in D? How about this simple example:

template <class T>
T cosSquared(T t)
{
T val = cos(t);
return val * val;
}

//....
std::complex<double> d(1, 2);
d = cosSquared(d);
//or
numerics::ridiculous_number n = ...;
n = cosSquared(n); //can take cosine of ridiculous numbers

Clearly your operator overloading lookup will find operator*, but what
about std::cos(std::complex<T> const&)? Note you can't make cos a
member function, since it has to work for double...

Tom

 

[Walter]

"Walter" <[email protected]> wrote in message

All the programmer does is
This seems like a strange blanket statement. Yes, I'd like to know why
you think you can assert that no C++ compiler can compile equivalent
code as fast as a D compiler, ever.

I'll start by saying that DMC++ is the fastest C++ compiler ever built. I've
spent a lot of time working with a profiler on it, going through everything
in the critical path.

The critical path turns out to be lexing speed. How fast can it deal with
the raw characters in the source file? Unfortunately, the phases of
translation required in C++ means that each character must be dealt with
multiple times. D is designed so that the source characters only need to be
examined once.

The next issue for C++ is the #inclusion model of compilation - each header
file gets read in and lexed over and over again, dealing with comments,
macros, etc. Various techniques try to minimize this, using #ifdef's, but
the source text still has to be passed over multiple times (those phases of
translation again). #pragma once works better, but is non-standard.

On an empirical note, the D compiler (which shares a code optimizer and
generator with DMC++) compiles equivalent source much faster than DMC++, and
I've made no attempt to profile or optimize the lexer in D. My experience
with trying to speed up C++ compilation did go into the design of D - so it
would be easy to build a searing fast compiler. I invite you to take a look
at the D lexer source - it comes with the DMD distribution
www.digitalmars.com/d/dcompiler.html - and see if that could be done with
C++. Compare it with the g++ lexer source.

Thoughts for the context: What if
there are processors or computer architectures that favours one over
the other?
Another thought: Optimisations in C++ compilers you may not
have thought of, yet?

I think that having to visit each character 3 times instead of once is
always going to be slower <g>.

 

[Walter]

I know. They also don't sell to end users, which probably saves them
more in support effort than all of the points you mention.

Still, as I said, the difference in some cases (I wasn't thinking of
Digital Mars) is several magnitudes. Are you trying to tell me that all
of these bits multiply the required effort by a thousand or more?

Which compiler vender has 3000 people working on their compiler? <g> Let's
have some fun with Brand X which has 3000 in their C++ department. That's
3000 times an average cost of $100000 each (salary + benefits + office
space) or a $300,000,000 annual budget just for C++ (and that's very, very
lowball for 3000 engineers). Wow!

Can anyone afford a language that requires such a massive annual investment?

 

[Walter]

And Digital Mars isn't on the approved list of suppliers at my customer,
so I can't use it. Probably because you don't have such layers.
(Perhaps the biggest single advantage g++ has is that I don't have to go
through purchasing to get it.)

You don't have to go through purchasing to get DMC++ either. It's a free
download from www.digitalmars.com/download/freecompiler.html.

Which buys me what if you're not on our approved list of suppliers?

If Digital Mars isn't on your approved list of suppliers, and the ones that
are on your approved list pay no attention to you, what can I say? I'm also
puzzled by Digital Mars not being approved because it doesn't have layers,
yet those layers prevent the vendor from addressing your needs?

They undergo the worse possible censorship. They're ignored by the
deciders. You may be able to get a small improvement in by convincing
the engineers, but you won't get export unless you can convince
purchasing in some of the large accounts to make it an issue.

If you keep buying from Brand X despite them ignoring your requirements,
then are those requirements that important to you? If large accounts don't
find export to be important, how important is it really?
But to be frank, a feature that costs $300,000 to implement needs,
realistically, to be able to generate at least $400,000 in incremental
revenue to make it worthwhile. A feature that costs $5,000 to implement that
would generate incremental revenue of $20,000 is going to get greenlighted
first <g>.

 

[Walter]

So that's operators covered, but how about non-member functions? There
are lots of idioms in C++ that rely on such things, such as "property
maps". Would it be possible to write something like the Boost graph
library in D? How about this simple example:

template <class T>
T cosSquared(T t)
{
T val = cos(t);
return val * val;
}

//....
std::complex<double> d(1, 2);
d = cosSquared(d);
//or
numerics::ridiculous_number n = ...;
n = cosSquared(n); //can take cosine of ridiculous numbers

Clearly your operator overloading lookup will find operator*, but what
about std::cos(std::complex<T> const&)? Note you can't make cos a
member function, since it has to work for double...

No, it won't find cos() unless it is imported into the scope of the
template, because D does not support ADL. There are multiple ways to make
this work, however:

1) pass cos in as an alias template parameter.
2) use partial specialization to have two versions of the template, one for
cos() as a class member and the other using cos() for built-in types
3) import the necessary cos() into the module with the template
4) pass in the appropriate import scope as an alias parameter, call it Foo,
and then:
Foo.cos(t)
For cos(double), you'd pass in std.math as the argument for the Foo alias
parameter.
5) box double within a struct X with a member function cos(), and pass in X
instead of double.

Note that in C++ you still have to #include the relevant cos() definitions
anyway.

 

[Joe Gottman]

Yes. Notice that the highest savings from export shoudl occur for
those templates which are instantiated over the same types in many
compilation units. That is, if you have a dozen files which all use
map<string,int>, the export form should only need to instantiate the
template once, and would thus hopefully be faster.

As I understand member functions of template classes, if a member
function is never called then it is never compiled. For example, this is
why pair<X, Y> can compile successfully when X and Y don't contain default
constructors; as long as you don't invoke pair's default constructor the
fact that it calls nonexistent default constructors for X and Y is
irrelevant. So suppose you have a dozen files that use map<string, int> and
none of them call map::max_size(). If you then create a thirteenth file
that uses map<string, int> and it happens to use the max_size() function on
this class, will the original 12 files need to be recompiled?

Joe Gottman

 

[David Abrahams]

Yes. Notice that the highest savings from export shoudl occur for
those templates which are instantiated over the same types in many
compilation units. That is, if you have a dozen files which all use
map<string,int>, the export form should only need to instantiate the
template once, and would thus hopefully be faster.

Why would that be any faster than link-time instantiation (a model
supported by EDG and therefore Comeau)?

 

[David Abrahams]

I'll start by saying that DMC++ is the fastest C++ compiler ever
built.

That kind of assertion is part of why some people don't trust your
claims. It's meaningless on its face, because what's "fastest"
depends on which programs you try to compile. I also note from
http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html that
you don't seem to have speed testing some significant contenders.
Metrowerks Codewarrior is one of the fastest compilers in some of my
tests. So it's hard to see how you can claim to have the "fastest
C++ compiler ever built."

I've spent a lot of time working with a profiler on it, going
through everything in the critical path.

The critical path turns out to be lexing speed. How fast can it deal
with the raw characters in the source file?

That's commonly the bottleneck in the parsing process of many
languages...

Unfortunately, the phases of translation required in C++ means that
each character must be dealt with multiple times. D is designed so
that the source characters only need to be examined once.

....but if that's your bottleneck, you obviously haven't tested it on
many template metaprograms. Template instantiation speed can be a
real bottleneck in contemporary C++ code. I happen to know that DMC++
can't yet compile a great deal of Boost, so maybe it's no coincidence.
It's easy to be fastest if you don't conform, and you only benchmark
the features you've implemented.

If you'd like, I'll privately forward you the performance appendix of
http://www.boost-consulting.com/tmpbook, which contains some very
simple benchmarks and graphs showing performance for a few other
compilers. Maybe you can use that as a way to think about optimizing
template instantiation.

 

[kanze]

Yes. Notice that the highest savings from export shoudl occur for
those templates which are instantiated over the same types in many
compilation units. That is, if you have a dozen files which all use
map<string,int>, the export form should only need to instantiate the
template once, and would thus hopefully be faster.

And this is probably the most usual case. std::basic_string and the
std::iostream hierarcy are certainly among the most widely used
templates, and how many different types to you instantiate them over in
a given program? Of course, the only time anything should change in
one of them is when I install a new version of the compile, in which
case, I'll do a complete rebuild anyway. But many of my own templates
are similar -- they are widely used, but typically with only one or two
different parameters.

 

[Hyman Rosen]

So suppose you have a dozen files that use map<string, int> and
none of them call map::max_size(). If you then create a thirteenth file
that uses map<string, int> and it happens to use the max_size() function on
this class, will the original 12 files need to be recompiled?

No, what for? If compiling any of those twelve would result in a
max_size() different from the thirteenth then the ODR is violated,
and this does not have to be diagnosed

 

[Nicola Musatti]

Which compiler vender has 3000 people working on their compiler? <g> Let's
have some fun with Brand X which has 3000 in their C++ department. That's
3000 times an average cost of $100000 each (salary + benefits + office
space) or a $300,000,000 annual budget just for C++ (and that's very, very
lowball for 3000 engineers). Wow!

Can anyone afford a language that requires such a massive annual investment?

DOD?

Cheers,
Nicola Musatti

 

[Steven E. Harris]

There are multiple ways to make this work, however:

1) pass cos in as an alias template parameter.
2) use partial specialization to have two versions of the template,
one for cos() as a class member and the other using cos() for
built-in types
3) import the necessary cos() into the module with the template
4) pass in the appropriate import scope as an alias parameter, call
it Foo, and then:
Foo.cos(t)
For cos(double), you'd pass in std.math as the argument for the
Foo alias parameter.
5) box double within a struct X with a member function cos(), and
pass in X instead of double.

Could you post a small code sample that illustrates what these various
solutions look like in D? In particular, I'd like to see proposals 1,
3, and 4.

 

[Hyman Rosen]

Why would that be any faster than link-time instantiation (a model
supported by EDG and therefore Comeau)?

Because you wouldn't have to include the implementation code
into every module that uses it. Why do we have to keep going
around in these circles?