FORTRAN 2-3 times faster than C++

#1 @Eric: Unfortunately though, the kind of game-genres you'd have coming from Fortran programmers would be:-

- Attack of the Statistical Asymptotic Expansions
- Differentiation Invaders
- Marble Blast on Polynomial Surfaces
- Too much thinking Tanks
- Manifold Zap
- GISH (Geometric Invariance of Spatial Harmonics)
- Elliptic Curve Construction Set

... and so on and so forth. ;)

(and to answer your question, I haven't got a clue on which would be faster)

- Melv.

#2 FORTRAN scared me out of programming for almost 3 years =)

#3 How about Dark Horizontal and Vertical Robots?

#4 >FORTRAN scared me out of programming for almost 3 years =)
That sounds like an interesting story. What happened?

>Unfortunately though, the kind of game-genres you'd have
>coming from Fortran programmers would be
Yeah, I don't know anyone who programs games in FORTRAN. It seems to be used a lot for scientific computing, though. I used to think that the only reason for learning FORTRAN was to understand old code, but now I know quite a few people who wouldn't use anything else. All the theorists in my department are FORTRAN programmers, and many of my classmates are taking FORTRAN classes.

#5 I had a FORTRAN class in high school back in 1990, don't remember it though. It's good for what it was designed for.

#6 Fortran is probably one of the best named languages out there--it stands for FORMula TRANslation--and is very very good at what it does. It is focused almost exclusively on being a language for implementing complex scientific formulas and mathematics, and with such a highly specialized target, good fortran compilers are very fast--but you will find yourself looking for functionality that you are used to having in C, C++, or whatever other language you use for non-scientific things.

Personally, if someone were to say they wrote a physics package in fortran as opposed to C/C++, I myself would be very interested in taking a strong look at the pack...both performance and accuracy should be extremely impressive for something like this done in a language that was made for it!

#7 There is one statement I am very skeptical about is : "The X Language is faster than the Y Language".

If this was true, all you had to do is create a Y Language compiler that generates code in the X Language and then run it thru the X compiler.

What slows down something isn't really the compiler, but the algorithm that was programmed, a sort command may be implemented either as a "bubble sort" or as a "quick sort". While the first takes takes N squared time (N being the number of entries ), the latter takes NlogN time which makes it real faster for a big N.

I beleive that the Fortran libraries are VERY well optimized for what they are supposed to do. They weren't optimized by the compiler, but by the programmers.

#8 Um the this is faster then that taken out of context is BS.

Sure fortran will outperform c++ in a given mathmatical algorithm but it lacks the other 90% of the stuff you can do in c++ that you cant do in fortran. There are plenty of things C++ will do faster then Fortran and many things fortran cant even begin to do at all because it lacks the functionality.

im mean come on, hand written assembly thats is well done is faster then all of them in some cases due to weaknesses in compilers (this is less and less true as they get better).

there is almost always a case where you can get one language to "beat" another by doing a feeble comparision that involves comparing the strength of one (like math in fortran) to one of many abilities of another.

its like saying this car is faster then that one (but only in the quarter mile as it can make turns like the other one thats "slower" but more versatile).

#9 Just to throw a gasoline soaked cloth onto the fire here...

Check out Jake2...the Quake 2 engine written in pure Java. No kidding.

#10 Bruno's post matches my own thoughts on this issue. Even if c++ has various other functionality, what is stopping a c++ compiler or library from using exactly the same implementation as a fortran compiler for those portions of code which are easily translated to fortran. When I first started learning fortran, I thought that would be only a small portion, but the link I gave in my first post shows that the most common c++ functionality is available in fortran 90.

Stephen's argument is interesting. The problem I see with it is that after all the effort of developing faster ways to compile a fortran program, wouldn't that same knowledge be applied to c++ also once the work is already done? The only way this makes sense is if companies working on fortran compilers and libraries (1) do not also produce compilers and libraries for other languages and (2) have no interest in licensing their technology to other companies who produce non-fortran compilers and libraries. It's possible that both of these are true for all of the best fortran companies, but it just doesn't seem likely.

#11 There are language features that can make 'X language is faster than Y language' a true statement - things like garbage collection, bounds checking, virtual machines and so on.

C++ and fortran are about the same in terms of these features (they don't have them), so they are equally fast.

Your Fortran programmer friends are just spewing the same things all partisan programmers say. If you worked with Scheme or Cobol programmers, you'd probably hear them claiming to be faster than C++ too. ;)

#12 Just as an aside... The previous posters remark that FORTRAN stands for (FORmula TRANslation) is mistaken. FORTRAN is based on a much older language called FORTH, which over time took on extra characteristics much as C took on OOP characteristics. FORTRAN means FORTH TRANslated, and is much the same to FORTH as C++ is to C.

It is an evolutionary change of the FORTH language.

#13 Uh, no.

Fortran is in no way related to Forth. First of all, Forth was developed at least 10 years later. Forth is a stack based language and has nothing in common with Fortran. Forth is used in the OpenFirmware standard.

Here's some more info for anyone interested.

en.wikipedia.org/wiki/Fortran
en.wikipedia.org/wiki/Forth_programming_language

#14 Nope, that's erroneous : FORTRAN means Formula translation and existed before FORTH, since FORTRAN dates back to the 50s, while FORTH is much more recent
If you don't believe it, check the bio of Chuck Moore, the guy behind FORTH, which was a pun on fourth generation language : he was using Fortran before he started working on FORTH in the late 60s.
If there is a link between the two, is that FORTH might be seen as a descendent of FORTRAN, not the other way around.

#15 If the above is true, then I need to hunt down my college professor and have him correct his text book. Anyways, looks like thats what I get for remembering :)

#16 Wow, can't believe how much FORTRAN knowledge some of you guys have :)

Here's an off-topic question. FORTRAN 90 doesn't seem to like it when I try to use allocatable arrays as type members. Any way to get around this? My only idea so far is to use linked lists instead, but since types don't have destructors I would have to remember to deallocate the linked lists every time the type went out of scope, not fun.

#17 LOL@names of games

#18 I heard a rumor that assembly is faster than visual basic ;)

#19 And easier too!

#20 Just to Chime in here.

I agree with the "x is faster than y" post. I think its misleading to say one "language" is faster than another because so many other factors play into how an application performs than the actual language its written in. Between different C++ compilers you may run into different performance measurements or better yet between different platforms.

As a matter of fact I would say that the "Compiler" and how the compiler translates the code down to assembler instructions, the "platform", the "type of application", and the "language specific features", would be the correct reasons for choosing a certain language.

I've read a couple of good books that discussed the C++ relationship with C and how C compiles down to Assembler Instructions through various flavors of compilers. What was really cool was learning about the number of assembler instructions certain C statements produced when compiled. It was extremely revealing because I discovered that

1 - I was just writing shitty C++ code LOL. (Code that generated way too many Assember instructions, hogged up too much system resources, and used inefficient algorithms)
2 - I was using a lot of libraries that sacrificed efficient memory and processor usage in favor of easy coding
3 - I didn't understand what my compiler, linker or language were really doing

That's why my apps were slower and not because of the language.

I would say that you should have your FORTRAN Comrads and C++ Comrads explain their opinion armed with this kind of information and applying it to a specific example before accepting the opinion, and even then accept it for that application and not as the rule for all apps written in the language.

Oh and Hell yea VB is faster than Assembler LOLOLOLOL