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
-
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
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 hierarchy -
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:
Then the comment was made that a lot of engineering was still being done in FORTRAN because it was the fastest executing language.
Who said that, a university lecturer? Because they generally don't have a clue, I still remember one of ours bleating on about how java was faster than C++ because java allocated memory on the heap and C++ could only do it on the stack - lol..... *rolls eyes*
-
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 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.
-
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
