7 berichten aan het bekijken - 1 tot 7 (van in totaal 7)
  • Q:
    Bijdrager
    viero

    Prioriteit geven aan programma's

    Besten,

    ik draai sinds kort Capture Polar op mijn MBP. Dit is lichtvisualisatiesoftware die het ArtNet signaal van mijn andere laptop omzet in een virtuele lichtshow. Nu zit ik met het probleem dat wanneer ik een hoop lampen teken de software zou durven haperen. Kan ik ergens op mijn mac aangeven dat Capture bv. 80% van het systeem mag gebruiken of gebeurt dit automatisch?

    Alvast bedankt!

    Bijdrager
    Maurits

    Is niet nodig, en ook niet mogelijk om in te stellen dat een programma meer of minder CPU krijgt.

    Als een programma meer CPU nodig heeft, krijgt het programma dat (mits beschikbaar).
    Pas bij gelijktijdige aanvragen gaan enkele OS taken (met name de kernel zelf) voor op andere taken.

    uitzondering: slecht geschreven software (single threaded) kan slechts 1 core maximaal benutten. (vele mac’s hebben 2 of 4 cores)

    Als jij dus vertraging merkt, zonder dat Capture veel CPU belasting heeft; dan ligt de oorzaak van de vertraging ergens anders.

    ik ken het programma Capture overigens niet, mijn verhaal is algemeen bedoeld.

    Bijdrager
    Sarcas

    Dit ligt buiten mijn kennisgebied, dus misschien is mijn suggestie niet van toepassing, maar toen ik dit las moest ik denken aan iets wat ik toevallig op MacUpdate zag:

    ProcessRenicer allow you to change the nice value of your computer processes.

    The nice value of a process is used by the kernel to compute the process priority. Giving a lower nice value to a process will increase it’s priority, and allow a better usage of the CPU resources.

    Bijdrager
    hendrik ijzerbroot

    Met dit programma (waar Sarcas ook naar verwijst) kun je de prioriteit veranderen. Verwacht echter geen wonderen, want de feitelijke CPU belasting veranderd er niet mee. (M.a.w: het programma gaat niet sneller werken op het moment dat het CPU tijd heeft toegekend gekregen). Het enigste wat verandert is dat het programma een grotere voorrang krijgt op andere processen. Dit levert dan wel een bepaalde winst op, maar dat hangt dan af van het aantal processen die na de aanpassing voorrang verlenen.

    Trouwens: op de hedendaagse multi-core/CPU systemen verliezen dit soort hulpmiddelen eigenlijk hun nut omdat er al reeds meerdere processen c.q. threads tegelijk kunnen draaien. Maakt een programma daar geen gebruik van, dan is dat al een bottleneck.

    Bijdrager
    iep

    Multicore en multiprocessor heeft er niets mee te maken. Ook op deze systemen kun je winst boeken. Wat je met dat ProcessRenicer doet is niets meer en minder dan de bekende unix utility nice gebruiken. Nice was en is nog steeds bedoelt om dingen met een andere prioriteit te laten draaien. Voor een gebruiker is dat niet bepaald van belang omdat het systeem grotendeels dit soort dingen zelf al uit kan vogelen. Voor bepaalde systeembeheer taken en performance optimalisatie is het gebruik van nice wel weer handig. Een applicatie die net teveel resources in beslag wil nemen kun je hiermee temmen (waar het dan ook voornamelijk voor gebruikt wordt). Zo kun je het systeem vrij houden voor andere taken en beter de pieken opvangen omdat je er voor zorgt dat een proces geen kans heeft om het gehele systeem te belasten.

    Een voorbeeld waarin je het als gebruiker zou kunnen toepassen is bijv. het opnieuw indexeren van de spotlight index. De processen mds en mdworker kunnen nog wel eens een flinke aanslag plegen op het systeem waardoor het allemaal een stuk trager wordt. Door middels nice de prioriteit van deze twee processen omlaag te schroeven kun je het systeem weer sneller maken waardoor het voor sommigen ineens weer een stuk bruikbaarder wordt. Het nadeel is wel dat een proces langer zal moeten draaien dus het indexeren zal een stuk slomer zijn dan normaal. Het gaat dus niet altijd even goed met dat multicore/cpu gebeuren omdat vaak de insteek is dat processen de volledige resources mogen gebruiken. Dan moet je ze soms even weer tot de orde roepen.

    Bijdrager
    hendrik ijzerbroot

    Stel je hebt 10 processen draaien op een CPU met twee cores en geen hyperthreading. Er zijn dan steeds 8 processen die even moeten wachten op 2 andere. Als je nu 1 van die 10 een lage nice waarde geeft (dus een hogere prioriteit) dan krijgt dat proces meer CPU tijd toebedeelt en dat is natuurlijk een aardige winst.

    Draai je die zelfde 10 processen op een 12 core systeem dan kun je wel winst boeken op de overige resources zoals RAM of disk-acces maar niet op de CPU tijd, omdat alle processen toch al een core tot hun beschikking hadden. Want als de CPU zelf voldoende resources biedt t.o.v. de eisen van een proces dan zal zelfs het proces dat de minste tijd toebedeelt krijgt tegen de 100% CPU zitten. Er vanuit gaand natuurlijk dat we het hier over processen hebben die meerdere cores ook daadwerkelijk benutten.

    M.a.w: het effect van ‘renicen’ is niet altijd even groot. Hoe meer een CPU tegelijk kan, hoe minder vaak het nodig wordt een bepaald proces voorrang te geven op de andere. Het is dus een kwestie van vraag en aanbod:
    Als het druk is op straat is elke automobilist (proces) die jou voorrang verleent meegenomen. Maar als je al de weg (core) voor je eigen alleen hebt, ben je al sneller thuis…
    http://en.wikipedia.org/wiki/Nice_%28Unix%29

    Bijdrager
    iep

    Nogmaals, het gaat helemaal niet over het aantal processoren of cores. Het nice verhaal geldt voor alle aantallen dus ook wanneer we het hebben over een single cpu met een single core. Niet zo raar want toen UNIX ontwikkeld werd bestond multicore en multicpu niet eens. Zoals verder in je wikipedia link staat is het ook vooral wanneer er meer aan cpu kracht wordt gevraagd dan er geleverd kan worden. Met andere woorden, je past het voornamelijk toe wanneer de cpu teveel moet doen. Ook dan boeit het niet hoeveel cores en cpus je hebt, het punt is dat je er niet genoeg hebt.

    Normaliter zou een proces alles mogen gebruiken wat het systeem tot z’n beschikking heeft maar moet het wat inleveren zodra een ander proces ook z’n werk wil kunnen doen. Dat mechanisme werkt lang niet altijd goed (multithreading is iets wat nogal complex is ondanks een API (libdispatch, aka Grand Central Dispatch) die het eenvoudiger moet maken) waardoor de load van het systeem stijgt en dingen trager gaan lopen. Met nice/renice kun je in dat geval het proces tot de orde roepen. Een goed voorbeeld hiervan zijn de diverse traagheidsproblemen die mensen ervaren bij het (her)indexeren van de spotlight index die ik al eerder aanhaalde.

7 berichten aan het bekijken - 1 tot 7 (van in totaal 7)

Je moet ingelogd zijn om een reactie op dit onderwerp te kunnen geven.