Re: "STL from the Ground Up"
- From: Jon Harrop <usenet@xxxxxxxxxxxxxx>
- Date: Sun, 16 Mar 2008 05:54:13 +0000
Paul Hsieh wrote:
On Mar 14, 4:04 pm, Jon Harrop <use...@xxxxxxxxxxxxxx> wrote:
My own analysis shows that .NET and Java take around a 50% hit in
performance versus raw C++ code.
Then you're not seeing the forest for the trees.
The purpose of higher-level approaches to programming is to make more
sophisticated software tractable, not to decrease the constant prefactor
in the performance of programs so trivial that they can be written in
antique languages like C++.
What makes you think I don't *see* this?
Your statement ".NET and Java take around a 50% hit in performance versus
raw C++ code" proved that you don't see this.
Not only will you be hard pressed to find an esoteric benchmark where C++ is
2x faster than C#, you will be inundated with benchmark results where C#
beats anything you can write in C++.
This is across the board of
essential programming primitives, giving the .NET/Java compilers every
opportunity to detect and optimize. My brief look at Scheme/Lisp
indicate that they are even worse (just because there is not anywhere
near the same kind of effort put into their compilers.) I don't have
any reason to hold out hope for Haskell.
You have misunderstood the purpose of all of these tools.
I have not. The proponents of those languages just don't understand
the effect of the changing hardware landscape.
A week ago you were blissfully unaware of the world's most popular CPU
architecture and now you're making statements about Microsoft's knowledge
of that same subject.
Their existence relied
on Moore's Law more than anything, because complaints about their
performance were always short-lived. Now, if you write an application
in one of these languages that's not parallelisable, and it has bad
performance, that complaint will stay with that application forever.
The whole point of their concurrent GCs is that concurrent applications are
much easier to write correctly in those languages.
[...] and its allocator is still 5x
slower than OCaml's. There is a lot of room for improvement.
Oh ... I should have known you were one of those people. Throws out
numbers that can almost surely be shown to be demonstrably false, and
just has not credibility or accountability at all. Last time, it was
a claim that Scheme was 21x faster than C (which made it 7 times
faster than the theoretical speed of just the hardware ALUs.)
Shall we do this again? Or will you just retract such a nonsensical
claim now?
The claim is trivial to test and the result would not surprise you if you
knew anything of either OCaml or .NET. Just look at the design of their
allocators.
[...] The reason is that "some form" of a language
feature is too little too late. C++ was long since superseded and will
never catch up.
Listen. GC is no faster than malloc + free.
Yes, it is. Production-quality GCs represent the culmination of man millenia
of work. You cannot possibly hope to compete by Greenspunning everything
yourself.
But it provides no
solution for realloc(), and no clever calloc() (which can leverage the
OS to page-in zeroed memory).
Look at BIBOP.
Furthermore, in C++ its a common
practice to write pool allocators, which are basically untouchable in
terms of performance.
Actually, OCaml's allocator is written in hand-coded assembler because C/C++
is too slow. So C++ literally cannot compete.
The "small objects" problem is a major performance killer in these OO
HLLs.
Look at any FPL implementation.
Add to this the fact that most C++ compilers retain a way to "escape
to assembly language" within a program,
You can call out to assembler from any language, including Java and all
.NET languages.
And what kind of overhead are these calls? Is the language still
sound and nice and scalable to write in if you do this?
No different from any other FFI.
and we have to conclude that C++ is basically *the* high performance
programming solution.
C++ is tremendously unproductive compared to modern languages.
Apples and oranges.
The only way that can be true is if you're talking about problems outside
the remit of modern languages, like systems programming. I suppose you're
going to tell Linus to rewrite the kernel in C++ next...
[...] Having to do manual memory management is painstakingly error prone
[and
typically very inefficient.
Its error prone. Its not inefficient.
C++ cannot represent closures, pattern matches and a multitude of other
features that are not only integrated but also heavily optimized in many
modern languages.
Its a little ironic that these "modern" programming languages have
started by painting themselves into a corner. They were all designed
with the idea that Moore's Law was the essential solution to all
performance problems. Their main argument being that the saved
development time was more important than a factor of 2 in performance,
because Moore's law would always make that performance difference
irrelevant.
I've no idea what gave you that impression but it is also completely
wrong.
The entire push back against these languages has been because of their
performance.
No, many excuses are given for not modernizing:
.. I find the syntax scary.
.. Unit testing cannot work.
.. Blub, e.g. it doesn't even have a Turing complete type checker and why
would anyone want a concurrent garbage collector?
Performance concerns are quoted alongside those. They are all meaningless
drivel and, consequently, we all continue to modernize to faster and more
productive languages.
These languages have never addressed this problem, and
yet have gotten away with it. How can this be? Its because people
are accepting of the compromised performance because they know that
new hardware will make it a moot point.
No, its because they realise that modern languages are more cost effective,
even for performance intensive code, because they are so much more
productive.
This has always been the case. It was the case when C++ was supposed to be
taking over from Fortran.
Programming language research has nothing to do with Moore's law.
Actually programming language research has nothing to do with
anything. As I've heard it said, the primary purpose for the ML
language is to write ML compilers in it. Why do scheme, and Haskell,
erlang, ML and languages like this exist? Because these people have
nothing better to do and have some personal reason for making a new
language that scratches their particular itch.
Look at .NET generics (which came directly from the parametric polymorphism
in the languages you've cited). Look at LINQ.
[...] Even if
performance stopped increasing, higher-level languages would still allow
you to solve lots of problems that are completely intractable with old
lower-level languages like C++.
So I would propose you attempt the following: I want you to write a
program to search the space of possible constant multipliers using
three temporaries and just the operations copy, add, shift and
subtract. I in fact wrote a Python program to do this, that was
absolutely correct. The program couldn't even run because it ran out
of memory before it could output anything useful. We know that to do
that properly we have to pack our memory quite densely.
Remove redundancy using a high-level approach.
Or as an alternative, write a low-latency real time high definition
video encoder.
Use the graphics hardware or you're wasting your time.
Your claim is utter nonsense. C++ makes much more possible than these
HLLs, even if it is much harder to do.
Yes, you're finally getting it! Problem solving in C++ is so much harder
that is is actually impossible for non-trivial problems that people solve
every day using more modern tools.
You could not possibly write the F# software that we sell in C++. You don't
have run-time compilation, interactivity, concurrent GC, safe interop with
other high-level languages (e.g. to use Windows Presentation Foundation)
and so on. These are just the basic features that we've built upon and you
would have to reinvent everything from scratch yourself if you used C++.
You'd be looking at tens or hundreds of millions of lines of code and
development costs would be orders of magnitude larger.
Put another way -- making .NET/Java faster is a very very hard
problem. Making C++ safer and easier to use, is a mildly difficult
problem.
That is a mindnumbingly stupid thing to say, IMHO.
Well, you might like to look into "safe pointers" in the Boost
library. Microsoft is slowly but surely adding in useful things like
memory checkers into their compilers. And the warnings in these
compilers are starting to go more and more in the direction of Lint.
That is playing catchup with decade old Fortran implementations.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
.
- References:
- Re: "STL from the Ground Up"
- From: Paul Hsieh
- Re: "STL from the Ground Up"
- From: Jon Harrop
- Re: "STL from the Ground Up"
- From: Paul Hsieh
- Re: "STL from the Ground Up"
- Prev by Date: Re: "STL from the Ground Up"
- Next by Date: Re: The annotated, annotated, annotated C standard continued
- Previous by thread: Re: "STL from the Ground Up"
- Next by thread: merge sort
- Index(es):
Relevant Pages
|
