🚀 go-pugleaf

"user" <no@thanks.be> schreef in bericht 
news:ib1rpd$i7p$1@news.eternal-september.org...
> Maurice ON4BAM wrote:
>
>> Je slaat de bal volledig mis, B.v. Adobe Premiere is speciaal
>> ontwikkeld met multicore in gedachte. Je haalt heel veel
>> snelheidsvoordeel uit een multicore tegenover een single core bij
>> videoediting waar effecten van verschillende kanalen simultaan worden
>> weergegeven zonder dat er eerst gerenderd moet worden.
>> BTW: Het programma Google ken ik niet....
>
>
> En weet je waarom hier parallel wel kan??
>
> Vraagje: zou je bij zoeken naar een bestand kunnen paralleliseren??
>
> http://en.wikipedia.org/wiki/Parallel_computing
>

Dit is een heel goed document dat aangeeft hoe moeilijk het is
om sommige problemen zodanig in een dual core processor te implementeren
dat je er voordeel van hebt vergeleken met een single core processor.
Het probleem ligt in de communicatie tussen deze deel processen
Bij vele fysische processen speelt dat ook een rol.
Je kunt ze niet gemakkelijk in stukken delen die van elkaar onafhankelijk 
zijn.
Een voorbeeld is het volgende pseudo programma:

Do
Synchronise 0
For i = 1 to 4
  a = 0                                                        *
  For j = 1 to 4                                           *
      d = x(i) - x(j)      ' Bereken afstand        *
      a = a + 1/(d*d)   ' Bereken versnelling   *
  Next j                                                       *
  v(i) = a                   ' Bereken snelheid       *
next  i
Synchronise  1
For i = 1 to 4
   x(i) = x(i) + v(i)     ' Bereken plaats          $
Next i
Synchronise 2
Loop

Dit programma bestaat uit twee binnen loops
aangeduidt met * en  $.
Als je uitgaat van 4 Processoren dan kun je ze parallel uitvoeren
Het grote probleem is dat je moet uitgaan van een soort
common data base die voor alle processoren gemeenschappelijk
is. Deze data base omvat bijv de rijen x en v
Daar naast moet je alle processoren synchroniseren. Dwz je kan pas verder
gaan als alle processen klaar zijn.
Dit alles geeft veel extra overhead.
De $ inner loop is maar een instructie.
Het heeft eigenlijk pas zin om deze inner loop parallel
uit te voeren als de tijdsduur van de overhead klein is vergeleken
met de tijdsduur van het uitvoeren van de instructies van de innerloop

Bij de ene instructie van de $ loop is uitvoer heel klein.
Bij de 1 + 4*4 + 1 instructies van * loop is het aantal instructies
groter maar veel en veel te klein.

Hopelijk helpt dit in de discussie.

Nicolaas Vroom