I had no idea that Mathematica uses Qt until now when I saw this on wiki en.wikipedia.org/wiki/Qt_%28software%29 under uses.

I thought it is interesting.

@Nasser You should plan to take the next boring afternoon to carefully inspect all directories in your $InstallationDirectory ;-)

You'll find a lot more that just the Qt libs there.

@halirutan sure, will do that :) I was just looking at Qt when I noticed this.

@halirutan hi

@OleksandrR. Hi. Thanks for joining.

@OleksandrR. So did I understand you correct, that parallelized compiled code can run parallel, even if it is not compiled to C?

Sounds odd to me. Could be another Linux issue? Do you get any strange error messages, or it just doesn't run in parallel?

Yes, that's right. It definitely can (I checked again a moment ago to be totally sure)

@OleksandrR. Can we take this function as example?

$adjustGraylevelFunc =
  Compile[{{values, _Real, 3}},
   Map[Floor[255.0*Min[Max[0.0, #], 1.0]^(0.25) + 0.5] &,
    values, {3}], RuntimeAttributes -> {Listable},
   Parallelization -> True, RuntimeOptions -> "Speed"];

So I left out the "C" part and did

data = RandomReal[1, {5000, 5000, 3}];
$adjustGraylevelFunc[data];

Btw, you can check that there are only basic op-codes in the compiled code and no MainEvaluate

@halirutan you're right. That particular one doesn't go in parallel. Not sure why?

@OleksandrR. Which function did you use for testing?

@halirutan Nelder-Mead minimizer. Load the package first, then:

With[{minimizer =
    NelderMeadMinimize`Dump`CompiledNelderMead[
     Function[{a, b, c, d},
      Block[{x = Range@Length[data]},
       Norm[data - (a + b x + c x^2 + d x^3)]]], {a, b, c, d},
     "ReturnValues" -> "OptimizedParameters"],
   epsilon = $MachineEpsilon},
  parallelFitter =
    Compile[{{data, _Real, 1}},
     minimizer[RandomReal[{0, 1}, {4 + 1, 4}], epsilon, -1],
     CompilationOptions -> {"InlineCompiledFunctions" -> True},
     RuntimeOptions -> {"Speed", "EvaluateSymbolically" -> False},

datasets = Accumulate /@ RandomReal[{-1, 1}, {1000, 100}];
parallelFitter[datasets]; // AbsoluteTiming

You also get a nice n-fold speedup over the serial case

@OleksandrR. Is datasets supposed to be data?

Oh wait, I see what you did wrong: need to reduce the tensor rank of the operation by one (i.e. 3 to 2) when adding Listable attribute

@OleksandrR. Ahh.

Sorry, no I see it's injected

@OleksandrR. What the heck.. all cores go up.

@halirutan I think they are actually separate VM instances each in their own thread. So the dispatcher has to statically partition the work between them before starting; it can't do it from inside the VM itself. So you need to give it that leading dimension to partition.

Now I'm stunned because until now I was not aware that this is possible. For me, it was a fact that the MVM is only one instance and cannot run in parallel.

@halirutan certainly the main evaluator can't. But the VM and RTL seem to be thread safe. I would need to check about the opcode 47 mechanism but I think it should be okay.

@OleksandrR. What do you mean by "So you need to give it that leading dimension to partition."?

Following two situations:

@halirutan e.g. in your case you're working with a rank-3 tensor. So the operation needs to be done over the trailing ranks, while Listable takes care of the leading one.

cf = Compile[{{value, _Real, 0}}, Max[0.0, value],
   RuntimeAttributes -> {Listable}, Parallelization -> True,
   RuntimeOptions -> "Speed"];

@OleksandrR. Ahh, I see. Therefore, this runs smoothly in parallel:

data = RandomReal[{-1, 1}, {4, 5000, 5000}];
cf[data];

The Listable processing/parallelization is done in the dispatcher that controls the VM instances, not in the VM itself. So the compiled code can't touch the leading dimension at all if it's to parallelize.

While this doesn't

(parallelize well)

@halirutan yes, sorry. I didn't even look closely enough at your function to notice that you're actually doing a rank-0 operation in fact.

Nonetheless it's probably better to use at least rank-1-capable RTL functions where possible, for efficiency's sake. What would be called Listable if it were outside the VM

@OleksandrR. OK, I'll have a look into this. Thanks for sharing.

@halirutan you're welcome. I must admit I thought this was common knowledge, but obviously I was wrong. :)

@OleksandrR. Since I started to use the parallelization capabilities of Compile when the whole compile to C hype started, I always assumed it needs to be compiled to C to run in parallel.

(And of course on look at the doc of Parallelization would have proven me wrong)

@halirutan the creation of the RTL and a thread-safe VM were requirements for both parallelization and compilation to C. So in a sense these are linked

If the VM were not thread safe, your suspicion would be correct, of course, as C functions use only the RTL and not the VM

@OleksandrR. Nevertheless, it is really nice now, because even the users/colleagues which don't have a compiler will have fast functions.

@halirutan so, I checked. Opcode 47 is not allowable. Only opcode 43 is, which isn't really a call out of the VM at all as it's only used for calling other compiled code in separate functions

@OleksandrR. So Opcode 47 is MainEvaluate and 43 is CompiledFunctionCall, right?

@halirutan 46 and 47 are both called MainEvaluate. The important point is that only 46 actually invokes the main loop. 47 just jumps right to the entry point of the function that it calls.

47 is a lot more efficient than 46 and in version 8 and 9 it has very little penalty associated with it

@halirutan I'm left very confused by the documentation and Joel Klein's comments here. Can you work it out? It seems to me that, at best, the advice is that if those things were implemented, then opcode 43 would be useful in relation to them. But they're not, so...?

@OleksandrR. OK, I'm not sure either, but as I understood it, then this should work without locking

cf = Compile[{{x}}, Sin[x]];
cf5 = Compile[{{x}}, cf[x^2],
   CompilationOptions -> {"InlineExternalDefinitions" -> True,
     "InlineCompiledFunctions" -> False}, Parallelization -> True,
   RuntimeAttributes -> {Listable}];

And indeed, it seems that on my machine the function works in parallel without any synchronization for the cf calls.

@halirutan yeah, I agree with that. But locking for access to what? Joel's answer says that it's the main evaluator, but it's not

Sorry. I mean, opcode 43 can't even be generated if access to the main evaluator is required. So what relevance do locks have at all to this discussion?

@OleksandrR. I understood Joel's answer differently: I thought he was referring to the case when there is a main-evaluate call in the compiled code.

I think his last paragraph just explains the locking and is not related to the beginning of his answer.

@halirutan but it's just explaining the concept of a lock. Notwithstanding the fact that nobody ever called it "synchronization locking" before (it's obviously a mutex), the concept does not even seem to be relevant in that context?

@OleksandrR. But it is Szabolcs last question.

Yeah but it was stimulated by the wording of the documentation. He didn't make it up out of thin air. (matheorem's question actually :))

As I understand it, the docs say: Even without inlining, you can have fast calls to compiled functions. If you use these fast CompiledFunctionCall's then you will not have synchronization locks (as you would have in MainEvaluate calls)

So, as I understand it: parallelization is mutually exclusive (heh) with opcode 46 and opcode 47. And recursion requires these and furthermore is mutually exclusive with opcode 43. So... we have a massive no sequitur. Am I wrong?

@OleksandrR. I definitely need a list of op-codes.. What are their real names again?

@halirutan you know, I'm not even convinced that opcode 43 is really a "function call" as such. I think it starts a new VM instance running the bytecode given in its argument. There doesn't seem to be any scope to have a function call that references anything other than self-contained bytecode.

@halirutan that's the problem, they don't even have real names as far as I know, so we have to use the numbers... the CompilePrint function calls 46 and 47 as MainEvaluate, and 43 as CompiledFunctionCall. But that's not what they're called (I hope) and certainly not what they do.

@OleksandrR. When I define a compiled function to be parallel, are there several instances of this function in the VM?

I mean, to be real parallel, there need to be duplicates of the instructions for each thread or not?

@halirutan I think several VMs running in parallel, one in each thread. I think there must be a dispatcher that gives them the bytecode from the compiled functions along with the arguments they need to process

Another thing about the parallelization--the result does not have to come back packed. It can be a ragged array. So this is not happening inside the VM for sure.

@OleksandrR. About the recursion: I never looked at it in detail. I'm only aware, that I read some question about it, maybe here, maybe on SO.

@halirutan I'd be interested to see that one. I wasn't on SO and I can't find it here.

@OleksandrR. Here is one mathematica.stackexchange.com/q/13504/187

@halirutan sure but that is using the main evaluation loop for recursion, not doing it in compiled code. So it's not an interesting case IMO

@OleksandrR. So the general goal is a recursive function which calls itself through opc 43?

@halirutan that's what I would have thought the documentation and Joel's answer are getting at, yes. And maybe that it can be parallelized?

@OleksandrR. When you assumption is correct

> I think it starts a new VM instance

then this would end in a mess or not?

Hey, people. I'm sure some of you have way better style sense than me. What do you thing would be nice fonts for coding, instead of Courier?

Comic Sans is by fair the best font for everything. No just kidding I have used Consolas alot.

@LiamWilliam Consolas it is then, for now :)

@Rojo I like DejaVu Mono and Inconsolata-dz. Consolas is not a bad choice though...

@rm-rf Thanks, trying them out :)

hello everyone

question: when I'm producing a Log - Log plot using ListPlot[mylist,Frame->True,Axes->False,FrameTicks->{{LogTicks,None},{LogTicks,‌​None}}]

I get a plot like this

How can I transform the XX axis such that the labeling comes as "0.1, 1, 10" and not as "10^-1, 10^0, 10^1"?

Also, note that I'm loading the LevelScheme package ( `<< LevelScheme``) to automatically generate the ticks

@Sosi The CustomTicks documentation has some examples of how to change it

@rm-rf I can find how to change the in the LogTicks (e.g. e^1, e^2), or how to change the labeling in LinTicks, but not how to change the labeling completely in LogTicks. I tried playing around with TickLabelFunction, but couldn't get it straight

ListLinePlot[Log10@{{0.01, 10^-8}, {1, 10^-9}, {10, 10^-7}}, Frame -> True, Axes -> False, FrameTicks -> {
        {LogTicks, None},
        {LinTicks[##, TickTest -> (IntegerQ@Rationalize@# &), TickLabelFunction -> (10^# &)] &, None}
}]

@Sosi ^^

Hi @rm-rf -- could you run some code for me?

@rm-rf thanks! I can play with that now!

@Mr.Wizard Sure

a = RandomInteger[99999, 1500000];
GatherBy[Ordering@a, a[[#]] &] // Timing // First
SplitBy[Ordering@a, a[[#]] &] // Timing // First

In v7 GatherBy is much faster. SplitBy doesn't seem to benefit from Szabolcz's method.

I wonder if anything has changed in v9.

I got 0.328 and 2.059 seconds.

Interesting; thank you.

No problem :)

bye

bye

@halirutan well, it doesn't necessarily have to spawn a thread or anything like that. I just meant that it's logically a new instance: completely new set of empty registers, no state to preserve from the caller. A "call" tends to imply branching to code at a particular location, but for this I think that it's only possible to make the VM execute the code that's explicitly given in the argument.

hello?

Hello

I have a quick question:

i have an eventlocator in NDSolve

but how can I catch multiple events:

when x[t] switches sign and when v[t] > 0

or is it just "Event" :> {x[t], v[t] > 0}?

no, that doesn't work :(

community.wolfram.com/groups/-/m/t/179333

Happy theoretical 2014 from Russia!

;-)

Wow!.. this is cool!

Link to notebook: goo.gl/wG9zlm

In Russian, but code is universal ;-)