Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. Which language is faster?

Which language is faster?

Scheduled Pinned Locked Moved The Lounge
delphialgorithmsquestionlearning
61 Posts 33 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • F Franc Morales

    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.

    L Offline
    L Offline
    leonej_dt
    wrote on last edited by
    #5

    No. Building your own special-purpose computer, redesigning each component if necessary, is actually unbeatable.

    Eduardo León

    F 1 Reply Last reply
    0
    • L leonej_dt

      No. Building your own special-purpose computer, redesigning each component if necessary, is actually unbeatable.

      Eduardo León

      F Offline
      F Offline
      Franc Morales
      wrote on last edited by
      #6

      Funny but not the answer to the question "Which language is faster?"

      1 Reply Last reply
      0
      • D Dr Walt Fair PE

        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

        OriginalGriffO Offline
        OriginalGriffO Offline
        OriginalGriff
        wrote on last edited by
        #7

        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 have no idea what I did, but I'm taking full credit for it." - ThisOldTony
        "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt

        G 1 Reply Last reply
        0
        • D Dr Walt Fair PE

          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

          J Offline
          J Offline
          JimmyRopes
          wrote on last edited by
          #8

          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

          D 1 Reply Last reply
          0
          • D Dr Walt Fair PE

            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

            L Offline
            L Offline
            Luc Pattyn
            wrote on last edited by
            #9

            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.

            D 1 Reply Last reply
            0
            • D Dr Walt Fair PE

              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

              G Offline
              G Offline
              Gary R Wheeler
              wrote on last edited by
              #10

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

              1 Reply Last reply
              0
              • OriginalGriffO OriginalGriff

                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.

                G Offline
                G Offline
                Gary R Wheeler
                wrote on last edited by
                #11

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

                D D E 3 Replies Last reply
                0
                • D Dr Walt Fair PE

                  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

                  K Offline
                  K Offline
                  Keith Barrow
                  wrote on last edited by
                  #12

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

                  D 1 Reply Last reply
                  0
                  • D Dr Walt Fair PE

                    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

                    A Offline
                    A Offline
                    Andy Brummer
                    wrote on last edited by
                    #13

                    Depends what you are doing, but I'm learning GLSL right now. ;) CUDA[^]

                    Curvature of the Mind

                    D 1 Reply Last reply
                    0
                    • D Dr Walt Fair PE

                      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

                      S Offline
                      S Offline
                      Snowman58
                      wrote on last edited by
                      #14

                      "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

                      D 1 Reply Last reply
                      0
                      • P peterchen

                        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

                        D Offline
                        D Offline
                        Dr Walt Fair PE
                        wrote on last edited by
                        #15

                        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

                        1 Reply Last reply
                        0
                        • J JimmyRopes

                          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

                          D Offline
                          D Offline
                          Dr Walt Fair PE
                          wrote on last edited by
                          #16

                          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

                          1 Reply Last reply
                          0
                          • L Luc Pattyn

                            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.

                            D Offline
                            D Offline
                            Dr Walt Fair PE
                            wrote on last edited by
                            #17

                            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

                            1 Reply Last reply
                            0
                            • K Keith Barrow

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

                              D Offline
                              D Offline
                              Dr Walt Fair PE
                              wrote on last edited by
                              #18

                              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

                              K 1 Reply Last reply
                              0
                              • A Andy Brummer

                                Depends what you are doing, but I'm learning GLSL right now. ;) CUDA[^]

                                Curvature of the Mind

                                D Offline
                                D Offline
                                Dr Walt Fair PE
                                wrote on last edited by
                                #19

                                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

                                S 1 Reply Last reply
                                0
                                • S 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

                                  D Offline
                                  D Offline
                                  Dr Walt Fair PE
                                  wrote on last edited by
                                  #20

                                  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

                                  1 Reply Last reply
                                  0
                                  • G Gary R Wheeler

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

                                    D Offline
                                    D Offline
                                    Dr Walt Fair PE
                                    wrote on last edited by
                                    #21

                                    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

                                    1 Reply Last reply
                                    0
                                    • D 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

                                      K Offline
                                      K Offline
                                      Keith Barrow
                                      wrote on last edited by
                                      #22

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

                                      1 Reply Last reply
                                      0
                                      • D Dr Walt Fair PE

                                        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

                                        S Offline
                                        S Offline
                                        Stefan_Lang
                                        wrote on last edited by
                                        #23

                                        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

                                        K D 2 Replies Last reply
                                        0
                                        • D 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

                                          S Offline
                                          S Offline
                                          Stefan_Lang
                                          wrote on last edited by
                                          #24

                                          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?

                                          1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups