Which language is faster?
-
It depends on the complexity of the problem and how much time you want to spend on optimization. I would go for C before C++ but, naturally, assembly is unbeatable.
-
No. Building your own special-purpose computer, redesigning each component if necessary, is actually unbeatable.
Eduardo León
Funny but not the answer to the question "Which language is faster?"
-
I had an interesting conversation the other day and I thought I'd ask the crowd here for further enlightenment. Essentially I am supposed to take a graduate course in numerical methods starting in a week or two, so I asked about what programming would be needed and was told that I could use any language I want. Then the comment was made that a lot of engineering was still being done in FORTRAN because it was the fastest executing language. Now, I've won bets in the past by taking some fairly "fast" FORTRAN and converting it to Pascal/C/VB, etc. and showing that my algorithms run faster than the original FORTRAN. However, in most cases it was the choice of algorithm that made the difference, not the language. I never actually went back and rewrote the FORTRAN code with an algorithm change to do a real comparison, but I'm sure that it would have been faster, too. So, aside from interpreted languages, is there a real case to be made for FORTRAN being faster than other compiled languages on number crunching? Perhaps the floating point libraries are better optimized? My guess is there is not, but that individual compilers may vary some, even with the same language. I haven't programmed much FORTRAN for the last 30 years, so I'm hoping I don't need to go back and do too much of that. As far as I was concerned, discovering that there were languages other than FORTRAN was an epiphany!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
For any given processor, memory and operating system, the fastest execution speed will always be the app written entirely in assembler fro that purpose only by a very experienced assembler programmer (EAP), well used to that target. No compiler on the planet can beat that, as the EAP will write code to do exactly what he wants, rather than what he wants within the strictures of the language, as interpreted by the compiler. However, the app will take considerably longer to write, debug, and maintain; will be more prone to error, and this will almost certainly outweigh any speed benefits you gain. Frequently, the OS will have a considerable influence on execution speed. For example, compare the latest word processor with a DOS based version!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
I had an interesting conversation the other day and I thought I'd ask the crowd here for further enlightenment. Essentially I am supposed to take a graduate course in numerical methods starting in a week or two, so I asked about what programming would be needed and was told that I could use any language I want. Then the comment was made that a lot of engineering was still being done in FORTRAN because it was the fastest executing language. Now, I've won bets in the past by taking some fairly "fast" FORTRAN and converting it to Pascal/C/VB, etc. and showing that my algorithms run faster than the original FORTRAN. However, in most cases it was the choice of algorithm that made the difference, not the language. I never actually went back and rewrote the FORTRAN code with an algorithm change to do a real comparison, but I'm sure that it would have been faster, too. So, aside from interpreted languages, is there a real case to be made for FORTRAN being faster than other compiled languages on number crunching? Perhaps the floating point libraries are better optimized? My guess is there is not, but that individual compilers may vary some, even with the same language. I haven't programmed much FORTRAN for the last 30 years, so I'm hoping I don't need to go back and do too much of that. As far as I was concerned, discovering that there were languages other than FORTRAN was an epiphany!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
Walt Fair, Jr. wrote:
I am supposed to take a graduate course in numerical methods starting in a week or two, so I asked about what programming would be needed and was told that I could use any language I want. Then the comment was made that a lot of engineering was still being done in FORTRAN because it was the fastest executing language.
Keep your eyes on the problem. It is a numerical methods course, not a compiler optimazitation course. Choose the programming language you are most compfortable using and concentrate on numerical analysis. That is unless there is credit given, or taken away, for programming language used.
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
I had an interesting conversation the other day and I thought I'd ask the crowd here for further enlightenment. Essentially I am supposed to take a graduate course in numerical methods starting in a week or two, so I asked about what programming would be needed and was told that I could use any language I want. Then the comment was made that a lot of engineering was still being done in FORTRAN because it was the fastest executing language. Now, I've won bets in the past by taking some fairly "fast" FORTRAN and converting it to Pascal/C/VB, etc. and showing that my algorithms run faster than the original FORTRAN. However, in most cases it was the choice of algorithm that made the difference, not the language. I never actually went back and rewrote the FORTRAN code with an algorithm change to do a real comparison, but I'm sure that it would have been faster, too. So, aside from interpreted languages, is there a real case to be made for FORTRAN being faster than other compiled languages on number crunching? Perhaps the floating point libraries are better optimized? My guess is there is not, but that individual compilers may vary some, even with the same language. I haven't programmed much FORTRAN for the last 30 years, so I'm hoping I don't need to go back and do too much of that. As far as I was concerned, discovering that there were languages other than FORTRAN was an epiphany!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
In unlimited time, the language is irrelevant; assembly is the proof. If you have to develop (design, code, test, finalize) the code in a limited amount of time, then language will matter, as will your prior experience in languages. Also if you have to develop an optimizing compiler, the target language will influence cost; or alternatively, for a given cost the code efficiency will depend on the target language. What often is meant by "language X is faster than language Y" is either there are better compilers for X, or, the semantics of X are better for detecting valid optimizations (e.g. think of pointer aliasing issues, when a function has several pointers as parameters one may not be sure they point to distinct memory blocks). :)
Luc Pattyn [Forum Guidelines] [My Articles] [My CP bug tracking] Nil Volentibus Arduum
Season's Greetings to all CPians.
-
I had an interesting conversation the other day and I thought I'd ask the crowd here for further enlightenment. Essentially I am supposed to take a graduate course in numerical methods starting in a week or two, so I asked about what programming would be needed and was told that I could use any language I want. Then the comment was made that a lot of engineering was still being done in FORTRAN because it was the fastest executing language. Now, I've won bets in the past by taking some fairly "fast" FORTRAN and converting it to Pascal/C/VB, etc. and showing that my algorithms run faster than the original FORTRAN. However, in most cases it was the choice of algorithm that made the difference, not the language. I never actually went back and rewrote the FORTRAN code with an algorithm change to do a real comparison, but I'm sure that it would have been faster, too. So, aside from interpreted languages, is there a real case to be made for FORTRAN being faster than other compiled languages on number crunching? Perhaps the floating point libraries are better optimized? My guess is there is not, but that individual compilers may vary some, even with the same language. I haven't programmed much FORTRAN for the last 30 years, so I'm hoping I don't need to go back and do too much of that. As far as I was concerned, discovering that there were languages other than FORTRAN was an epiphany!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
I took an undergraduate numerical methods sequence back in the Jurassic era. Based on those memories, use the language that you have the greatest familiarity with, especially for floating point handling and precedence rules. Look at compiler and run-time library controls for floating point processing, precision, exceptions, and so on, as those will be critical to algorithm behavior. Numerical methods attempt to compute a result in a reasonable time with a certain precision and maximum allowed error in the result. The 'edge behavior' options in your language and environment can have a profound effect. I've noticed in the other posts the word 'optimization' coming up a lot. Optimization can be a dangerous thing in numerical methods implementation. Some optimizations will actually alter numerical methods results by moving calculations around and altering loop behavior. Regarding FORTRAN: FORTRAN's sole advantage in numerical processing is its long lead time, plus the fact that it has become a niche language in the scientific community. As a result, a lot of implementations include numerical methods support 'out of the box'. I doubt your purposes will be served by using those, since the point of the class is to learn how to implement the method, rather than use someone else's canned version.
Software Zen:
delete this;
Fold With Us![^] -
For any given processor, memory and operating system, the fastest execution speed will always be the app written entirely in assembler fro that purpose only by a very experienced assembler programmer (EAP), well used to that target. No compiler on the planet can beat that, as the EAP will write code to do exactly what he wants, rather than what he wants within the strictures of the language, as interpreted by the compiler. However, the app will take considerably longer to write, debug, and maintain; will be more prone to error, and this will almost certainly outweigh any speed benefits you gain. Frequently, the OS will have a considerable influence on execution speed. For example, compare the latest word processor with a DOS based version!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
OriginalGriff wrote:
For any given processor, memory and operating system, the fastest execution speed will always be the app written entirely in assembler fro that purpose only by a very experienced assembler programmer (EAP), well used to that target.
While that may have been true at one time, I don't believe that is the case any longer, except on microcontrollers. Modern compilers are sufficiently sophisticated in the optimizations they perform, and broad in the scope at which they're applied, that I doubt any human programmer could achieve equivalent or better results except in a small number of cases. I haven't had cause to use assembly language code for optimization purposes since 1995 or so. Since I work on process control applications, with real-time and near real-time performance requirements, I probably would have seen the need if there was one.
Software Zen:
delete this;
Fold With Us![^] -
I had an interesting conversation the other day and I thought I'd ask the crowd here for further enlightenment. Essentially I am supposed to take a graduate course in numerical methods starting in a week or two, so I asked about what programming would be needed and was told that I could use any language I want. Then the comment was made that a lot of engineering was still being done in FORTRAN because it was the fastest executing language. Now, I've won bets in the past by taking some fairly "fast" FORTRAN and converting it to Pascal/C/VB, etc. and showing that my algorithms run faster than the original FORTRAN. However, in most cases it was the choice of algorithm that made the difference, not the language. I never actually went back and rewrote the FORTRAN code with an algorithm change to do a real comparison, but I'm sure that it would have been faster, too. So, aside from interpreted languages, is there a real case to be made for FORTRAN being faster than other compiled languages on number crunching? Perhaps the floating point libraries are better optimized? My guess is there is not, but that individual compilers may vary some, even with the same language. I haven't programmed much FORTRAN for the last 30 years, so I'm hoping I don't need to go back and do too much of that. As far as I was concerned, discovering that there were languages other than FORTRAN was an epiphany!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
I'd go for clearest over fastest. I've not studied numerical methods,but they sound like a shoe-in for functional languages, if you can spare the time needed for the learning curve.
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^] -
I had an interesting conversation the other day and I thought I'd ask the crowd here for further enlightenment. Essentially I am supposed to take a graduate course in numerical methods starting in a week or two, so I asked about what programming would be needed and was told that I could use any language I want. Then the comment was made that a lot of engineering was still being done in FORTRAN because it was the fastest executing language. Now, I've won bets in the past by taking some fairly "fast" FORTRAN and converting it to Pascal/C/VB, etc. and showing that my algorithms run faster than the original FORTRAN. However, in most cases it was the choice of algorithm that made the difference, not the language. I never actually went back and rewrote the FORTRAN code with an algorithm change to do a real comparison, but I'm sure that it would have been faster, too. So, aside from interpreted languages, is there a real case to be made for FORTRAN being faster than other compiled languages on number crunching? Perhaps the floating point libraries are better optimized? My guess is there is not, but that individual compilers may vary some, even with the same language. I haven't programmed much FORTRAN for the last 30 years, so I'm hoping I don't need to go back and do too much of that. As far as I was concerned, discovering that there were languages other than FORTRAN was an epiphany!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
I had an interesting conversation the other day and I thought I'd ask the crowd here for further enlightenment. Essentially I am supposed to take a graduate course in numerical methods starting in a week or two, so I asked about what programming would be needed and was told that I could use any language I want. Then the comment was made that a lot of engineering was still being done in FORTRAN because it was the fastest executing language. Now, I've won bets in the past by taking some fairly "fast" FORTRAN and converting it to Pascal/C/VB, etc. and showing that my algorithms run faster than the original FORTRAN. However, in most cases it was the choice of algorithm that made the difference, not the language. I never actually went back and rewrote the FORTRAN code with an algorithm change to do a real comparison, but I'm sure that it would have been faster, too. So, aside from interpreted languages, is there a real case to be made for FORTRAN being faster than other compiled languages on number crunching? Perhaps the floating point libraries are better optimized? My guess is there is not, but that individual compilers may vary some, even with the same language. I haven't programmed much FORTRAN for the last 30 years, so I'm hoping I don't need to go back and do too much of that. As far as I was concerned, discovering that there were languages other than FORTRAN was an epiphany!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
"Fastest" is a relative term. Fastest to execute is the usual interpertation, but one can also ask the question as which is the fastest from task concept to end result. In which case VB or Java might be the answer because one is framilar with it. I learned to program in Fortran - time to result was something like this; 1 Subroutine Fix_typo(i) 2 RePunch card(i) 4 Submit the deck 5 Wait 24 hrs for result 6 End Subroutine 7 Comment 8 for i = 1 to MaxCard 9 Fix_typo(i) 10 i = i + 1
Melting Away www.deals-house.com www.innovative--concepts.com
-
Barring optimizations of the algorithm, it's hard to beat an engineer who knows his platform. You are up against years of refined knowledge of compiler, libraries and CPU (ask what machines they use). It's a local optimium, though one that's hard to refute. Knowing by heart e.g. when a loop invariant will be hoisted gives a significant advantage. So, of course C++ is the fastest to execute ;)
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyYeah, I agree. I used to know FORTRAN inside and out and think I can get there again pretty fast, but it's definitely not my favorite language!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
Walt Fair, Jr. wrote:
I am supposed to take a graduate course in numerical methods starting in a week or two, so I asked about what programming would be needed and was told that I could use any language I want. Then the comment was made that a lot of engineering was still being done in FORTRAN because it was the fastest executing language.
Keep your eyes on the problem. It is a numerical methods course, not a compiler optimazitation course. Choose the programming language you are most compfortable using and concentrate on numerical analysis. That is unless there is credit given, or taken away, for programming language used.
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopesOh, I agree. I'll use whatever language makes sense and if the profs prefer FORTRAN and I can get a compiler, then FORTRAN it will be. I've done lots of numerical methods professionally over the last 40 years in more languages than I can name off hand, I just don't have graduate school credit for a course. In fact I worked my way through engineering school working as a FORTRAN programmer doing reservoir simulation code (numerical solutions to partial differential equations).
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
In unlimited time, the language is irrelevant; assembly is the proof. If you have to develop (design, code, test, finalize) the code in a limited amount of time, then language will matter, as will your prior experience in languages. Also if you have to develop an optimizing compiler, the target language will influence cost; or alternatively, for a given cost the code efficiency will depend on the target language. What often is meant by "language X is faster than language Y" is either there are better compilers for X, or, the semantics of X are better for detecting valid optimizations (e.g. think of pointer aliasing issues, when a function has several pointers as parameters one may not be sure they point to distinct memory blocks). :)
Luc Pattyn [Forum Guidelines] [My Articles] [My CP bug tracking] Nil Volentibus Arduum
Season's Greetings to all CPians.
I agree with most everything you mention, Luc. I personally see no great advantage to using one language over another, but for specific problems there may be advantages. I think the choice of algorithm and the availability of a good compiler are more important. And of course, familiarity with the language makes a big difference in debugging, time to "release," etc.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
I'd go for clearest over fastest. I've not studied numerical methods,but they sound like a shoe-in for functional languages, if you can spare the time needed for the learning curve.
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^]I'm not an expert in functional languages, but the problem I see is that the functional languages tend to hide precisely the stuff you need to control to make non-trivial numerical methods work properly without losing precision. I'm not saying it can't be done and I might try to see how F# works in that regard. It's an interesting idea.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
That sounds neat! I'll have to see what they're doing with the GPU's on the UT campus.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
"Fastest" is a relative term. Fastest to execute is the usual interpertation, but one can also ask the question as which is the fastest from task concept to end result. In which case VB or Java might be the answer because one is framilar with it. I learned to program in Fortran - time to result was something like this; 1 Subroutine Fix_typo(i) 2 RePunch card(i) 4 Submit the deck 5 Wait 24 hrs for result 6 End Subroutine 7 Comment 8 for i = 1 to MaxCard 9 Fix_typo(i) 10 i = i + 1
Melting Away www.deals-house.com www.innovative--concepts.com
Heh, heh. ;P :laugh: Yeah that's how I learned, too. Fortunately I later found other languages, but more importantly, some design techniques.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
OriginalGriff wrote:
For any given processor, memory and operating system, the fastest execution speed will always be the app written entirely in assembler fro that purpose only by a very experienced assembler programmer (EAP), well used to that target.
While that may have been true at one time, I don't believe that is the case any longer, except on microcontrollers. Modern compilers are sufficiently sophisticated in the optimizations they perform, and broad in the scope at which they're applied, that I doubt any human programmer could achieve equivalent or better results except in a small number of cases. I haven't had cause to use assembly language code for optimization purposes since 1995 or so. Since I work on process control applications, with real-time and near real-time performance requirements, I probably would have seen the need if there was one.
Software Zen:
delete this;
Fold With Us![^]Yes, I think compiler optimization has come a long ways in the last few decades. I've done real time programming in C, assembly for various CPUs, etc. In years past I at times wrote in C, then optimized the resulting assembly by hand in critical routines. However, between compilers and processor speed, I find that is rarely needed these days.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
I'm not an expert in functional languages, but the problem I see is that the functional languages tend to hide precisely the stuff you need to control to make non-trivial numerical methods work properly without losing precision. I'm not saying it can't be done and I might try to see how F# works in that regard. It's an interesting idea.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
Thanks. I'm not sure functional languages are ideally suited either, but I thought I'd throw them out as an idea!
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^] -
I had an interesting conversation the other day and I thought I'd ask the crowd here for further enlightenment. Essentially I am supposed to take a graduate course in numerical methods starting in a week or two, so I asked about what programming would be needed and was told that I could use any language I want. Then the comment was made that a lot of engineering was still being done in FORTRAN because it was the fastest executing language. Now, I've won bets in the past by taking some fairly "fast" FORTRAN and converting it to Pascal/C/VB, etc. and showing that my algorithms run faster than the original FORTRAN. However, in most cases it was the choice of algorithm that made the difference, not the language. I never actually went back and rewrote the FORTRAN code with an algorithm change to do a real comparison, but I'm sure that it would have been faster, too. So, aside from interpreted languages, is there a real case to be made for FORTRAN being faster than other compiled languages on number crunching? Perhaps the floating point libraries are better optimized? My guess is there is not, but that individual compilers may vary some, even with the same language. I haven't programmed much FORTRAN for the last 30 years, so I'm hoping I don't need to go back and do too much of that. As far as I was concerned, discovering that there were languages other than FORTRAN was an epiphany!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
It depends. You haven't mentioned (a) where you're working or (b) what kind of problems you'll expect to work on or (c) how familiar you already are with various languages or (d) what tools you have available or could get approved of (maybe a budget question?). Last time I worked with FORTRAN was ~25 years ago, at university. The problem was both numerical and algebraical in nature, and FORTRAN was the standard (at universities) for everything remotely mathematical. The main reason for that, a professor once explained to me, was not that it was 'fastest' (maybe it even was for some types of problems, but the mathematicians didn't care about that all that much), but that it was 'error compatible', meaning that all universities used the same huge numerical library for all kinds of problems, and any results produced by a FORTRAN program using that library would produce the same results - and the same errors! - as the original, when being run at other universities. That was a pretty strong point for using FORTRAN at that time: reproducing scientifical results. I've worked for more than 20 years outside university and never ever came across anyone using FORTRAN. C/C++ is the industry standard for desktop applications. (or maybe C# has taken the lead in the meantime - but I doubt you'll find a lot of that in applications with a strong focus on number crunching) Web applications preferably use other languages (and I am the wrong person to ask about that), but as you are dealing with numerical stuff, and are looking for high performance, I doubt you want to deal with any of that. That said, while I do program lots of numerical and algebraical stuff at work, I do not have the luxury of a numerical library to help with the hard work. If I'm missing an algorithm, I have to program it myself. And even though many textbooks on numerics and algebra provide good descriptions of their algorithms, forging them into a program that is numerically stable even under occasionally exotic conditions isn't easy at all. So if you do have FORTRAN libraries available for that kind of stuff, but don't know where to start looking for similar libraries in other languages, you'd better stick with FORTRAN! If you want an idea what to expect when developing stable implementations for numerical algorithms, search for Jack Crenshaw and his article series on rootfinders, spread over several years! Here is a link to one of these articles
-
That sounds neat! I'll have to see what they're doing with the GPU's on the UT campus.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
Depending on the type of problems you face, CUDA may not be of help at all. In fact I know of few numerical algorithms that could be sped up using a parallel implementation. Usually the algorithms are sequential in nature and strongly build on intermediate results from previous steps. There is some effort to recreate numerical algorithms on parallel machines, but so far I am unaware of any useful results. Also, AFAIK many of the CUDA-enabled graphics cards only support floating point precision on their GPUs. That could be a roadblock if you need high precision. I didn't have the time to look into the CUDA library itself though, maybe it does provide double precision functions wrappers?