[disc] programmeren voor multi-processor systemen *

[kakanox]

ik vroeg me af of er hier misschien iemand is met ervaring in het programmeren van software voor systemen met HyperThreading of meerdere processoren, aangezien ik van plan ben hier eens een experimentje mee te starten. Het idee was hiervoor een systeempje te bouwen (ben trouwens nog op zoek naar een dual AMD mainboard voor weinig, liefst met IDE-RAID, iemand nog wat liggen?)

zit te denken om twee oude XP1800+ die ik hier heb liggen te modden en daarmee te draaien, maar werkt dit voor het systeem hetzelfde als bijvoorbeeld dual Opterons, dual Xeons, dual Pentium III-S of - nog leuker - een Pentium 4 incl. HyperThreading? En hoe gaat het met twee Xeons die beide voorzien zijn van Hyperthreading of nog meer processoren?

Ik programmeer zelf in Microsoft Visual Basic en ben een beginnende programmeur onder Linux, maar mocht dit een gigant van een discussie worden, dan heb ik in elk geval geen bezwaar tegen informatie over andere talen...

[.oisyn]

Ik heb je titel maar even aangepast. Maar wat wil je nu, een discussie aanzwengelen? Dan zul je toch met een wat uitgebreidere openingspost moeten komen, want zoals het nu is lijkt het op "vertel mij over SMP programming" zonder dat je zelf wat onderzoek gedaan hebt. En dat verwachten wij hier toch wel enigzins

Er zit overigens geen verschil tussen al die verschillende systemen die je noemt. HyperThreading is voor de programmeur ook gewoon 2 verschillende CPU's, ook al ligt de daadwerkelijke hardwarematige implementatie vrij anders.

Het idee is gewoon dat je met verschillende threads werkt, waarbij elke thread op een andere CPU draait. En daar komt veel synchronizatie bij kijken, want de ene thread kan natuurlijk niet data gaan wijzigen waar de ander net mee bezig is.

En met Visual Basic kom je niet ver, daar het multithreaded programma's niet ondersteunt (tenzij je VB.Net bedoelt)

[kakanox]

JA, ik zoek informatie over SMP programmeren. JA, heb gegoogled, zou alleen niet weten waar ik moet beginnen. Wist nog niet dat dat ook de benaming "SMP" had, en kon idd weinig vinden over VB6 en multiprocessor-programmeren, dat is de reden dat ik deze post plaatste.

Misschien dat jullie eerst eens moeten kijken naar of je misschien een antwoord weet, dus of je iemand de goeie richting insturen, voordat je je af gaat vragen of die persoon misschien nog niet gegoogled heeft. Dat is even snel ingetypt. Moeilijk gedoe hier altijd... 4 the record: Ik google altijd eerst zelf, dan plaats ik pas een post.. gaat immers sneller.

Voor het antwoord dat je me gaf: bedankt, ik weet nu dat ik een VB.NET-licentie moet aanschaffen.

[Macros]

Ik zou eerst eens naar Java kijken. Die heeft een erg gebruiksvriendelijke versie van Threads ingebouwd. Dan kan je daarmee oefenen en tegelijk de C(++) syntax onder de knie krijgen. Als je dan wat meer performance wilt en het aan durft kan je C(++) met een threads library proberen. Dan weet je hoe threads meestal werken en kan je de wat lastigere C versie wel aan.
Voor C bestaan meerdere libraries die Threads ondersteunen. Volgens mij is het nog verschillend voor Windows en *nix'en, maar zeker weet ik dat niet omdat ik nog nooit met Windows threads heb geprogged, behalve in Java dan.

[curry684]

Ik zit al enkele jaren in de Simultaneous Multi Processing, oftewel SMP development. Eerst lang op Windows software geschreven die er van profiteerde, en ondertussen zit ik alweer een maand of 9 te hobbyen op fabrieksautomatisering waar zoveel mogelijk performance uit 3 a 4 Alpha's gehaald moet worden onder VMS.

Ik wil je best hier en daar wat vertellen, maar dan moet het wel iets exacter gevraagd In principe is SMP een soort van 'denkstijl' die vergelijkbaar maar lang niet identiek is aan multithreaded (of hyperthreaded) programmeren.

In een 'normale' omgeving kun je vaak enkele tot tientallen procenten winst trekken uit multithreading omdat je terwijl er 1 thread in een kernel/IO waitstate zit 100% uit de andere thread kunt trekken. Dat verhaal geldt hetzelfde voor SMP, echter daar moet je stukken meer threads uit de klei trekken, want op een 4-way SMP zijn je eerste 4 threads puur benodigd om het hele systeem aan het werk te krijgen. De volgende 8 zorgen voor de balancing gedurende wait-states

[.oisyn]

kakanox schreef op 11 december 2003 @ 21:42:
Misschien dat jullie eerst eens moeten kijken naar of je misschien een antwoord weet, dus of je iemand de goeie richting insturen, voordat je je af gaat vragen of die persoon misschien nog niet gegoogled heeft. Dat is even snel ingetypt. Moeilijk gedoe hier altijd... 4 the record: Ik google altijd eerst zelf, dan plaats ik pas een post.. gaat immers sneller.

heej flipje, ten eerste geef ik je een antwoord, dus ik schopte je sowieso in de goede richting, ten tweede kon ik je topic ook gewoon sluiten volgens de policy, en ten derde geeft [google=multiprocessor programming] toch aardig wat goede hits. Als je de policy wilt bediscussieren dan is dit niet de goede plaats, kijk daarvoor naar topics als Betreft te laag/hoog niveau W&G P&W

Voor verder commentaar kun je me mailen op [e-mail]

[Alarmnummer]

Een goed boek wil wel eens helpen, en deze kan je ook in digitale vorm ergens vandaan plukken. Wel kopen natuurlijk als je hem goed vindt.

[Soultaker]

[mierenneuk] SMP staat voor zover ik weet voor Symmetric Multi-Processing. [/]

[curry684]

Soultaker schreef op 12 december 2003 @ 13:49:
[mierenneuk] SMP staat voor zover ik weet voor Symmetric Multi-Processing.

[/quote]
Als je dan wil mierenneuken is het 'Symmetrical', maar je hebt wel gelijk

[.oisyn]

Oh ik dacht ook dat het simultaneous was Maar het is trouwens ook niet Symmetrical curry, Soultaker had het helemaal goed (afgezien van het koppelstreepje ). Kijk maar

[ Voor 8% gewijzigd door .oisyn op 12-12-2003 16:07 ]

[MSalters]

Ik heb langer gewerkt aan multi-threaded systemen dan aan single-threaded systemen, dus ik denk dat ik hier ook mee mag doen.

Kort gezegd, SMP systemen zijn duur in aanschaf en programeren. Waarom het dan toch populair is is omdat de hardware alternatieven nog duurder zijn: Een Pentium 4 op 3.2Ghz is veel duurder dan 2 1.6 Ghz systemen, 2 losse PCs een enkele opdracht uit laten voeren is veel complexer dan een enkele dual-CPU. Een goedkopere oplossing is vaak een efficientere programmeertaal, in het bijzonder als de applicatie veel gebruikt wordt (meer terugverdien mogelijkheden).

Een groot deel van de SMP applicaties kun je als simpel beschouwen: een compiler kan twee files onafhankelijk van elkaar compileren; een database kan twee queries op twee verschillende tabellen teglijkertijd uitvoeren, etcetera. De moeilijkheden komen pas op het moment dat twee CPUs data moeten delen, en dan wordt het gauw lastig om algemene regels te geven.

De theorie is simpel: Alle gesharede data moet beschermd zijn tegen write-write conflicts, een read-thread die het resultaat van een write-thread niet wil afwachten mag dat doen als de read-thread in beide gevallen (voor/na read) een zinnig resultaat geeft en de read atomair is, etcetera - pak een goed boek (Jaja, An Introduction to Parallel Algorithms. Addison-Wesley Publishing Company, New York, 1992. bv.)

De praktijk is lastiger. Of data geshared wordt is een consequentie van het design, en hangt af van de prijs van synchronisatie. Soms kan het dupliceren van informatie de prijs van synchronisatie verlagen, ook al gaat dat ten nadele van het geheugengebruik. voor een dual CPU machine is een separate GUI thread een zinnig design, maar werkt datzelfde ontwerp nog goed op een single-CPU machine? Voor een groot deel komt dit nog op ervaring aan.