Language for ultimate speed
- Thread starter rpg.314
- Start date
MrGaribaldi
Regular
A while back I took a course in numerical programming with C++, you can find the slides and all here, and one of the first things we were told was that if we were to be working on very large datasets, we should port the most computational intensive parts to Fortran 77 and do the rest in C/C++.
You find some of the arguments under the "Efficiency; C++ vs. F77" chapter.
Outside of those very large datasets, I think the difference between doing it in C or F77 should be rather small, and I'd stick with C as I know that best...
What are you collecting the data for?
You find some of the arguments under the "Efficiency; C++ vs. F77" chapter.
Outside of those very large datasets, I think the difference between doing it in C or F77 should be rather small, and I'd stick with C as I know that best...
What are you collecting the data for?
Dominik D
Regular
Speed of what? Development? Testing? Boot? Execution?
You can write fast code in several of those languages, and slow code in all of them. Certainly between C and F77 I'd say the difference would most likely be in the programmer not the language.
Even speed of execution is vague. Local, remote, distributed, data-heavy, computation-heavy, etc. are all variables (excuse the pun) that affect one language or the other. Certainly, C is the fastest as it is a macro-assembler. Nowadays I wouldn't be caught dead using it though.
I'm with NRP, with C# time you save coding your priority modules is time spent on adding new features, improving performance, or getting rid of bugs. I'm also taking a closer look at F# for large sea-of-processors type apps.
I'm with NRP, with C# time you save coding your priority modules is time spent on adding new features, improving performance, or getting rid of bugs. I'm also taking a closer look at F# for large sea-of-processors type apps.
Some people may be thinking about the dynamic binding features in C++, which is slower in general. However, I think if one wants to write a very fast C++ program, s/he is likely to be using templates, which is basically a very powerful macro compared to anything C offers. I think it's possible in this sense for C++ to be faster than C.
Jawed
Legend
Cooler than assembly is a chip that runs Forth natively:
http://www.intellasys.net/index.php?option=com_content&task=view&id=35
Jawed
http://www.intellasys.net/index.php?option=com_content&task=view&id=35
Jawed
It 100% depends on what you're trying to write... frankly if you can express something efficiently in a super-simple language like a shading language (HLSL for instance) it'll easily be the fastest since compilers/optimizers can be hyper-aggressive due to the rules of the language.
But for practical general-purpose, single-threaded stuff I'd say C/C++, although Fortran has some advantages over them in terms of aliasing analysis (hell even Matlab can occasionally compile more optimal code than a similar implementation in C/C++ due to using much saner aliasing rules and value semantics). Fundamentally the aliasing rules in C/C++ are going to screw it over (and have already started to) in the parallel programming world, but it's still the best we have for now since the compilers are so mature.
But for practical general-purpose, single-threaded stuff I'd say C/C++, although Fortran has some advantages over them in terms of aliasing analysis (hell even Matlab can occasionally compile more optimal code than a similar implementation in C/C++ due to using much saner aliasing rules and value semantics). Fundamentally the aliasing rules in C/C++ are going to screw it over (and have already started to) in the parallel programming world, but it's still the best we have for now since the compilers are so mature.
Yes, there was an interesting and very long thread on the "Game Developers Algorithms" mailing list on this very subject, for example:
Jim Tilander said:
I can but try
It did split but the original bulk is here http://sourceforge.net/mailarchive/...dfe659a1@iit.edu&forum_name=gdalgorithms-list
but you should also look for the "strict aliasing" thread.
Thanks for the link, Simon.
Strict aliasing and in a few cases "restrict" help, but they do not solve the fundamental language problem... they reduce it somewhat (particularly the catastrophically stupid compiler cases), but they don't fix it completely. I'm just becoming more and more depressed with the prospect of how much we'd have to bolt on/change C/C++ to make it usable and efficient in a massively (data) parallel world, but we'll see what people come up with.
Strict aliasing and in a few cases "restrict" help, but they do not solve the fundamental language problem... they reduce it somewhat (particularly the catastrophically stupid compiler cases), but they don't fix it completely. I'm just becoming more and more depressed with the prospect of how much we'd have to bolt on/change C/C++ to make it usable and efficient in a massively (data) parallel world, but we'll see what people come up with.
Last edited by a moderator:
