I suggest a block which contains 3 C-block sections, to be called “simultaneously”…

When you execute it, it will start executing the first two C-blocks at the same time, and then when both are finished the ‘simultaneously’ block exits.

The third-leg of the block is for when there are insufficient resources to run simultaneously. In this case neither of the first two blocks executes and only the third block does.

I'm assuming that parallel executions would be limited in the same way that clones are.

This block would effectively add threads/clones to any code, with a rendezvous after execution. In systems with multiple cores it would execute in genuine parallel otherwise it would simulate parallel execution the way that clones currently do.

G

Why three in particular? Why not just a block like this?

launch thread and run :: control cstart
  ...
end

And then you could join as many as you wanted together

Upon reading this a second time I see what you mean about three branches. I now support your suggestion as it is.

ChocolatePi wrote:

Upon reading this a second time I see what you mean about three branches. I now support your suggestion as it is.

You saved me a lot of typing there :-)

Look on it as a fork + try/catch block if you prefer that model. I hesitated to include the part for a failure but it's really necessary I'm afraid. As is waiting for both parts of the fork to complete before continuing. Otherwise the multi-threading has to be handled by the entire Scratch run-time - whereas with this not only is the user code clearer but the new code to add to Scratch to implement it can be localised to one block (I hope).

Sounds rather complicated for Scratch, but support.

Would it look like this?

launch :: control cstart
  ...
and :: celse
  ...
if out of resources :: celse // better wording anybody?
  ...
:: cend

liam48D wrote:

Sounds rather complicated for Scratch, but support.

Would it look like this?

launch :: control cstart
  ...
and :: celse
  ...
if out of resources :: celse // better wording anybody?
  ...
:: cend

yep, that was exactly what I meant. Wording to be determined.

No support, new scratchers and scratchers who do not know advanced code will be extremely confused.

Support, although it may be confusing.

PrincessPanda_test_ wrote:

No support, new scratchers and scratchers who do not know advanced code will be extremely confused.

Many Scratch features are confusing to beginners. Gtoal's suggestion would be very helpful for many Scratchers. Merely being too “advanced” is not a valid reason to not support suggestion; one must also consider the potential benefits.

Chibi-Matoran wrote:

PrincessPanda_test_ wrote:

No support, new scratchers and scratchers who do not know advanced code will be extremely confused.

Many Scratch features are confusing to beginners. Gtoal's suggestion would be very helpful for many Scratchers. Merely being too “advanced” is not a valid reason to not support suggestion; one must also consider the potential benefits.

Anyway Scratchers already handle multithreading/parallelism, through clones. This just makes it a little more explicit and easier to understand. And control.

gtoal wrote:

Chibi-Matoran wrote:

PrincessPanda_test_ wrote:

No support, new scratchers and scratchers who do not know advanced code will be extremely confused.

Many Scratch features are confusing to beginners. Gtoal's suggestion would be very helpful for many Scratchers. Merely being too “advanced” is not a valid reason to not support suggestion; one must also consider the potential benefits.

Anyway Scratchers already handle multithreading/parallelism, through clones. This just makes it a little more explicit and easier to understand. And control.

Yeah, creating a clone is inefficient. However, I'm a bit confused. If I'm understanding the suggestion correctly, except for the third part, can't it also be worked around with broadcasts (still, this suggestion would be useful because it would allow blocks to be executed simultaneously in the same script)?

...
broadcast [launch threads v] and wait
...
when I receive [launch threads v]
...
when I receive [launch threads v]
...

Am I misunderstanding the suggestion?

Chibi-Matoran wrote:

gtoal wrote:

Chibi-Matoran wrote:

PrincessPanda_test_ wrote:

No support, new scratchers and scratchers who do not know advanced code will be extremely confused.

Many Scratch features are confusing to beginners. Gtoal's suggestion would be very helpful for many Scratchers. Merely being too “advanced” is not a valid reason to not support suggestion; one must also consider the potential benefits.

Anyway Scratchers already handle multithreading/parallelism, through clones. This just makes it a little more explicit and easier to understand. And control.

Yeah, creating a clone is inefficient. However, I'm a bit confused. If I'm understanding the suggestion correctly, except for the third part, can't it also be worked around with broadcasts (still, this suggestion would be useful because it would allow blocks to be executed simultaneously in the same script)?

...
broadcast [launch threads v] and wait
...
when I receive [launch threads v]
...
when I receive [launch threads v]
...

Am I misunderstanding the suggestion?

Interesting, I didn't realise you could trigger the same script twice outside of clones. You're right, this is a similar effect and may suffice, though what I was suggesting would have a much stronger guarantee of actual parallelism if possible. The idea was to take a mechanism that Scratchers were to some extent familiar with (clones) but supply a stronger version of it that could be used to do some real computation and not only speed up heavy Scratch computations, but give Scratchers something that is a little bit closer to the model of parallelism that is used in multi-processor systems (eg OpenMP, pthreads, fork)

Question: does the broadcast and wait actually wait until both receive blocks have completed?

G

gtoal wrote:

Chibi-Matoran wrote:

-snip-

…can't it also be worked around with broadcasts (still, this suggestion would be useful because it would allow blocks to be executed simultaneously in the same script)?

...
broadcast [launch threads v] and wait
...
when I receive [launch threads v]
...
when I receive [launch threads v]
...

-snip-

Question: does the broadcast and wait actually wait until both receive blocks have completed?

Actually, it does! That's an interesting and generally poorly understood function of Scratch that is actually quite useful.