Ask Slashdot: Best Language To Learn For Scientific Computing?

New submitter longhunt writes "I just started my second year of grad school and I am working on a project that involves a computationally intensive data mining problem. I initially coded all of my routines in VBA because it 'was there'. They work, but run way too slow. I need to port to a faster language. I have acquired an older Xeon-based server and would like to be able to make use of all four CPU cores. I can load it with either Windows (XP) or Linux and am relatively comfortable with both. I did a fair amount of C and Octave programming as an undergrad. I also messed around with Fortran77 and several flavors of BASIC. Unfortunately, I haven't done ANY programming in about 12 years, so it would almost be like starting from scratch. I need a language I can pick up in a few weeks so I can get back to my research. I am not a CS major, so I care more about the answer than the code itself. What language suggestions or tips can you give me?"

Comments

Python

[curunir]

I have a friend who works for a company that does gene sequencing and other genetic research and, from what he's told me, the whole industry uses mostly python. You probably don't have the hardware resources that they do, but I'd bet you also don't have data sets that are nearly as large as theirs are.

You might also get better results from something less general purpose like Julia, which is designed for number crunching.

Re:Python

[the gnat]

the whole industry uses mostly python

This is certainly the way of the future, not just for gene sequencing but many other quantitative sciences, although a complete answer would be Python and C++, because numpy/scipy can't do everything and Python is still very slow for number-crunching. It's best to start with just Python, but eventually some C++ knowledge will be helpful. (Or just plain C, but I can't see any good reason to inflict that on myself or anyone else.)

Re:Python

[Anonymous Coward]

Python is the new VB.

Re:Python

[Garridan]

I use Sage. When Python isn't fast enough, I can essentially write in C with Cython. It's gloriously easy. Have some trivially parallelizable data mining? Just use the @parallel decorator. Sage comes with a slew of fast mathematical packages, so your toolbox is massive, and you can hook it all in to your Cython code with minimal overhead.

Re:Python

[shutdown -p now]

a complete answer would be Python and C++, because numpy/scipy can't do everything and Python is still very slow for number-crunching.

The problem with using the mix (when you actually write the C++ code yourself) is that debugging it is a major pain in the ass - you either attach two debuggers and simulate stepping across the boundary by manually setting breakpoints, or you give up and resort to printf debugging.

OTOH, if Windows is an option, PTVS is a Python IDE that can debug Python and C++ code side by side, with cross-boundary stepping etc. It can also do Python/Fortran debugging with a Fortran implementation that integrates into VS (e.g. the Intel one).

(full disclosure: I am a developer on the PTVS team who implemented this particular feature)

Re:Python

[shutdown -p now]

Python is VB done right.

Re:Python

[shutdown -p now]

You can use Cython for heavy lifting without dropping all the way down to C.

Re:Python

[SJHillman]

VB is feeding your scrotum to a python.

Re:Python

[rwa2]

Yes, I did my master's thesis using simpy / scipy, integrated with lp_solve for the number crunching , all of which was a breeze to learn and use. It was amazing banging out a new recursive algorithm crawling a new object structure and just having it work the first time without spending several precious cycles bugfixing syntax errors and chasing down obscure stack overflows.

I used the psyco JIT compiler (unfortunately 32-bit only) to get ~100x boost in runtime performance (all from a single import statement, woo), which was fast enough for me... these days I think you can get similar boosts from running on PyPy. Of course, if you're doing more serious number crunching, python makes it easy to rewrite your performance-critical modules in C/C++.

I also ended up making a LiveCD and/or VM of my thesis, which was a good way of wrapping up the software environment and dependencies, which could quickly grow outdated in a few short years.

Re:Python

[dmbasso]

The problem with using the mix (when you actually write the C++ code yourself) is that debugging it is a major pain in the ass

Only if you don't use the C/C++ code as an independent module, as it should be. If you *must* debug it in parallel, you're designing it wrong.

Re:Python

[Anonymous Coward]

VB is closed-source trash.

Re:Python

[polyphemus]

+1

I was using Mathematica in grad school (experimental physics). Great for simple number crunching, but awful for doing anything programmatically interesting, and annoyingly expensive.

I'm now using Python and loving it.

Re:Python

[shutdown -p now]

How do you write C++ code for use from Python such that it's not an independent module?

Anyway, regardless of how you architecture it, in the end you'll have Python script feeding data to your C++ code. If something goes wrong, you might want to debug said C++ code specifically as it is called from Python (i.e. with that data). Even if you don't ever have to cross the boundary between languages during debugging, there are still benefits to be had from a debugger with more integrated support - for example, it can show Python representations of objects that were passed to your C++ code.

Re:Python

[ebno-10db]

Perl is still in wide use.

Do not use Perl for this. I've been using Perl for 15-20 years, and I love it for "scripting", text processing, etc., but using it for scientific computing sounds like an exercise in masochism.

Re:Python

[alexgieg]

I was using Mathematica in grad school (experimental physics).

That wasn't the right tool for the task. Mathematica is for symbolic math, not number crunching.

Re:Python

[Monkey-Man2000]

a complete answer would be Python and C++, because numpy/scipy can't do everything and Python is still very slow for number-crunching.

That's why more people should check out Cython. It's basically it's own language modeled closely after Python but uses C-like language constructions when optimizations are helpful. I quite liked it when I checked it out, but I haven't been following it much recently.

Re:Python

[mwvdlee]

Python is suicide inducement done right?

Re:Python

[khellendros1984]

I wrote an AES implementation in Perl once. It was horrifically sluggish, and I don't recommend it.

Re:Python

[dmbasso]

How do you write C++ code for use from Python such that it's not an independent module?

I mentioned C/C++ because of the context, but I was actually referring to the logical aspect of the system. You can (and I know people who do) make spaghetti-code even with, for instance, RPC calls.

Anyway, regardless of how you architecture it, in the end you'll have Python script feeding data to your C++ code.

That's the point: you should not depend on that. The C++ code must be thoroughly tested independently of the Python code. You know, the whole high cohesion / low coupling thing.

If something goes wrong, you might want to debug said C++ code specifically as it is called from Python (i.e. with that data).

Then you should use that recorded data in your C++ unittests.

Even if you don't ever have to cross the boundary between languages during debugging, there are still benefits to be had from a debugger with more integrated support - for example, it can show Python representations of objects that were passed to your C++ code.

Even if your debugger had not that feature, it would still be useful. My point is that a good developer should need your debugger only on special cases (e.g. when you don't have access to all the code).

Re:Python

[wanax]

Sage is okay for small-midsize projects, as is R (both benefit from being free).. on the whole though, I'd really recommend Mathematica, which is purpose-built for that type of project, makes it trivial to parallelize code, is a functional language (once you learn, I doubt you'll want to go back) and scales well up to fairly large data sets (10s of gigs).

Re:Python

[RDW]

I have a friend who works for a company that does gene sequencing and other genetic research and, from what he's told me, the whole industry uses mostly python.

I think your friend is mistaken. Though it's essential to know a scripting language, most of the computationally expensive stuff in sequence analysis is done with code written in, as you might expect, C, C++, or Java. Perl and Python are used more for glue code, building analysis pipelines, and processing the output of the heavy duty tools for various downstream applications. R is used heavily for statistics, and especially for anything involving microarrays.

Re:Python

[TopherC]

For numeric code, I find that stepwise debugging is rarely helpful and never necessary. Print statements are my primary tool for spot-checking numbers, data structures, and even for evaluating the general flow of the program. The next tool is to create histograms and other plots of the data you're getting at various stages or calculations. By varying the inputs and seeing the effects on plots (in vague terms), you have a very powerful and underrated diagnostic. The more work you put into analyzing your program's data, the better off you'll be.

I second the Python/C++ combination, and should add that you can do a lot with numpy and scipy so you may very well not need the C++ side of things.

I've also written a lot in Fortran years ago, but only because I was working with a ton of legacy code. Compared to C and C++, Fortran is actually more elegant for pure numerical computing. I'm not actually recommending it, mind you, but I also found the main weaknesses of Fortran could be mitigated by writing wrappers in Perl to get data in and out. Java is not actually bad for numerical code either, and it's arguably easier to learn than C++. I guess I'm saying this to point out that it doesn't actually matter much what language you use. Visual basic is a rare exception -- never use that for any reason. :-) And you have to be aware that high-level languages like Python are going to be slow if you have no consideration for what operations are time-consuming. Be particularly mindful of memory allocation / object creation.

Re:Python

[Bill_the_Engineer]

Do not use Perl for this. I've been using Perl for 15-20 years, and I love it for "scripting", text processing, etc., but using it for scientific computing sounds like an exercise in masochism.

I use Perl (admittedly not by choice) for scientific computing and it is used daily to process very large files of raw instrument data. You can use NYTProf and Inline::C to make necessary speed improvements and the CPAN library is extensive.

Re:Python

[shutdown -p now]

I don't argue that unit tests and other forms of automated testing should be your first line of defense. I've yet to see a sufficiently large codebase with 100% coverage, though, and that's not even getting into the debate of what "coverage" really means. In practice, no matter how much coverage you have, you will run into issues eventually when running your code on real data in production, where it's all working together - and that's when you'll need to debug it to figure out what exactly is wrong and fix it (and then, of course, write a unit test to cover that case, for future regression testing).

By the way, unit testing does not necessarily mean language isolation. For example, one of our users is a company that writes most of their code in Fortran, but uses Python to write unit tests for it - the tests themselves are shorter and clearer, Python has a good standard unit testing framework, and Python IDEs support them well, integrating them into the regular coding workflow.

Re:Python

[Jane Q. Public]

"This is certainly the way of the future, not just for gene sequencing but many other quantitative sciences, although a complete answer would be Python and C++, because numpy/scipy can't do everything and Python is still very slow for number-crunching."

I mostly agree with your conclusion, but for somewhat different reasons. I don't believe Python is "the wave of the future", but rather I'd recommend it because it has been in use by the scientific community for far longer than other similar languages, like Ruby. Therefore, there will be more pre-built libraries for it that a programmer in the sciences can take advantage of.

I also agree that some C should go along with it, for building those portions of the code that need to be high performance. I would choose C over C++ for performance reasons. If you need OO, that's what Python is for. If you need performance, that's what the C is for. C++ would sacrifice performance for features you already have in Python.

If it were entirely up to me, however -- that is to say, if there weren't so much existing code for the taking out there already -- I'd choose Ruby over Python. But that's just a personal preference.

Re:Python

[Garridan]

I've used Sage on a supercomputer, chugging through hundreds of gigs of data. Do you know what you're talking about, or are you just recommending the shiny thing that you paid lots of money for?

Re:Python

[Princeofcups]

Perl is still in wide use.

Do not use Perl for this. I've been using Perl for 15-20 years, and I love it for "scripting", text processing, etc., but using it for scientific computing sounds like an exercise in masochism.

I have a friend who worked on his PhD in Physics with a combination of C and Perl. The C for the heavy compute intensive number crunching, and Perl for the final correlation and make-it-pretty part. That worked quite well for him, since he's a professor now.

Re:Python

[Joce640k]

Compared to C and C++, Fortran is actually more elegant for pure numerical computing.

Unsurprising - that's what Fortran was designed for...!

Re:Python

[shutdown -p now]

No, it's a simple language that is easy for beginners to learn. But, unlike VB, it is not horribly designed, and is useful even once you grow out of the beginner phase.

Re:Python

[Darinbob]

It's impossible to have VB done right.

Re:Python

[columbus]

There are a lot of good suggestions in this discussion so far.

I have a few points to add.
1) compiled language vs scripting language
In general, any compiled language is going to run faster than any scripting language. But you will probably spend more time coding and debugging to get your analysis running with a compiled language. It is useful to think about how important performance is to you relative to the value of your own time. Are you going to be doing these data mining runs repeatedly? Is it worth spending ten times as many hours getting this thing up and running if by doing so, you can get it to run really fast? If so, than chose a compiled language. You're already familiar with C so that would be a natural choice. If, after consideration, you value your development time more than processing time, stick with a scripting language. You'll probably be able to stand up a working program much faster & you can look for other ways to squeeze out extra performance

2) Parallelism. Your initial question explicitly said you want to use all 4 cores on a Xeon, but I've only seen 1 response so far that addresses this issue. To get good performance out of multiple cores you may need to re-work your algorithms to split the problem into pieces and crunch them down in parallel. Is your problem one that is easily amenable to parallelization? If yes, then you probably want to start thinking about multi-thread or multi-process programming. If your program will never run on something bigger than 1 server, than you will probably be OK sticking with with single multi-threaded process. I don't have experience in this myself, but I've heard that writing your program in a functional language like Haskell will make it intrinsically easy to parallelize. If you ever think your program is going to run on something bigger than that Xeon server - let's say you're thinking of ramping up to a cluster, than I would suggest building it on top of MPI from the beginning. I've had good results getting something up and running on MPI quickly using a combination of python, NumPy, SciPy and mpi4py.

Good Luck.

Re:Python

[Anonymous Coward]

Mathematica is useful for data processing if there is some already existing code that does exactly what you need, or you have a problem that could use benefit from it handling arbitrary functions efficiently by working with them symbolically before doing number crunching. But after having been experienced at programming in Mathematica, I switched to Matlab for data analysis and had no desire to go back. More recently, I've been able to do nearly everything I did in Matlab with NumPy, minus frustrations with a license server.

Re:Python

[jdavidb]

Debugger versus printf debugging is a false dichotomy. Better to have a nice logging system that is implemented in both languages. (But my coworkers think I'm irrational for favoring logging over debuggers, so probably noone will agree.)

Re:Python

[shutdown -p now]

It's not really a versus thing - printf debugging is still useful in conjunction with interactive debuggers, especially when there is some support for this combo (e.g. you get some kind of special "debug printf" that outputs to the dedicated debugger window, like Debug.Write in .NET).

Re:Python

[occasional_dabbler]

Erm, what's wrong with using good ol' FORTRAN with Python/Numpy/Scipy? Combined with the multiprocessing module I have coded up some very fast multi-core routines in very little time. f2py is almost stupidly easy to use, especially on Linux

Re:Python

[Just Some Guy]

I wrote some Perl that looked like the output of AES once.

Re:Python

[Mitchell314]

I've seen python, perl, and java bioinformatics software. Not much of C or C++. I've used matlab and it's pretty good for doing heavy number crunching and graphing. SAS OTOH is a PITA.

Re:Python

[shutdown -p now]

There's absolutely nothing wrong with using Fortran, with Python or by itself. It's just that if you already know C or C++, it's probably "good enough" for the high-perf part that there isn't much point in learning yet another language.

Re:Python

[amacbride]

True, though most aligners are written in C/C++; lots nowadays take advantage of CUDA.

Re:Python

[rahvin112]

Some of us like masochism, no give me my whip back.

Re:Python

[joetainment]

>> Python and C++, because numpy/scipy can't do everything

Yes, definitely true, and it's actually pretty easy to use them together.

If you don't want to write C++ however, there are a couple other options:

Cython - basically let's you generate c/c++ by writing Python like code and is very easy to use interacting with Python. It keeps the Cython parts of your code super fast, like straight up C.
http://cython.org/

Pypy - a super fast version of Python. If you write Python code yourself, and don't use off the shelf Python stuff, Pypy is crazy fast. (About C speed in my own tests of doing C like things.) Pypy gets slower if you use a lot of other Python code that wasn't written with Pypy in mind, but even then it's still normally much faster than regular Python. Using Pypy, you might just be able to write all the code in it and not have to bother with anything else.
http://pypy.org/

Both of these are easy enough that you can be up and running, writing/using new code, same day as downloading.

Finally, even if you are calling other code from C/C++, there's some new tools to make that easier. CFFI is a good example. It makes calling C/C++ pretty easy. I'm not sure how ready it is for a lot of real world use though.
http://cffi.readthedocs.org/en/release-0.7/

Re:Python

[khellendros1984]

It was a school assignment. The professor told us to choose our own language to implement it in. I chose poorly.

Re:Python

[techno-vampire]

I agree with you that doing the number crunching is best in a language designed for that but I don't think C is the answer because it was primarily designed for systems programming, not numeric. If you really need efficient number crunching, go with FORTRAN, especially as the OP says that he already has experience with it.

Re:Python

[rwa2]

Yep. High level languages such as python are great for letting you focus on the domain-specific task you want to accomplish without spending years learning all the little poorly-documented compiler-specific idiosyncrasies of compilers and preprocessors and template languages. Once you're through the prototyping phase and have your interface definitions and unit tests set up, you can then toss things one module at a time over to one of those software weenies to turn into hand-optimized production code. And they'll probably be happier since they don't have to tax their communications skills talking to project managers while trying to figure out what's going on from a nebulous requirements definition document.

Re:Python

[elashish14]

As long as his friend isn't writing the actual code himself, then a scripting language should be perfectly sufficient. I know C, C++, Java as well as anyone else I know, and do a considerable amount of development in them, but when I was running simulations in graduate school, I didn't touch C++ once - all I used was Scheme the front-end to my simulation package), Python (glue) and bash (a little more glue). Worked great for me, and I'm a fine developer in any maintstream language.

Re:Python

[lennier1]

True!

Python seems to be especially popular among mathematicians.
Thinking back to my university days and how Matlab tended to piss me off at every opportunity, I can't really fault them for that.

Re:Python

[sg_oneill]

VB (We're refering to VB6 here right? I know very little about vb.net except I dont know any coders who use it) wasn't a bad language because it was accessible to beginners. It was a bad language for the same reason PHP is held in disrepute. Its because many of the underlying assumptions are poorly thought out.

VB encouraged poor type hygiene, made it difficult to abstract business processes in any sort of rational way (You tended to just drop the business logic under the buttons and glue com objects in for functionality) and encouraged a style of programming where people would just draw up the screens and then put in just enough code to make it behave like the spec. This is like old world PHP where people would just mess in logic and presentation, and end up with an awful unmaintainable mess with SQL injections, magic globals and other sorts of horrors.

Python is indeed accessible to the beginner, but its accessible because its concise and readable. It encourages proper abstraction, has a clean and readable OO system, and a great library of USUALLY well written libraries.

It has shown a few wrinkles adapting to some more recent ideas such as closure oriented programming (its the wrong choice for that) but its combination of computer-sciency abstraction and accessibility is the reason for its popularity with new coders, NOT its encoding of bad coding work flow.

Re:Python

[shutdown -p now]

That was precisely my point. Python is a language that's designed (among other things) to be accessible to beginners, and it's designed right for that. VB is a language with a similar goal (which it arguably reached), but with bad, inconsistent design that promoted numerous bad practices.

Re: Python

[tolkienfan]

Python is easy to learn, flexible and highly descriptive. It doesn't have undefined behavior like C, and there are libraries to assist with almost anything, especially scientific computing. There is even an MPI implementation for python. Just avoid tabs. Personally I use Octave and C depending. But for this purpose, C is too difficult. Not to be insulting - C has all kinds of quirks and is low level. The benefits aren't big enough for many things. Python is much quicker to become productive. Octave is even more descriptive for vectors and matrices, but less in other areas like IO and OO. Either of those would be my advice. Just make sure you vectorise the hell out of it. If you write a for loop you're incurring several orders of magnitude penalty in performance.

Re: Python

[tolkienfan]

I've written some very dense code quickly in Perl. I can't read it now, of course...

Re:Python

[hyperfl0w]

I have a friend who works for a company that does gene sequencing and other genetic research and, from what he's told me, the whole industry uses mostly python.

I work in a Gene Sequencing company and the current debate is: Python vs Clojure vs Scala:
Python unquestionably has the best bioinformatics support. Period. No debate. But the lack of language features has irked many programmers, myself included.
Clojure is gaining attention as a pure functional language with an R-like environment for large scale machine learning tasks. (Bioinformatics is machine learning applied to biomedicine). This makes porting Matlab/Octave/R code much easier, or so the thinking goes.
Scala has its backers. Java is nearly invisible in the bioinformatics world, but the JVM is hard to ignore. Scala has excellent support for Machine Learning but terrible support for "biological and medical applications". Hat tip: you can hire scala programmers or teach Scala to Java programmers in short time


BIG DATA is a bigger problem for us today than previously:
"genome wide arrays" used to mean all ~25,000 gene transcripts or 500,000 single DNA changes (SNP).
These revolutionary technologies are already considered "old".
The rise in performance and drop of cost of DNA sequencing is much faster than the commodification of CPUs during the internet dot-com race .

Re:Python

[hyperfl0w]

a complete answer would be Python and C++, because numpy/scipy can't do everything and Python is still very slow for number-crunching.

The problem with using the mix (when you actually write the C++ code yourself) is that debugging it is a major pain in the ass

+1 "I just spent three days chasing down build error that uses numpy/scipy"

Re:Python

[Jane Q. Public]

" If you really need efficient number crunching, go with FORTRAN, especially as the OP says that he already has experience with it."

That's true but there are a couple of problems with it. First, to this day, FORTRAN's input-output is still an abomination. And second, modern languages like Python and Ruby can import and work directly with C libraries, but as far as I know Fortran does not play nicely with them.

I agree that efficient number crunching is Fortran's forte. But I suppose it depends on what you are trying to do.

Re:Python

[ILongForDarkness]

Image processing in the biology space at least seems to be a combination of Matlab and applications developed in Java in my experience. Physics was still when I was going through (2004) mainly a C or Fortran land place. A C style language and you won't go wrong. I'd suggest C++ or C# to pull in the object oriented side of things and huge libraries. Computationally extensive data mining: lots of data or lots of post processing required? If it is just lots of data you'll be be limited mainly by disk/network speed and languages will be relatively less important. If it is a lot of crunching you'll probably want a lower level language like C/C++ or a mature VM language Java/.Net as non of the popular scripting languages can touch them for raw performance.

Re:Python

[ILongForDarkness]

Not saying it is right but in my experience in the scientific programming space unit tests essentially never get written. You stare into space and try to figure out what is long with your logic. You use printf statements. But you are hardly getting paid in the first place so spending a bunch of your time writing unit tests for code that you likely will be the only one that uses for ~1 year before you write your thesis just doesn't happen. There are just too many papers, conferences and beers to take part in. There are exceptions of course like if you are working on a project that is generating tools for the field to use (say image processing tool, n-body simulation framework etc) but those jobs are relatively rare compared to the "get data from this piece of equipment and generate a time series of fourier transforms of the data" type things that are essentially one offs).

Re:Python

[shutdown -p now]

Like I said, VB was horribly designed, which is orthogonal to it being an easy language to use. Yes, it let non-CS people design & write simple software. There are other, better ways to let non-CS people design & write simple software, which do not involve teaching them bad habits.

Re:Python

[Smerta]

Is there any Perl that /doesn't/ look like the output of AES? I look back at some of my one-liners from a year ago, and it's like, "WTF?!?!"

Re:Python

[khellendros1984]

Speed wasn't a requirement. Input for the assignment was something like a 16-byte key, with the message following (or an equivalently-simple arrangement). Output was the decoded message...which was a mixture of ASCII art and cryptography-related quotes.

Re:Python

[chrismcb]

Noooo! Not a Formula Translator!

Re:Python

[wanax]

I have little idea what works for supercomputers and highly parallized data analysis (I've never used one).. I work on data sets that tend to have memory bottlenecks, which I think describes a lot of exploratory data analysis activity... and in the framework, I've found one major advantage of mathematica is that I can leave the data intact, while creating a lot of code that accesses it in multiple forms, due to mathematica's ability to process the symbolic instructions before querying the dataset.

In terms of price of the shiny, I bought my initial license for mathematica for $500.. I've paid on average about $120/year for two licences (work and home) 8 and 6 core respectively.. It's hardly an expense.

Re:Python

[stoatwblr]

Which is why a lot of space science is done using fortran (despite the vast shortcoimings of Gfortran compilers)

A couple of branches of space science use IDL and other monstrosities for number crunching... ... Which leads to such inanties as someone writing an IDL program to call WGET 200,000 times to fetch files from an archive when one wget command would do the job.

People write in what they're used to writing. It's very hard to break habits.

Re:Python

[Garridan]

I have little idea what works for supercomputers and highly parallized data analysis (I've never used one).

Oh ok. So when you said Sage is okay for "small-midsize projects" and recommended Mathematica for large projects? You've only used Mathematica for small projects, and have no idea what a large-scale project is. And your pricing info is woefully outdated if you're recommending this to a new user.

Re: Python

[cheesybagel]

There are libraries for C as well like ATLAS for the Intel MKL. MPI implementations are usually written in C. You are just invoking a C library from inside python.

I agree that it is easier to write a prototype in python for such an application but I haven't had great experiences writing large python programs...

Re:Python

[ILongForDarkness]

Depends on the scale of the problem. I worked on things that took ~200k CPU hours back in the day when CPUs were single core. You couldn't sacrifice 2-10X the speed for ease of development. Also, professors were under the opinion of unless you coded it yourself you don't really understand it.

Re:Python

[occasional_dabbler]

The Fortran I'm writing is pretty much pseudo code. It's only the lowest level math stuff that looks exactly the same in any language, but is run thousands of times per loop. All you need of the language itself is subroutine(inputs, output) and you're done.

Fortran

[Anonymous Coward]

sorry to say, but that is a fact

Re:FORTRAN

[Anonymous Coward]

Yeah, sure.

So that no one can ever check your models or replicate your results even if you publish code and initial data.

Re:Fortran

[shutdown -p now]

It depends on what exactly his computationally intensive part is. It may be something that can be trivially implemented in Python in terms of standard numpy operations, for example, with performance that's "good enough".

Re:FORTRAN

[jythie]

Was that supposed to be a crack about popularity? Because auditing fortran is no worse then most other languages, and it can be argued that fortran is better then most in terms of being able to validate models.

Re:FORTRAN

[Frosty Piss]

Clearly you are not involved in serious science.

And if you think FORTRAN is some ancient esoteric languge, you're ignorent as well. The most recent standard, ISO/IEC 1539-1:2010, informally known as Fortran 2008, was approved in September 2010.

Fortran is, for better or worse, the only major language out there specifically designed for scientific numerical computing. It's array handling is nice, with succinct array operations on both whole arrays and on slices, comparable with matlab or numpy but super fast. The language is carefully designed to make it very difficult to accidentally write slow code -- pointers are restricted in such a way that it's immediately obvious if there might be aliasing, as the standard example -- and so the optimizer can go to town on your code. Current incarnations have things like coarray fortran, and do concurrent and forall built into the language, allowing distributed memory and shared memory parallelism, and vectorization.

The downsides of Fortran are mainly the flip side of one of the upsides mentioned; Fortran has a huge long history. Upside: tonnes of great libraries. Downsides: tonnes of historical baggage.

If you have to do a lot of number crunching, Fortran remains one of the top choices, which is why many of the most sophisticated simulation codes run at supercomputing centres around the world are written in it. But of course it would be a terrible, terrible, language to write a web browser in. To each task its tool.

Re:FORTRAN

[jonesy16]

Agreed. There are also OpenMP implementations for doing your parallel processing. If you're running on a Xeon processor then I would SERIOUSLY consider Intel's linux fortran compiler as it will provide the best performance by far.

Re:FORTRAN

[K. S. Kyosuke]

Before you C++ kids want to tell me something, read up on that Mr Kuck and his optimizers. Fortran optimizers did things about 20 years ago which C++ optimizers still cannot do.

Such as? (Please understand that I'd opt for Fortran instead of C++ for numerics any day of the week myself. But I think this is mostly a fallacy nowadays - I'm pretty sure the Intel stuff shares a major part between the two compilers.)

Re:FORTRAN

[Frosty Piss]

Having to read old FORTRAN is not a pleasant experience for someone who figures they can generally read languages without hitting a book of some sort,

Having some experience actually writing Fortran code helps...

Re:FORTRAN

[shutdown -p now]

It's totally possible to use Python and Fortran side by side. Fortran for heavy computational tasks, Python (with numpy) for glue wrapper code that loads the data and massages it into the desired shape before handing it over to that super-fast Fortran routine, and then visualizes the result

Re:FORTRAN

[Obfuscant]

Upside: tonnes of great libraries.

Those great libraries are spread across several different "FORTRAN"s. gfortran. gfortran44. Intel's fortran. f77. f90. PGI pgif90. etc. etc etc.

Gfortran is woooonderful. It allows complete programming idiots to write functional code, since the libraries all do wonderful input error checking. Want to extract a substring from the 1 to -1 character location? gfortran will let you do it. Quite happily. Not a whimper.

PGI pgif90 will not. PGI writes compilers that are intended to do things fast. Input error checking takes time. If you want the 1 to -1 substring, your program crashes. PGI assumes you know not to do something that stupid, and it forces you to write code that doesn't take shortcuts.

So, if you get a program from someone else that runs perfectly for them, and you want to use it for serious work and get it done in a reasonable amount of time so you compile it with pgif90, you may find it crashes for no obvious reason. And then you have to debug seriously stupidly written code wondering how it could ever have worked correctly, until you find that it really shouldn't have worked at all. They want to extract every character in an input line up to the '=', and they never check to see if there wasn't an '=' to start with. 'index' returns zero, and they happily try to extract from 1 to index-1. Memcpy loves that.

The other issue is what is an intrinsic function and what isn't. I've been bitten by THAT one, too.

And someone I work with was wondering why code that used to run fine after being compiled with a certain compiler was now segment faulting when compiled with the same compiler, same data. Switching to the Intel compiler fixed it.

Sigh. But yes, FORTRAN is a de-facto standard language for modeling earth sciences, even if nobody can write it properly.

Re:FORTRAN

[shutdown -p now]

It's mainly due to more constraints that Fortran places on data structures, e.g. lack of aliasing, that let the optimizer do a better job.

Re:FORTRAN

[Anubis IV]

Not really. My first job while still green and fresh out of high school was an internship with Lockheed Martin, working on hundreds of thousands of lines of meteorological software code that was used by NASA and was written in FORTRAN. I went in without ever having seen it before in my life, and was able to pick it up easily enough so that I was productive within a couple of weeks. I recall that having the first few columns of each line reserved for special uses threw me off the first time I saw it, as did parsing data, but I got used to it easily enough. I later did that same internship the next summer, took a class on FORTRAN during my time at university, and later, while in grad school, ended up as the Teaching Assistant on that class the very last semester it was ever offered at my university.

So, I think it's fair to say that I've been exposed to it more than most people in the under-30 crowd, though I've never been at a point where I'd consider it my primary language or my go-to language when I want to get something done. Even so, for what it's designed to do, it's hard to compete with it. I haven't had a reason to use it in at least five years, but were I involved in scientific computing that relied on number-crunching, I'd certainly consider it seriously. To not do so would be foolish, I think.

Re:FORTRAN

[K. S. Kyosuke]

Haven't the aliasing issues been ameliorated in the newer C/C++ revisions? I'm pretty sure that C99 has at least restricted pointers. Of course, it blows up into your face if you, in fact, do alias when calling such a routine with improper data, but at least it shouldn't block the optimizations.

Re:Fortran

[ebno-10db]

if you don't care about having your code be maintained or extended by anyone under age 30

1. There are plenty of programmers over age 30.
2. Someone who is 30 today, likely finished his BSc in 2005. Do you think Fortran was much more popular then?
3. People under age 30 learn Fortran if they're involved in HPC. It's still widely used, and has advantages over C/C++ (easy, built-in parallelization, etc.).

don't plan on doing any custom visualization beyond GNUplot

There are lots of other programs you can use besides GNUplot. In serious HPC graphics are often considered a back end that runs separately from the main program, and sometimes on a different machine.

don't care if you ever find employment outside of academia

1. You don't know what his major is - he may care less about putting the programming language du jour on his resume. In fact he specifically said "I haven't done ANY programming in about 12 years ... I am not a CS major".
2. If you do HPC, Fortran could be a very useful thing to put on your resume. All the more because it's obscure these days.

Don't think that whatever kind of code you write is the be all and end all of programming.

Re:FORTRAN

[ebno-10db]

When's the last time you tried to read Fortran, and what version was it? I originally learned Fortran IV (aka '66 -- '77 had come out but we didn't have a compiler for it). I cursed and moaned about it all the way. Some years later I had to work on a Fortran program and was dreading it. To my pleasant surprise it wasn't bad, because it was Fortran '90.

Re:FORTRAN

[mbkennel]

Fortran 95 or 2003 is better than C++ for numerical computation, if you don't need to do complex I/O or interact with data base libraries with C interfaces (and without Fortran interfaces).

Re:FORTRAN

[shutdown -p now]

C++ still doesn't have anything like "restricted", though. And in C land, I believe that optimizers still don't make a good use of it, probably because it came relatively late in the game (though I wounder about the newer compilers like Clang which should, in theory, be designed for the new standard from the grounds up).

Re:Fortran

[The_Wilschon]

This is exactly the right answer. Never write code that someone else has already written. If you can compose standard operations to do your calculations, then do so in a high-level language. Spend more time thinking and less time coding. OTOH, if you need to code up something custom and you're REALLY sure that you can't use standard operations to do it, then think again about whether or not you can do it with standard operations. You probably can. But, if you can't, then go with FORTRAN. Or maybe C or even C++. But probably FORTRAN. But even then, code as little as you can in FORTRAN. Don't write the whole thing in FORTRAN. Create small operations, and compose them in a high-level language as if they were the standard operations.

Re:FORTRAN

[Bill_the_Engineer]

Excellent synopsis. I would like to add that as a whole it is hard to beat the speed of Fortran in scientific computing.

However if you are like most grad students (or even established scientists) and need to do a quick "back of the napkin" calculations for your thesis, I'd recommend iPython with numpy and matplotlib. It is no where near the speed of fortran, but you more than make up for it in how quickly you can throw a routine together and for one-time or very occasional use speed isn't really a factor. Also nothing prevents you from flushing out the algorithm and writing it in fortran, or even better write the computationally expensive operations in fortran and binding it to python ( I've seen to binding libraries for that purpose ).

Re:FORTRAN

[steveha]

Seriously consider FORTRAN

On the other hand, the basic underpinnings of SciPy are FORTRAN. The BLAS and LAPACK libraries, and other fast and well-understood FORTRAN libraries, are "wrapped" by SciPy.

http://www.scipy.org/scipylib/faq.html#id12

Using the IPython notebook, you can work with data sets in an interactive way that FORTRAN won't do. But the number crunching is being done for you at FORTRAN speed because it is compiled FORTRAN code that is doing the work.

http://ipython.org/notebook.html

Re: FORTRAN

[ZiggyM]

I agree. Look up about compiler differences between c and fortran. Fortran allows the compiler to better know about things like if a variable can be put in a register or not because maybe some other thread has its address and might change it or whether it can auto paralellize some array processing etc. i love c/c++ and ive done large systems on both but for specific routines fortran rules.

Re:FORTRAN

[Obfuscant]

I recall that having the first few columns of each line reserved for special uses threw me off the first time I saw it,

That reminds me of more differences between standard FORTRAN compilers. There are compilers that default to free-form input, so your first few columns don' t mean what they used to. There are compilers that default to strict column definitions, so if your line runs past column 72 and it compiles fine with one compiler, don't expect it to compile on any other. And if your free form input runs past column (I forget which) and it compiles fine, another free-form input compiler will barf because it defaults to free-form input lines only shorter than that.

This is a day when standard packages for things come with a configure script and it is usually as simple as saying "./configure; make; make install" and you've got a working whatever. I have yet to see ANY modeling code written in FORTRAN come anywhere close. Most require hand editing of the Makefile to pick a compiler, and even when the Makefile contains references to which compiler was used by the original author, that compiler on YOUR system will gag on various parts. I've had to hand-edit the Makefile not to change the definition of FC, but to add author-provided functions to the lists of "compile me with the free-format flag" source, or "use 132 character free form lines".

This truly is job security for anyone who can debug and decipher crash dumps and wants to work in modeling.

Re:FORTRAN

[ebno-10db]

my go-to language

Bad pun.

Re:Fortran

[Darinbob]

Depends on environment. If you're going to be on a supercomputer, then Fortran compilers tend to do the most optimization out there. Plus Fortran really is designed for number crunching (even modern versions). On the other hand, most people are getting along just find with PCs, and you want to do parallelism Fortran doesn't necessarily help as much.

Re:FORTRAN

[Darinbob]

Fortran is the most popular scientific computing language. There are many people who will check the models and replicate it that way. Plus there are tons of old Fortran programs and libraries waiting to be used (ie, any decent scientist wanting to check the models or results of older programs will need to know Fortran).

In some sense, Fortran is like Windows. It's not pretty, everyone wants to do something better, but everyone sticks with it anyway because it's the most common and compatible option.

Re:Fortran

[fermion]

I started off in Fortran, and of course it was the language developed for science and maths. I know that it is still used in some places, but the people I know who have been in the technical industry for a very long time seem to be porting away from it.

Here is what I see. Clock cycles are very cheap, and programmers, and scientists, are not. The advantages of using relatively low level constructs are just not present with computers that basically waste cycles and memory on eye candy.

So I would have to say that C or Fortran might be justified if one is going to write really intensive simulations or the like, but otherwise everyone seems to be using Python for casual computing, and from what I do with it is seems to work fine. There are even very good books that teach how to write good scientific code in Python.

I have written extensive over the years in C, Fortran, Assembly among other languages, and right now pretty much just use Python.

Re:FORTRAN

[DanielOom]

If you like your programs nice and slow (and single-threaded), use Matlab, or Python if you can't afford the fee. For a bit of speed, use C or Fortran. If you're in a hurry, get a couple of heavy GPUs and program these in assembler.

Re:FORTRAN

[loufoque]

FORTRAN is for scientists that aren't software engineers.
You cannot do advanced optimizations (you do not have fine control of memory nor codegen) or make parallelism scale well with just FORTRAN. It's just a dumb number crunching language. While FORTRAN is still used for supercomputing, most of the time it's just for black box routines with the rest of the application in C or C++.

Re:FORTRAN

[Anubis IV]

An undesired one, I assure you. I was trying to figure out a different way to phrase it, just because I knew it would be read that way, but nothing came to mind.

Re:FORTRAN

[mbkennel]

There are lots of things which C++ can do better than Fortran. Graphs, guis, operating systems,drivers, template metaprogramming, compiler message heiroglyphics, segmentation faults, memory leaks, & heisenbugs.

Numerical computation isn't part of that.

Part of my paycheck is doing numerical computing with C++. I find the Eigen library and C++ 11 makes things better. F2003 would still be better yet.

Re:FORTRAN

[ebno-10db]

An undesired one

That's what they all say.

Re:FORTRAN

[ebno-10db]

It's also of interest that OOP is specifically BANNED from aircraft software!

Everywhere, or just extreme cases like DO-178B Level A? I know most of the F-35's software is written in C++ (though considering how that project is going, that's hardly an endorsement).

Re:Fortran

[mjwalshe]

yes as an older Fortran programmer id jump at a chance to get into HPC and writing fortran again any jobs going in the UK ?

Re:FORTRAN

[gajop]

Fortran is, for better or worse, the only major language out there specifically designed for scientific numerical computing.

What about Matlab/Octave?

English

[Anonymous Coward]

Obviously.

FORTRAN

[Frosty Piss]

Seriously consider FORTRAN

MATLAB?

[Anonymous Coward]

Have you looked at Matlab? It's commercial, requiring a license, but many universities have a site license available for you to use it. Pretty powerful, faster than VB, but not as fast as native C/C++ but unless you're running some calculations real-time, this probably is not an issue for you.

Re:MATLAB?

[golden age villain]

All the labs I know in my field (neuroscience) do most of the data analysis and simulations with MATLAB. It is also used to control hardware for data acquisition.

Re:MATLAB?

[Fallen Kell]

He already stated he uses Octave which is the open source equivalent to Matlab, it can even read in about 95-98% of all Matlab scripts (the exceptions being a couple of lesser used toolboxes).

Re:MATLAB?

[alexgieg]

many universities have a site license available for you to use it

And if not, anyone can download and use its open source clone, GNU Octave.

Re:MATLAB?

[MightyYar]

MATLAB is an obvious choice unless the license fee becomes an issue. I would caution against doing a GUI in MATLAB, though. (That said, I'm doing one right now...)

Python is nice, but in my experience fewer people are familiar with scientific computing in Python than in MATLAB. I think if I didn't have that roadblock, I'd use Python (NumPy, SciPy).

Re:MATLAB?

[joe_frisch]

We use matlab extensively at SLAC. If the license fee isn't a problem, it is a very powerful language for numerical work. The language includes a variety of high performance toolkits with multi-processor, distributed computing and GPU support.

OCTAVE and the other free versions really do not substitute for matlab - I'd recommend python instead if matlab is too expensive.

I've used python as well, and it is OK, but IMHO less optimized in structure for numerical work (even with pylab etc) than matlab, but better for other types of programming.

Re:MATLAB?

[spike hay]

The problem with Octave is that it just generally sucks balls at everything. It's commonly an order of magnitude slower or more than Matlab. It's compatible with simple scripts that only use basic library functions, but if you start talking about plotting and such, it isn't.

Of course, Matlab is actually a horrible language itself. Everything is a double. One function per m-file (I know, local functions, but you can't call them from the outside). It's really sad that everyone is so locked into it.

Julia is the best choice, IMO. R and Numpy/Scipy are also loads better.

Step one: export to a database?

[xxxJonBoyxxx]

>> I initially coded all of my routines in VBA because it 'was there'.

Are you in Access? Or Excel?

If your routines work but are just slow, I'd first look at moving the data to SQL Server and porting your VBA routines to VB.NET.

If you have more time, you may want to learn what the "Hadoop" world is all about.

Re:Step one: export to a database?

[K. S. Kyosuke]

If he wrote it in VBA, I'm pretty sure he can rewrite it into a native extension of some kind and use it from the same environment. Some industries love those since you expose the functionality to many users who want or need to work in that user environment.

Re:Step one: export to a database?

[Anonymous Coward]

If you have more time, you may want to learn what the "Hadoop" world is all about.

That's the absolute wrong answer to the question as posed. Hadoop is all about massive parallelization. It's the answer to "How do I throw hardware at a difficult problem?" instead of "How do I solve a difficult problem efficiently."

I'm not saying that Hadoop isn't extremely useful, but for a student who managed to scrounge up a single Xeon machine, it's entirely ill suited.

Re:Step one: export to a database?

[xxxJonBoyxxx]

>> Hadoop isn't extremely useful, but for a student who managed to scrounge up a single Xeon machine, it's entirely ill suited

Go back and read the problem again: "would like to be able to make use of all four CPU cores"

Here's a guy seeking parallelization...and may not know that you don't have to throw big (potentially expensive) multicore processors against the problem - he could throw multiple (cheaper?) computers against it.

Re:Step one: export to a database?

[shutdown -p now]

"All four CPU cores" is a scale that's way too small to even begin considering Hadoop.

Don't use Hadoop - your data isn't that big.

More details?

[schneidafunk]

Depending on your needs, R may be your best bet if it is statistical processing you are interested in.

Re:More details?

[Bovius]

Second this. There are numerous languages out there that are tailor-made for specific kinds of problems. You didn't quite share enough to narrow down what kinds problems you need to solve, but the R project is geared toward number crunching, albeit with a significant bent toward statistics and graphic display.

http://www.r-project.org/

If that's not pointed in the right direction, some other language might be. Alternatively, there are a lot of libraries out there for the more popular languages that could help with what you're doing. Heck, 12 years ago we didn't even have the boost libraries for C++. It's difficult for me to imagine using that language with out them now.

Re:More details?

[Vesvvi]

R is terrific but it's also horribly overused (much like Excel). In my experience R is best when called for very specific calculations within the context of a larger package written in something more general-purpose.

Re:More details?

[plopez]

+1 also. To elaborate. I used R all through my thesis. Nice tool; both gratis and libre, powerful graphing capability, and a host of packages from a huge number of scientific and technical fields. Lots of code examples and a good community.

Re:More details?

[Anonymous Coward]

That's funny. It makes sense, but for statisticians it is exactly the opposite: R is just a really crappy general-purpose environment for which several special-purpose libraries have been written, covering everything under the sun. Without the libraries, you'd be crazy to use it these days.

Re: More details?

[jonnyj]

R is by far the best solution that I've found for statistical analysis and data mining. It's ugly, inconsistent, quirky and old fashioned but it's absolutely brilliant.

The whole syntax of R is based around processing data sets without ever needing to worry about loops. Read up on data tables - not data frames - in R and you'll learn how to filter data, aggregate it, add columns, perform a regression and beautifully plot the results all in one line of code. The Zoo package will sort out your time series analysis and longitudinal analysis. With R, you can calculate the statistical significance of you hypotheses and apply the model you've developed to your hold-out sample using built-in functions. And the concept of workspacecd means that you don't need to think of funky ways to store your interim results.

Using knitr, R will produce publication quality documents and presentations. ggplot will give you the best data visualisation tools in the business.

R is the tool that has been purpose-built for the task in front of you. Anything else might be easier to learn or more widely supported - but it won't be as effective.

What are you doing?

[RichMan]

What do you mean by scientific computing?

Modelling: Hard core finite element simulations or the like. Then C or Fortran and you will be linking with the math libraries.
Log Processing: A lot of other stuff you will be parsing data logs and doing statistics. So perl or python then octive.
Data Mining: Python or other SQL front end.

Re:What are you doing?

[UnknowingFool]

Well if your problems require statistical computing, R is the language to use. For general scientific computing, the last I checked Octave was still valid. As for multi-core processing only a few languages and compilers support platforms like Open MP. Fortran, C, and C++.

Re:What are you doing?

[TheCarp]

It sounds like you are saying a more specific version of what I was going to post.

A little research goes a long way and libraries may be more important than language. I don't care how nice the language is.... the less underlying mechanisms I need to implement, and the faster I can get into the meat of what I am working on, the better.

If you want to do RSA encryption in your code (for example) your best bet is NOT to pick a language where you can't find an RSA implementation (Applesoft basic? lol not sure what that would be these days) and implement your own.

Sure its not too bad, but any mistakes could sink you, and it means debugging and supporting yet more code....when you could be using a standard library that lots of other people use and has already had most of the kinks worked out, and gets updated on its own.

Base languages are all exceedingly similar when you strip away the syntactical sugar. Its the varying quality of the different sections of their libraries that really set them apart in different areas.

Re:What are you doing?

[shutdown -p now]

Well if your problems require statistical computing, R is the language to use.

A lot of people seem to be pretty happy with Python+pandas lately.

(and the advantage of going the Python way is that it's also a general purpose language that's useful elsewhere)

Re:What are you doing?

[s.petry]

I second this selection for the same reasons. Many people dislike having to code for simple Unix commands, so favor a "scripting" language like Python or Perl because it's easy. Performance is never easy, and massive number crunching requires real compiled code not pseudo code. R, C, C++ are all exceptional for number crunching. Hell, I would put Pascal up against Python any day of the week for pure number crunching, and Pascal's syntax for math is very easy to learn.

Re:What are you doing?

[nabsltd]

That mix pretty much matches what we use where I work.

We have a 1200-core HPC cluster, used mostly for biomedical applications (gene sequencing, simulations, etc.), so it's not huge by any means, but it isn't tiny either. Our latest toys are 32-core boxes with 1.5TB of RAM.

Re:What are you doing?

[UnknowingFool]

The question is how to take advantage of multi-core. The problem is at what scale do you program this functionality. Certainly you can code for multiple threads, however, it is somewhat manual to code to determine how best to use the cores. Right now he has only one server. What if he gets a second? He could use a platform like OpenMP and let the platform assist. There will always be some tweaking; the question is whether you want to tackle it all yourself or get assistance. I'm not an expert of the perils of multi-core processing. I would rather get some help. If you want a platform, the you have to bear in mind which languages and compilers you can use.

IPython Notebook + Python Data Analysis Library

[rla3rd]

Install these 2 and you'll be good to go
http://ipython.org/notebook.html
http://pandas.pydata.org/

Python

[Anonymous Coward]

Try Python. Make sure to use scipy (numpy really), because you don't want to do the heavy lifting in native Python.
http://www.scipy.org/

what the rest of your team uses

[peter303]

You should all be sharing your codes to avoid rewriting and to perfect it.
And if you are not a member of a team then I seriously question the quality of your graduate program.

BAD TIM! BAD!

[girlintraining]

What language suggestions or tips can you give me?"

Timothy, shame on you. You should know better than to start a holy war.

Re:BAD TIM! BAD!

[ImdatS]

Shakespeare http://en.wikipedia.org/wiki/Shakespeare_(programming_language) - my favorite language...

(and yes, this is supposed to be funny)

Re:BAD TIM! BAD!

[ebno-10db]

Why is the PP marked "funny". It sounds like a serious concern to me.

Re:BAD TIM! BAD!

[sensei moreh]

Actually, using the programming language you know best may indeed be the most efficient way to go - depends on the problem

Fortran (plus MPI and some CUDA)

[Anubis350]

Fortran and learn some how to implement MPI and CUDA code is your work is parallelizable.

Re:Fortran (plus MPI and some CUDA)

[GiganticLyingMouth]

For completeness, it should also be noted that both C and C++ work with MPI and CUDA. Fortran can theoretically be faster than C or C++ as its compiler can optimize more aggressively (due to the lack of pointer aliasing in Fortran), but I don't have any hard data for how much of a difference it would make in actual runtime speeds.

Re:Fortran (plus MPI and some CUDA)

[Anonymous Coward]

Fortran and learn some how to implement MPI and CUDA code is your work is parallelizable.

DO NOT USE CUDA

Use OpenCL

Re:Fortran (plus MPI and some CUDA)

[afidel]

The biggest deciding factor is usually what are the standard libraries for your field available in, in many disciplines your base libraries might only be available in Fortran.

Re:Fortran (plus MPI and some CUDA)

[nabsltd]

Better still, learn about the Intel Phi and let the Intel compiler do the parallelization, all without having to learn a different architecture and API.

Re:Fortran (plus MPI and some CUDA)

[loufoque]

A FORTRAN compiler can generate better code than a C compiler for dumb code, the difference in that with C you have the option to optimize your code yourself and actually do a better job than even the FORTRAN compiler.

Re:Fortran (plus MPI and some CUDA)

[GiganticLyingMouth]

Last I checked (a few years ago) CUDA had better tools and more features than OpenCL. Has this changed much since then? OpenCL didn't even support templates back then...

2 paths

[johnjaydk]

If you can find anything that resembles a math library with the correct tools then go with Python. Numpy is everyones friend here.

If you have to do the whole thing from scratch then Fortran is the fastest platform. I can't say I've meet anyone who enjoyed Fortran but it's wicked fast.

Re:2 paths

[the gnat]

If you have to do the whole thing from scratch then Fortran is the fastest platform. I can't say I've meet anyone who enjoyed Fortran but it's wicked fast.

True, but the only place where this *really* matters is programming for repetitive calculations on massively parallel supercomputers. For anything else, there is a tradeoff between program speed and developer speed, and ultimately it's cheaper to buy more computers than hire more programmers.

Re:2 paths

[ebno-10db]

ultimately it's cheaper to buy more computers than hire more programmers

We're talking about grad students - seriously different budgetary concerns.

Re:2 paths

[mbkennel]

And assuming the acquisition, configuration, installation and parallelization of the servers has zero cost in time.

The supervisor of two researchers finds that one gets the job done with very fast code in Fortran 95 in a reasonable time, the other gets a demo up real quick but it is far too slow to be used for practical data reduction, and wants to buy 50 servers to spawn it out with some new package (which he hasn't used yet and is bleeding edge freeware).

"Well, if sequestration is repealed you can write a justification in the grant renewal in 9 months, and if it gets approved (funding rates are under 7% these days at NSF) we might have money for 2 in 18 months. You could rent some on Amazon on your own money, I guess but we have to check with legal about data security requirements."

Personally, I want to get my research done now.

Re:2 paths

[Anonymous Coward]

Yes. Rephrase the cost of computers in packets of ramen.

Java Java!

[Latent Heat]

For research engineering, I use Java to run the numerical examples of the algorithms I develop although most of the authors in the journals I publish in are using Matlab for this purpose (ewwwwww!). Long time ago I was a Turbo Pascal person as were engineering colleagues who crossed over to Matlab seeking the same kind of ease-of-use. Me, I transitioned to Delphi but now I am with Java and Eclipse -- the Turbo Pascal of the 21st century.

For numeric-intensive work, I can get within 20% of the speed of C++ using the usual techniques -- minimize garbage collection by allocating variables once, use the "server" VM, perform "warmup" iterations in benchmark code to stabilize the JIT. I use the Eclipse IDE, copy and paste numeric results from the Console View into a spreadsheet program, and voila, instant journal article tables.

Re:Java Java!

[ebno-10db]

For numeric-intensive work, I can get within 20% of the speed of C++

Did you measure it? No snark - I'm curious.

I would like to see some benchmarks that support the claim that Java is almost as fast as C/C++ for number crunching. I'm in the C/C++ camp, but am willing to openly entertain what you get from good benchmarks. These benchmarks show C++ consistently beating Java.

What those benchmarks don't cover, but I'd love to see, is a comparison of pure C++, pure Java, Java w/ some wrapped C/C++ (I understand there are some nice packages like that), and NumPy/SciPy/Cython (we know straight Python is glacial compared to Java).

P.S. This is not necessarily an answer to the author's question, as he isn't clear (and may not be clear himself) about how speed critical his stuff is.

Re:Java Java!

[Atzanteol]

I tried out those benchmarks myself.

Java:
$ time java nbody 50000000
-0.169075164
-0.169059907

real 0m8.863s
user 0m8.820s
sys 0m0.016s

Not too shabby. But checkout the C++ times!
$ time ./nbody.gpp-7.gpp_run
Segmentation fault (core dumped)

real 0m0.097s
user 0m0.000s
sys 0m0.000s

OMG that's a ton faster!

Re:Java Java!

[Atzanteol]

Doh! I'd forgotten the parameter... PEBKAC. I now return you to your regularly scheduled doldrums.

Re:Java Java!

[ebno-10db]

How many iterations of those tests did you run, and were you using the server version of the JVM?

Like I said earlier, I'm in the C/C++ camp, but I'm just asking what a Java advocate would probably ask. They're forever talking about "warm up" time, which seems like a big technological step backwards to me. I thought computers used transistors now instead of tubes.

Re:Java Java!

[Atzanteol]

The "warm-up time" is allowing the JIT to gather statistics and optimize the compiled code on-the-fly. The first pass will be slower than the nth pass over the same code. At a certain threshold (number of executions) the JIT will perform more optimizations and the more often the same bit of code is executed the more the JIT learns about how to optimize it. The idea is to not pay the compilation/optimization penalty unless it's worth it.

Keep in mind that bytecode is platform independent. Each JIT will make different optimizations depending on the local system. But if you stop/restart you pay that penalty again (interesting note: Dalvik for Android saves the compiled versions for later runs).

Out of curiosity I've run the 'nbody' test on my system with C++ and Java for varying numbers of iterations.

For 1,000,000,000 iterations C++ took 105.39 seconds and Java 174.15 seconds. That puts Java at about 60% the performance of the C++ in this case. I'm running a 1.8 JVM (still experimental) but I believe it should be representative.

I'm in the Java camp myself and while I'd like it to perform better the reality is that it simply doesn't. But the reality for me and my line of work is that it easily performs "well enough" and provides enough other benefits to be worth the trade-off.

Re:Java Java!

[ebno-10db]

I'm in the Java camp myself and while I'd like it to perform better the reality is that it simply doesn't. But the reality for me and my line of work is that it easily performs "well enough"

I appreciate that "well enough" often applies in the real world, and if you have a lot of Java, know it well, etc., it would be silly to switch (though Scala sounds more interesting, is interoperable, and about the same speed). I also believe you can speed up Java number crunching a lot by using some of the packages where C/C++ has Java wrappers.

I understand the whole warmup thing w/ the JVM, but it's simply a drawback (even if it doesn't matter much on servers).

The only thing that irks me is when Java advocates say it "can be faster, is just as fast, or within a hair's breadth of C/C++". I'd love to see some benchmarks that show that, but no one ever seems to produce them.

'D' might be a good number crunching language, though I haven't tried it. I'll be the first to admit that C++ is a Rube Goldberg, C is primitive, and both give you all the rope you need to hang yourself with (though I rarely find that a problem w/ number crunching). D is kind of C++ done right, and it's a lot safer. It's come a long way, though it still has some rough edges. For instance, it still uses a "stop the world" garbage collector, though there's at least an alpha of a decent generational GC. "The Computer Language Benchmarks Game" that I often cite dropped D for an interesting reason. To reduce the work of maintaining the site they had to drop some languages, and amongst others, chose D because it was so similar to C++.

Re:Java Java!

[mjwalshe]

And how close to a full on FORTRAN program making use of MPI and CUDA? for a scientific computing problem C++ has all that OO overhead

Re:Java Java!

[ebno-10db]

for a scientific computing problem C++ has all that OO overhead

Only if you choose to use the OO part of it. C++ is very flexible in that regard. Looking for speed? Templates can be very helpful.

Re:Java Java!

[BlazingATrail]

lol did anybody notice the Segmentation fault.. that pretty much sums up the cost of C++ Real programs that execute many iterations, warm up quickly in Java and it's all compiled to assembly by JIT/Hotspot. We've done many benchmarks and in production numerical code Java is just as fast as C/C++

Re:Java Java!

[Atzanteol]

As I understand it there are *very* specific use-cases where Java has a speed advantage - and that's in memory allocation on the heap. But no - in general for number-crunching it will not be as fast as C/C++. And I agree that Java advocates don't do themselves any favors by pretending that it is.

Garbage collection these days is pretty smooth - unless you're short on memory. But there is that overhead of memory usage that will always be there... I was interested in D at one point but it seems to have just gone nowhere.

In my opinion the thing that C++ needs isn't just a GC but a standard library that is as complete as what Java and C# have. C++11 seems to have done some work there (though I haven't checked it out too much as my world is Java/C# these days) but it should have been done *ages* ago.

Re:Java Java!

[CraterGlass]

Two more good reasons for java: Strong typing and array boundary checking.

For a scientist who spends more time doing science than being a programmer, boundary conditions and bad type casts are a permanent trap waiting to snap on you. A few years back I had a contract to convert a large mathematical application from Fortran to java. You'd be surprised how many simple errors of this nature had been lurking in the Fortran code for decades. Incorrect mathematical results are not always obvious.

Another good reason - arbitrary depth of precision. Java has built in classes for numbers with very high precision, e.g. BigDecimal.

Re: Java Java!

[tolkienfan]

You get a performance benefit from preallocating in both C++ and Java, so the whole gc being smooth is irrelevant. If you are constantly allocating and deallocating you haven't written optimal code. Current compilers (applies to jit too) do a terrible job of vectorising for simd instruction sets. Take Intel avx2. That's 512 bit wide operations... e.g 16 simultaneous floating point multiplies. Java can't get close to hand optimized vector code in C plus assembly. Similarly for gpgpu... Of course, OP wanted to make an improvement without learning something entirely new... but if we're comparing C and Java...

Re:Java Java!

[hyperfl0w]

Honest question: what do you do when you need Math / ML support? Java is astonishingly vacant -- only Weka and Mahout -- but no packages provide logistic regression, variation measures, distance functions, distribution functions, etc.

How do you do MATH with Java?

Re:Java Java!

[mjwalshe]

But still dont have a lot of the builtin primitives useful for scientific computer which is C and C++'s big limitation for the uber HPC type of aplications pklus you dont have decades of existing code and librarys that fortran will have.

Re:Java Java!

[ebno-10db]

I agree that Fortran is still the champ for fast number crunching, but I was specifically refuting your point that C++ necessarily carried the overhead of OO.

Re: Java Java!

[Atzanteol]

True - Java basically implements a transparent memory pool for the developer. It's nothing that *couldn't* be done with C/C++ (indeed, it *is* with the JVM!). But with Java you get it "for free." And that also ignores stack allocation in C/C++ which is much faster anyways and impossible in Java. So there aren't really any performance benefits with Java that can't be matched by C/C++ (albeit with a bit more effort). But if performance were all that mattered why do we have any other languages other than assembly?

Nothing is going to beat hand-tuned perfectly optimized assembly - but you hit diminishing returns on effort/performance very quickly. If you're trying to brute-force a crypto algorithm by all means spend a ton of extra time hand-optimizing that inner-loop in assembly that is specific for your processor. If you're calculating a sum of somebody's paychecks for the last year from a database you're probably fine with spending a few minutes writing it in Python.

Oh - and I agree that it would be great if compilers could take better advantage of SIMD operations. Their use is "situational" though and seems a tough job to predict when they should be used. It seems to me that a JIT may be better positioned to make use of them though given the run-time analysis that can be performed. I'm not a compiler guy though so it's very likely I'm wrong. :-)

Re: Java Java!

[tolkienfan]

I completely agree. In scientific computing, although, vector math is ubiquitous. So I'd almost discount current Java implementations from scientific computing. At least for the "hot spots"

Rather than learning a language...

[Anonymous Coward]

I would recommend learning what a programming language is. Especially if you have the time. Personally I spent a lot of time learning languages and not really seeing the abstraction that every programming language adhere's to, making learning a new language difficult and time consuming. I can only really describe it as trying to learn a language rather than learning linguistics. All computer languages share common patterns all based on formalism, just like all spoken languages share common patterns. Learning formalism makes picking up new programming languages much easier since you'll not only be able to identify patterns shared between them faster, but pick up the lexicon to communicate well formed questions to other programmers. I'd recommend reading Structure and Interpretation of Computer Programs. There are other books that attempt to replicate what this does, but it really is great and I haven't seen other books get to the point of computer programming faster. It is based on LISP, which most people will never use, but its deceptively easy to read and understand, so getting through the book for someone that hasn't used LISP before shouldn't be a problem. Good Luck!

Python, or ...

[Kiliani]

First suggestion: Python. Lot's of nice stuff for science (NumPy, SciPy), lots of other goodies, easy to learn, many people to ask or places to get help from. Plus you can explore data interactively ("Yes Wedesday, play with your data!").

Beyond that: CERN uses a lot of Java (sorry folks, true), they have good (and fast) tools I do a project right now where I am using Jython since it is supported by the main (Java) software I have to use. I like jhepwork/SCaVis quite a bit, if you are into plotting stuff on Java.

If you have extra free time and want to learn how to program well? I'd learn something like Smalltalk (for OOP concepts) and/or Haskell (functional programming). Scientists are often lousy programmers because they often do not learn programming properly, and/or the language allows them to get away with bad programming (I know, every language allows bad programmers to write bad code, but some make it easier than others).

So, stick with Python, it works really well, is modern, and has good support. Plus you can read your code in 5 years time ...

What do I program in? Python (and Jython), Perl, C, IDL (yickes!), Smalltalk, Matlab, Mathematica. I know some Lisp, but that's just for fun. And whatever allows me to load sketches on an Arduino. I like Python (get's stuff done) and Smalltalk (works actually like I think - passing messages between objects).

Use whatever works and you don't hate :-)

Re:Python, or ...

[SerenelyHotPest]

If you have extra free time and want to learn how to program well? I'd learn something like Smalltalk (for OOP concepts) and/or Haskell (functional programming). Scientists are often lousy programmers because they often do not learn programming properly, and/or the language allows them to get away with bad programming (I know, every language allows bad programmers to write bad code, but some make it easier than others).

This is extremely well-intentioned advice and very correct in big-picture terms but not at all appropriate for cold-starting the ability to read and write simple programs for numerical scientific work. If the OP intends to become a programmer specializing in scientific computing and must manage a substantial code-base, this will prove good advice to take as some tertiary measure; if his/her goal is to become proficient enough to write a few hundred lines of code for a cross-component patch in some specific scientific context, it's frankly a waste of time--and I say this as an apologist for learning both Smalltalk and Haskell (along with possibly Scheme) if you intend to call yourself a computer programmer and/or especially a computer scientist. I don't deny understanding several paradigms of programming is invaluable for any programmer; I'm just saying that if you treat your time as precious and programming as one small part of what you do, this isn't the best use of your time.

R-language

[biodata]

Most of the cutting edge data mining I've seen is done using R (which acts as a scripting wrapper for the C or Fortran code that the fast analysis libraries are coded in), or alternatively in python. Some people swear by MatLab if they have trained in it (so your octave would come in handy there). Have a look at some discussions at places like kaggle.com to see what the competitive machine learning community uses (if that is what you mean by data mining).

Re:R-language

[green is the enemy]

This is the correct advice: Use whatever language is most common in your research area, so you can benefit from the most existing source code. This will almost certainly be a high-level scripting language like R, MATLAB or Python, with the ability to drop down to C, FORTRAN and CUDA for the small parts of the code that need optimization. (In my case: electrical engineering = MATLAB + C and CUDA mex files)

Re:R-language

[T.E.D.]

Dang, I had mod points this morning, but not now.

This is in fact the Right Answer. Scientific Computing folks have started to cast about for Fortran alternatives in the last few years, and most of the talk I have heard has centered on R. So I'd go with a newer Fortran compiler (for God's sake, not 77 or earlier) and/or R.

This is most definitely a field where you want to follow the herd, unless you happen to have an interest in esoteric CS things like code optimization, cross language binding generation, and mathematics library debugging, to go along with your interest in Scientific Computing. If you strike out on your own, that's the kind of stuff that will be consuming your time.

Re:R-language

[hyperfl0w]

R is great until you look under the hood at the package implementations.
"A good implementation beats a good design "

Go (aka Golang) if you come from a C background

[genghisjahn]

http://golang.org/ You won't regret it.

Re:Go (aka Golang) if you come from a C background

[K. S. Kyosuke]

Could use some vectorizing FP, but yeah, it's not a bad choice, especially if the complexity of mixed environments is undesirable. (Could also use some native port of netlib/GSL as well, though.)

It might also make him a better practical software engineer, which, as I understand, is an area in which many numerics people...experience certain difficulties.

Profile

[Arker]

A lot of people will propose a language because it is their favorite. Others because they believe it is very easy to learn. I will give you a third line of thought.

I would not look for a language in this case, I would look for a library, then teach myself whatever language is easiest/quickest to access it. I would try to profile what you are building, figure out where the bottlenecks are likely to be (profiling your existing mockup can help here but dont trust it entirely) and try to find the best stable well-designed high performance library for that particular type of code.

Re:Profile

[jythie]

I am not sure how much that helps since unless the person is doing something very specific, chances are it will just shift the problem into 'which library is best' debate, which will again mostly involve people suggesting libraries they like or because they believe they are easy to learn.

Re:Profile

[Anonymous Coward]

Python is recommended because it has two very fast and powerful computational libraries written by scientists for number crunching. People analysing vast amounts of data do not want to be fucking around with bottlenecks, they want to get on with their jobs.

Re:Profile

[CQDX]

Unless you are doing something completely novel, don't reinvent the wheel. Look for existing libraries that are commonly used in your area of research. Then your language choice will be narrowed down to possibly only one. If by chance this library doesn't have the performance you need, it will be easier to tune it for speed as compared to starting from scratch. Unless you are in CS, grad school is not where you want to embark on a huge software project if the fundamental coding has already been done by others. You could easily "waste" 1-2 years writing and debugging code without producing anything publishable. BTDT.

Re:Profile

[Arker]

"Unless you are doing something completely novel, don't reinvent the wheel."

Exactly why I said I would think about looking for the library first instead of the language.

"If by chance this library doesn't have the performance you need, it will be easier to tune it for speed as compared to starting from scratch."

False dichotomy. Performance tuning is not something you just pick up overnight like a new language can be, it's serious stuff. If you have to do that yourself you might as well do the whole job and forget about the crappy library. Find one that is already optimized for the tasks that your app will spend most of its time and resources on, then use the most convenient glue to make it work.

Hadoop?

[bjzadwor]

If you are doing a computationally intensive data mining problem, have you considered porting to a Hadoop solution? You may need to rewrite your code, or you may be able to use Hadoop to call your current functions. You could use an AWS Hadoop cluster; Amazon often gives free credits to students, it may cost you nothing out of pocket, and help you learn a hot new technology.

Speed incarnate

[Impy the Impiuos Imp]

If you're using VBA in Excel, you can speed it up a ton by putting this at the beginning of your function:

Application.Calculation = xlCalculationManual

And restore it with ...Automatic at the end.

Do this at the top level with a wrapper function whose only purpose is to disable and enable that, calling the real function in between.

If you want a real speedup, I am available for part time work in C or C++.

My favorite is CnH2n+1OH

[nanospook]

It take all the work out of the computations..

Fortran 90+ with OpenMP or Python

[dlenmn]

If you really want to do heavy lifting, you can't beat Fortran. Just stay away from Fortran 77; it's a hot mess. Fortran 90 and later are much easier to use, and they're supported by the main compilers: gfortran and ifortran.

ifortran is Intel's Fortran compiler. It's the fastest out there, and it runs on Windows and Linux. Furthermore, you can get it as a free download for some types of academic use. (Search around intel's website -- it's hard to find.) That said, I usually use gfortran -- which is free and open source -- on linux. See http://www.polyhedron.com/compare0html for a compiler comparison.

If you use Fortran, it's very easy to use OpenMP to do multiprocessing and make use of all those cores. OpenMP is supported by the main compilers.

If you're doing lighter work, SciPy/NumPy works fine; I use it a fair amount if maximum performance isn't essential. However, I can't speak to its multiprocessing ability.

Re:Fortran 90+ with OpenMP or Python

[Eunuchswear]

Fortran 77 is for weenies. Real men program in FORTRAN 66.

Re:Fortran 90+ with OpenMP or Python

[Eunuchswear]

Geeze, why did i get "funny" for that? I was hoping for informative or insightful.

Why code, when you are use a workflow tool?

[Grantbridge]

Use KNIME and you can probably do 90% of what you want by dragging and dropping a new nodes and joining them up. KNIME does all the complicated memory caching for large filesets for you, and you can write your own Java functions to plug into it if you need something special.

Depends

[Enry]

R, MATLAB, SAS, Python, there's a bunch of languages you can use, and a bunch of ways to store the data (RDBMS, NOSQL, Hadoop, etc.). It really comes down to what kind of access to the data you have, how it's presented, what other resources you have available to you, and what you want to do with it.

Fortran + Python = F2PY

[n1ywb]

Better yet, Fortran + Python.

http://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html#f2py

I used it to wrap some crazy magnetometer processing code written in Fortran into a nice Python program. I ripped out all the I/O from the Fortran code and moved it into the Python layer. It worked great. Fortran is AWESOME at number crunching but SUCKS ASS at IO or well pretty much anything else, hence Python.

Re:Fortran + Python = F2PY

[HiThere]

How long is the expected to last? Last I checked F2PY didn't work with Python3. I can't remember whether it worked with versions of fortran past Fortran95. Python2 is still being supported, but it's probably only got a couple of years before it's mothballed. (I think the original promise was 5 years of support after Python3 was released.)

OTOH, perhaps Python2 will be more durable than expected. Or perhaps F2PY supports...when I checked just now I got a bunch of people reporting errors in using F2PY with Python3, but many of them were over a year old, so maybe it's working now.

OTOH, a modern Fortran is actually pretty good just by itself if you don't need bunches of external libraries. And as for I/O...well, nothing is good at that, it's too general a requirement. Fortran77 is quite good a binary I/O, I haven't tried a recent fortran. OTOH, I will agree that Fortran77 is rather poor at character I/O.

One consideration that you might have is handling unicode. The last time I checked (quite awhile ago) fortran (all of them) was as poor as C at dealing with unicode, whereas Python handles it quite well. I don't know whether this has changed (or which version of Fortran you would be using, or whether it matters for your application).

OTOH, support in dealing with Fortran is rather limited. If you don't know someone, you may have trouble finding support. Few people use it. As you said you haven't used it for a rather long time, this may be significant.

The real answer is that it depends on details of your application. It depends on what you mean by a large amount of data. It depends on your computer. (Also, my recent experience is with Linux. You appear to be using MSWind, judging by your comment about VBA. I have no knowledge of how any Fortran works on an MSWind system, but I suspect that it's barely supported. Which would make Python a better choice. (You said you could load the system with either MSWind or Linux, but there's much to be said for familiarity.)

Re:Fortran + Python = F2PY

[occasional_dabbler]

F2Py is so insanely useful, if it falls out of support I'l ltake it up myself.

Re:Fortran + Python = F2PY

[mvdw]

OTOH, exactly how many hands do you have??

Re:Fortran + Python = F2PY

[mjwalshe]

Oh come FORTRAN io isn't that hard on you just have to suck it up and learn to use the format statement - hell i worked on a billing system that was 70% FORTRAN 77

Re:Fortran + Python = F2PY

[plopez]

Nah. Fortran 2003 and 2008 pretty much obviate a need for a language like Python

Re:Fortran + Python = F2PY

[n1ywb]

Fortran is widely used in science (speaking as a scientific developer here) and perfectly supported on Windows.

http://software.intel.com/en-us/fortran-compilers

I love the "automatically paralellize" checkbox in the intel fortran settings. Take that, C et al.

Re:Fortran + Python = F2PY

[n1ywb]

Maybe it's just bad developers but any software that reads config data based on fixed line numbers is crap IMNSHO and just about every fortran program I've worked with worked that way. It's std lib is jonesing for an .INI parser or something.

Re:Fortran + Python = F2PY

[mjwalshe]

use Ratfor :-) http://en.wikipedia.org/wiki/Ratfor

Depends... On the Data...

[tiberus]

Well, it depends. You say " computationally intensive data mining problem" but, what kind computations (arithmetic, mathematical, text-base, etc.).

In general for flat out speed, toss interpreted languages out (Perl, Python, Java, etc.) the door. You'll want something that compiles to machine code, esp. if you are running on older hardware. Crunching numbers, complex math, matrices then Fortran is the beast. If you're data is arranged in lists, consider lisp, then pick something else as it will likely give you a migraine. The format of your data and what you need to do with it will drive your language choice.

Is finding a partner an option? Seems you should be able to work with someone from CS who needs a coding project...

Python or R

[Anonymous Coward]

I work in the industry (all our customers are scientists), and the two languages that seem to be predominant are R and Python. R has lots of cool stuff specifically for advanced number crunching, while Python is more the swiss army knife that can be used to tackle anything. I don't think you can go wrong with either, but Python will probably be more friendly (eg. it has way more books on it than R) and will serve you better in non-scientific enterprises.

Python, numpy, Pyvot

[shutdown -p now]

Since you mention VBA, I suspect that your data is in Excel spreadsheets? If you want to try to speed this up with minimum effort, then consider using Python with Pyvot to access the data, and then numpy/scipy/pandas to do whatever processing you need. This should give you a significant perf boost without the need to significantly rearchitecture everything or change your workflow much.

In addition, using Python this way gives you the ability to use IPython to work with your data in interactive mode - it's kinda like a scientific Python REPL, with graphing etc.

If you want an IDE that can connect all these together, try Python Tools for Visual Studio. This will give you a good general IDE experience (editing with code completion, debugging, profiling etc), and also comes with an integrated IPython console. This way you can write your code in the full-fledged code editor, and then quickly send select pieces of it to the REPL for evaluation, to test it as you write it.

(Full disclosure: I am a developer on the PTVS team)

matlab

[smadasam]

FORTAN used to be it back in the day, but now days Matlab is the stuff that many engineers use for scientific computing. Many of the math libraries are very good in Matlab and don't require you to be a computer scientist to make them run fast. I used to work with scientists in my old lab to port their Matlab code to run on HPC clusters porting them to FORTAN or C. Often the matlab libraries smoked the BLAS/Atlas packages that you find on Linux/UNIX machines for instance. The same would hold true for Octave since they just build on the standard GNU math pacakges like BLAS.

Re:Matlab

[Endloser]

You not having written code in 12 years makes me second this suggestion.
Matlab is in wide use in universities and research facilities around the world.

Remember you care about the result not the code.
Matlab will take advantage of your system in ways that you only could had you been programming the past 12 years and not needed to ask this question.

Re:Matlab

[coolsnowmen]

matlab has an open source + free version called octave if you just want to learn the language. You might need to purchase matlab if you want one of their speciliazed "tool boxes"

I used matlab for about 7 years.

Re:MATLAB

[burdickjp]

It's also not free, under any definition, and proprietary, meaning you're making your development dependent on the availability of MATLAB as a resource. Learning a free language, such as Python, would free you from the cost and availability restraint, and mean you are learning a more general, and thus more useful, language.

Re:Matlab

[theEnguneer]

Matlab is great for testing out ideas, but it is slow compared to Python or C. Also, for doing Data Mining, Matlab is a poor choice because the whole point of Matlab is to make it so the user doesn't have to worry about variable/data storage, which is the thing that data miners need to optimize.

Re:matlab

[J. J. Ramsey]

The catch with Matlab is that outside of academia, it is expensive. If one's workplace has the licenses for it, great. If not, it may be better to make do with Octave, or Numpy & Scipy.

Re:matlab

[hyperfl0w]

Matlab user here: it is EXPENSIVE.
Leaving your company means leaving your language.

One should not have have to leave your language behind just because you leave your people.

Re:Matlab

[hyperfl0w]

I did this! New company doesn't want to pay for matlab. :(

Same language as your piers

[willy_me]

If you want to be able to ask someone for help then it would be best to use the same tools they use. The point is that any programming language will work. Some languages are easier then others but the difference is negligible compared to the advantage of being able to ask your piers for assistance.

Re:Same language as your piers

[the eric conspiracy]

Wooden posts stuck into the ground don't use programming languages.

Re:Same language as your piers

[WillAffleckUW]

Maybe they're using metallic or plastic piers?

We used to run S on our GRID computers to figure out proper pier placement, after a discussion with our peers.

Re:Same language as your piers

[rk]

I have worked at places that disprove your statement.

Try J..

[DavidHumus]

...at jsoftware.com .

It's more powerful, concise, and consistent than most languages. However, R and Matlab have larger user communities and this is an important consideration.

There was a note on the J-forum a few months ago from an astronomer who uses J to "...compute photoionization models of planetary nebulae." His code to do this is about 500 lines in about 30 modules and uses some multi-dimensional datasets, including a four-dimensional one of "...2D grids of the collisional cooling by each of 16 ions".

However, the point of his note was that he ported this code to his i-phone - and it works! Consider, too that porting consists mainly of copying some text and data files - there would be little to no code changes.

C/C++

[ericcc65]

I'm a MSEE and I've been working in the digital signal processing realm for the last 10 years since graduating. I should mention that I haven't done a lot of low level hardware work, I haven't programmed actual DSP cards or played with CUDA. I have written software that did real-time signal processing just on a GPU. Everyone in my industry at this point uses C or C++. There is some legacy FORTRAN, and I shudder when I have to read it. Some old types swear by it, but it's fallen out of favor mostly just because it's antiquated and most people know C/C++ and libraries are available for it.

For non-real-time prototypes I'd recommend learning python (scipy, numpy, matplotlib). Perhaps octave and/or Matlab would be useful as well.

At some point you have to decide what your strength will be. I love learning about CS and try to improve my coding skills, but it's just not my strength. I'm hired because of my DSP knowledge, and I need to be able to program well enough to translate algorithms to programs. If you really want to squeeze out performance then you'll probably want to learn CUDA, assembly, AVX/SSE, and DSP specific C programming. But I haven't delved to that level because, honestly, we have a somewhat different set of people at the company that are really good in those realms.

Of course, it would be great if I could know everything. But at the moment it's been good enough to know C/C++ for most of our real time signal processing. If something is taking a really long time, we might look at implementing a vectorized version. I would like to learn CUDA for when I get a platform that has GPUs but part of me wonders if it's worth it. The reason C/C++ has been enough so far is that compilers are getting so good that you really have to know what you're doing in assembly to beat them. Casual assembly knowledge probably won't help. I might be wrong, but I envision that being the case in the not too distant future with GPUs and parallel programming.

Re:C/C++

[ericcc65]

Edit: GPU in the first paragraph should be GPP, general purpose processor.

Quick suggestion...

[MiniMike]

Do you have access to MATLAB or a similar analysis tool? Many universities have licenses, and overall it seems like it might be a good choice for you. These programs usually have a lot of build-in functionality that will be difficult to reproduce if you are not an experienced scientific programmer.

I haven't done ANY programming in about 12 years, so it would almost be like starting from scratch.

This is probably a bigger problem than choosing which language to use. If you don't know how to program properly and efficiently, it doesn't matter which language you choose. If you go this route I'd suggest taking a course to refresh or upgrade your skills. Since you're familiar with C that might be a good language to focus on in the course. Another factor is if you have to work with any existing libraries it might limit your choices. I program in C, FORTRAN, and VB and find that for computationally intensive programs C is usually the best fit, sometimes FORTRAN, and never VB.

Re:Quick suggestion...

[Anonymous Coward]

NO.

No Matlab. Not portable, not open, and it perpetuates a vendor lock-in for quantitative scientists/engineers every bit as bad and destructive as the stranglehold Windows has enjoyed on the desktop for decades.

Python is more readable, more enjoyable to code, has equivalent IDEs available (Spyder), far more user-friendly features, you can use your code literally anywhere you go without worrying about a Matlab license, and the SciPy Stack has reached functional feature parity with Matlab (and is evolving well beyond in certain areas).

Furthermore, indented blocks force good code practices! iPython lets you have a Python workbook! No more semicolons! Multiple function declarations in a true package, instead of dumping loads of files in a working directory!

iPython is leagues ahead of Matlab in terms of scripting, and Python programming is miles ahead of Matlab.

Never recommend Matlab to anyone. The future is open. The future is Python.

Re:Quick suggestion...

[umafuckit]

NO.

No Matlab. Not portable, not open, and it perpetuates a vendor lock-in for quantitative scientists/engineers every bit as bad and destructive as the stranglehold Windows has enjoyed on the desktop for decades.

I think you're over-stating things a touch. Some of the core stuff is closed source but most of the functions are open, meaning that they are readable .m scripts. e.g. if you're worried about how MATLAB implements ANOVA then you read the file and check. You can modify if needed. So MATLAB is open enough in most normal usage scenarios. You're not really locked in given that we have Octave.

Python is more readable, more enjoyable to code, has equivalent IDEs available (Spyder), far more user-friendly features, you can use your code literally anywhere you go without worrying about a Matlab license, and the SciPy Stack has reached functional feature parity with Matlab (and is evolving well beyond in certain areas).

I like Python and I've spent some time learning it recently and ported some of MATLAB code. Python is not a panacea, however. For starters, there is no equivalent of the excellent MATLAB docs. For a newcomer with no programming experience, the entry barrier is definitely higher. Much more Googling needed to get stuff to work. The plots produced by Matplotlib are good but don't do everything. e.g. I found animating data was too slow in Matplotlib and I spent ages messing about with pyqtgraph. So to get the most out of it you have to screw about with different plotting packages and that can be very time consuming. In general, the syntax for matrix operations is a lot more elegant and economical in MATLAB than in Python/numpy. I also ran into issues where seemingly equivalent code would run substantially slower in Python than MATLAB. In many cases I was able to resolve the issue and surely to a degree it was due to me being a numpy beginner, but I do feel it's easier to get the most out of MATLAB than the most of out of numpy. MATLAB has now become quite smart about helping the user to optimise code. Admittedly this might make the user a less careful programmer: I definitely learned things whilst trying to get Python code to run at the same speed as my original MATLAB code. So the process was useful. I'd like to use Python more in the future, but rabidly hating on MATLAB isn't fair. Finally, they're pretty different languages: Python is a general-purpose language which has been adapted to number crunching, whereas MATLAB was designed for number-crunching from the ground up. When you use these languages, their heritage shows.

Use an interpreted language that calls C libraries

[pigiron]

newLISP is small and can easily call most c/c++ libraries, plus Java for graphics. HTML/XML are really just LISP S-expressions for all practical purposes. Throw in a little Unix/bash and you are there.

VB

[confused one]

Personally, I would do it in C unless you have Fortran libraries you want to use, then I'd use Fortran. However, if you have existing VBA code you want to leverage, I'd just use VB.Net, import the core parts of the code and run with it. There's a moderately steep learning curve going from VB6 or VBA to VB.Net; but, it'll be much less effort than learning a new language.

What is worth your time?

[BruiserBlanton]

It depends on what you willing to deal with.

Python is good if you don't need to very heavy array code. I know you can use Python libraries that give you access to good arrays but I think of Python as a scripting language. It's good for a quick prototype as well, but for heavy computation, I would move on to a compiled language.

Fortran 90 or Fortran 2003/08 is what will be the most like what the mathematical syntax you'll use. Despite what people may tell you, it is possible to write code that is understandable and reusable in Fortran, it just takes a great deal of understanding when you design the code. Most people have only seen Fortran code that was either hacked together or is so heavily optimized that it has been obfuscated.

C++ is good as well but you'll spend more time figuring out how to express your mathematics and to use the arrays than you might might find productive. In my group, we do computer science parts of our codes in C++, but numeric calculations and heavy-duty array manipulation is done in Fortran.

The thing about taking advantage of the multiple core machine is much deeper than simply choosing a language. There are MPI and OpenMP libraries that are very good for Fortran and C++. However, producing efficient code that is parallelizable requires changing and complicating the algorithm for a well understood and functioning serial code. Writing effective parallel code will take you much more time than picking up a programming language.

Matlab

[necro81]

If you are working in academia, then you probably have access to Matlab. Matlab, as a language, has both scripting abilities and programming abilities. The scripting was born from Matlab's roots in Unix, which makes it handy for batch processing lots of files. It's programming functions started off as C, but has since incorporated features from C++, Python, and Java. The programming side of it has, in my opinion, more structure and formalism than Python, but makes certain things like file IO and data visualization (i.e., graphing) easier than straight up C/C++. The basics of using it can be picked up in an afternoon, and the sky's the limit from there. There are lots of well-written and documented functions built in; specialized toolboxes can be had for additional fees. There's a fair bit of user-generated code out there. Plus, I expect you can find a lot of people around you who know plenty about it.

Not enough infomation

[already_read]

The answer would really depend on the nature of the problem. If you are doing more statistics type processing then R is commonly used in academia. Python might be good in the short and medium term, but you will probably want to get acquainted with C++ if you are serious.

Fortran

[quietwalker]

I worked as a sysadmin for a high energy physics group at the Beckman Center. Day and night, it was Fortran, on big whopping clusters, doing monte carlo simulations.

Though it ~was~ many years ago.

Elsewhere, I worked for a company doing datamining on massive datasets, over a terabyte of data back in 2000, per customer, with multiple customers and daily runs on 1-5 gig subsets. We used C + big math/vector/matrix libs for the processing because nothing else could come close, and Perl or Java for the data management; preprocessing, set creation and munging (like attempting to corrrect spelling mistakes, parsing date strings into a standard format, normalizing data against a standard metric, applying expert system filters, even actual machine analysis like clustering or shape detection, which to us was still just preprocessing).

Matlab

[Spazmania]

Don't use a programming language. Use a tool like Matlab or Mathematica instead. These tools are well designed for scientific computing and have sufficient scripting built in to support the programming-language-like functionality you're probably looking for.

You won't be able to call yourself a programmer. But you're not a programmer, you're a scientist.

You want to use all your cores? Stick to FP!

[Anonymous Coward]

Stick to 'functional' flavored languages, especially ones that are geared toward composing concurrent code particularly easy and feature immutability of variables as a default, as that's particularly important when you've got a lot of working parts running in parallel. We've been pulling away from the higher-level languages reimplementing most of Lisp poorly toward languages that more and more resemble the ML family with each year that goes past. Haskell is the current darling of that group, though I'd not suggest a lazily evaluated language to a beginner as it's particularly difficult to reason about compared to the more typical eager evaluation. Still, you can try taking a crack at Learn You a Haskell if you want to see a brief glimpse at one of the most interesting languages floating around at the moment, especially since there's ample resources available for study compared to say, Standard ML, my personal favorite.

I would keep my eyes out on Rust in particular, which has taken a few of the better ideas from ML (pattern matching, type inference) and has tried to graft it to a more pragmatic set of trade-offs, such as pushing garbage collection from a required performance hindrance to a per-task elective option and has focused on strong interoperability with C and its calling conventions. It also was a day-one design decision to focus on parallelism and concurrency, which is part of why I cannot directly suggest OCaml at the moment, as that is its biggest weakness in otherwise a very robust and well-established member of the ML family.

I would avoid Go for myriad reasons, unless you want to cover a third of your source-code with explicit error handling or just silently discard them, suffer through the lack of generics (not everything has to be shit with generics like Java and C++, guys, c'mon) or just really enjoy null errors and weird versioning issues that crop up during project development because the Go build system is a bit too simplistic and their solution is to just pull all your dependencies into your own tree to avoid the issue.

R, Perl, some C

[digitalhermit]

I run lots of statistical analyses. Most of the code is in R with some wrappers in Perl and some specific libraries in C. The R and Perl code is pretty much all my own. The C is almost entirely open source software with very minor changes to specify different libraries (I'm experimenting with some GPU computing code from NVidia). Most of the people who are doing similar things are using Python with R (or more specifically, the people I know who are doing the same thing are using Python/R).

An average run with a given data set takes approximately 20 minutes to complete on an 8-core AMD 8160. About 80% of the run is multi-threaded and all cores are pegged. The last bit is constrained mainly by network and disk speed.

You may consider using something like Java/Hadoop depending on your data and compute requirements. Though my Java code is just a step above the level of a grunting walrus, I've found that the performance is actually not that bad and can be pretty good in some cases.

 

Let's cut through the BS and get serious

[satan666]

As others have pointed out, if you are going to do serious research,
you dont want to mess around with the latest and greatest.
Stick with something that has been around and works.
COBOL is that language!

Ha! Made you smile :P

Seriously tho, use C or FORTRAN. Nothing beats them for optimization and speed.
Cheers!

python

[memaartje]

it's easy to learn, it's fast, it's suitable for almost any task because there are many ready to use libraries out there. thus python. btw I learned python in three hours! see github.com/masikh for my work.

I recommend C#.NET

[dryriver]

Not only is C# easy to learn, and easy to both read and write, it also runs at a fairly high speed when it is compiled. To make use of multiple CPU Cores, C# has a neat feature named PARALLEL.FOR. If your algorithm scans across a 2D Data Array using a FOR LOOP at all, Parallel.For will automatically break that array into smaller arrays, and have each calculated by a different CPU core, resulting in a much faster overall computation speed. I develop algorithms in C# and highly recommend it if you want a) a nice, readable code syntax and b) fast execution speed. I hope this helps...

Re:Depends... On the Data...

[K. S. Kyosuke]

If you're data is arranged in lists, consider lisp,

Oh please! It's not like Lisp doesn't have any other data structure, is it? You can have your multidimensional numerical arrays in CL quite easily. (I'm saying neither "use CL" nor "don't use CL", merely that your argument is pretty weak. It's easier to learn to work with lists in the language you already know (unless it's COBOL!) than to learn an entirely different one just because of lists.)

old xeon box? linux vs. xp

[Fubari]

In order to realize all possible performance from your hardware, I would suggest linux over XP.
With xeons going 64-bit around 2005, it would have to be really old to be only 32 bit.
And even if it was an ancient 32-bit only xeon, XP is still going to have issues using more than 3.5 gb ram.
XP process management seems weak to me compared to the linux side of things.

I don't have a favorite brand of linux to recommend; I would ask your professors and fellow researchers if they have a preference (because they are going to be your go-to support crew).

In any event, I would try to max out the ram your specific motherboard can handle.
And I would beg/buy/borrow/steal a modest SSD to run the OS on, you can probably get both for $100 or so.
Keep your data sets on the slower spinning-rust drives.

One especially insightful response I saw above was asking about what kind of computation you're running.
The python guys are probably right.
I suspect your problems with VB is it will be single-threaded, and (I'm not a VB developer, I've just had to cope with it from time to time) not so generous with efficient data types.
I've had some awful experiences trying to run multi-threaded procsses on XP and Java.
I think you'd get better results from ditching XP.
Your actual language doesn't matter as does some parallel-capability.

Finally, the good news: almost anything is certain to be better than running VB in XP.
The fact that you could implement your solution VB suggests that it is not crazy complex.
Doing it in raw C will be a pain because you'll have to code your own process management.
I'd be very interested in seeing if numpy or perhaps "R" can do the math that you need.

Do follow up and let us know what you end up doing.

Congratulations! You are a sysadmin!

[Artagel]

It sounds like you have control of the whole machine, which makes you the sysadmin. You don't only get to choose the programming language. You have to design a workflow. The programming language will fall out of you designing your plan of attack. You have to do so within the limitation of your advisor's budget, the assistance you can beg, etc. Take comfort in the fact that procedural languages are deep down 98% the same with different words for things, it is the libraries that get confusing. And read the library documentation like your life depends on it. It does.

PHP

[Anonymous Coward]

PHP because it's fast, fun and scalable!

*ducks for cover*

Python, R and may be MySQL

[pesho]

You don't specify the scientific field. My experience is from biology and what i can recommend is Python (look at the numpy and BioPython modules) and R (www.cran.org), which is an excellent statistics and data mining tool (again on the biology side it has the bioconductor toolset). MySQL may also come handy to store data depending on the project. I find myself writing some pieces in R, some in Python and using the Rpy2 python module to glue them together. MySQL can also be accessed from both python and R.

lol.

[Grog6]

http://www.hardocp.com/article/2012/05/08/inside_mind_stuart/

I saw it years ago, when everyone was wondering if it was real, lol.

Reminds me, I need some more nyquil...

PDL

[swm]

Perl Data Language
The power of Perl + the speed of C

Re:PDL

[Roger W Moore]

The power of Perl + the speed of C

...and the readability of machine code?

Python

[SunTzuWarmaster]

I am a scientist who dabbles in data mining problems. I use Python with a healthy dose of C++ and the occasional Java. These are probably the three most common languages among the community. I see people using R and Matlab relatively frequently. A bunch of people in this topic have suggested Fortran, but I've never seen anyone use it seriously.

I haven't run into anyone who who doesn't use a minimum of two programming languages (Python/C++, Matlab/Java, etc.).

Note that Kaggle.com (the data mining competition site) frequently posts their example solutions in Python. Failure to understand the Python solution starts you out at a healthy disadvantage.

APL

[Squidlips]

Back when Men were Men....

Re:APL

[mjwalshe]

And Magic was Real - "unless declared as integer" :-)

R with C and Perl

[WillAffleckUW]

We tend to use R, C, some C++, and a lot of Perl.

But then, we do real science.

Re:R with C and Perl

[biodata]

We use a lot of perl too. I mentioned python instead in the post above as I hear a lot of labs use it, but perl is faster and I prefer it personally.

Computationally intensive data mining

[the eric conspiracy]

Sounds like you are working on some sort of similarity search problem.

You probably find most of your peers are working with C/C++.

If that's the case I'd go for that language.

Re:Computationally intensive data mining

[the eric conspiracy]

Seriously? Listen to an anon over a low id user?

Most of the machine learning stuff I've seen is C/C++.

And this stuff doesn't scale all that well to really large datasets.

Plus this guy is an academic.

Look at the frameworks.

[DdJ]

You are not going to write everything from scratch by yourself. You're just not. Not if you actually want to get anything done. You're going to reuse code.

So: figure out what code you're most likely to reuse, what frameworks are useful in the field you're interested in, and let that suggest the language.

If you don't know how to get started on that: asking the question of peers in the same scientific field will get you a more useful answer than asking the question on a wide-open generic technical forum.

Another angle: look at what network databases you want to integrate with (eg. protein databases at nih.gov), and look for sample code showing how to access 'em. That'll give you a clue what other practitioners are doing.

Use what your adviser/group members/colleagues use

[allwheat]

For scientific computing, you will be doing a lot of collaboration and very likely sharing codes with other scientific programmers, very few of whom enjoy learning new programming languages all the time. To simplify/enable collaboration, you should follow what the community uses. In physics, generally that means Fortran. Anything past Fortran90 is basically modern, it's really not too bad to learn and even has basic object-oriented stuff, though not as good as C++. F77 is mostly obsolete and a major pain in the neck, but you will see it around in older codes, as well as a lot of the libraries. There are C/C++/Python/f77/etc codes around, but most physicists use >F90, especially in high performance/parallel computational work. But there are subfields of physics with their own popular tools too. My advice is to go with whatever the majority of your colleagues are using, placing a very big premium on what your adviser and group members use, which is who you will collaborate with the most. What the majority in the field uses is usually suitable for the job anyway.

It sounds like you're interested in parallel computing as well. Fortran is probably the best option then, mostly for the libraries, but you can still interface from C/C++ or whatever. Also, if you have a lot of computationally intensive stuff, you should try to get supercomputer access. Ask around, you should be able to work something out. You'll need to decide on OpenMP or MPI for parallel programming, depending e.g. on your memory, shared/distributed etc. Here's a quick rundown: http://www.dartmouth.edu/~rc/classes/intro_mpi/parallel_prog_compare.html
Most scientific hpc (high performance computing/supercomputer/parallel) is on unix/linux.

What field are you in exactly, and what is the nature of your data mining?

Fortran 2003 + Python + C = profit

[excelsior_gr]

Especially for a beginner Fortran will make the most sense, IMHO. Here's why:
- User-friendly syntax. Especially vector and matrix syntax and operations are very intuitive.
- Strong typing will let you catch lots of errors at compile-time rather than let you hit your head against the wall at run-time.
- Fast in quite a foolproof way (just remember to loop over columns first, or possibly even use the simpler Matlab-like syntax and let the compiler figure it out)
- Usable with OpenMP and MPI
- Massive availability of free code on the net (visit netlib). Old code also has very good chances to run out-of-the-box or with very minor changes.
C is a close second to many of these points. I can't recommend C++ and Java though, as all the clutter will slow you down especially at the beginning. I also like Python a lot, but there's a catch, which brings me to my next point:

Do you have a plan of your program? How well do you know what you'll be programming? Is that going to change a lot along the way? Code changes are a lot harder to implement in Fortran and C than in Python. The abstraction level in Python really amazed me, as the interpreter would run anything I would throw at it. Mixing paradigms in Python makes scientific programming a breeze of fresh air. There are ways to make it quite fast, too! Mixing procedural and object-oriented programming is possible in Fortran as well, but by far not as versatile as in Python. In any case, if you decide to use the OO-paradigm, you have to make sure you have the whole program figured out before you start so that you can define your objects wisely. I have mixed experience with scientific OO in C++, so I can't really recommend it.

Output is also a huge topic in scientific computing. It is a pain to make live graphs in Fortran (the intel compiler has a proprietary library that somewhat helps), but you can export the raw data and use gnuplot or another tool for visualization (even Excel for small graphs). For larger 3D+time datasets there is Paraview. These things are much more fun to do in C/C++. On the other hand, you can use the C-interoperability features of Fortran 2003 and combine them! Or use f2py or PyFort and combine Fortran and Python!

Re:Fortran 2003 + Python + C = profit

[mjwalshe]

or go really old school use GINO-F which is how we did it back in the day :-)

You mean Fortran 77?

[mbkennel]

Things have moved on. Fortran 95+ is almost as easy as Matlab, definitely easier than C++ and faster than both.

And for heavily numerical algorithms it is better designed, beyond just the speed.

The one language question

[jgotts]

If you want to do programming as a career, you need to be flexible enough to be able to pick up any language, so use whatever language you feel comfortable enough using to write maintainable code.

Re:fortran of LaTeX

[The_Wilschon]

LaTeX is a great thing to learn, but it is most emphatically NOT a remotely reasonable choice for writing number crunching code...

"Scientific Computing" is over-broad

[FellowConspirator]

The problem with this question is that "scientific computing" is an over-broad term. The truth is that certain languages have found specific niches in different parts aspects of scientific computing. Bioinformatics, for example, tends to involve R, Python, Java, and PERL (the prominence of each depends largely on the application). Big-data analytics typically involves Java or languages built on Java (Scala, Groovy). Real-time data processing is generally done in Matlab. pharmacokinetics, some physics, and some computational chemistry are often done in FORTRAN. Instrumentation is generally controlled using C, C++, or VB.NET. Visualization is done in R, D3 (JavaScript), or Matlab. Validated clinical biostatistics are all done in SAS (!).

Python is a nice simple to learn start, very powerful, and the NumPy package is important to learn for scientific computing. R is the language of choice for many types of statistical and numerical analysis. Those are a good place to start, if incomplete. From there, I'd look at the specific fields of interest and look at what the common applications and code-base are for those.

With regard to the OS, that's pretty easy: Linux (though OS X is a reasonable substitute). Nearly all scientific computing is done in a UNIX-like environment.

Re:Why not hire someone?

[allwheat]

seconded. If possible this is a nice route.

One word

[vikingpower]

Julia

Also, it is fast

[Sycraft-fu]

In part, this is because Intel has a compiler for it. On commodity hardware (as in desktop, laptop), you will generally get the best performance running an Intel CPU and using an Intel compiler. That means C/C++ or FORTRAN, as they are the only languages for which Intel makes compilers. C++ is easy to see, since so much is written in it but why would they make a FORTRAN compiler? Because as you say, serious science research uses it.

When you want fast numerical computation on a desktop, FORTRAN is a good choice. We have a few researchers here who use it, and they all use the Intel Fortran Compiler because they want fast computation, but they don't have the money to buy bigass systems for every grad student. What they get out of the IFC and a regular Intel desktop chip is pretty impressive.

Compilers matter, and Intel makes some damn good ones. So if your research calls for lots of performance on little budget, that can influence language choices. Heck same thing on supercomputers. That is not my area of expertise, but it isn't as though all compilers for a given supercomptuer will be equally good. If I were to bet, I'd say the FORTRAN compilers are some of the better ones.

no single answer here.

[niftymitch]

The best compiler support for numbers will commonly be Fortran.

Python belongs on the list because slow functions can be coded in C
or another native language for speed. It is also a rich and portable protyping
language.

There is value in asking your advisor.

A linux distro like Centos is well regarded, almost any programming language
can be downloaded. Switching to Redhat for product support has a small learning curve.

R is a statistical rich environment that you should be aware of. Python bindings for R exist so
again Python.

SUMMARY: Python and R. R may be all you need.... R makes charts and graphs, slices dices....
runs on many platforms even WinsowZ

monty

[burdickjp]

Python Python Python Python Python It already does almost everything you could ask for, and is growing in acceptance and userbase. It is a modern language with modern language structure. It is designed to be human readable and consistent.

Keep it simple

[seyfarth]

Your best bet is to use C. It is highly efficient. If possible use computational code like the Atlas BLAS package. This code will run circles around your own code no matter what language you use. You already know C and moving to C++ is a major problem. All the other languages are distractions from your purpose.

If possible run multiple, independent processes rather than writing parallel code. That can be a major ordeal.

If your goal is to process data as opposed to learning elaborate programming techniques, keep simplicity in mind. C is a very powerful language and you can reach maximal efficiency for many problems using Atlas BLAS and multiple processes. If you goal is to get a degree in CS, ignore what I've suggested.

Matlab will fall, SciPy will rise

[steveha]

If you are working in academia, then you probably have access to Matlab.

On the other hand, you definitely have access to SciPy, given that it's free.

I predict that Python with SciPy/NumPy will completely displace Matlab within a few years.

I say that even though I am working in one industry, digital signal processing, that is really married to Matlab and will be one of the last places to make the switch.

Because Matlab was purpose-built for scripting with matrices, it has some nice syntactic sugar for that. In every other way, Python as a language is far superior.

I was able to attend the SciPy conference a couple of years ago, and one thing I heard there: people like that Python works as a universal language. Sysadmins can use Python to do admin tasks; the web site guys can use Python (with Django) to make web sites; the science guys can use SciPy... it's one language that is flexible enough to do anything you might need, and it's much easier to learn than other really flexible languages like Lisp.

Because Matlab has been around a long time and has man-centuries of work invested in it, it has very complete and well-debugged libraries available for it. SciPy is playing catch-up here. But the basics are already solid, and if SciPy will work for you, you should choose it because it is the future.

There was a time, not that long ago, when people spent $30 to get a web browser. Now people expect web browsers to be free. I predict in the near future the same thing will happen with Matlab vs. SciPy.

SciPy has the advantages of being free and open, as well as the advantage of being free as in beer. And Python is just a better language than the Matlab language. Mark my words: Matlab will fall and Python/SciPy will rise.

Re:Matlab will fall, SciPy will rise

[ericcc65]

Speaking as someone who used to use Matlab exclusively and almost got a job with the Mathworks let me say that I hope you're right. I love that scipy gives me a general programming language, and I love that it's free.

But there is one major obstacle before that happens...toolboxes. I'm in the DSP realm too and the signal processing package of scipy just doesn't hold a candle to all the numerous toolboxes that you can get with Matlab. There are some BASIC functions that are missing from scipy and there are a TON of extra functions in the Matlab toolboxes that aren't anywhere close to being implemented in scipy. The communications toolbox alone has so much that scipy doesn't offer it's not even funny.

I guess I should stop complaining and start contributing. But I honestly don't know that I'm good enough of a programmer to feel like I could contribute something. I guess I'm pretty sure I could implement a few algorithms without major bugs, so maybe I should pitch in. I don't know that it would be the prettiest or most optimal, but you've got to start somewhere.

Re:QT

[burdickjp]

Python +PyQT or PyGTK is a similar, and probably easier, answer.

Solved

[piRSqrd]

I recently had to answer this same question for myself and my group. I reduced the problem to evaluating the trade offs of the following dimensions:

• 1. Ease of reading/programming/maintaining by non-professional programmers.
• 2. Accessability.
• 3. Well supported/documented libraries.
• 4. Quickness.

#1 reduced the field of choices (IMO) to * Matlab/Octave * R/S+ * SAS * Perl * Python * Julia
As for #2 gives preference to Python, R, Julia, Perl, or Octave (Your situation may not be as limiting).
#3 led me to many searches that all indicated that R and Python have a rich set of libraries and lots of community support.
As for #4 From Julia's website http://julialang.org/ they show nice benchmark information that indicates that Python is pretty quick.
My conclusion was that I couldn't really go wrong between R or Python. However, I chose Python because it was quicker, I like the syntax better, I like the libraries better (NumPy, SciPy, Pandas, Matplotlib) and is seems to play nicer with everything else. This is what worked for me and how I went about deciding.

Re:bioinformatics and computational biology

[ebno-10db]

Truth is stranger than fiction. Even as a Perl lover, I would never have thought of using it w/ number crunching. Still doubt it would be my first choice.

Investigate Center for Open Science, framework

[myvirtualid]

In addition to the excellent comments previously made, consider investigating the Center for Open Science, specifically their information for developers, and the associated Open Science Framework (note: will display only if cookies are enabled; I've no idea what value they provide in this context and will be contacting them about that).

They may not have anything that can help you. Or they might. Or you might be able to help them. Or not. YMMV, etc.

Worth taking a peek, anyway.

Look for what's already there in your area

[mike449]

The best environment is one that already has the stuff for your application, so that you just cobble together calls to code written by somebody else. Perl + CPAN was the winning combination for many years. These days it seems to be Python+numpy/scipy/scikits.

Depends, but Matlab/Python are mostly great

[istudyplanets]

I would say it largely depends on what people in your field use. I use Matlab on a desktop for data analysis and Fortran/Python for HPC number crunching (astronomy/planetary science). Recent releases of Matlab have seen heavy optimization in number crunching and the parallel processing toolbox is incredibly simple to use. The plotting and graphing tools are second to none and very intuitive if you want to visualize multi-dimensional datasets. For integration of visualization, editing and debugging in one scientifically-oriented IDE, it can't be beat. Plus it sounds like you're familiar with GNU Octave. Python is a better language in my opinion, but lacks some of the 'do-science-straight-out-of-the-box' feel that Matlab is good at. Python obviously has the advantage of being free. The best scientific package is the Enthought Python Distribution which integrates their Canopy IDE with numpy, matplotlib and other great python modules. Free licenses are available to student/academic users.

Scientist here: IDL, Matlab, SQL, C++, Perl.

[Remus Shepherd]

Where I'm coming from: I'm a satellite physicist working as a contractor for the USGS on the Landsat program. I work very closely with NASA.

Almost all the scientific programming we do -- and by 'we' I mean USGS and NASA -- is either in IDL/ENVI or Matlab. They're the defacto standards for scientific processing. We do need to know SQLPlus to get our data out of the databases, and we need rudimentary C++ skills in order to make prototype code for the IT coders to turn into an operational release. Sometimes it's easier to code something in C++ then IDL or Matlab, so it's nice to be able to jump straight to that when warranted. Add Perl for text manipulation (which always turns out to be useful in some way) and that's all the programming I've done for the past ten years. Many scientists in the building swap out ARCGIS or ERDAS for IDL/ENVI. (Matlab doesn't seem to be swappable; you either need to use it or you never touch the stuff.)

I've dabbled in Php when they asked me to prototype a web site but that never went far. I've done a little Flash programming that they eventually decided to hire out for. (I did a fine job, but they wanted the application to go bigger.) In the early days of my career FORTRAN was everywhere, you couldn't get away from it. There are still some FORTRAN programs in-house that I could fiddle with if they asked me to, although I'd blanch at the prospect.

All that said, what you need depends on what your role is. If you're a scientist like me then these self-taught languages might be enough. If you're a science-oriented IT person, you'll need more -- most importantly strong C++ skills, at least around here. And different disciplines will have different needs; I worked briefly for NIH (National Institutes of Health) and they still had COBOL programs.

I know of one person in two organizations (USGS and NASA) who knows Python, and he's an IT guy not a scientist. He's also the only person I know who has ever used Hadoop. I have never met anyone who knew R. Visual Basic is used occasionally here and there for prototyping, and almost immediately switched out with C++ as soon as management decides to support the project.

VB is too slow for you? C++ then...

[bobbied]

I suspect that VB is NOT your problem here. But, if you have a VB program that is too slow, then I'm going to suggest you do the following:

1. Profile your program and see if you can figure out what's taking up all the processing time. It may be possible to change the program you already have slightly and get the performance you need. It would be a shame to go though all the trouble to learn a new language and recode the whole thing if replacing some portion of your code will fix it. Do you have a geometric solution implemented when a non-geometric solution exists?

2. Consider adding hardware - It's almost ALWAYS cheaper to throw hardware at it than to re-implement something in a language you are learning.

3. Rewrite your program in VB - This time, looking for ways to make it perform faster (you did profile it right? You know what is taking all the time right?) Can you multi-thread it, or adjust your data structures to something more efficient?

4. Throw hardware at it - I cannot stress this enough, it's almost ALWAYS easier to throw hardware at it, unless you really have a problem with geometric increases in required processing and you are just trying to run bigger data sets..

5. If 1-4 don't fix it, then I'm guessing you are in serious trouble. If you really do not have a geometric problem, You *MIGHT* be able to learn C/C++ well enough to get an acceptable result if you re-implement your program. C/C++ will run circles around VB when properly implemented, but it can be a challenge to use C/C++ if your data structures are complex.

6. Throw hardware at it - seriously.

Unless you really just have a poorly written VB program or you are really doing some geometric algorithm with larger data sets (In which case, you are going to be stuck waiting no matter what you do) getting better hardware may be your only viable option. I would NOT recommend trying to pick up some new language over VB just for performance improvement unless it is simply your only option. If you do decide to switch, use C/C++ but I would consider that a very high risk approach and the very last resort.

C. Obviously.

[RandCraw]

You know C. C is simple, as fast as any alternative, it's straightforward to optimize (aside from pointer abuse), and you always know what the compiler/runtime is doing. And threading libraries like pthreads or CUDA are best served via C/C++. Why use anything else?

Another thought: scientific libraries. If you need external services/algorithms then your chosen language should support the libraries you need. C/C++ are well served by many fast machine learning libs such as FANN, LIBSVM, OpenCV, not to mention CBLAS, LinPACK, etc.

Metric

[drakesword]

... that is all

nothing beats c++

[Piotrecles]

I work in gambling and we write everything in c++. It's as fast as anything else, and the new standard makes everything a lot easier. Threads especially. You also have tons of libraries at your fingertips: GSL, good RNGs, whatever you can think of. I think C is probably the worst thing to write in if you're just coming back to it. You'll end up spending more time with memory management than you will actually getting stuff done. Go with C++ and use standard containers.

R, Matlab/Octave or Python with Pandas or Numpy/Sc

[joeblog]

My experience at this comes from being a MooC addict where some of the courses are in Python, others in R, and others in Matlab or its GNU counterpart Octave.

Of these Python is my favorite since it's the language I'm most familiar with. Furthermore, you can "bolt" R to Python with the Pandas library, and you can "bolt" Matlab/Octave with the Numpy & Scipy libraries.

A big drawback, however, is speed. The big advantage of domain specific mini-languages over "kitchen sink" languages was brought home to me by writing a Python script to simulate the popular (in statistics courses) Monty Hall problem and the same script in R. While my Python script took several seconds to simulate a couple of thousand Monty Hall game turns, the R script would give the percentage for millions the instant I hit the enter key.

More complicated problems ended up with weird bugs in R scripts I couldn't figure out, whereas (because of my better familiarity with Python's "mutable list" problems) I tended to get correct -- albeit slower -- answers from my Python programs.

Re Octave: whereas R has overtaken commercial versions of S, I've written off Octave as a lame "freeware" version of Matlab -- lots of features are missing, the documentation is frustrating (it seems to only be used by universities, so "gurus" on stackoverflow etc automatically assume any question is some student trying to cheat at homeworkd) so I'm not a fan. But if I knew Octave as well as Python, I might like it.

R, on the other hand, has an obvious speed advantages for the problems it's aimed at, and a probably a better selection of specialist libraries for statistical problems. But it's full of strange quirks for non specialists.

Fortran

[hooiberg]

I have worked for almost a decade in scientific computing, and it is Fortran everywhere. Make sure you get up to the new standard. Contemporary Fortran is not the same as Fortran77. Many problems typically associated with Fortran are things of the past. ;) Next is C. Moreover, Fortran is a fairly easy language to learn. Avoid all object oriented stuff. For scientiicf computing, this is never used, and even shunned to a great degree. Avoid c++ and C# and all that stuff. When you work in SciCom, you will never see that anyway.

Re:More details? (R-is pretty strong)

[EngineeringStudent]

Best is meaningless without a measure of goodness. (from Optimization) You are going to get a slew of candidate bests but folks aren't going to often articulate what makes it best. there will conflicting or even mutually exclusive rubrics.

The goal of the language might include:
- inexpensive (starving college student budget)
- employable (typically used and valued in your post degree career)
- fast enough (not every grad student needs to run on a supercomputer to get their job done)
- great breadth and depth of libraries

IMO the "R" language does some of these really well.
- It imports into JMP, SAS, and Python so you can wrapper it for your job.
- It is engineered and maintained by stats/math grad students so it is wide, deep, and mostly correct
- It is open source so it is free

Personally I use MatLab, which was taught in school and it hurts for the following reason:
- where I work is JMP-dominant, so it is pulling teeth to stay in the $5k/yr CAL.
- nobody else here speaks the language (statistically speaking) so I have to do extensive hand-holding to share the code
- If I am not connected by VPN to the work CAL server, I can't turn on my software

As long as I am not doing CFD I find the interpreted language is good enough. Computers today are much better than the supercomputers of 15 years ago. We have smart-phones with better CPU's than a bleeding edge Pentium II yesteryear.

I particularly like RStudio as an IDE.
http://www.rstudio.com/

a fair point... Re:old xeon box? linux vs. xp

[Fubari]

That is a fair point r.e. reboot vs. data access.
I was thinking of what could give the op a performance boost while staying on a ramen budget.
*shrug* without knowing more it is really hard to say.

And I would beg/buy/borrow/steal a modest SSD to run the OS on, you can probably get both for $100 or so. Keep your data sets on the slower spinning-rust drives.

If he's going to keep the data sets on the spindles then I see no reason at all to invest in a SSD. All calculation takes place in ram, it is loaded and written to spindles... Yeah the computer will boot in 15 seconds instead of 75, but how often is this thing going to be rebooted?

LabView

[Hillgiant]

Leave programming to the programmers. If you want to get science done, use LabView.

Re:bioinformatics and computational biology

[Mike Buddha]

When searching and sorting DNA sequences, it's just [ACGT]* in a text file. Why wouldn't Perl be ideal?

Re:bioinformatics and computational biology

[ebno-10db]

I think of that as text processing rather than number crunching.

Depends on the level of flexibility you need

[mitkey]

If you need to be very flexible, which is typically when you are doing research from scratch -- devising/changing your algorithms often, visualizing the data, etc., I'd suggest MATLAB. It allows you to program and evaluate stuff very quickly. If you are able to vectorize the problem you are solving, it is also very fast, since it uses highly optimized vector/matrix handling libraries.

Once you know what you want to do and how, you might want to implement your stuff in other languages, as MATLAB is cumbersome, if you for example need to process text or perform networking ... or actually do anything that cannot be vectorized. In such a case one choice would be Python, that has lots of libraries for everything.

As for C/C++ (or even Fortran :-o), I would avoid these unless you need to address a bottleneck that cannot be solved by use of an optimized library. And even in such case, I would only rewrite the bottleneck in it, nothing more, and interface with higher-level languages. Programming in C/C++ is literally a minefield for beginners. Updating/refactoring your code in C/C++ takes much more time than in higher programming languages, as you need to take care of many issues related to low-level programming (compared to Python or Java, even C++ is a low level language). Actually I'm surprised that so many people recommend it.

Use what you already know

[Linzer]

You did a fair amount of C? Just refresh your knowledge of C, and you'll be back to business in a few days.

Re:fortran of LaTeX

[MouseTheLuckyDog]

Why not? It's turing complete!

Re:VB is too slow for you? C++ then...

[excelsior_gr]

6. Throw hardware at it - seriously.

This must be the most lame piece of advice on the whole page. If we were having this discussion back in 1990, then yes, "throwing hardware at it" could be the way to go. But now PCs are thankfully in the 64bit era so programs are allowed to allocate a lot of memory (of which there is always plenty in a modern system), SSDs offer fast I/O, your standard CPU has 4 cores or more and the GHz race has stagnated. And this is a very typical PC that you can get for less than 1000 bucks. So what is he going to do to "throw more hardware at it"? Get more memory? This is not going to help unless his program is paging. Should he get more cores or distribute the computation over a network? And he is going to do this with VB how, exactly? Oh, and he never mentioned VB, he mentioned VBA, which is interpreted. By Excel. Yikes.

Using the right algorithm is correct, but it's not going to help much in this case. He'll get a moderate speedup whereas picking the right language will reduce the rum-time by orders of magnitude.

Re:fortran of LaTeX

[excelsior_gr]

I would love to see it done though ;-)

Re:C. Obviously.

[GiganticLyingMouth]

It should also be noted that as of C++11 threading is part of the C++ standard library (so you usually won't have to use pthreads or any other platform-specific threads directly).

Don't be silly..

[h8sg8s]

Don't be silly, you can write FORTRAN in any language..

depends Fortran or Posibly Python

[mjwalshe]

If its really heavy compute intensive I would say use fortran its relatively a simple language to pick up rather than C++ or C.

Quantifying Java performance

[Latent Heat]

I tried various Java profilers and they seemed to offer too much "instrumentation overhead" for what I was doing.

For Java, I use System.nanoTime(). For C++, I use the Windows-specific QueryPerformance() call. So

The technique profilers claim to use is to calibrate the overhead of something like System.nanoTime() with a loop and then subtract the estimated overhead from your instrumented code. The overhead to the nanoTime() calls can even be larger than the execution time of code segments you are trying to measure, but if your estimate is accurate, this works.

I am doing plain add-subract-multiply-divide in a mix of scalar and looped operations on arrays -- if you are doing largely trig or calls into a numeric library, you are timing loops and library calls, not the intrinisic performance of your language.

I am also doing a lot of the OO version of using global variables. Java is supposed to do "escape analysis" where if you allocate inside a method and don't let a reference pass outside, the JIT is supposed to recognize that as a local-context stack allocation, but I am not using an advanced Java version or the right set of JVM flags to get that to work.

two obvious options

[cas2000]

1. get back in to Fortran - especially if you'll be working with other researchers on existing code.

2. python, with the scipy and numpy libraries.

Python Spyder

[srobert]

Python is being suggested frequently here. If you do go with that, I'd strongly suggest taking a look at the Spyder IDE:
http://code.google.com/p/spyderlib/
It's especially useful for scientific work and entirely cross-platform. I even have it running under FreeBSD.

Re:VB is too slow for you? C++ then...

[bobbied]

But, my point is that if you have a properly written program, even in VB, the performance gain from recoding into C/C++ is not going to be all that great considering the effort involved. If time is money (and it usually is) then throwing hardware at the problem is a cost effective solution that has been used for decades to get less than efficient solutions to market.

Please note the ORDER of what I suggest. Always fully evaluate your program's performance weakness and KNOW what is causing the bulk of the problem in your system. This is ALWAYS first. KNOW how your solution scales and why your performance is what it is. I'm just guessing here, but I'll be willing to BET that the issue is not his choice of tools (visual basic) but either how it was coded and/or the nature of the problem. VB is not the fastest solution for data processing out there, but it's not a total disaster in performance either.

If you are seriously suggesting that VB is orders of magnitude slower than C++, I'm going to object. (And I'm an old C programmer with decades of experience who hates VB.) If you use VB properly, it's not great, but it's not a total dog either. You should get *some* improvement but not 10X better. Further, I'm going to claim that a novice C++ programmer is extremely unlikely to be able to punch out performant C++ code that has any kind of data structures to process. So the situation is we have some performance improvements possible, but we also have a novice programmer.

Both of these issues tell me that the least risky way to take a reasonably well written VB program and improve it's performance is to throw HARDWARE at it. Throwing programing resources who don't know C++ at it to convert it is a way to spend a lot of money/time and get nothing to show for it.

I hate throwing hardware at problems too. I've seen it done many times and it seems a waste. But I've also seen projects flounder because they where hesitant to re-spin the processor card and add that extra memory or faster processor where we spent many hours wringing out a few more bytes here and making that interrupt routine a few cycles shorter there. Of course it was really expensive to change custom hardware, so sometimes you just have to make it fit. Off the shelf hardware is CHEAP, and often it makes the most sense when you consider how much programming effort costs. I could be wrong, but in this case, I'd recommend trying to fix the VB code first, then throw hardware at it

Julia is build for Scientific Computing

[AeiwiMaster]

Take a look at Julia. http://julialang.org/
It is almost as fast as C, which make it much faster than Matlab, Octave, R and Python.

Re:Julia lang seems to match your needs.

[spike hay]

I'm using Julia for most of my work. It's very usable. There's good libraries for most common tasks now, and for anything that there isn't, Python functions can be called (with automatic conversion to Numpy arrays, etc) with no wrapper with a package called PyCall. This is a feature that Julia developers should really make more noise about.

For example, suppose I want to do a simple plot of a two vectors x and y:
________________
using PyCall #import the module
@pyimport matplotlib.pyplot as plt #import the Python module itself
plt.plot(x,y)
plot.show
-------------
That's it. A window with the plot shows up, exactly as it would in python.

Apart from that, Julia has many innovative features. A good type system and multiple dispatch make for a very elegant and fast language. As well, like lisp, code is data like any other, allowing for useful macros (the @pyimport is actually a macro call). I used to use Matlab, and then Python/Numpy, but a really haven't looked back after moving to Julia.

Java

[maroberts]

Reasonable performance - better than Python, Perl, PHP, not much worse than C/C++ or Fortran
Object Oriented,readable and easy to learn quickly.
Modern day language
Widely understood in Educational field.
Can test your code on your Android phone :-)

Re:VB is too slow for you? C++ then...

[confused one]

he said he was using VBA, which is not fully compiled code and is probably a set of Excel macros. VBA in Excel isn't particularly fast and is single threaded. If, however, he moves his code to one of the compiled versions of VB then he will see a performance boost and be able to spawn multiple threads.

Python along with C/C++ or FORTRAN

[amicitas]

I do scientific programming for a living (Fusion Scientist) and have extensively used a lot of different languages in my research including:
Python
IDL
MATLAB
FORTRAN
C/C++
Ruby

When working on my own project my favorite setup is to use Python along with Scipy/Numpy. When I need extra speed I use Cython, and also use Cython to interface with libraries that are written in C or C++. For interaction with my codes I use ipython (assuming I need command line interaction) or QT (assuming I need GUI interaction). For libraries written in FORTRAN I use f2py. For plotting I use matplotlib.

This setup works very well for me. It is fast and powerful, almost completely platform independent, and has excellent mathematical and scientific library support. It is extremely easy to integrate C/C++ or FORTRAN code into a Python project which can be extremely useful. It is also very straight forward to do basic multithreading and parallelization. Interactive debugging is very easy and can really help both in the development and in finding problems with scientific calculations. Plotting support is fantastic and easy.

I would say that the next best option is MATLAB. This has good support, an excellent mathematical and scientific library and good plotting tools. I don't particularly like the language for large and complicated projects, and it does require a license, which can make it difficult or impossible to share codes between institutions.

Working directly in C/C++ or FORTRAN is fine for certain kinds of large projects, but is inconvenient for working on lots of small projects or numerous related calculations. Doing something simple like creating a plot requires a significant amount of programming, and debugging can be very time consuming.

I would stay away from IDL; while a nice language in many respects, it is quite out of date at this time and is no longer well supported in terms of staying current. Ruby does not have sufficient support in terms of math/science/plotting libraries at this point to work well for scientific programming.


At the end though it does really matter what kinds of projects you will be working with and what your final goals are. It also matters who else you will be working with to make sure that code can be easily shared.

Re:VB is too slow for you? C++ then...

[excelsior_gr]

Read the summary and my last comment again, carefully, and the comment by user "confused one" right below. He is using VBA not VB. Visual Basic for Applications. Not the same thing. And yes, a re-write from VBA in any compiled language will get him at least a speedup of one order of magnitude, maybe two. Add to this your advice on algorithms and he won't know what hit him.

It's not that I don't like updating the hardware because of cost or whatever, it's that I can't add more hardware any more. For a single threaded application in VBA there is nothing you can do to make it faster anymore hardware-wise. Again, algorithmic optimization is to the point but "more hardware" isn't. Even massively parallel applications hit a wall at some point where the data distribution and communication costs start to outweigh the speedup you get by the extra processors. BTW, I found out that VB can also be parallelized natively as well, but the re-write alone from VBA to VB will do the trick.

Re:C. Obviously.

[Teckla]

You know C. C is simple, as fast as any alternative, it's straightforward to optimize (aside from pointer abuse), and you always know what the compiler/runtime is doing. And threading libraries like pthreads or CUDA are best served via C/C++. Why use anything else?

This is just nonsense, and to see it constantly repeated and modded up is just sad.

C is only simple in the same way a written alphabet with only two letters is simple: sure, you only have to remember the letters A and B (simple!), but actually using it is not simple.

For crying out loud, in C, you can't even do A = B + C; without having a very good chance of invoking undefined behavior. Why? Because in C, overflow or underflow on signed values has undefined behavior!

Access beyond the end of an array and damage data elsewhere in the system (making it often really hard to find)? No problem!

Laboriously managing your own memory (and probably leaking it)? No problem!

What, real strings? Heck no, real men like to take the risk of overflowing the strings and their buffers!

C is filled with literally hundreds of mine fields just waiting to trap the unwary, and often forces you to write a lot of code that would only be a few lines in a higher level language.

C is not simple to use. C is not simple to use.

Javascript/NodeJS: speed is overated/pointless

[fygment]

Javascript is the language of the UI of the future: the browser.
Javascript is fast enough: 2x C/C++ (on par or faster for some tasks).
Javascript is ... lacking libraries BUT it can call C/C++ routines or the latter can be converted to JS/NodeJS using Emscripten/LLVM.

Speed only makes sense in real-time apps, say day-trading or control systems. If you are crunching numbers, what difference does an hour or a day or a week make? Seriously, if you are sitting around idle while your numbers a crunching, you are a waste of space. You should be:
planning the next experiment,
reviewing/refactoring your code for correctness and efficiency,
writing the paper in which your results will be published (esp. intro, background, experimental set-up/procedure),
setting up the website on which you will publish the pre-print so others can review your work and maybe prevent you from publishing foolishness,
fleshing out your next steps to follow your results,
thinking of your next great hypothesis.

Screw speed, it will come with faster processors. Code, make your code correct, and make it accessible and shareable. Javascript/Nodejs will do that in spades.