OpenWatcom vs. Digital Mars C/C++ compilers/IDEs

[p***@free.fr]

Hello,

has anyone on this list used both the OpenWatcom and Digital Mars C/C+
+ compilers and IDE?

If so, what would you say are each compiler's/IDE's advantages and
disadvantages?

Thanks.

phiroc

[Mat Nieuwenhoven]

Post by p***@free.fr
Hello,
has anyone on this list used both the OpenWatcom and Digital Mars C/C+
+ compilers and IDE?
If so, what would you say are each compiler's/IDE's advantages and
disadvantages?

For C++ features, see http://cmeerw.org/prog/freecpp/ .
OW is fully cross-compiler/multiplatform, I don't know if that is an issue
for you.
Digital Mars I have no experience with .

Mat Nieuwenhoven

[Peter C. Chapin]

Post by p***@free.fr
If so, what would you say are each compiler's/IDE's advantages and
disadvantages?

I've heard it said that OW has a better code generator in that it tends
to produce faster executables. However, you'll definitely want to
investigate this with your own code before believing it.

Peter

[chris elliott]

The times to build are at
http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html

Note that build time is not the only criterion; i really like the watcom
debugger, (turbo explorer's debugger is also very nice, but likes
Borland's VCL library more than conventional programs).

chris

Post by Peter C. Chapin

Post by p***@free.fr
If so, what would you say are each compiler's/IDE's advantages and
disadvantages?

I've heard it said that OW has a better code generator in that it tends
to produce faster executables. However, you'll definitely want to
investigate this with your own code before believing it.
Peter

[Michal Necasek]

Post by chris elliott
The times to build are at
http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html

I am wondering if the results are entirely apples to apples
comparisons. Were the builds configured in an identical way, ie. with
the exact same set of features?

The executables almost certainly use dynamic libs in some cases and
static in others. That likely skews the size comparison somewhat.

The run-time values for Open Watcom are also a bit suspect. There's
just no way OW generates 5x slower code than Borland, although there's
of course a possibility that the test case somehow provoked bad
behaviour on OW's part.



Michal

[Cesar Rabak]

Post by Michal Necasek

Post by chris elliott
The times to build are at
http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html

I am wondering if the results are entirely apples to apples
comparisons. Were the builds configured in an identical way, ie. with
the exact same set of features?

Chris account (IIUC) is that it used defaults for the compilers (my
humble interpretation of "Default builds").

Post by Michal Necasek
The executables almost certainly use dynamic libs in some cases and
static in others. That likely skews the size comparison somewhat.

Yes.

Post by Michal Necasek
The run-time values for Open Watcom are also a bit suspect. There's
just no way OW generates 5x slower code than Borland, although there's
of course a possibility that the test case somehow provoked bad
behaviour on OW's part.

I would add that for an almost three years old study, it is interesting
to take all figures with a grain of salt, specially for the compilers
that still are being activelly developed.

--
Cesar Rabak

[chris elliott]

Sorry not to get around to replying yesterday,

All the default builds include debugging information, and no
optimisations. Except for gcc, precompiled headers were used (no wonder
it was slower). All the libraries were built statically.

My impression is that since I did the survey, the wxWidgets library has
grown larger (mode code) and compile times for Borland 5.5. and Micrsoft
vc6 compiler have increased.

Compile times for the newer Borland and Microsoft compilers are longer,
but I have no precise data. gcc is a lot faster as it has precompiled
headers, but still by far the slowest. Watcom 1.6 seems faster than 1.1
(maybe taking half the time), but still not as fast as
Borland/Microsft/Digital mars

I was really surprised that Watcom's compiler did the string scanning
task more slowly than any other, and have no real explanation for this

chris

Post by Michal Necasek

Post by chris elliott
The times to build are at
http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html

I am wondering if the results are entirely apples to apples
comparisons. Were the builds configured in an identical way, ie. with
the exact same set of features?
The executables almost certainly use dynamic libs in some cases and
static in others. That likely skews the size comparison somewhat.
The run-time values for Open Watcom are also a bit suspect. There's
just no way OW generates 5x slower code than Borland, although there's
of course a possibility that the test case somehow provoked bad
behaviour on OW's part.
Michal

[Michal Necasek]

Post by chris elliott
All the default builds include debugging information, and no
optimisations. Except for gcc, precompiled headers were used (no wonder
it was slower).

What I was wondering about was if the default wxWidgets configuration
for each compiler is identical. That is, were all the compilers building
the exact same code?

Post by chris elliott
All the libraries were built statically.

The wxWidgets libs, sure, but not the compilers' C/C++ runtime libs
(that is, not in all cases). The library sizes on disk will be
comparable, but executable sizes not quite.

Post by chris elliott
I was really surprised that Watcom's compiler did the string scanning
task more slowly than any other, and have no real explanation for this

I'm sure there is an explanation :) I just don't know what it is.


Michal

[chris elliott]

Post by Michal Necasek

Post by chris elliott
All the default builds include debugging information, and no
optimisations. Except for gcc, precompiled headers were used (no
wonder it was slower).

What I was wondering about was if the default wxWidgets configuration
for each compiler is identical. That is, were all the compilers building
the exact same code?

No, the wxWidgets code is littered with #ifdefs especially where
templates are concerned.

chris

[Michal Necasek]

Post by chris elliott
I was really surprised that Watcom's compiler did the string scanning
task more slowly than any other, and have no real explanation for this

How *exactly* did you arrive at the numbers anyway? I can't see any
explanation on the webpage detailing how to reproduce the timings.


Michal

[chris elliott]

Post by Michal Necasek

Post by chris elliott
I was really surprised that Watcom's compiler did the string scanning
task more slowly than any other, and have no real explanation for this

How *exactly* did you arrive at the numbers anyway? I can't see any
explanation on the webpage detailing how to reproduce the timings.
Michal

wxHatch is an IDE to develop wxWidgets programs across Windows, Linux,
BSD, etc. It loads the source code from disk into memory. When you
choose Windows|view class tree it searches through all the open files
for class definitions etc and builds a list of all the classes and their
methods. It uses wxWidgets strings to do this task. Under windows, it
uses the tickcounter to time the operation, and puts the time in the
status bar at the end of the process.

in this case, wxHatch loaded its own source and was the only program
"running"

chris

[Michal Necasek]

Post by chris elliott
wxHatch is an IDE to develop wxWidgets programs across Windows, Linux,
BSD, etc. It loads the source code from disk into memory. When you
choose Windows|view class tree it searches through all the open files
for class definitions etc and builds a list of all the classes and their
methods. It uses wxWidgets strings to do this task. Under windows, it
uses the tickcounter to time the operation, and puts the time in the
status bar at the end of the process.

Thanks.

It looks like there's going to be a big difference depending on
whether STL string support is used or not. The wxWindows string code
that I briefly stepped through appears to be horrendously inefficient.

For instance, the wxHatch code likes to call wxString::Replace() to
strip spaces (replacing spaces with empty strings). Now
wxStringBase::replace() is implemented such that wxStringBase::append()
is going to be called for every single character of the source string
except for the space being deleted. This append function calls another
two functions at least, and uses a loop to copy the - in this case -
single character.

In the replace function source code there is a comment about string
copy functions being unsuitable due to the possibility of null
characters in the source string. Makes me wonder if the author ever
heard of memcpy()...

How many of the compilers in your test used STL? If some did and some
didn't, that could skew the results considerably.


Michal