Puzzling how optimize works with "time" function. It's obvious in normal working WorkSheet. What does it do within 'time' ? But in the rkfixed, there is nothing to optimize, i.e: simplify once for ever with the optimized option. Or in other words: there is no precalculation that can be performed ahead.
Robert: In that long work sheet, if we instruct the timing up at the top like usual and no optimization, look at the bottom => it returns the absolute time. Now, move the time calculation where the hand shows: now you have the timing in sec. Not easy to explain except when it's too much...it decides its own way. Be careful: optimized screws the work sheet and never stops, and if you stop calculations it does not want and keeps ringing about every sec ... even more puzzling ! then you must shut down.
I guess I need to keep remembering the different types of optimization. The original reason I was trying to time the ODE solver was to see if there was a significant difference in how long it took to evaluate the function. For example, if I have a 10 element vector, does Mathcad compute the vector and then pull out the elements one at a time, or does it compute the entire vector each time it wants a single element. The answer appears to lie somewhere in between. Clearly, there is some numerical optimization of the Mathcad interpreter that can speed things up.
Here's the problem that I ran into using the time function to time things. I should have plotted this picture to begin with. It shows the simplest of all timing scenarios, how long does it take to call time? I compare the user dll that uses the pentium time stamp counter to the time function. It illustrates a couple of interesting points.
1. The time function uses the very coarse system clock which is set to 10 msec updates on my computer. This is probably the worst possible clock to use for timing functions in general because of the granularity and function overhead. It only works if there is a lot of time between calls.
2. Vectorizing shows quite a bit more compiler optimization on the native function than the dll call.
3. There is a lot of overhead on the dll call. To put things in perspective, the time stamp counter takes ~30 ticks to execute and store data. The microsoft version of that function runs ~450 ticks. The Mathcad call of that function in a dll runs ~1-2,000,000 ticks. Mathcad calling its own function seems to have ~1/2 to 1/10 the overhead of a dll call in this particular case.
4. I left a windows task running in the background just to show how easily it messes up timing of things. Most of the glitches in the data are task switching.
I left out one very important point in this timing plot which is how long it takes the first execution to occur. That number is quite large and quite variable. It may wipe out the gains vectorize offers depending on the number of iterations required.
The bottom line is that I haven't found a magic bullet that constantly gives a factor of 10 performance increase in the general ODE solver case, but the user dll I made gives people another option for timing short functions which just can't be timed with time.
Here's another interesting timing picture that has me a little puzzled at the moment. It shows the time required for repeated calls to the ReadCpuTicks user dll function. It shows Mathcad has a minimum call time of ~12000 ticks which is not too bad considering that I'm actually making 2 function calls. The actual function call is dt = ReadCpuTicks(ResetCpuTicks(n)). Calling ResetCpuTicks appears to be free, and it only appears to get called once if I apply the vectorize operator rather than once for each element in the vector. This doesn't appear to be the case if I vectorize a normal Mathcad function calling a Mathcad function. Anyway, it looks like a good chunk of the 1-2 million clock ticks I get calling a user dll is tied up in API drawing functions rather than actually calling the dll which makes timing a Mathcad function a real nightmare.
Robert, Very interesting that *.gif below. It may be true that Valery is more accurate, I leave it to your expertise. That's not the point. When writing program like that one, if the symbolic blocks, then optimization does not get out => and a very simple program can screw the work sheet. Read the red note. "RK4_last point" does not built up the matrix of calculated values, so less work involved but takes longer than Mathcad 'rkfixed'...Puzzling ? NO... The 'rkfixed', if you program it, it will do same as the 'built-in rkfixed'. But the 'built-in rkfixed' is then embedded in the Mathcad special engine. At the time of beta testing 2001i, I tested many identical functions between 8 Pro and 2001i. The gain in time is about 1/10. So, same functions but not same engine. I made *.gif for all to check in their own machine. Mine is Pentium II-300 Cyrix, 128 MB. running in Win.98 Me I have 'rkfixed' in Excel. If you are interested in the "tick-clock", let me know.