ode in c/fortran
in [Matlab]
|
Prev: Matlab sucks
Next: Cluster Purity and Cluster Entropy
From: kizzie on 18 Sep 2009 00:52 Dear all, Why are the ode functions in Matlab still m coded? I guess, a lot of our calculations would run much faster when these functions would be built-in, or c or fortran based. Is there a specific reason why this isn't done yet? Cheers, Kizzie
From: Rune Allnor on 18 Sep 2009 06:59 On 18 Sep, 10:52, kizzie <kizzien...(a)gmail.com> wrote: > Dear all, > > Why are the ode functions in Matlab still m coded? I guess, a lot of our calculations would run much faster when these functions would be built-in, or c or fortran based. > Is there a specific reason why this isn't done yet? Because speed is not a priority in matlab? I would imagine problems with feeding anonymous functions to a C/Fortran implementations. If you want the capacity to use the sover with aonymous functions, you would need a callback form C to the matlab workspace. This callback would induce a lot of overhead compared to a pure C implementation, which might mean that one only gains a fraction of the potential speed compared with the pure C implementation. In other words: One would add a lot of complexity and get only a little gain in return. Rune
From: Bruno Luong on 18 Sep 2009 07:52 kizzie <kizzienova(a)gmail.com> wrote in message <1450093932.5590.1253263969195.JavaMail.root(a)gallium.mathforum.org>... > Dear all, > > Why are the ode functions in Matlab still m coded? I guess, a lot of our calculations would run much faster when these functions would be built-in, or c or fortran based. > Is there a specific reason why this isn't done yet? In many applications, the major part CPU time in ODE resolution is to evaluate user functions (RHS). There is very little gain to code in C, which is more difficult to maintain. Bruno
From: Jan Simon on 18 Sep 2009 09:19 Dear kizzie > Why are the ode functions in Matlab still m coded? I guess, a lot of our calculations would run much faster when these functions would be built-in, or c or fortran based. > Is there a specific reason why this isn't done yet? Program time = programing time + debug time + run time. If the run time is a few minutes (or hours) only, the advantage from a small debug and programing time still matters. In a lesson for numerical optimization, I offered a Dormand-Prince-Compiler to my students in a C and a Matlab version. The C-method could called through a MEX interface from Matlab also. Then they got the job to insert an internal numerical differentiation to measure the sensitivity of the results. The students, who decided to do the job in Matlab, needed some hours and the assessment of the results was easy for me. For the solutions in C I had to cope with segmentation faults, problems with underscores when calling BLAS lib or even better: self-programed vector libraries. My conclusion: If a user sits in front of a GUI and waits, 5 sec is the maximum bearable delay. Otherwise speed does not matter. Success does. Frustration after hours of debugging does, too. Therefore the slow Matlab directly supports a peaceful mind. In tranquility, Jan
From: Rune Allnor on 18 Sep 2009 10:31
On 18 Sep, 15:19, "Jan Simon" <matlab.THIS_Y...(a)nMINUSsimon.de> wrote: > Dear kizzie > > > Why are the ode functions in Matlab still m coded? I guess, a lot of our calculations would run much faster when these functions would be built-in, or c or fortran based. > > Is there a specific reason why this isn't done yet? > > Program time = programing time + debug time + run time. > > If the run time is a few minutes (or hours) only, the advantage from a small debug and programing time still matters. > > In a lesson for numerical optimization, I offered a Dormand-Prince-Compiler to my students in a C and a Matlab version. The C-method could called through a MEX interface from Matlab also. Then they got the job to insert an internal numerical differentiation to measure the sensitivity of the results. > > The students, who decided to do the job in Matlab, needed some hours and the assessment of the results was easy for me. For the solutions in C I had to cope with segmentation faults, problems with underscores when calling BLAS lib or even better: self-programed vector libraries. Don't use C. Use C++. > My conclusion: > If a user sits in front of a GUI and waits, 5 sec is the maximum bearable delay. > Otherwise speed does not matter. > Success does. > Frustration after hours of debugging does, too. > Therefore the slow Matlab directly supports a peaceful mind. No, it doesn't. I've been working in an environment where high-throughput data processing is the name of the game. A lot of people use the 'easy' matlab approach, only to find that they need 5-10 hours to process the data that are collected in one. As this is a 24/7 operation that can persist for indefinite amounts of time, one accumulates a backlog from the word 'go!'. So I made some simple demos to show how slow matlab really is, compared to C++. The guys literally went pale - "we thought matlab was the best there is..." Mat*LAB* is just that - a lab toy. Do not for one second believe otherwise. If your mind is at peace using matlab, be aware that people are worked more or less to death (at least vocationally speaking - various stress factor wear them down to the point they are unfit to work) from using matlab. Rune |