About alternatives to Matlab

[Mark Morss]

Carl,

I agree with practically everything you say about the choice between
Python and functional languages, but apropos of Ocaml, not these
remarks:

>
> In the same way that a screwdriver can't prevent you from driving a
> nail.  Give me a break, we all know these guys (Haskell especially) are
> designed to support functional first and other paradigms second.  Way
> second.  That's quite enough imposing for me.
> ...
> And let's face it, functional
> languages are (or seem to be) all about purity.

As you will see if you look at some OCaml references (there are a
number that are available on the OCaml website) that OCaml goes a very
long way toward facilitating imperative, procedural methods.  It's
possible to write perfectly good code in OCaml and not use functional
methods.  The OCaml people are fond of saying "OCaml isn't pure."
Indeed, the need for speed is one very good reason to choose and
imperative style over a functional one.


Carl Banks wrote:
> Jon Harrop wrote:
> > Carl Banks wrote:
> > >> 0.56s C++ (direct arrays)
> > >> 0.61s F# (direct arrays)
> > >> 0.62s OCaml (direct arrays)
> > >> 1.38s OCaml (slices)
> > >> 2.38s Python (slices)
> > >> 10s Mathematica 5.1
> > > [snip]
> > >> 1.57s Python (in-place)
> > >
> > > So,
> > > optimized Python is roughly the same speed as naive Ocaml
> > > optimized Ocaml is roughly the same speed as C++
> >
> > Absolutely not:
> >
> > Optimized Python is 14% slower than badly written OCaml.
>
> I'd call that roughly the same speed.  Did you use any sort of
> benchmark suite that miminized testing error, or did you just run it
> surrounded by calls to the system timer like I did?  If the latter,
> then it's poor benchmark, and 10% accuracy is better than you can
> expect.  (Naive tests like that tend to favor machine code.)
>
> > Given the problem,
> > rather than the Python solution, nobody would write OCaml code like that.
> >
> > Unoptimised but well-written OCaml/C/C++ is 2.5-2.8x faster than the fastest
> > Python so far whilst also requiring about half as much code.
>
> Frankly, I have a hard time believing anyone would naively write the
> Ocaml code like the optimized version you posted.  You'd know better
> than I, though.
>
> > Optimising the C++ by hoisting the O(log n) temporary array allocations into
> > one allocation makes it another 20% faster. I'm sure there are plenty more
> > optimisations...
> >
> > >> There aren't any complicated types in the above code. In fact, there are
> > >> only two types: float and float array.
> > >
> > > You're vastly underestimating the complexity of numpy objects.  They
> > > have an awful lot going on under the covers to make it look simple on
> > > the surface.  There's all kinds of type-checking and type-conversions.
> > > A JIT that folds loops together would have to have knowledge of that
> > > process, and it's a lot of knowledge to have.  That is not easy.
> >
> > My suggestion doesn't really have anything to do with numpy. If you had such
> > a JIT you wouldn't use numpy in this case.
> >
> > That's my point, using numpy encouraged the programmer to optimise in the
> > wrong direction in this case (to use slices instead of element-wise
> > operations).
>
> Ok, I can see that.  We have a sort of JIT compiler, psyco, that works
> pretty well but I don't think it's as fast for large arrays as a good
> numpy solution.  But it has more to deal with than a JIT for a
> statically typed language.
>
> > >> I was referring to the slicing specifically, nothing to do with
> > >> functional programming. My F# and OCaml code are now basically identical
> > >> to the C++ code.
> > >
> > > It is pretty strong thing to say that anything is fundamentally bad
> > > just because it's not fast as something else.  Fundamental badness
> > > ought to run deeper than some superficial, linear measure.
> >
> > The slice based approach is not only slower, it is longer, more obfuscated
> > and more difficult to optimise. That doesn't just apply to Python and
> > numpy, it also applies to Matlab, Mathematica etc.
> >
> > Which begs the question, if you were writing in a compiled language like F#
> > would you ever use slices?
>
> If I was writing in F#?  I absolutely would, because some problems are
> most cleanly, readably, and maintainably done with slices.  I don't
> have any speed-lust, and I don't waste time making things fast if they
> don't need to be.  I would rather spend my time designing and
> implementing the system, and optimizing things that actually need it.
> I don't want to spend my time tracking down some stupid indexing error.
>
> If it was critical for it to be fast, then I'd pull out the stops and
> write it as efficiently as possible.  In my experience, a typical
> middle size program will have half a dozen or so subroutines where it's
> critical to be as fast as possible.
>
> Will any other F# people do it?  I don't know if they all have
> speed-lust, or if they'd all deliberately avoid slicing to prove some
> kind of point about functional programming and/or non-machine-compiled
> languages, but I assume there'd be some who would do it for the same
> reasons I'd do it.
>
> > > Now, I was going to write the program in Python, and use the very
> > > convenient numpy to do the transformation part.
> >
> > What makes numpy convenient?
>
> It's in Python, it's almost always fast enough, it's clean, it scales
> up well, it expresses mathematical concepts straightforwardly, it's
> well suppported, it has useful advanced functionality built in (linear
> algebra, etc.).
>
> And a lot of the time, you don't have to worry about indexing.
>
> > > No problem, numpy will be fast enough for my needs.
> >
> > Ok. But you'd rather have a compiler?
>
> Python *is* compiled, buddy.  It has a VM that runs bytecode.
>
> But, would I rather have a seperate compile to *machine code*, when an
> automatic compile to VM code is fast enough?
>
> Not remotely.  Compilers are a PITA and I avoid them when it's
> possible.
>
> > > But wait!  It's silly try to optimize code in a fundamentally slow
> > > language!  It's vanity to even try!  I guess for the sake of getting
> > > this little D4 transform to double in speed
> >
> > C++ is currently 3.4x faster than Python.
>
> Oh, well *that* made all the difference.
>
>
> > > I'll scrap Python and write the whole thing in OCaml.
> >
> > Why not drop to C for this one function?
>
> Why would I?  The assumptions clearly stated that numpy is fast enough.
>  Why would I take several hours to write a C extension when I could do
> it with numpy in about 20 minutes, *and it's fast enough*?
>
>
> > > [snip]
> > >> This is really great work but I can't help but wonder why the authors
> > >> chose to use Python when other languages seem better suited. I'd like to
> > >> work on raising people's awareness of these alternatives, and probably
> > >> create some useful tools in the process. So I'm keen to learn what Python
> > >> programmers would want/expect from F# and OCaml.
> > >>
> > >> What would it take to make you convert?
> > >
> > > Them not being functional would be a good start....
> >
> > They don't impose functional programming on you.
>
> In the same way that a screwdriver can't prevent you from driving a
> nail.  Give me a break, we all know these guys (Haskell especially) are
> designed to support functional first and other paradigms second.  Way
> second.  That's quite enough imposing for me.
>
> Look, I don't want to accuse you of anything, but when you come in here
> and say "speed is crucial" and then "you should be using Haskell,
> Ocaml, F#, etc., ...even though C++ is faster...", it gives off a
> really strong signal that you're not interested in speed so much so as
> in pimping functional languages; speed is just the mechanism.  Which is
> fine; those languages are undeniably faster, and there's nothing wrong
> with using an advantage of a language to push it, if you're respectful.
>
> But let me offer you some advice: if you wan't to lure people from
> Python, speed isn't going to cut it.  Most people who chose Python
> (and, let's face it, most people who use Python chose it themselves)
> already knew it was slow, and chose it anyways.  Pythonistas prefer
> Python because it's clean, readable, well-supported, and practical.
> Practical might be the sticking point here.  If you were to get a
> Python prompt, and type "import this", it would print the Zen of
> Python, a set of principles by which the language is designed.  One of
> them is "Practicality beats purity."  And let's face it, functional
> languages are (or seem to be) all about purity.  Notice that there's no
> Zen that says "Fast is better than slow".  If you want us to swtich to
> Ocaml, you better figure out how it supports the Zen of Python better
> than Python does.
> 
> 
> Carl Banks