On Tue, May 13, 2014 at 09:53:27AM +0200, Konrad Hinsen wrote: > Matthias Felleisen writes: > > > > Note however that I didn't look at performance, which is not > > > really important for most of what I do. > > > > In hindsight that is obvious from your use of Python :-) It should > > have clicked in me, but I am just so used to think "scientific > > computation ~ simulations of nuclear bombs, aircraft wings, oil > > platforms, and such" and that's when performance is the overriding > > concern. > > That's a very common misconception. High-performance computing is the > most visible part of scientific computing, but not what most > scientists write code for. Mundane tasks such as file format > conversion take much more of our time. > > That said, it's interesting to look at why Python became such a > popular language in science. Python code rarely has great performance, > but Python makes interfacing to C and Fortran code very easy. Most > domain-specific scientific libraries for Python have a C library at > their core. One reason for this simplicity of interfacing is Python's > reference-counting approach to garbage collection. In many scientific > applications, the bulk of the data is held in NumPy arrays, which is > just a C/Fortran array plus some bookkeeping information for Python. > Both sides can work on the data, with no copying and no access > restrictions due to garbage collection. > > The price we pay for this is of course the dangers of C and its > explicit memory management. I'd really love to get away from this (and > I know I am not alone), but there is no GC-based language yet (as far > as I know) that is convenient enough for scientific computing. The > most frequent problem (also in Racket) is GC ruining performance for > short-lived small data items (think of complex numbers or points in 3D > space). Even if the GC overhead itself is small with a good > generational GC, GC tends to prevent other code optimizations > that are crucial for performance.
There's Modula 3, which is not nearly as well-known as it ought to be. It is type-safe, garbage-collected, object-oriented (as well as traditionally procedure-oriented), and doesn't have any significant overhead for complex numbers. Complex numbers simply don't need to be stored as separate garbage-collected objects, any more than integers do. It interfaces well with Fortran and C. You mark modules as being UNSAFE, which allows you to use UNTRACED pointers to non-garbage-collected storage (such as that used by C and Fortran). Of course, when you do that to a module, you can evade type-safety as well, which is why it's normally only done when it's absolutely necessary. See the links in its Wikipedia article for details. -- hendrik ____________________ Racket Users list: http://lists.racket-lang.org/users
