Which language is faster?

[Snowman58]

"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

[Dr Walt Fair PE]

Yeah, 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

[Dr Walt Fair PE]

Oh, 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

[Dr Walt Fair PE]

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

[Dr Walt Fair PE]

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

[Dr Walt Fair PE]

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

[Dr Walt Fair PE]

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

[Dr Walt Fair PE]

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

[Keith Barrow]

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[^]

[Stefan_Lang]

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

[Stefan_Lang]

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?

[Michael Kingsford Gray]

Tight machine code runs the fastest. But I admit to a Cray-style highly parallel FORTRAN bias.

[Dan Neely]

I'm going to have to disagree here. Einstein @ Home[^] got an ~2x speedup in their science application* when they replaced their C++ hotloop with assembly. The same person previously provided a ~4x speedup by reworking the C++ algorithm to work better within the number of CPU pipelines and cache sizes. * The gravitational wave one anyway, I think the binary radio pulsar app is still in too much flux for them to be working on an assembler version; they only did it for prior apps once they were certain everything worked right and was stable.

3x12=36 2x12=24 1x12=12 0x12=18

[Lost User]

Walt, To be perfectly honest, the speed of the language has ceased to be a consideration in modern computing except for very rare cases. If you're writing logic for a low-power micro controller or operating systems level code where you have to squeeze every ounce of processor speed to ensure fast context-switching or something then you might need to consider it. I've been at this for over 35 years now. While I still believe in writing your code to be as conservative as possible with machine resources, choosing a language based on minute differences in execution speed simply doesn't make sense any more (except for the above). There are many fine languages to choose from. Pick the language based on what you want to do with it or what the opportunities you wish to pursue require. Yes, FORTRAN (I wrote it for many years) is an extremely fast language. It was originally designed that way for scientific use. If you want to learn to code for business, I'd suggest you get into .Net. Learn C# or VB.Net. I personally prefer C# now (having written C for 15 years or so) but I wrote almost nothing but VB (VB6 and VB.Net) for about 10 years. They both get the job done. If you're going to go to web development, the above (C# and VB.Net) with maybe a mixture of Javascript or PHP. The technology really has reached a point now where speed is not the #1 concern for a language any more. My 2-cents, -Max

[Chris Boss]

One of the fastest programming languages I have come across is PowerBasic (remember Borlands TurboBasic ? This is its great grand child). Powerbasic has similiar syntax to Visual Basic (non-OOP code), but the people at Powerbasic are experts in Intel machine code and in counting CPU cycles (meaning squeezing as much speed as possible). PowerBasic also has such a rich command set, there are always better ways to optimize code. In the rare instance that is not enough, you can write inline assembler code right in the middle of basic code. PowerBasic gives you the control required to optimize code to the max! The generated machine code by the compiler is probably as fast as it gets and I am confident PowerBasic would hold its own compared to any other language. I have been using PowerBasic for about 10 years now and am a developer of programming tools for use by professional programmers (who also use PowerBasic). PowerBasic allows me to write applications (and DLL's) which are smaller in size than what is generated by most languages, even C or C++ and the speed rivals the fastest C compilers. I can work with things like pointers, register variables, calling functions via a pointer, etc. The data types are so extensive there is always a better data type for the task at hand. PowerBasic IMO probably has the best string handling command set of any language and if you have to do text parsing I doubt it could be beat by any language. I wrote a 2D Sprite engine (100% software based with no special hardware required) using Powerbasic which requires extremely fast manipulation of millions of pixels in DIB sections and it can fly, even on a slower CPU like an Intel Atom found in many Netbooks today. I actually do testing on older PC's like a Windows 95 PC with a 500 mhz CPU (or less). I like to see my software fly on even a legacy PC, so it will be super fast on the latest PC's. Many programming languages couldn't even be used on a 500 mhz Windows 95 PC (PowerBasic can) and they surely would not be used to write software for such a legacy PC (too slow). Since I write tools for programmers, I have to be concerned about speed and PowerBasic has always matched my needs. I am currently developing the next generation of my tools which also handle 3D drawing using OpenGL and my OpenGL Canvas control (yes a real Windows control) has excellent speed in translating a GL scripting Graphics Language the control provides for 3D drawing. The control must interpret a script language and then handle all the 3D drawing via OpenGL

[Alan Balkany]

As the number of cores on a processor increase, parallel processing is going to become more of a consideration for overall processing speed. Other advances in hardware (more registers and larger caches) will also require updating the older numerical methods code, optimized for single-process FORTRAN with few registers and a small cache. Modern processors now overlap the execution of several sequential instructions in parallel, even for a single process (pipelining). This has allowed optimization techniques that expand the branch-free regions of inner loops to facilitate this (e.g. loop unrolling). Bottom line: Know your hardware, because it will impact your software's performance in ways you might not anticipate from a pure software viewpoint.

[Euhemerus]

Gary R. Wheeler wrote:

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.

Your having a laugh! Compare a compiled program's size to the the same program written in assembly language and i'll put money on it that it's at least 4 to 5 times the size. So all those extra, superfluous instructions are just wasting processor time in the compiled version.

Nobody can get the truth out of me because even I don't know what it is. I keep myself in a constant state of utter confusion. - Col. Flagg

[Sterling Camden independent consultant]

Even assembly can be made slower than other languages if you don't know what you're doing. Granted, assembly adds the least overhead of its own, but the biggest overhead of all is over your shoulders.

Contains coding, but not narcotic.

[Kieryn Phipps]

It's the compiler that matters more than the language. Any compiler that is written specifically for a native architecture is going to do better than one that is standard or for a general architecture. Also certain compilers may work better with certain algorithms. Same for the language probably - perhaps certain algorithms work better for certain languages. In terms of language, there will be probably be little difference between C, C++ or Fortran. It will depend most on which compiler you choose and the algorithm you are writing than it will the language.

[Kieryn Phipps]

This is spot on. I did a year of Aerospace Engineering at University before switching to Computer Science. We used Fortran in Engineering because it was numerically tight. It has strict standards on numerical accuracy and replicating results independent of platform or compiler. I never used or have heard of anyone else using Fortran since that switch. Regardless of speed, if numerical accuracy matters then stick with Fortran. I have seen first hand that the same code in other languages like C/C++ can produce slightly different results depending on the compiler used because the standards are not as strict.