Re: Choice of programming language

Language choice is a deeply religious issue, you'll be hard pressed to
find people who give answers backed up by much more than feelings and
stories.

If absolute performance is your goal, code up some test cases and
compare for yourself. The answer will vary depending on the problem,
the computer architecture, and the compiler.

If someone is using the arbitrary precision facilities of Java, they've
thrown performance out the window. Arbitrary precision and fast don't
belong in the same sentence. AP is a 1000lb hammer. When you need it,
you absolutely have to have it, and you're willing to pay the price for
it.

Fortran has been the historical answer, but one of the key reasons for
its supremacy has been the maturity of the compilers. I don't know
that this applies to the F90/F95/F2003 compilers the way it did to the
F77 and older. I also don't know how well the Fortran compilers are
keeping up with the new processors.

Do you have a bunch of money to drop on a compiler, or are you going to
use something free & readily available? It makes a big difference.

Java isn't slow by definition. It is slow by dogma. Google around,
you'll find as many modern benchmarks showing it is faster than C or
Fortran as it is slower.

Despite all this, I would suspect that the best language for a
particular problem should seldom be decided by raw performance alone.
Who writes finely tuned code? Who spends lots of time profiling their
code to see where speedups can be made? Who achieves that last 1% of
performance? I don't. I would rather spend that time debugging,
improving the algorithm, the physical model, running cases, making
money, or writing papers.

Instead, the choice is probably made by programmer familiarity,
existing code base, compiler availability, etc.

Those aren't always good reasons for making a choice, but they're what
happens in the real world.

I realize that my reply raises more questions than answers, but this is
because I have been pondering the same question for one of my future
projects, and I would appreciate some informed opinions and debate on
the subject without religion and dogma.

With quad-core hyperthreaded laptop computers around the corner, I
think that real performance gains will come from writing good
multithreaded programs more than from raw speed. For truly large scale
problems, extend this to multiprocessor computers and distributed
(Beowolf) computers. Language / compiler support for these
technologies will be critical.

How important is portability to you? Compile once, run anywhere?
Compile anywhere & run? Fight it anywhere?

Also, look at the language constructs you will be using. Will you be
working with pure arrays, or will you be using trees, hashtables, and
other data structures? Will primitive variables be sufficient, do you
need structures, or are you familiar with true object oriented
programming? New Fortran supposedly supports OOP concepts, but I don't
know how well, and the compilers can't be as mature as tried and true
F77.

If you're looking at an unstructured approach to a problem, you can
work with arrays, but you'll be much more comfortable with another data
structure. I think algorithmic gains by proper data structure choice
are often more important than raw number crunching performance.

If your program will only be used 'in-house' then I think Matlab is a
very viable contender. Matlab can be very fast, supports OOP (though
not always elegantly), has high-level support for matrix / vector
operations that are a joy to work with, and it has good visualization
capabilities built-in. If code development time is important, Matlab
is tough to beat.

For example (one that I have very little idea about the state of the
art, but it seems straightforward for this discussion) consider a
massive N-body problem. The conventional Fortran approach would be to
throw a big array at it and crunch away. A more elegant approach would
be to use a bounding-box octree to hold the points, calculating
influence between nearby bodies directly, but lumping the influence of
far away bodies. Parallelizing the array approach becomes ugly, with
lots of communication needed. The octree brings some elegance to
parallelization. However, doing an octree approach without proper
language support would be a nightmare.

You have to judge the language with your problem, your approach, and
your skills in mind.

I hope this helps,

Rob

.

Relevant Pages

  • Re: "STL from the Ground Up"
    ... high-level intermediate language than can interoperate with many other ... If your language lacks expressive features then you cannot write code ... memory management in comparison. ... Mostly because type errors mean that the programmer and compiler disagree ...
    (comp.programming)
  • Re: Fortran 2003 and F
    ... >> As the Fortran language keeps getting bigger, ... Walt's F compiler doesn't have ... what part of object-oriented programming ...
    (comp.lang.fortran)
  • Re: A note on computing thugs and coding bums
    ... It would handle international characters if the execution character ... method I used in "Build Your Own .Net Language and Compiler". ... work areas and counting on Nul is an illusion. ...
    (comp.programming)
  • Re: WaitForSingleObject() will not deadlock
    ... represent an incorrect implementation of the language. ... the *compiler* does not guarantee this. ... but to state it in terms of the execution instead of the formal semantics of the language ... as long as the optimizations do not change the semantics of the language). ...
    (microsoft.public.vc.mfc)
  • Re: subroutine stack and C machine model
    ... Use a compiler optimizer ... higher determinism means that optimizer has more information. ... C programmers like to brag that their "language" is more ... prospective computer science majors at Princeton. ...
    (comp.lang.c)
Loading