Timing comparison for diffeq program in c++, Maple and Maxima

I ran a timing test comparison for c++, Maple and Maxima.
All three programs generated by omnisode - a set of Ruby programs.
Set time limit to 1 minute.
Maximum iteration was sufficient to solve entire problem.
Problem was sin.ode for all three.
Output was redirected to file only - none to screen
Results:
c++ solved entire problem in 23 seconds (140001 iterations)
Maple performed 11542 iterations in 60 seconds
Maxima performed 372 iterations in 60 seconds
That amounts to:
c++ 6,087 iterations/second
Maple 192 iterations/second
Maxima 6.2 iterations/second
c++ is almost 32 times faster than Maple which is almost 31 times faster than Maxima.
So c++ is almost 982 times faster than Maxima.

More info on omnisode at:
http://sode.sourceforge.net/



Dennis J. Darland
dennis.darland at yahoo.com
http://dennisdarland.com/
http://dennisdarland.com/dennisdaze/
http://dennisdarland.com/philosophy/
http://sode.sourceforge.net/
"According to the World Health Organization, the warming of the planet caused an additional 140,000 deaths in 2004, as compared with the number of deaths there would have been had average global temperatures remained as they were during the period 1961 to 1990. This means that climate change is already causing, every week, as many deaths as occurred in the terrorist attacks on September 11, 2001"
-- Peter Singer _Practical Ethics, Third Edition_, p. 216.


--- On Sun, 7/22/12, Dennis Darland <dennis.darland at yahoo.com> wrote:

> From: Dennis Darland <dennis.darland at yahoo.com>
> Subject: On Ruby program to generate maxima or maple code to solve differential eq's
> To: "Richard Fateman" <fateman at eecs.berkeley.edu>, "math maxima" <maxima at math.utexas.edu>
> Date: Sunday, July 22, 2012, 4:32 PM
> I will be testing larger step sizes
> (again) when I am reasonably sure I have the rest all
> working correctly. I have made some improvements (which I
> think will improve both speed and accuracy), but these must
> be tested systematically. I know of some problems I haven't
> got to yet. I had not implemented them (the improvements)
> before as I needed to get the general design working
> correctly first - which I think I have done. I still need to
> retest there also - especially systems of equations. There
> is also work to do on estimating poles and making
> adjustments for them. But you must put the horse before the
> cart. There is no rush. I want to be systematic and
> thorough. I have no deadline. Also I am more interested in
> the asymptotic upper bound of the algorithm than how a
> particular implementation performs.
> 
> Though, I suppose, would like a big following, it is not a
> big deal. One of Bertrand Russell's favorite quotations from
> the Bible had to do with not following a multitude to do
> evil. I don't think traditional computational scientists are
> evil, but I still have no reason to follow them, or worry
> that they are not following me. I am trying to make whatever
> I accomplish available through sourceforge. This is just
> something I am interested in.
> 
> Dennis J. Darland
> dennis.darland at yahoo.com
> http://dennisdarland.com/
> http://dennisdarland.com/dennisdaze/
> http://dennisdarland.com/philosophy/
> http://sode.sourceforge.net/
> "According to the World Health Organization, the warming of
> the planet caused an additional 140,000 deaths in 2004, as
> compared with the number of deaths there would have been had
> average global temperatures remained as they were during the
> period 1961 to 1990. This means that climate change is
> already causing, every week, as many deaths as occurred in
> the terrorist attacks on September 11, 2001"
> -- Peter Singer _Practical Ethics, Third Edition_, p. 216.
> 
> 
> --- On Sun, 7/22/12, Richard Fateman <fateman at eecs.berkeley.edu>
> wrote:
> 
> > From: Richard Fateman <fateman at eecs.berkeley.edu>
> > Subject: Re: [Maxima] maxima is 100 times slower than
> maple
> > To: "Dennis Darland" <dennis.darland at yahoo.com>
> > Cc: "maxima List" <maxima at math.utexas.edu>
> > Date: Sunday, July 22, 2012, 3:23 PM
> > On 7/22/2012 12:17 PM, Dennis Darland
> > wrote:
> > > The step sizes I used there were for test
> purposes.
> > Because I use the analytic solution for the initial
> > conditions, as well as comparison to the numeric
> solution.
> > They start identical. If all is well, with a very small
> step
> > size they stay very close.
> > The justification for the taylor series solution (not
> > exactly analytic...)
> > is that it will take much longer per step, but each
> step
> > will be huge,
> > at least away from singularities.
> > 
> > You should be seeing how large a step size you can take
> and
> > still have substantial agreement.
> > 
> > As far as evaluating the taylor series rapidly, it is
> > definitely plausible
> > to create and compile a program to do so, all within
> > Maxima/lisp,
> > that would be considerably faster.? It would help to
> > reduce all the
> > coefficients to double-floats and declare their types
> > appropriately.
> > With some skill and perhaps luck in choosing the right
> > implementation
> > of Lisp under the Maxima, you can certainly get a
> factor of
> > 100X
> > speedup. Or more.
> > 
> > The major issue with these methods is that they are
> > unpopular with
> > the people who actually might use them (computational
> > scientists)
> > because (a) the methods are quite different and in
> some
> > sense
> > not comparable to the familiar old methods. (b) They do
> not
> > push on the
> > driving edge of faster / parallel / hardware but
> rather
> > smarter software.
> > (c) Computer algebra systems are, for the most part,
> under
> > utilized by
> > computational scientists. (d) Such systems are
> generally
> > not presented to students at appropriate times in
> > survey/introductory
> > computational courses, but -- if taught at all--
> relegated
> > to some 
> > special (often theoretical) advanced
> > course.
> > 
> > 
> > >???The difference between the analytic
> > solution (numerically evaluated) and the numeric
> solution is
> > usually much less than the step size. (This is not a
> > necessary truth - there could be a VERY large
> derivative).
> > But if there is any significant divergence this
> usually
> > indicates either I have the analytic solution wrong,
> or
> > there is some error in my program. I am testing at
> this
> > point. Really, practically, solving problems no doubt
> you
> > would need & try a larger step size or it would
> take too
> > long. But you need to make sure your program works
> correctly
> > first. A very small step size seems to me to be helpful
> in
> > this regard. The time estimate would be especially
> useful in
> > practical problems, but I find it
> > >???interesting even here. (BTW it goes up
> > to millennia.) You can run the problem for a small
> number of
> > iterations, and get a good idea how long the whole
> problem
> > would take. My interest is all theoretical anyway. I
> have,
> > myself, no problems to solve. But I would not mind if
> it
> > turned out to be useful for something. (BTW I did not
> name
> > the thread and am not worried about the speed of maxima
> -
> > though my testing seems to confirm it is much slower at
> what
> > I am doing than Maple is.)
> > > Also there are some links elsewhere on the home
> page to
> > tests with various sizes of increment and I do need to
> do
> > more of that. That is of theoretical interest as well
> as
> > practical. But being correct comes first.
> > >
> > >
> > > Dennis J. Darland
> > 
> >
> 
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>