Experiences with HP aC++ or Sun Studio C++?

M

mlimber

I'm considering different platforms and compilers for a project.
Anyone have experience (positive or negative) with HP aC++ on HP-UX?
It seems fairly standard compliant since it supports Boost 1.34, but
I'd like to hear from you all. Same question for Sun Studio's C++
compiler on Solaris.

I gather from http://hpux.cs.utah.edu/hppd/answers/4-4.html that
running g++ on HP-UX is not particularly efficient, but apparently g++
on Solaris works reasonably well (at least version 3.x that comes with
it) .

Any experiences related to standard conformance or efficiency that you
could share would be helpful. TIA.

Cheers! --M
 
I

Ian Collins

mlimber said:
I'm considering different platforms and compilers for a project.
Anyone have experience (positive or negative) with HP aC++ on HP-UX?
It seems fairly standard compliant since it supports Boost 1.34, but
I'd like to hear from you all. Same question for Sun Studio's C++
compiler on Solaris.
It looks like you are putting the card before the horse. If both
platforms have both gcc and mutually exclusive native compilers, surely
the choice is one of which platform rather than which compiler?
 
D

Daniel Pitts

Ian said:
It looks like you are putting the card before the horse.
Sorry to be so pedantic, but I think the expression is "putting the cart
before the horse", as in a horse-drawn cart.
 
M

mlimber

It looks like you are putting the card before the horse. If both
platforms have both gcc and mutually exclusive native compilers, surely
the choice is one of which platform rather than which compiler?

As I see it, the questions are interrelated. We must evaluate the
quality of development tools as an integral part of the platform as a
whole and use that information to help determine which platform is
most suitable.

Moreover, we have some existing gcc code that may be ported over, and
while I don't mind changing code to make it more standard compliant,
I'd like to avoid making it less compliant (and thus less portable)
just to work around a native compiler's idiosyncrasies.

Cheers! --M
 
M

mlimber

mlimber said:
[..]
As I see it, the questions are interrelated. We must evaluate the
quality of development tools as an integral part of the platform as a
whole and use that information to help determine which platform is
most suitable.
[..]

Not really an answer, but you should consider asking in the newsgroups
dedicated to the platforms you're looking at. I bet the folks there
have already compared the compilers available.

Will do. I was asking here (and would still appreciate answers)
because the denizens of this group are typically more attuned to
standard conformance.

Cheers! --M
 
M

mlimber

Regarding Standard conformance, if one of your goals (even in long term)
might be switching to another platform or using a different compiler,
then you will most likely be forced to use some kind of common standard
denominator instead of using as much of the standard as your current
compiler allows. It's not necessarily a good policy if you're always
using the same compiler, but who of us can claim that they never had to
change the compiler in their lives (considering they use C++ for more
than a couple of years)?

Sure, but C++98 is pretty well supported these days, excluding
"export" of course. If HP and Sun's compilers are keeping up on their
compliance (I'm looking for experience here, not their product
marketing), then the common denominator is set at a good and well-
defined level for the future. (I'd rather have good *and* well-
defined, rather than just one of them.) We're not going to be using
much template metaprogramming voodoo, but there are plenty of other
areas where compilers might annoyingly fail to conform.

Cheers! --M
 
I

Ian Collins

mlimber said:
As I see it, the questions are interrelated. We must evaluate the
quality of development tools as an integral part of the platform as a
whole and use that information to help determine which platform is
most suitable.

Moreover, we have some existing gcc code that may be ported over, and
while I don't mind changing code to make it more standard compliant,
I'd like to avoid making it less compliant (and thus less portable)
just to work around a native compiler's idiosyncrasies.
Well I can only comment on the Solaris tools, CC and gcc. If you strive
for standards compliance, build your code with both. The tools supplied
with Sun Studio are a step ahead of the GNU tools and the compiler tends
to generate faster executables. The OS provides a host of performance
tuning tools.

If you want maximum portability, check with more than one compiler.
 
S

sebor

I'm considering different platforms and compilers for a project.
Anyone have experience (positive or negative) with HP aC++ on HP-UX?
It seems fairly standard compliant since it supports Boost 1.34, but
I'd like to hear from you all. Same question for Sun Studio's C++
compiler on Solaris.

I gather fromhttp://hpux.cs.utah.edu/hppd/answers/4-4.htmlthat
running g++ on HP-UX is not particularly efficient, but apparently g++
on Solaris works reasonably well (at least version 3.x that comes with
it) .

Any experiences related to standard conformance or efficiency that you
could share would be helpful. TIA.

HP aCC 6 is based on the EDG front end which is widely regarded
as one of the most conforming, if not the most conforming, C++
compilers out there. aCC 6 also comes integrated with HP cadvise,
a static analysis tool that detects things like null pointer
dereferences and potential memory leaks at compile time. The
compiler is available for HP-UX on IPF hardware only. If you're
targeting PA-RISC, aCC 3 isn't quite as good (on PA, cadvise is
available as a standalone tool).

As far as efficiency of the generated code goes, here's the
output of Stepanov and Stroustrup's Standard Container Benchmark
(http://www.stepanovpapers.com/container_benchmark.cpp) compiled
with aCC 6.10 and gcc 3.4.3 on HP-UX 11.23/IPF (1.4GHz Itanium
II CPU in 32-bit mode). To eliminate the differences between
the implementations of the C++ Standard Library I used Apache
C++ Standard Library 4.2.1 with both compilers.


HP aCC 6.10 (-O):
size array ptrvec itervec deque list set multiset
10 1.11 1.35 1.34 3.79 3.76 2.41 3.24
100 0.47 0.50 0.50 1.38 1.92 1.07 1.62
1000 0.45 0.48 0.47 1.25 1.56 0.82 1.17
10000 0.45 0.47 0.47 1.23 1.63 0.78 1.09
100000 0.50 0.51 0.51 1.41 3.65 1.29 2.36
1000000 0.56 0.58 0.58 1.51 7.08 3.60 4.62

real 1m6.370s
user 1m5.920s
sys 0m0.130s

gcc 3.4.3 (-O2):
size array ptrvec itervec deque list set multiset
10 1.55 1.71 1.69 4.66 5.23 2.78 3.62
100 0.72 0.74 0.73 1.70 2.79 1.23 1.80
1000 0.64 0.65 0.64 1.53 2.27 0.93 1.28
10000 0.62 0.61 0.62 1.47 2.28 0.86 1.20
100000 0.69 0.68 0.69 1.62 4.05 1.33 2.40
1000000 0.74 0.75 0.74 1.68 7.19 3.72 4.96

real 1m19.960s
user 1m18.960s
sys 0m0.110s
 
J

James Kanze

Well I can only comment on the Solaris tools, CC and gcc. If
you strive for standards compliance, build your code with
both. The tools supplied with Sun Studio are a step ahead of
the GNU tools and the compiler tends to generate faster
executables. The OS provides a host of performance tuning
tools.

I've not experience with anything later than SunStudio 11, but
with that, while the compiler is fairly good (although not quite
as good as g++), both of the libraries available with it are, to
put it mildly, junk, with any number of serious errors which
need work arounds.
If you want maximum portability, check with more than one
compiler.

Or use the same compiler everywhere:). The simplest way to
achieve portability is just to standardize on g++. As far as I
can tell (and I've a fair amount of experience in the question),
this has no real disadvantages for Unix platforms: the native
compilers will typically optimize a bit better, but most
applications don't need that extra performance. As for the
tools, vim or emacs and GNU make are the same for both as well
(and GNU make ensures a more or less portable build environment
as well---writing portable makefiles is more difficult than
writing portable C++).
 
M

mlimber

I've not experience with anything later than SunStudio 11, but
with that, while the compiler is fairly good (although not quite
as good as g++), both of the libraries available with it are, to
put it mildly, junk, with any number of serious errors which
need work arounds.

Thanks for the reply (to you and all). I presume you mean the standard
C and C++ libraries. Can you elaborate with an example or two? Is
there free alternative that is better? What do you use instead?

Cheers! --M
 
I

Ian Collins

James said:
I've not experience with anything later than SunStudio 11, but
with that, while the compiler is fairly good (although not quite
as good as g++), both of the libraries available with it are, to
put it mildly, junk, with any number of serious errors which
need work arounds.
I don't consider STLport to be junk.
Or use the same compiler everywhere:). The simplest way to
achieve portability is just to standardize on g++. As far as I
can tell (and I've a fair amount of experience in the question),
this has no real disadvantages for Unix platforms: the native
compilers will typically optimize a bit better, but most
applications don't need that extra performance. As for the
tools, vim or emacs and GNU make are the same for both as well
(and GNU make ensures a more or less portable build environment
as well---writing portable makefiles is more difficult than
writing portable C++).
I was talking about the profiler, debugger and support tools like
lock_lint, not the editors. GNU make lacks (or at least used to lack)
decent support for distributed building, something I've fond very useful
over the years.
 
J

James Kanze

Thanks for the reply (to you and all). I presume you mean the
standard C and C++ libraries. Can you elaborate with an
example or two?

The default library in Sun CC is a fairly ancient version of the
Rogue Wave library, implemented before the compiler supported
template members. So to begin with, it doesn't have any of the
template member functions. It was also implemented before the
compiler supported the f<T>() syntax, so functions whose types
cannot otherwise be deduced have an additional T* argument. In
some cases, it also writes to memory that doesn't belong to it:
in particular, ostrstring with a user buffer will always write
one past the end of the buffer. And the iostream implementation
is simply horrible from a performance point of view: something
like out << i makes three or for system calls, even if the
stream is fully buffered.

The alternative is STL port. (Again, not the latest version.)
I've used it considerably less (since most of the code I write
has to link with third party libraries using the default
library), but each time I've used it, I've encountered some
problem or another.
Is there free alternative that is better? What do you use
instead?

We use g++ whenever possible: the compiler is somewhat better,
and the library is a couple of orders or magnitude better. And
since the long term planning has everything ported to Linux,
using g++ under Solaris simplifies the port. Most of the time,
however, third party libraries mean that we must use Sun CC with
its default library, problems or not, so we develop work-arounds
for them, and use it.
 
J

James Kanze

I don't consider STLport to be junk.

I've run into quite a few bugs with it. More even than the
Rogue Wave library that is the default. But compared to the
Dinkumware library or g++, they're both at a distinctly lower
level. (To be fair to Rogue Wave and the STL port, I don't
think that the versions Sun distributes are the latest.)
I was talking about the profiler, debugger and support tools
like lock_lint, not the editors. GNU make lacks (or at least
used to lack) decent support for distributed building,
something I've fond very useful over the years.

Hmmm. I think you're right about that. On the other hand, we
need to be portable to both Solaris and Linux: the easiest way
to be sure that the make file is portable is to use the same
make everywhere (and GNU make has a lot of features for writing
makefiles, which Sun make doesn't).

As for the other tools, we use them so rarely that it really
doesn't matter.
 
M

Martin Sebor

I've run into quite a few bugs with it. More even than theRogue Wavelibrary that is the default. But compared to the
Dinkumware library or g++, they're both at a distinctly lower
level. (To be fair toRogue Waveand the STL port, I don't
think that the versions Sun distributes are the latest.)

FYI: Sun C++ comes with version 2.1.1 of the The Rogue Wave library
from 1999. The latest is 4.2.1.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top