4 ms·

For physics simulators it is C++, C, and Fortran. I knew people who had SciPy code and rewrote it in C++. Many in the HPC community think anything that is not

For physics simulators it is C++, C, and Fortran. I knew people who had SciPy code and rewrote it in C++. Many in the HPC community think anything that is not compiled is a joke.

iyulaev 14y ago
Yes. I've used SciPy for some pre/post-processing but for the simulation kernel, C(++) or Fortran it was. Despite claims of JIT compilation, automatic parallelism, etc that matlab and other languages promised, our C-based implementation crushed everything else.
- codewright 14y ago
  >Despite claims of JIT compilation, automatic parallelism My experience with repeatedly seeing claims like this in different contexts is that I'm not sure they've ever exceeded the performance of static binaries in pretty much anything. They used to claim it for Lisp, then Java. I'm done waiting, I'd rather just use something I know can be made fast than hoping the PyPy guys do magic.
  - pnathan 14y ago
    You should be aware that Steel Bank Common Lisp is, in many cases on Ye Old Shootout, close to static binary performance. Certain blog posts from some of the community record results that have beaten C++ results. (Numerical performance, as I recall, but don't quote me). My point is that in certain scenarios where you need performance but aren't willing to pay the C++ grief, you can get away with better languages without significantly sacrificing.
    - codewright 14y ago
      A few points of order: 1. My first high-level language was Common Lisp (clisp). >My point is that in certain scenarios where you need performance but aren't willing to pay the C++ grief, you can get away with better languages without significantly sacrificing. 2. And? I expressly said that when you need to be able to squeeze every last ounce and have total control over the behavior of the program and that's when this discussion became relevant. Close only counts in hand grenades and horseshoes. I'm talking about systems work.
- iyulaev 14y ago
  Oh, having the performance of a static binary would be wonderful. We were more than 1 order of magnitude off.
codewright 14y ago
>Many in the HPC community think anything that is not compiled is a joke. As someone who works with a lot of Python/NumPy/SciPy, I can see how they'd come to that conclusion. Python's a great way to prototype, but a production runtime for high performance applications it is not.
- cdavid 14y ago
  A production runtime for high performance does not mean much: it depends on the cost you're willing to bear. If you have a team of very gifted C/C++/Fortran programmers and have a long-term plan, then great, go for it. But what I have seen more often than not is mediocre developers having unmanageable c++ codebases with so many issues it is not even funny: boost with swig with some multithreading in the mix that is full of race conditions, things that can only be compiled with a lot of voodoo. Also, the intersection really good C++ programmers + domain specific knowledge is very small in general. I don't think that's where the world is going in general, honestly, except for some niches or areas where skilled human factor is cheap (e.g. academia).

For physics simulators it is C++, C, and Fortran. I knew people who had SciPy code and rewrote it in C++. Many in the HPC community think anything that is not compiled is a joke.

iyulaev 14y ago

Yes. I've used SciPy for some pre/post-processing but for the simulation kernel, C(++) or Fortran it was. Despite claims of JIT compilation, automatic parallelism, etc that matlab and other languages promised, our C-based implementation crushed everything else.

codewright 14y ago
>Despite claims of JIT compilation, automatic parallelism My experience with repeatedly seeing claims like this in different contexts is that I'm not sure they've ever exceeded the performance of static binaries in pretty much anything. They used to claim it for Lisp, then Java. I'm done waiting, I'd rather just use something I know can be made fast than hoping the PyPy guys do magic.
- pnathan 14y ago
  You should be aware that Steel Bank Common Lisp is, in many cases on Ye Old Shootout, close to static binary performance. Certain blog posts from some of the community record results that have beaten C++ results. (Numerical performance, as I recall, but don't quote me). My point is that in certain scenarios where you need performance but aren't willing to pay the C++ grief, you can get away with better languages without significantly sacrificing.
  - codewright 14y ago
    A few points of order: 1. My first high-level language was Common Lisp (clisp). >My point is that in certain scenarios where you need performance but aren't willing to pay the C++ grief, you can get away with better languages without significantly sacrificing. 2. And? I expressly said that when you need to be able to squeeze every last ounce and have total control over the behavior of the program and that's when this discussion became relevant. Close only counts in hand grenades and horseshoes. I'm talking about systems work.
iyulaev 14y ago
Oh, having the performance of a static binary would be wonderful. We were more than 1 order of magnitude off.

codewright 14y ago

>Many in the HPC community think anything that is not compiled is a joke. As someone who works with a lot of Python/NumPy/SciPy, I can see how they'd come to that conclusion. Python's a great way to prototype, but a production runtime for high performance applications it is not.

cdavid 14y ago
A production runtime for high performance does not mean much: it depends on the cost you're willing to bear. If you have a team of very gifted C/C++/Fortran programmers and have a long-term plan, then great, go for it. But what I have seen more often than not is mediocre developers having unmanageable c++ codebases with so many issues it is not even funny: boost with swig with some multithreading in the mix that is full of race conditions, things that can only be compiled with a lot of voodoo. Also, the intersection really good C++ programmers + domain specific knowledge is very small in general. I don't think that's where the world is going in general, honestly, except for some niches or areas where skilled human factor is cheap (e.g. academia).