Fortran comparison Re: [SciPy-dev] scipy.weave versus simple C++.

[Prabhu Ramachandran]

>>>>> "eric" == eric  <eric at scipy.org> writes:

    eric> I've rewritten the code in C++ as quickly as I know how and
    eric> added a few optimizations.  It has the same errors as the
    eric> previous example, but, again, is useful for
    eric> benchmarking. (maybe Prabhu will fix my bugs in this code
    eric> also. :) The results are as follows:

Yes, I'll try to fix this one also.  I'll stop with this though.  I
hope no one decides to send in an inline assembler comparison. ;)

    eric> Blitz indexing: Iterations took 3.54500007629 seconds.
    eric> After re-write: iterations took 1.77300000191 seconds.

    eric> I think it used to be, but the recent years have been kinder
    eric> to C than Fortran.  Among other things, market forces have
    eric> pushed C/C++ compilers to evolve more quickly than Fortran
    eric> compilers simply because more people are interested in fast
    eric> C/C++ compilers.  The result is that C/C++ can be made to
    eric> execute algorithms at close to the same speed as Fortran in
    eric> most cases -- at least that has been my experience.  As for
    eric> gcc and g77, I think only the front ends of the compilers
    eric> are different.  The same back-end is shared by both.

I also think that it is a known fact that if one uses something like
blitz++ can acheive speed as good if not better than Fortran.

    eric> the above reasons are valid.  Scientist are interested in
    eric> the fastest way to results -- not in writing elegant, full
    eric> featured, re-usable, scriptable programs.  For one or more
    eric> of the above reasons, some still consider Fortran their best
    eric> choice to optimize this interest.  Other scientist choose
    eric> Matlab or IDL or even C.  Hopefully we can increase the
    eric> share that see Python+Numeric+SciPy+f2py+weave as a good
    eric> choice also.

Yes.  Unfortunately, dylan is not as complete or mature as Python is.
To me it seems the best possible approach where you can rapidly
prototype and later speed up your code all in the same language.

    eric> This thread definitely needs to get summarized and put into
    eric> a web page.

Well, I'll work on a draft sometime next week and send it to you
folks.

Meanwhile I'm stuck pretty bad on f2py.  Yeah, this discussion might
not belong here but I need to get Pearu's example working if I am to
include it.  More on that later.

prabhu