ACCEPTED SOLUTION
Accepted Solutions
You didn't include the faster routine without using stack. But you are right, without stack the routine is MUCH faster! I don't know why - you would expect built-in routines to be more efficient than self written loops.
In the attached sheet you find 8 different split-routines. I have no idea how I could judge memory consumption other than watching process mathcad.exe in task manager which would be very unreliable, to say the least. So I have concentrated on time taking. In the pic you see the calculation times needed for splitting 10 times a 1000x1000 matrix.
The splitting routines:
split0: is your original program
split1: damp sqib; here I tried to replace the row selection from submatrix to a transpose/column/transpose combination and the routine went a lot slower (factor 10!). Transposing the whole matrix for every row obviously does cost a lot of time
split2: went back to submatrix but included some improvements (getting rid of if/oherwises, unnecessary submatrix,..) Does not do much better and in the last runs I could not duplicate the double speed of this rotine which I mentioned in the file.
split3: transpose the matrix and work column-wise instead of row-wise. That way we can use the column selector. Very slight improvement of calculation time
split4: The lonely winner! Unfortunately we are cheating here, as this routine does return nested vectors. To access a single number you would have to type M[ispace[0,j instead of M[i,j. So it does not count
split5: Trying to use split4 but "flattening" the result to get the desired matrix. flattening uses stack, so again big slow down.
split7: Using method of split4 and a flattening routine which replaces stack by for loops. More or less ex aequo with split6
split6: usually number one in time ranking (not counting split4). stack, augment, submatrix replaced by for loops. As you wrote this is much quicker (factor 10 to 12) - strange.
You didn't include the faster routine without using stack. But you are right, without stack the routine is MUCH faster! I don't know why - you would expect built-in routines to be more efficient than self written loops.
In the attached sheet you find 8 different split-routines. I have no idea how I could judge memory consumption other than watching process mathcad.exe in task manager which would be very unreliable, to say the least. So I have concentrated on time taking. In the pic you see the calculation times needed for splitting 10 times a 1000x1000 matrix.
The splitting routines:
split0: is your original program
split1: damp sqib; here I tried to replace the row selection from submatrix to a transpose/column/transpose combination and the routine went a lot slower (factor 10!). Transposing the whole matrix for every row obviously does cost a lot of time
split2: went back to submatrix but included some improvements (getting rid of if/oherwises, unnecessary submatrix,..) Does not do much better and in the last runs I could not duplicate the double speed of this rotine which I mentioned in the file.
split3: transpose the matrix and work column-wise instead of row-wise. That way we can use the column selector. Very slight improvement of calculation time
split4: The lonely winner! Unfortunately we are cheating here, as this routine does return nested vectors. To access a single number you would have to type M[ispace[0,j instead of M[i,j. So it does not count
split5: Trying to use split4 but "flattening" the result to get the desired matrix. flattening uses stack, so again big slow down.
split7: Using method of split4 and a flattening routine which replaces stack by for loops. More or less ex aequo with split6
split6: usually number one in time ranking (not counting split4). stack, augment, submatrix replaced by for loops. As you wrote this is much quicker (factor 10 to 12) - strange.
Efried schrieb:
Wow you did a great job thank you so much.
I'm sorry the alternative looping solution was done for a similar problem where I found out that stacking is costly. You did the proof for this problem too. Great!!!
I really wouldnt have expected that the built in routines stack and augment are performing that bad compared to self written loops.
Let's see what PCT thinks about that 😉
Wouldn't expect too much, but am open for a pleasant surprise, though.
Because of the impractibality to use Mathcad for real world simulation problems I now have an i7 CPU - and I will be testing Mathcad PRIME because it uses more than one core for the calculations, before switching to python back again....
Choosing the right tools for the task is not easy in every case. While a lot of people are using Mathcad in business for their "real world problems" with success, there sure are problems for which Mathcad simply isn't the appropriate tool.
I have just converted the sheet and the results of Prime are somewhat daunting. See below the comparison of two runs 1000x100 matrix 10 times, one with Prime, the other with MC15 on the same machine (slow, single core) . While I guess that the timing with time is not correct in Prime because of Primes attempts to simultanously evaluate regions, it took a lot more time in Prime2 to finish all calculations.
Efried wrote:
...What was the easiest way to transfer the code from Mathcad 15 to Prime 2.0?...
By using "Mathcad Prime 2.0 XMCD, MCD Converter":
thhe Mathcad 15 results where already posted above as pdf- here is a screenshot:
My only explanation from my C++ experience is that there might be a lot of sequential or even recursive calls for subroutines - which is the worst you can do, so stacking (version 0 ) is much slower in Prime but surprise the transposing trick in variant 1 is much better. Ther variants I would use namely 6 iand 7 is not significantly different...
Oops, I just noticed that you can turn on/off multithreading and the switch is ecactly where you would think it should be 😉
I don't like to use Prime because of its slow reaction, the slow workflow as of the need to use the menues s o much, etc., so I have not the experience.
I tested it on my single core machine and found out that with multicast switched on Prime seems to try "parallel" processing at first but very quickly goes back to sequential operation. By this I mean that at the beginning I see 3 to four of these yellow "please wait I'm thinking" disks but soon it switches back to one after the other. So there is not much difference in time between the two modes.
What this means is that I was wrong in writing that we should not blame PTC/Prime for being so slow as it may be wrong results from the timing routine as an effect of the multi-threading. Thats not true - Prime simply IS much slower than MC15 and only sometimes on modern machines can at least live up to MC15 because of its ability to use more than one core/processor. Its sad that MC15 will never be able to do so.
Below a comparison between MC15 and the two modes of Prime2 on a slow single core (all with a 1000x1000 matrix splitted ten times in a row. Interesting the effect with split6, the routine that uses as few built-in commands and function calls as possible. This seems to show that PTC made the performance of the built-in routines even worse as the used to be in MC15.
