Shop OBEX P1 Docs P2 Docs Learn Events
Again on prime numbers: program slower without semaphores? — Parallax Forums

Again on prime numbers: program slower without semaphores?

samuellsamuell Posts: 554
in Learn with BlocklyProp
Hello all!

I've decided to take away all the semaphores from the prime calculation program I've posted here a way back. This was only because of curiosity, because I was obvioulsy doing something wrong and I wanted to see if the program produced bad results. Well, seemingly it didn't produced bad results, but it was a lot more slower. I was not expecting that, and it seems to go against logic.

Why the program still works correctly while having multiple cogs accessing the same values? And why is it a lot more slower without semaphores than with them?

It defies logic, IMHO. I've posted the source code of both the original and the version without semaphores, for SimpleIDE.

Kind regards, Samuel Lourenço
c
c
Prop_primos.c
9K
c
c
Prop_primos_nolock.c
8K

Comments

  • samuellsamuell Posts: 554
    Hi, can anyone reproduce this issue?

    Kind regards, Samuel Lourenço
  • ersmithersmith Posts: 6,051
    I haven't analyzed it thoroughly, but I think probably that without the locks sometimes two cogs end up working on the same numbers, thus "wasting" some of the compute time and causing the program to be slower.
  • samuellsamuell Posts: 554
    ersmith wrote: »
    I haven't analyzed it thoroughly, but I think probably that without the locks sometimes two cogs end up working on the same numbers, thus "wasting" some of the compute time and causing the program to be slower.
    That would be a bit strange. The dispatcher cog (cog 0) won't assign the same number to two different cogs. Also, each cog can only work in a particular index of the common strings (for example, cog 1 will only operate with elements of index 0). Unless I've overlooked something. I was expecting access conflicts and eventually wrong results.

    But if you could analyse, I would appreciate. Thanks in advance!
  • ersmithersmith Posts: 6,051
    I'm sorry, I don't have time to analyze in detail. One thing that did strike me when I was looking at the program is that the lock is held by cog 0 while printing results. Why is that? Serial output can take a long time, so this may block the worker cogs while they're waiting for the lock.

    Actually looking at the program I don't really see that the lock is necessary -- it looks like each cog has its own queue, so they won't interfere with each other, and only cog 0 puts data into the queues.
  • samuellsamuell Posts: 554
    edited 2016-08-05 12:52
    ersmith wrote: »
    I'm sorry, I don't have time to analyze in detail. One thing that did strike me when I was looking at the program is that the lock is held by cog 0 while printing results. Why is that? Serial output can take a long time, so this may block the worker cogs while they're waiting for the lock.

    Actually looking at the program I don't really see that the lock is necessary -- it looks like each cog has its own queue, so they won't interfere with each other, and only cog 0 puts data into the queues.
    Well, the lock not being necessary was the reasoning behind this experiment. However, cog 0 has to extract the result before assigning a new number to a cog, so the wait would still be there.

    Mind that the worker cogs are only blocked when reading or writing from the queue, but not during the calculation. But I think it would be a good idea to use multiple locks, one for each worker cog. Perhaps the efficiency will improve a bit.

    Just to add, all cogs read and write from the common variables. I wonder if that is the issue.
Sign In or Register to comment.