Zou Gentoo de ideale distro zijn voor dual-proc systemen?

Pagina: 1
Acties:

  • MBMarduk
  • Registratie: Februari 2001
  • Niet online
5 minuten geleden las ik dit bericht over Apple, dual-procs en photosjop en ik dacht bij mezelf:
"Dus Adobe software programma's zijn dual-proc enabled? Kan GIMP dat ook?.....Heej dan compile je die toch zelf....erm....Heej dan compile je je hele systeem speciaal voor dual-proc support toch?"

Catch my drift? Waar ligt het dan aan of een binary dan wel of niet dual-proc enabled is?
Sowieso de kernel...en bij de app? (dus in de Makefile als die dan wel of niet makkelijk in te bouwen is) Of ergens anders?
Zou je dan op deze manier alle binaries op je doos dan dual-proc enabled kunnen compilen? (dit bedoelde ik dus met Gentoo...als dat kan)

Of zit ik er volledig naast?

  • GarBaGe
  • Registratie: December 1999
  • Laatst online: 11:49
Volgens mij is SMP geen compiler optie... Geeft dus geen extra voordelen tov een single-proc systeem

Ryzen9 5900X; 16GB DDR4-3200 ; RTX-4080S ; 7TB SSD


  • MBMarduk
  • Registratie: Februari 2001
  • Niet online
DUS ligt het bij GCC die smp niet ondersteunt?
(n.b. ik heb geen idee of het uberhaupt een flag is bij GCC want (1)ik heb nooit een dual-proc gehad dus (2)heb dat dus nooit in de docu's moeten opzoeken.)

Dude I'm getting confused :? COFFEE!!

  • MBMarduk
  • Registratie: Februari 2001
  • Niet online
Hmm, **doordenken**
Wacht, de kernel zorgt voor het onderverdelen van resources onder de processen/threads (of andersom, bedoel ik)
Dus er bestaan helemaal geen SMP-binaries?!

  • imdos
  • Registratie: Maart 2000
  • Laatst online: 05-08 12:09

imdos

I use FreeNAS and Ubuntu

Het is zo dat een programma zelf efficienter kan werken met dual-proc opstelling ipv dat de kernel de processen op een manier splitst die de kernel goed uitkomt lijkt mij. Dat zou mijn inziens de enigste logische manier zijn om dit probleem uit te leggen. Dit is alleen een aanname van mij; dit hoeft dus niet zo te zijn of-course

pvoutput. Waarom makkelijk doen, als het ook moeilijk kan! Every solution has a new problem


  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 09:26

deadinspace

The what goes where now?

MBMarduk schreef op 14 augustus 2002 @ 14:21:
Dus er bestaan helemaal geen SMP-binaries?!

Precies. Wat programma's wel kunnen doen is gebruik maken van meerdere processes en/of threads. Op een uniproc systeem draaien deze dan 'naast' elkaar op dezelfde CPU, in een SMP systeem mogelijk op meerdere CPUs. multiprocess/multithreaded apps hebben dus - mits goed geprogrammeerd - geen performanceverlies op uniproc, maar wel performancewinst op SMP.

Multiprocess/multithreaded is iets wat vaak heel ingrijpend met het programma en haar structuur samenhangt, dus dat is normaalgesproken nooit een compile-optie.

  • MBMarduk
  • Registratie: Februari 2001
  • Niet online
De app in kwestie moet dus *expliciet* voor SMP worden geschreven, right?
En dan zoiets van ./configure --enable-smp ofzo...dus ALLEEN GCC ondersteuning zonder dat de app zo is geschreven kan niet?

Bestaat compiler ondersteuning voor SMP uberhaupt theoretisch? Moet toch wel? Bepaalde optimalizations die dan makkelijker parallel verwerkt kunnen worden m.i. :?

Verwijderd

MBMarduk schreef op 14 augustus 2002 @ 14:45:
De app in kwestie moet dus *expliciet* voor SMP worden geschreven, right?
Ja.
En dan zoiets van ./configure --enable-smp ofzo...dus ALLEEN GCC ondersteuning zonder dat de app zo is geschreven kan niet?
Nee. Dat wordt gewoon at runtime ontdekt. Bijvoorbeeld via sysctl op het aantal CPUs oid. Als de app ervoor geschreven is (SMP-capable/threaded), dan runt dezelfde binary net zo goed, omdat het een special case SMP is: namelijk SMP met 1 processor.
Bestaat compiler ondersteuning voor SMP uberhaupt theoretisch? Moet toch wel? Bepaalde optimalizations die dan makkelijker parallel verwerkt kunnen worden m.i. :?
Nee, want de compiler kan niet weten op welke manier resources over de processors verdeeld mogen worden. Een applicatie kan dan te makkelijk race conditions tegenkomen die er in de non-SMP nooit in zouden komen. Het is hetzelfde als threads toevoegen zonder resource protection (locking). Dat kan ook niet.

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 09:26

deadinspace

The what goes where now?

Het heeft zelfs helemaal niks met gcc te maken.

Als ik mijn programma zo maak dat hij twee processes maakt en de rekenlast over die twee processes verdeeld, dan wordt het zo gecompiled. Daar zijn geen extra compile-flags voor nodig, maar je kunt het ook niet uitzetten: het programma zal altijd twee processes starten.

Op een uniproc systeem gebruiken dan bijvoorbeeld beide processes 50% CPU, en op een dualproc systeem gebruiken beide processes ieder één CPU volledig (in ideale gevallen).
Dat een programma multiprocess en/of multithreaded is is niet alleen voor SMP bakken nuttig, het kan ook op uniproc systemen voordelen bieden: parallelisatie, 'vloeiendere' performance, onafhankelijkheid.

In het geval van the Gimp zou betere SMP-performance misschien de belangrijkste reden zijn, maar dat is niet altijd het geval.

Voordeel van een SMP systeem is btw ook dat bijvoorbeeld the Gimp je ene CPU volledig gebruikt, en dat de andere CPU 'overblijft' voor X, mplayer, je browser, enz.

Verwijderd

Hier een beetje pesudo code, dan krijg je een idee wat er allemaal bij komt kijken. Een standaard geval van video encoding. Je hebt een video van N frames die je van divx wilt encoden naar mpeg in een applicatie. Audio laten we ff weg voor de simpelheid.

Simpel case:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
VideoFile *in_file = new VideoFile("path/to/video.avi");
VideoFile *out_file = new VideoFile("path/to/video.mpg");
VideoDecoder *decoder = new VideoDecoder("divx");
VideoEncoder *encoder = new VideoEncoder("mpeg");
int n;

for (n=0;n<in_file.numFrames();n++) {
  VideoFrame *frame = in_file.readFrame(n);
  VideoFrame *decodedframe = decoder.decodeFrame(frame);
  VideoFrame *encodedframe = encoder.encodeFrame(decodedframe);
  out_file.writeFrame(encodedframe);
}

in_file.closeFile();
out_file.closeFile();


Het is vrij simpel: pak elk frame, decode het, encode het, stop het in de nieuwe video, klaar. Kan niet makkelijker. Nu de SMP manier. Ik laat de specifieke threading code weg omdat dat niet te begrijpen is als je het niet eerder gezien hebt. Maar die moet je dus ook nog zelf programmeren!

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
ResourceCondition *frame_ready = new Resourcecondition();
ResourceLock *in_frames = new ResourceLock();
ResourceLock *out_frames = new ResourceLock();
int frameswritten = 0;
int framesread = 0;
Thread *decoder_thread[num_cpus];
Thread *encoder_thread[num_cpus];
VideoFile *in_file = new VideoFile("path/to/video.avi");
VideoFile *out_file = new VideoFile("path/to/video.mpg");
VideoDecoder *decoder = new VideoDecoder("divx");
VideoEncoder *encoder = new VideoEncoder("mpeg");
int n;

run()
{
  while (1) {
    in_frames.lock();
    VideoFrame *frame = in_file.readFrame(framesread);
    int numframe = framesread;
    framesread++;
    in_frames.unlock();

    VideoFrame *decodedframe = decoder.decodeFrame(frame);
    VideoFrame *encodedframe = encoder.encodeFrame(decodedframe);

    while (frameswritten < numframe)
      frame_ready.wait();
    out_frames.lock();
    out_file.writeFrame(encodedframe);
    frames_written++;
    out_frames.unlock();
    frame_ready.notify();
  }
}

main() {
  for (n=0;n<num_cpus;n++) {
    thread[n] = new Thread(run);
  }

  while (framesread < in_file.numFrames())
    frame_ready.wait();

  for (n=0;n<num_cpus;n++) {
    thread[n].killthread();
  }

  in_file.closeFile();
  out_file.closeFile();
}


Je ziet dat de code al veel moeilijker wordt. In echte code is het dus nog drie keer gecompliceerder omdat ik de threading code hier versimpel. Je moet resource locken om de frames in de juiste volgorde in de nieuwe file te krijgen en om te zorgen dat niet meerdere threads op 't zelfde moment data gaan lezen/schrijven, dan krijg je namelijk data door elkaar.

Dus 't is vrij moeilijk, vandaar dat niet veel projecten aan SMP capability doen...

  • MBMarduk
  • Registratie: Februari 2001
  • Niet online
Gotcha. Bedankt iedereen :)
Dus, simpel voorbeeld: AppX is niet SMP-enabled en spawnt 1 steeds 1 proces. Op een SMP doos gebuikt het ook constant 1 en dezelfde CPU in dezelfde run.
AppY is ook niet SMP-enabled maar spawnt 2*n processen. De kernel zorgt dan dat hun tijd wordt verdeeld onder de CPU's maar dit loopt verre van optimaal.

Damn, inmiddels lijkt de inhoud van dit draadje niet zoveel meer op de topic, LOL.

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 09:26

deadinspace

The what goes where now?

MBMarduk schreef op 14 augustus 2002 @ 15:33:
Gotcha. Bedankt iedereen :)
AppY is ook niet SMP-enabled maar spawnt 2*n processen. De kernel zorgt dan dat hun tijd wordt verdeeld onder de CPU's maar dit loopt verre van optimaal.

Als AppY zijn rekenload redelijk over die twee processes verdeelt, dan is dat redelijk optimaal... Voor twee CPUs uiteraard.
Pagina: 1