@erik10 Correction: I mean the non-compiled & parallelized method seems to be the fastest ...

@Carl Love I tried Acers original code. Again compilation succeeded and it yielded times around 1.10-1.20 seconds. So the fastest so far seem to be compiled & parallelized. Maybe that is the final conclusion? The evalhf command seem to be pretty fast.

Erik

@Carl Love I tried Acers original code. Again compilation succeeded and it yielded times around 1.10-1.20 seconds. So the fastest so far seem to be compiled & parallelized. Maybe that is the final conclusion? The evalhf command seem to be pretty fast.

Erik

@Carl Love Thanks!

Regarding Acer's compilation code, then I read in the Help menu under 'Compile':

On 64-bit Windows platforms, the Microsoft compiler, if available, is used to compile the emitted C code.

So I searched on the Internet to get information about compilers. One place it was mentioned you could get a compiler installed together with the free Visual Studio Express 2012. So I installed it, and restarted my worksheet. This time I got a 'true' for compilation, BUT time was increased by a factor of 2-3. Without compilation it was less than 1 sec, and with compilation it was 2-3 seconds. Here is my file after some edits:

simulering_teststati.mw

I supposed it to be faster. What can be the problem?

Erik

@Carl Love Thanks!

Regarding Acer's compilation code, then I read in the Help menu under 'Compile':

On 64-bit Windows platforms, the Microsoft compiler, if available, is used to compile the emitted C code.

So I searched on the Internet to get information about compilers. One place it was mentioned you could get a compiler installed together with the free Visual Studio Express 2012. So I installed it, and restarted my worksheet. This time I got a 'true' for compilation, BUT time was increased by a factor of 2-3. Without compilation it was less than 1 sec, and with compilation it was 2-3 seconds. Here is my file after some edits:

simulering_teststati.mw

I supposed it to be faster. What can be the problem?

Erik

@Carl Love Great! With your new file, it works. Little less than 1 sec. Starting up with an execution time of 40 seconds (ignoring my initial unnecessary loop) it is now reduced to less than 1 second. That is indeed really nice.

I think I understand your basic idea, using the Seq command in the Threads package to get access to parallel execution. For every i, the procedure is being executed. But there is one line I don't understand: Why 

(),

in line 94?

Could be interesting if Acer could tell how to make the compilation work ...

Erik

@Carl Love Great! With your new file, it works. Little less than 1 sec. Starting up with an execution time of 40 seconds (ignoring my initial unnecessary loop) it is now reduced to less than 1 second. That is indeed really nice.

I think I understand your basic idea, using the Seq command in the Threads package to get access to parallel execution. For every i, the procedure is being executed. But there is one line I don't understand: Why 

(),

in line 94?

Could be interesting if Acer could tell how to make the compilation work ...

Erik

@Carl Love 

I downloaded your code and reexecuted it right away in Maple 17.01 by pressing the icon with the three !!!. I received the following error message following the call of the procedure:

B := CodeTools:-Usage(Qsim(Size, Total, L, X, r, c));
Error, (in unknown) type `Sample:-sizeType` does not exist

I am unsure what Maple are hinting at?

Erik

@Carl Love 

I downloaded your code and reexecuted it right away in Maple 17.01 by pressing the icon with the three !!!. I received the following error message following the call of the procedure:

B := CodeTools:-Usage(Qsim(Size, Total, L, X, r, c));
Error, (in unknown) type `Sample:-sizeType` does not exist

I am unsure what Maple are hinting at?

Erik

I can't make the Compiler work either! Get a false statement. Maybe Acer can explain why it works for him and not us? Anyway it works, because of the try command. Apparently the evalhf command is speeding up things quite a lot. I assume the compiler - if it worked - would make it even faster?

I have edited the code a bit, so as to suit myself. I changed the L vector, adding 0 and 1, just for logical reasons. 

Carl: In a previous comment you suggested to remove my variable broekdel, but I have introduced it again, because it increases the execution time, when the program need to calculate the left hand side in A[number] - j  > L[n] again and again. In a previous version of my code it increased time from 14 sec to 16 sec. Now it is less, though.

One last thing I would like is to use the parallelism suggested by Carl, but I am not sure how to combine your earlier code with Acers.

Here is my newest version: Simulation3.mw

Again thanks a lot! I really appreciate your contributions.

Erik

I can't make the Compiler work either! Get a false statement. Maybe Acer can explain why it works for him and not us? Anyway it works, because of the try command. Apparently the evalhf command is speeding up things quite a lot. I assume the compiler - if it worked - would make it even faster?

I have edited the code a bit, so as to suit myself. I changed the L vector, adding 0 and 1, just for logical reasons. 

Carl: In a previous comment you suggested to remove my variable broekdel, but I have introduced it again, because it increases the execution time, when the program need to calculate the left hand side in A[number] - j  > L[n] again and again. In a previous version of my code it increased time from 14 sec to 16 sec. Now it is less, though.

One last thing I would like is to use the parallelism suggested by Carl, but I am not sure how to combine your earlier code with Acers.

Here is my newest version: Simulation3.mw

Again thanks a lot! I really appreciate your contributions.

Erik

I should note that in principple the calculations of forv could result in a division by zero, but it is extremely unlikely to occur, unless Total is small. Therefore I have omitted any check here to keep execution times low ...

I should note that in principple the calculations of forv could result in a division by zero, but it is extremely unlikely to occur, unless Total is small. Therefore I have omitted any check here to keep execution times low ...

Really amazing how the change of frac made a big difference. With that change I am down to 16 sec. I just replaced frac(A[number]) with A[number]-(j-1).

It is really interesting now! Carl, I am not entirely sure how you make the computer use all processors? I am not an expert on programming, so please be detailed ;)

The same to Acer: Very interesting with the compiling thing, but I need details.

Great! Thank you.

Erik

Really amazing how the change of frac made a big difference. With that change I am down to 16 sec. I just replaced frac(A[number]) with A[number]-(j-1).

It is really interesting now! Carl, I am not entirely sure how you make the computer use all processors? I am not an expert on programming, so please be detailed ;)

The same to Acer: Very interesting with the compiling thing, but I need details.

Great! Thank you.

Erik