Hi all,

I just received an evaluation of DMC++ and would like
Walter and others to comment, for the benefit of its
author and any others like him.  (Assume the most
recent beta compiler as the reference, since there's
no reason not to.)

The author also skips over the major point that DMC++
is free, a significant virtue.

My impression here is that the author just resurrected
6-year-old, second-hand information rather than doing
his own investigation.  So bring him up to speed!

Thank you,
Mark


Quotes: =======================================================

DMC++ ... doesn't support template template parameters
and its name lookup is quite broken.  I've also heard
about it not supporting Koenig lookup, namespaces are
broken and partial template specialisation doesn't
quite work always.  Lastly, the output from DMC++ is
not very optimised.

If you enable link-time compiling on MSVC7.1, you get
very  substantially optimised code though it breaks
the ABI. Also it can  use the SSE/3dnow unit instead
of the x87 FPU whose design is broken.

MSVC7.1 has known issues with anonymous namespaces,
its incremental  linker is broken as is its
precompiled headers. However, these can  all be worked
around or it just takes longer to compile.

If you know the backchannels into Microsoft, it's easy
to report bugs.

I think it's generally recognised that MSVC7.1 is an
excellent  conforming C++ compiler. Few can fault it.
Also, the MSVC debugger is  outstanding, makes GDB
look really archaic :(

DMC++ has a terrible reputation for speed of output.
This may have changed recently.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:bvmvhv$5bg$1@digitaldaemon.com...
> Hi all,
>
> I just received an evaluation of DMC++ and would like
> Walter and others to comment, for the benefit of its
> author and any others like him.  (Assume the most
> recent beta compiler as the reference, since there's
> no reason not to.)

What do you want to be said? He's clearly wrong on multiple points.

If he thinks VC++ 7.1 is an outright winner in performance terms, he's clearly not done a lot of template work. (see http://www.cuj.com/documents/s=8943/cujexp0312wilson/ for an example; there are many more). That's not to say that VC++ 7.1 does not beat DMC++ on other marks, but the situation is *far* from the picture he paints.

> The author also skips over the major point that DMC++
> is free, a significant virtue.
>
> My impression here is that the author just resurrected
> 6-year-old, second-hand information rather than doing
> his own investigation.  So bring him up to speed!

Maybe he is used to VC++ release cycles, and therefore thinks it's reasonable to make a comparison using a 6-month, or older, version of DMC++.

I'm too tired to be insulting - I finished my book at 3am this morning!! - so I'll just say he's wrong, and he needs to do more research.

Interestingly, in two days time I'll be writing an article on C++ compiler optimisation for Dr Dobb's. If your correspondent, or anyone else, wishes to suggest any benchmarks to be included in my tests, I'm all ears. I'll be conducting tests on Win32-only (since I've only got a few days) and will cover Borland 5.6, CodePlay 2.06, CodeWarrior 8, Comeau 4.3.3, Digital Mars 8.38, GCC 3.2, Intel 8.0, Visual C++ 6.0 & 7.1 and Open Watcom 1.2.

[btw, does your correspondent have a name? If so, why may we not know it?]

Cheers

-- 
Matthew Wilson

Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
    (www.synesis.com.au/articles.html#columns)

-----------------------------------------------------




>
> Thank you,
> Mark
>
>
> Quotes: =======================================================
>
> DMC++ ... doesn't support template template parameters
> and its name lookup is quite broken.  I've also heard
> about it not supporting Koenig lookup, namespaces are
> broken and partial template specialisation doesn't
> quite work always.  Lastly, the output from DMC++ is
> not very optimised.
>
> If you enable link-time compiling on MSVC7.1, you get
> very  substantially optimised code though it breaks
> the ABI. Also it can  use the SSE/3dnow unit instead
> of the x87 FPU whose design is broken.
>
> MSVC7.1 has known issues with anonymous namespaces,
> its incremental  linker is broken as is its
> precompiled headers. However, these can  all be worked
> around or it just takes longer to compile.
>
> If you know the backchannels into Microsoft, it's easy
> to report bugs.
>
> I think it's generally recognised that MSVC7.1 is an
> excellent  conforming C++ compiler. Few can fault it.
> Also, the MSVC debugger is  outstanding, makes GDB
> look really archaic :(
>
> DMC++ has a terrible reputation for speed of output.
> This may have changed recently.
>
>

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in news:bvnf79$17qr$1@digitaldaemon.com:

> Interestingly, in two days time I'll be writing an article on C++ compiler optimisation for Dr Dobb's. If your correspondent, or anyone else, wishes to suggest any benchmarks to be included in my tests, I'm all ears. I'll be conducting tests on Win32-only (since I've only got a few days) and will cover Borland 5.6, CodePlay 2.06, CodeWarrior 8, Comeau 4.3.3, Digital Mars 8.38, GCC 3.2, Intel 8.0, Visual C++ 6.0 & 7.1 and Open Watcom 1.2.

If you want complex benchmark then I would suggest  POV-Ray with its build- in benchmark which presents a lot of floating point operations in raytracing together with a lot of integer calculations for noise. Regarding POV-Ray 3.5 with some modifications I was able to build it with Borland, DMC, GCC and Open Watcom for Win32 console. I have no access to others compilers but I know it was also compiled with CodeWarrior, Intel and VC. I have no idea about quality of building POV-Ray with Comeau and CodePlay. Being involved in POV-Ray/MegaPOV development I would be interested in reading about such benchmarking. Ask for details if needed.

Regards, ABX

> DMC++ ... doesn't support template template parameters

Incorrect.

> and its name lookup is quite broken.

If you've got specific examples that fail, please report them here or to me as bugs.

> I've also heard
> about it not supporting Koenig lookup,

Incorrect.

> namespaces are
> broken

It supports the namespaces as used by the STL, and although I have one bug in the bugbase on namespaces, that hardly qualifies it as broken. If you've got specific examples that fail, please  report them here or to me as bugs.

> and partial template specialisation doesn't
> quite work always.

Actually, it works quite well.

> Lastly, the output from DMC++ is
> not very optimised.

Depends on what is being compiled.

> If you enable link-time compiling on MSVC7.1, you get
> very  substantially optimised code though it breaks
> the ABI. Also it can  use the SSE/3dnow unit instead
> of the x87 FPU whose design is broken.

SSE/3dnow does not support 80 bit long doubles. I know that most of the programming community seems to brush this off as irrelevant, but few who really understand floating point math are so willing to lightly dismiss accurate results. (80 bit arithmetic gives more accurate results *even if* one is only using float or double variables in the source.) I used to write numerical programs to help design airplane parts, and the buildup of roundoff errors was always a menace that needed to be dealt with. 80 bits helps a lot with that, and getting the right answer is far more important than getting a slightly faster one. In my not-so-humble-opinion, the x87 hardware support for 80 bits more than compensates for all its faults w.r.t. its hard-to-optimize internal stack architecture.

> MSVC7.1 has known issues with anonymous namespaces,
> its incremental  linker is broken as is its
> precompiled headers. However, these can  all be worked
> around or it just takes longer to compile.

I.e. VC has bugs just like every other compiler, and like every other compiler, once you get used to them you can easilly avoid them.

> If you know the backchannels into Microsoft, it's easy
> to report bugs.

You can report bugs to Digital Mars through the front door <g>.

> I think it's generally recognised that MSVC7.1 is an excellent  conforming C++ compiler. Few can fault it.

Being a C++ vendor, my view is obviously biased, so I won't waste anyone's time posting it <g>. But I will say that different compilers have different 'styles' in how they work, and different styles appeal to different programmers. For example, some programmers need 80 bit long doubles. Some really like the very fast compile times of DMC++, or the better support of DMC for C90 features like complex numbers.

> Also, the MSVC debugger is  outstanding, makes GDB
> look really archaic :(

Not really relevant, since a debugger isn't part of the compiler, and DMC++ doesn't ship with GDB either.

> DMC++ has a terrible reputation for speed of output.
> This may have changed recently.

Every compiler has its own style of generating code. Once you get familiar with it, one winds up unconsciously writing code in a style that the compiler handles well. Such styles tend to do less well when used with another compiler. And vice versa.

"W³odzimierz Skiba" <abx@abx.art.pl> wrote in message news:bvnk0a$1jf6$1@digitaldaemon.com...
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in news:bvnf79$17qr$1@digitaldaemon.com:
>
> > Interestingly, in two days time I'll be writing an article on C++ compiler optimisation for Dr Dobb's. If your correspondent, or anyone else, wishes to suggest any benchmarks to be included in my tests, I'm all ears. I'll be conducting tests on Win32-only (since I've only got a few days) and will cover Borland 5.6, CodePlay 2.06, CodeWarrior 8, Comeau 4.3.3, Digital Mars 8.38, GCC 3.2, Intel 8.0, Visual C++ 6.0 & 7.1 and Open Watcom 1.2.
>
> If you want complex benchmark then I would suggest  POV-Ray with its
build-
> in benchmark which presents a lot of floating point operations in raytracing together with a lot of integer calculations for noise. Regarding POV-Ray 3.5 with some modifications I was able to build it with Borland, DMC, GCC and Open Watcom for Win32 console. I have no access to others compilers but I know it was also compiled with CodeWarrior, Intel and VC. I have no idea about quality of building POV-Ray with Comeau and CodePlay. Being involved in POV-Ray/MegaPOV development I would be interested in reading about such benchmarking. Ask for details if needed.

Please. Give me a url, where I can download the testsuite.

> Regards, ABX

Cheers

Matthew

>[btw, does your correspondent have a name? If so, why may we not know it?]

I have given him the URL to this newsgroup.  If he wishes to participate, he will.  I expect he will at least read this thread.

I did not want to embarass him because I knew how wrong he was. Much more could be said about object code performance, in particular.

The floating-point benchmark article will be of great interest.

One reason for this post is that some big names in C++ still suffer serious delusions about DMC++, and their opinions seem to cause a trickle-down effect.

Walter, maybe some more FAQs about this stuff?  A "speed FAQ"? A "template FAQ"?  A "namespace FAQ"?

Mark

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:bvotj2$snn$1@digitaldaemon.com...
> One reason for this post is that some big names in C++ still suffer serious delusions about DMC++, and their opinions seem to cause a trickle-down effect.

We're definitely the underdog <g>.


> Walter, maybe some more FAQs about this stuff?  A "speed FAQ"? A "template FAQ"?  A "namespace FAQ"?

I'm planning on doing a chart cross referencing the C++ standard and what features DMC++ does right.

>I'm planning on doing a chart cross referencing the C++ standard and what features DMC++ does right.

That is a good idea, just keep it current.  I have always liked Christof's chart at http://cmeerw.org/prog/freecpp/ although it references version 8.37.7 while the most recent beta is DMC++ 8.39.3.  Still, a nice chart, complete with code snippets; a good example to follow.

Maybe two columns, one for the last "official" release and one for the "current beta," which is what I always use anyway.

Here is another idea.  How about a frequency chart showing the
steady release cycle of DMC++ and number of technical support questions
answered!  You're the king Walter.

Mark

>[btw, does your correspondent have a name? If so, why may we not know it?] Matthew Wilson

With permission:

Niall Douglas
s_sourceforge <a t>  nedprod <d o t> com
http://www.nedprod.com/TnFOX/

> >[btw, does your correspondent have a name? If so, why may we not know
it?]
> >Matthew Wilson
>
> With permission:
>
> Niall Douglas
> s_sourceforge <a t>  nedprod <d o t> com
> http://www.nedprod.com/TnFOX/

Hi Niall

Well met!

Don't worry about the misunderstanding wrt DMC++. My October DDJ article contained far too many failure-in-researchs for anyone's good. That's one of the motivating factors for the article I'm working on now, which will be going in May's DDJ.

Cheers


-- 
Matthew Wilson

Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
    (www.synesis.com.au/articles.html#columns)
-----------------------------------------------------