Digital Mars - c++ - Dispel evil rumors about DMC++

↑ ↓ ← → Mark Evans <Mark_member pathlink.com> writes:

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.

Feb 02 2004

↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:

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

Feb 02 2004

↑ ↓ ← → "W�odzimierz Skiba" <abx abx.art.pl> writes:

"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

Feb 02 2004

↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:

"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


 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

Feb 03 2004

↑ ↓ ← → Mark Evans <Mark_member pathlink.com> writes:

[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

Feb 03 2004

↑ ↓ ← → Mark Evans <Mark_member pathlink.com> writes:

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

Feb 03 2004

↑ ↓ ← → "Phill" <phill pacific.net.au> writes:

"Walter" <walter digitalmars.com> wrote in message
news:bvp2p1$15pt$1 digitaldaemon.com...
 "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>.


Maybe they try to knock DMC++  down because the
price is so low, it is a threat to their sales.
I dont believe that there would be too many novices
out there with the big name compilers(not legal copyies
anyway). They are just way over priced, and out of reach
to the average person.
I dont see any benefit gained by spending the extra
hundreds(or is it thousands in some cases?)of dollars on them.

There is much better support here also, when you need it.


From a novice

Feb 03 2004

↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:

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




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

Feb 03 2004

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

 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.

Feb 03 2004