In Maple 2015.0 the Task multithreaded compiled code I gave immediately above runs about twice as fast as in Maple 18.02 on my 64bit Windows 7, for that 600x800 example.

@Carl Love You should check your results for correctness, when using `Compile` on a procedure containing calls to `add` over float values. It's a "known bug" that it often get confused about the types in play, in such a mix. As you originally have it the code intended to be compiled will not produce correct results, I suspect. The workaround of replacing `add` calls with explicit loops may slow down under evalhf. So one may need distinct versions for running compiled versus running under evalhf.

The following uses explicit loops instead of `add`, for the Compile version. The temporary accumulator for the sum is a scalar variable, since using `newaa[i,j]` instead as accumulator can (MS-Windows, LLVM compiler) incur a big performance hit due to unnecessary referencing into array memory.

Also, as mentioned before, I also obtain another performance gain by computing i-k-1+m outside of the n-loop (stored in `mindex`).

And lastly, by having the procedure `Convolve_C` accept the lower and upper index values for the i-loop as arguments, the Threads:-Task model can be applied to parallelize the computation.

Download convolve_compiled3.mw

@Carl Love Yes, that top-level code isn't the same as calling `Convolve` without evalhf. Rather, it is an elementwise (vectorized) use of kernel builtin `*` on float[8] rtables which it knows how to treat well. So, yes, it's already parallelized in another way, and is fast despite the fact that it repeatedly creates `subimage` as a collectible garbage rtable.

Attached is a sheet with a few ideas on speedup. This does not include what I'd expect to be best: Compiled and multithreaded with the Task mode.

The top level code can be optimized at its second stage, by rolling the two nested `add` calls into just one call.

Yes, I believe that using order=C_order on `subimage` and `kerneld` can make it a bit faster -- as long as loops or the nested `add` calls walk along rows at their innermost layer (so as to walk adjacent entries in memory).

More saving can be had by constucting part of the `subimage` indicies, for re-use, at the start of each nested i and j loop. (See `ipart`, `jpart`, and `mindex`.)

And then one can notice that `subimage` is not really needed in such a proc.

Download convolve_evalhf.mw

@rollermonkey Your claims about my suggestions appear to be entirely false, and appear to depend on your continued mistyping of key syntax, or misspelling (you now appear to have done with(Plots) not with(plots) as I suggested), or perhaps in part due to a faulty installation. Carl's Answer covers it in detail, I see.

@Carl Love Did you intend,

  subimage[m,n]:= aa[i-k+m-1, j-k+n-1] * kerneld[m,n]

instead of that,

  subimage[m,n]:= aa[i-k+m, j-k+m] * kerneld[m,n]

within that innermost loop of `Convolve`?

You have several basic syntax mistakes which are not version specific.

To assign a plot to name F you need to use the syntax,

F := ...

and not,

F = ...

The plots package is loaded by issuing the command,

with(plots)

and not by (what you have),

withPlots

If you want to call display without loading the package then it would be done like either,

plots[display]( ... )

or,

plots:-display( ... )

and not (as you have it) as,

plots[display][ ... ]

acer

@Carl Love If one of the goals is to avoid potentially quadratic memory use (ie. O(k^2)) then it might be a good idea to explicitly unassign the names which get the indexed assignments, before the loop begins.

That would add safeguard against the user re-running the code without doing a restart, and incurring such a cost.

It could also help the user avoid a runtime error which trying to assign to a "long list", if re-run with restart, in the case that k>100.

It might also be more clear to use different names: say tableA for the indexed assignments and listA for the final conversion.

@kegj You have ignored my query: where are the statement terminators between the statements in the for-do loop?

More specifically, why is there no statement terminator at the end of this statement?

Y[j]:=Y[j-1]+dY

@maple2015 Did you try print(NCP) after first doing your plotsetup call? Try it.

@nm Your screenshots each show a single execution group containing the first three commands.

@nm I was talking about `add` in particular, because you mentioned it specifically. I have a suspicion that, apart from a general note, the only things that usually get in such Compatibility sections are mention of new or changed options.

FWIW, there are details on changes to `cat` and `rand` on the ?updates,Maple2015,Language help page.

Of course, this too does not cover your Question in full. I don't know of any uniform way to find details on all changes.

@nm Make sure that the three first commands are in separate execution groups or document blocks.

There is a long-standing problem in that the Std GUI implementation of the interface command may not take effect if it follows a restart in the same execution group.

You'll know it has worked because the printout will be in plaintext mode, not typeset (or italic).

@Preben Alsholm My ~/.mapleinit initialization file contains code to read a .mapleinit file from currentdir(), if found. Sometimes I use this mechanism to customize libname, etc, according to directory.

Basically, I often have multiple projects on the go, and instead of having to change working directory and pass the -b option to the TTY interface I can just set up the details once in a local directory-specific initialization file.

...and I have such local initialization files print something to the terminal, to remind me whether or not they are active in the current session. I don't want that output pasted in my responses here.

Sure, I could just use the -s option to prevent the initialization file from running. But I also use the TTY interface history feature quite a bit, and I usually prefer not to quit the session since I can lose the connection between that project and that command history.

There are quite a few words that I habitually misspell. Fortunately, restart doesn't seem to be one of them.

@Markiyan Hirnyk I think that it's more automatic to not have to supply v>=3, which is why I wrote that Kitonum's answer is better. I realize that English may not be not your first language, but please try and pay closer attention.

@Markiyan Hirnyk Your suggestion is not better, since it is not more automatic. It still depends on the user utilizing special knowledge of the structure; in this case the position of the value.

Kitonum's answer is more automatic, and it is better.