DevX interviewed Bjarne Stroustrup about C++0x, the new C++ standard that is due in 2009. Bjarne Stroustrup has classified the new features into three categories Concurrency, Libraries and Language. The changes introduced in the Concurrency makes C++ more standardized and easy to use on multi-core processors. It is good to see that some of the commonly used libraries are becoming standard (eg: unordered_maps and regex).
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-02-02
Ashigabou:
I do not know whether you have an industry affiliation or experience but your comment does not reflect my experience.
Currently, all oil and gas exploration goes through several steps that are computationally time consuming. Seismic surveys need to be processed several times, and a turn around time of 6-12 months is the average (depending on the algorithms that are applied). These algorithms are tweaked and optimized time and time again, and are currently run on clusters of e.g. 5000 nodes and upwards to achieve appropriate turn around times.
A reduction in performance of a factor of 2-3 (as you mentioned yourself that "nobody cares about") would imply that the oil and exploration world wide would go down with the respective amount per year. That's not tolerable.
In fact : Take a look at the plethora of code that is being implemented and ported to FGPAs, CUDA/TESLA/GPGPU and other acceleration devices. Jacob is entirely correct in his assumption that complexity is worth the hassle. Actually, the hassle to have complex yet high performance code is probably offset by billions of dollars.
That was oil and gas. Ditto for medical imaging. Lives are saved every day due to the use of clusters, FPGAs and other acceleration devices used for image reconstruction, CAD (computer aided diagnostics) and other image processing. Again, factors of 2-3 or more aren't acceptable.
At the end of the day, this "the code is too obscure" argument is old and tired. It may be relatively complicated, but since it allows unmatched results, it's just worth it.
That's where we disagree, and I guess we'll have to agree to disagree; I think readability beats speed almost all the time (to a certain extent, obviously, I would not be able to afford being 1000x times slower than C; 10 is certainly affordable most of the time, like most people can afford to be several times slower in C than they are in ASM). Almost nobody cares about a factor 2-3 of speed anymore. Buying more hardware is just cheaper.
[.....]
I wish your project to succeed, but my personal opinion is that it is not where the future of numerical computation is. If you rewrite some algorithms from say Fortran, going to C++ is just not worthwhile from a maintainability POV. Fortran is painful to use, but yet, people do not rewrite the algorithms. Again, the fact that C++ still, after 30 years, does not have a matrix concept as found in a 60 years old language like Fortran does not help. [/q]
Member since:2005-11-11
Currently, all oil and gas exploration goes through several steps that are computationally time consuming. Seismic surveys need to be processed several times, and a turn around time of 6-12 months is the average (depending on the algorithms that are applied). These algorithms are tweaked and optimized time and time again, and are currently run on clusters of e.g. 5000 nodes and upwards to achieve appropriate turn around times.
A reduction in performance of a factor of 2-3 (as you mentioned yourself that "nobody cares about") would imply that the oil and exploration world wide would go down with the respective amount per year. That's not tolerable.
That's a really specific example. You will always find areas where you need to squeeze as much power as possible. Like I said, C++ still is the best (almost only) choice for some things.
In fact : Take a look at the plethora of code that is being implemented and ported to FGPAs, CUDA/TESLA/GPGPU and other acceleration devices. Jacob is entirely correct in his assumption that complexity is worth the hassle. Actually, the hassle to have complex yet high performance code is probably offset by billions of dollars.
But that's totally different: once you get optimization of GPGPU, you get an abstraction which is usable from any language. Which is not the case of template (you can't really reuse template from any other language). Of course good, high performance building blocks are important, but that's because they can be used a building blocks.
Again, factors of 2-3 or more aren't acceptable.
Of course it is acceptable, because it would have a huge cost to do everything as fast as possible. I mean 2-3 speed factor is what you could get by using ASM instead of C, most of the time (heck, you can get this different just by using a different compiler on the exact same code), and those stuff are not mostly written in ASM anymore.
A lot of image processing is done with matlab on windows running internally on more and more machines, talk about inefficiency. You have some bottom line to reach to make your software fast enough, of course, but this bottom line is more and more accessible without using a lot of compiled code. The question in industry is time from design to market to getting the result. Fast software is just part of the equation, which loses ground to the design phase/production delivery significance.
C++/C is more of a legacy than a critical feature of many image processing stuff out there IMO.
Member since:
2005-11-11
Not really. although it certainly have practical implications. I never talked about the difficulty for compiler writers
From the user's point of view, I don't think there exists any significant drawback! There used to be the too long compile times but that changed a lot in recent years as C++ compilers improved.
Not really, compiling C++ with template is still incredibly slow (at least with g++ and sun studio compilers). Compiling relatively small heavily templated source code of a couple of 100s lines takes up to 300 Mb of memory with g++ -O2 (4.2). Boost.Python is even worse. That's the only language I am aware of where you have to use special implementation techniques with design implication to make compilation time bearable.
Coming back to the implementor's point of view... If you want to see how template metaprogramming allowed 2 devs to write only 11 KLOC and surpass 500+ KLOC libraries, see my blog here, http://bjacob.livejournal.com/6723.html
I did not know about your project, it looks interesting and I will look at it (the header only certainly has a big implication on the deployment issue for open source projects, it makes it really easy to use, big plus IMO), but I think it is misleading to compare your library to say atlas or MKL. First, MKL implements a huge number of features you don't have (fft, etc...), and blas/lapack interface is a must for any serious use in the scientific community (I understand you are interested
in less scientific usage, but by comparing yourself to ATLAS/GOTO/MKL and co, that's where you are putting yourself
I am a bit surprised at your benchmark results: in my experience, ublas is one order of magnitude slower than ATLAS for example. But then, it depends so much on your CPU, compiler, compiler flags, etc... Benchmarking this correctly is extremely difficult.
At the end of the day, this "the code is too obscure" argument is old and tired. It may be relatively complicated, but since it allows unmatched results, it's just worth it.
That's where we disagree, and I guess we'll have to agree to disagree; I think readability beats speed almost all the time (to a certain extent, obviously, I would not be able to afford being 1000x times slower than C; 10 is certainly affordable most of the time, like most people can afford to be several times slower in C than they are in ASM). Almost nobody cares about a factor 2-3 of speed anymore. Buying more hardware is just cheaper.
Your argument, that external code generators are preferable, made a lot of sense in the times where C++ compilers were not powerful enough for metaprogramming
I don't quite understand your argument about compiler implementation. The problem with templates is in the nature of templates, and the fact that they were never designed for what people try to do with them with meta-programming, not so much how (incredibly) difficult they are to implement for compilers. g++ error messages are still totally obscure and unreadable (with g++ 4.1, at least), and the syntax is horrible. Templates in C++ are a kind of code generators, and you could argue they are powerful, since they are turing complete. But HLL like LISP/ML or even things like python are much more easy to use for parsing/generating code, and certainly more readable.
I find the code you posted quite painful to read, but you could argue it is personal taste. Objectively, though, most of it is just boilerplate to get around fundamental limitations of the template syntax. In languages like LISP of OCAML, partly designed (and certainly used for) compiler/language design, it would be much easier to do, and arguably more elegant.
I wish your project to succeed, but my personal opinion is that it is not where the future of numerical computation is. If you rewrite some algorithms from say Fortran, going to C++ is just not worthwhile from a maintainability POV. Fortran is painful to use, but yet, people do not rewrite the algorithms. Again, the fact that C++ still, after 30 years, does not have a matrix concept as found in a 60 years old language like Fortran does not help.