Wine geclustered draaien ? (:P)

[XTerm]

Beste nosser,

Bij het lezen van de topic titel moest u waarschijnlijk reeds een lach onderdrukken, toch is dit geen grap. Bij ons op school moet je in het derde jaar een eindwerk maken. Een van de eindwerken dit jaar was het volgende:

Bij Barco Belgium (een Belfisch bedrijf dat hightech maakt) is men bezig met FPGA's, ofwel programmeerbare logica. Het "compileren" hiervan neemt zeer veel rekenkracht in beslag. Voor FPGA bestaan enkel complexe en ongeloofelijk niet vrije windows only programma's.

Men is op het idee gekomen om (hou u vast en zorg dat uw stoel met 4 poten op de grond staat) om deze software in Wine te gaan draaien op... (tromgeroffel) een Linux cluster.

Een 2 tal studenten heeft dit eindwerk op zich genomen. Ze kennen *niets* van GNU/Linux, *niets* van OS'en en ook niets van clusters. NOS term zou : "windows noob" zijn.

Mijn vraag:

Hoe zinloos is dit ? Is Wine multithreaded ? Forked wine op een zinvolle manier ? Gaat de rekenkracht uberhaupt verdeelt worden ?

Zou het niet enorm veel logischer zijn dit in Windows zelf te clusteren ? Is dit spreekwoordelijk 2 Ferraries en een Olifant een karretje laten trekken ?

[dawuss]

Ik vind het nu al een geweldig idee

Helaas weet ik zelf heel weinig van het Wine Project af. Dit lijkt me de beste start, maar ik neem aan dat je daar al hebt gekeken.

Houd ons op de hoogte!

[Super_ik]

ik heb zelf met xilinx fpga's gewerkt en van dat xilinx pakket heb ik een windows en een linux versie. maar zo lang duurt t compilen toch niet

k heb met xilinx en sporadisch met altera gewerkt, compilde meestal op een 1gieg bak met 512 mb geheuge, en duurde toch nooit echt heel lang....

edit:
barco? juist daar heb ik met die fpga's gewerkt, xilinx dus? daar is echt wel een linux ide van.

een windows cluster wordt zowieso nix volgens mij. een linux (mosix) cluster is best goed te doen, vindt ik...

[ Voor 30% gewijzigd door Super_ik op 14-06-2004 23:45 ]

[Verwijderd]

Super_ik schreef op 14 juni 2004 @ 23:16:


een windows cluster wordt zowieso nix volgens mij. een linux (mosix) cluster is best goed te doen, vindt ik...

Maar dan moet de software het wel ondersteunen...?

[Verwijderd]

Het kan niet, want de applicatie moet clusters ondersteunen. Het is niet zo dat elke applicatie per definitie clusterbaar of zelfs multithreaded is of kan zijn - integendeel.

Oftewel: kansloos. Wel grappig dat ze dat zelf niet doorhebben. .

[Semyon]

Verwijderd schreef op 15 juni 2004 @ 06:13:
Het kan niet, want de applicatie moet clusters ondersteunen.

Van de mosix Home Page:

In a MOSIX cluster there is no need to modify or to link applications with any library, or even to assign processes to different nodes, MOSIX does it automatically - just fork and forget, like in an SMP

Volgens mij kan MOSIX dat juist wel zelf oplossen als er maar meerdere threads zijn, en in wine hangt dat af van de applicatie die je draait.

[PipoDeClown]

Semyon schreef op 15 juni 2004 @ 06:30:
[...]


Van de mosix Home Page:

[...]


Volgens mij kan MOSIX dat juist wel zelf oplossen als er maar meerdere threads zijn, en in wine hangt dat af van de applicatie die je draait.

kan mosix ook threads verdelen dan?

[Semyon]

PipoDeClown schreef op 15 juni 2004 @ 07:14:
kan mosix ook threads verdelen dan?

Volgens mij is dat het hele idee van Mosix... Maar ik heb er niet mee gewerkt, maar zonder dat zou je niks aan Mosix hebben.

[Jesse]

Ik dacht dat mosix taken door kan schuiven naar een volgende pc zegmaar. Maar alleen complete taken. Dus niet zoals beowulf waarin een zware taak verspreid wordt over een heleboel pc's.

[Macros]

Ik vermoed dat mosix alleen hele processes met hun eigen geheugen kunnen verdelen over de cluster. Losse threads zal moeilijk gaan of HEEL langzaam, omdat 2 threads bij hetzelfde geheugen moeten kunnen en als dat op 2 bakken draait heb je met normale PC's een probleem.

[Verwijderd]

uit de faq

openMosix lets a cluster of computers behave like one big multi-processor computer. However, it doesn't automatically parallelise programs. Each individual process only runs on one computer at a time. For example, if your computer could convert a WAV to a MP3 in a minute, then buying another nine computers and joining them in a ten-node openMosix cluster would NOT let you convert a WAV in six seconds. However, what it would allow you to do is convert 10 WAVs simultanously. Each one would take a minute, but since you can do lots in parallel you'd get through your CD collection much faster .

If what you need to do is take a single process and parallelise it across multiple machines, then openMosix is probably not the technology you're looking for.

[Maasluip]

Het eerste wat ik mis is het doel van deze aktie. Performance? Kosten? Laat dat eerst even duidelijk zijn.

Als tweede zou ik die twee studenten eerst even een Linux machientje laten opzetten. Als ze dat niet lukt dan weet je ook dat het een lang gebed gaat worden.

Na dit voorwerk zou mijn volgende stap zijn het bekijken hoe de performance van dat pakket onder WINE is (gewoon 1 machine, bij voorkeur een test met een single- en multiprocessor) en hoe het programma schaalt op een multiprocessor machine met Windows geïnstalleerd.

Dan kun je iets zeggen of het nuttig is en of het te doen is.

Als het onder windows op een MP machine schaalt dan is dat een goede optie. Voor € 12.000 kun je een 8 processor machine hebben. Per processor is dat niet zo veel.

Heb je ook al naar Condor gekeken?

Geef wel even updates, interessant topic.

[balk]

als het met Wine niet lukt kan je altijd nog een Linux compiler pakken en distcc opzetten. Ook leuk en leerzaam
distcc is een distributed compiler en stuurt pakketjes naar andere pc's: http://distcc.samba.org/

[Verwijderd]

Als ik bovenstaande lees denk ik dat je meer behoefte hebt aan multithreading icm. multiprocessors (SMP, 4 tot 8 cpu's), om als volgende stap distributed computing te gaan gebruiken.

Clustering gebruik je vaak om de beschikbaar van een applicatie te verhogen, het zegt eigenlijk verder weinig over het verhogen van prestaties.

Ik zie niet wat het voordeel is van het draaien van een Win32 executable op een Linux machine. Misschien dat je dat kun laten toelichten door die heren? Ik verwacht niet dat er een flinke prestatiewinst optreedt als je die executable onder Wine aan de praat krijgt.

[ Voor 3% gewijzigd door Verwijderd op 15-06-2004 09:36 ]

[Martin Sturm]

Clustering gebruik je vaak om de beschikbaar van een applicatie te verhogen, het zegt eigenlijk verder weinig over het verhogen van prestaties.

Dit is gewoon niet waar. In een cluster kun je zeker wel de prestaties verhogen. Hoe denk je dat de meeste supercomputers werken? Juist, dat zijn gewoon clusters... volgens hebben supercomputers vaak wel aardige prestaties met conventionele cpu's (Apple G5, Opteron's etc)

[dawuss]

balk schreef op 15 juni 2004 @ 09:35:
als het met Wine niet lukt kan je altijd nog een Linux compiler pakken en distcc opzetten. Ook leuk en leerzaam
distcc is een distributed compiler en stuurt pakketjes naar andere pc's: http://distcc.samba.org/

Sinds wanneer is de Gnu C Compiler in staat om logica te compileren?

[balk]

geen idee
ben dan ook geen programmeur nog doe ik een informatica opleiding. Ik bedoelde meer te zeggen dat er wel een distributed compiler bestaat en dat ze daar misschien dingen mee kunnen doen, icm een andere taal.

[Verwijderd]

Martin Sturm schreef op 15 juni 2004 @ 10:34:
[...]

Dit is gewoon niet waar. In een cluster kun je zeker wel de prestaties verhogen. Hoe denk je dat de meeste supercomputers werken? Juist, dat zijn gewoon clusters... volgens hebben supercomputers vaak wel aardige prestaties met conventionele cpu's (Apple G5, Opteron's etc)

Het KAN wel, maar dat is vaak niet de reden dat je gaat clusteren (in de prakijk die ik ken). Als je alleen maar meer werk wilt verzetten kies je vaak eerder voor een machine met meerdere/snellere processoren. Denk hierbij aan een Sun Fire15k bijvoorbeeld. Da's een doos met meerdere bladen, en totaal 96 processoren. Je kunt in zo'n machine dan meerdere domeinen aanmaken, en per domein het aantal processoren toewijzen.

Wil je echter services redundant of met een hogere beschikbaarheid aanbieden, dan wil je dat wanneer één van de nodes down gaat, de filesystemen en services doordraaien op de andere node(s).

Als het je zuiver om de prestaties gaat wil je je niet bezig hoeven houden met zwevende IP-adressen, fysieke en virtuele nodes, clustered RAID-systemen, etc. Maar als je tóch al een cluster gaat bouwen dan kun je inderdaad profiteren van de extra processoren/geheugen door active/active te gaan draaien.

[Bas!]

@Max_Kool
Dus jouw wereld is heilig?
Clusteren is een manier om goedkoop veel rekenkracht te krijgen. Zeker als de rekenkacht geen lage latencies nodig heeft is het een uitkomst. Berekeningen zoals die in distributed computing gebruikt worden of offline renderwerk is rekenwerk wat zich goed leent voor een cluster.

[Verwijderd]

Neen nee!

Ik wilde alleen aangeven dat het toevoegen van rekenkracht en clustering niets met elkaar te maken hoeft te hebben. That's all.

En ik had al aangegeven dat je op zoek kon gaan naar een vorm van distributed computing.

[ Voor 26% gewijzigd door Verwijderd op 15-06-2004 11:23 ]

[Bas!]

Nog even terugkomend op de topicstarter, is een linuxcluster met daarop een vm met windows draaiende geen handigere oplossing dan wine als je niet een windows cluster wilt draaien?
Ik vraag me af hoe het dan zit met licensing, in principe draai je maar een windows

[Verwijderd]

Semyon schreef op 15 juni 2004 @ 06:30:
Volgens mij kan MOSIX dat juist wel zelf oplossen als er maar meerdere threads zijn, en in wine hangt dat af van de applicatie die je draait.

Nee, kan niet. Zie onder andere malaria's comment, daar geven ze 't zelf ook toe. Elke node in een cluster moet z'n eigen geheugensegment hebben en mag niet sharen, dus zelfs als een applicatie voor SMP is geschreven, kun je d'r nog niks mee. Slechts hele specifieke applicaties die geschreven zijn zonder SHM en met process forking, kun je iets met zo'n node opstelling. En dat doet beowulf al lang. .

Clustered wine kan gewoon niet.

[XTerm]

Bas! schreef op 15 juni 2004 @ 16:14:
Nog even terugkomend op de topicstarter, is een linuxcluster met daarop een vm met windows draaiende geen handigere oplossing dan wine als je niet een windows cluster wilt draaien?
Ik vraag me af hoe het dan zit met licensing, in principe draai je maar een windows

Ken jij VM's dan die windows multuthreaded kunnen draaien ? Zou dan je hele VM niet gewoon op 1 CPU draaien ?

Het hele voorstel is een beetje krankzinnig zoals in in mijn topicstart ook al aangaf, ik probeer gewoon wat meningen bij elkaar te rapen om de 2 studenten in kwestie voor te bereiden dat ze aan een onmogelijke taak zijn begonnen...

Wat *ik* zou doen in hun plaats (behalve het eindwerk weigeren ) is het gewoon met Windows clustersoftware draaien, of zoals enkele mensen al aangeven op een SMP machine gaan draaien.

Weet misschien iemand of die Xilinx (want daar gaat het over) compiler multithreaded zijn ? En zo ja, stel dat ze dat zijn (want windows kent geen fork iirc), zal Wine die threads dan zelf verder threaden ?

[Verwijderd]

XTerm schreef op 15 juni 2004 @ 21:15:
Weet misschien iemand of die Xilinx (want daar gaat het over) compiler multithreaded zijn ? En zo ja, stel dat ze dat zijn (want windows kent geen fork iirc), zal Wine die threads dan zelf verder threaden ?

Wine emuleert Win32 threads via pthread, afaik.

[XTerm]

Verwijderd schreef op 16 juni 2004 @ 19:13:
[...]


Wine emuleert Win32 threads via pthread, afaik.

Maar aangezien threads niet verdeelt kunnen worden over meerdere systemen, is de enige oplossing meerdere CPU's ....

En daarmee valt de reden voor het gebruik van Linux weg.

Conclusie : ze zijn beter af met een Windows SMP bak

[smokalot]

blijkbaar is er ook een xilinx voor linux, denk dat je daar nog het best mee af bent.


_{maar dat kan persoonlijk zijn, ik zou er zelf nogal veel voor over hebben om geen windows te hoeven draaien}

[Wilke]

Clustered wine gaat inderdaad eenvoudigweg niet werken, zoals Beelzebubu en anderen al aangeven.

Ook niet met Mosix.

[Verwijderd]

Verwijderd schreef op 15 juni 2004 @ 16:20:
[...]


Nee, kan niet. Zie onder andere malaria's comment, daar geven ze 't zelf ook toe. Elke node in een cluster moet z'n eigen geheugensegment hebben en mag niet sharen, dus zelfs als een applicatie voor SMP is geschreven, kun je d'r nog niks mee. Slechts hele specifieke applicaties die geschreven zijn zonder SHM en met process forking, kun je iets met zo'n node opstelling. En dat doet beowulf al lang. .

Clustered wine kan gewoon niet.

Er zijn wel degelijk oplossingen om applicaties die shared memory gebruiken the delen over nodes binnen een OpenMosix cluster.

Migshm is een voorbeeld van gedeeld shared memory over meerdere openmosix nodes:
http://jazzalbums.net/maask/

Is best grappig om apache processen over de verschillende nodes te zien migreren. Het is al weer even geleden dat ik er mee gespeeld heb en helaas heb ik er op dit moment helemaal geen tijd meer voor om verder met dat soort leuke dingen te spelen

Tjah verder blijft het wel een redelijk onmogelijke opgave, zeker voor mensen die uberhaupt nog nooit met GNU/Linux en clustering gewerkt hebben

[ Voor 16% gewijzigd door Verwijderd op 17-06-2004 01:30 ]

[KompjoeFriek]

Verwijderd schreef op 17 juni 2004 @ 01:28:
[...]
Tjah verder blijft het wel een redelijk onmogelijke opgave, zeker voor mensen die uberhaupt nog nooit met GNU/Linux en clustering gewerkt hebben

nou, download clusterknoppix, booten, en tadaa

http://bofh.be/clusterknoppix/

[Verwijderd]

Euhm ik heb het over het project waar TS het over heeft.

Iedereen kan wel een clustertje draaien ja

[PipoDeClown]

Verwijderd schreef op 17 juni 2004 @ 01:28:
[...]
Migshm is een voorbeeld van gedeeld shared memory over meerdere openmosix nodes:
http://jazzalbums.net/maask/

overigens schitterend voorbeeld dat er ook slimme vrouwen in de compu wereld zijn ^o^ (en een reden om je werk te outsourcen aan indiers hehe)

[Verwijderd]

Verwijderd schreef op 17 juni 2004 @ 01:28:
Migshm is een voorbeeld van gedeeld shared memory over meerdere openmosix nodes:
http://jazzalbums.net/maask/

Ik had inderdaad aan die mogelijkheid gedacht maar had toen ik reageerde iets van: "laat ik dat nou maar niet doen". . Ik wist dus ook niet dat dit in praktijk ook echt bestond. Wel stoer. .

Maar het feit dat dit soort sync/lock dingen bestaan is wel enorm stoer. Ervanuitgaande dat je er ooit mee gespeeld hebt: hoe efficient is dit? Worden applicaties er veel trager van? Ik ga d'r vanuit dat je het met X shmem of no-shmem kan vergelijken, en dan is no-shmem geen pretje. .

[ Voor 8% gewijzigd door Verwijderd op 17-06-2004 16:22 ]

[Verwijderd]

PipoDeClown schreef op 17 juni 2004 @ 13:23:
[...]

overigens schitterend voorbeeld dat er ook slimme vrouwen in de compu wereld zijn ^o^ (en een reden om je werk te outsourcen aan indiers hehe)

Yupz, het is een knap stukje werk gemaakt door vrouwelijke studentes. Zie in in NL nog niet zo snel gebeuren

Verwijderd schreef op 17 juni 2004 @ 16:21:
[...]

Ik had inderdaad aan die mogelijkheid gedacht maar had toen ik reageerde iets van: "laat ik dat nou maar niet doen". . Ik wist dus ook niet dat dit in praktijk ook echt bestond. Wel stoer. .

Het heeft dan ook aardig wat erg positieve kritiek gekregen. Ik zie in ieder geval dat het beduidend serieuzere vormen aan begint te nemen dan toen ik er mee gespeeld heb.

Maar het feit dat dit soort sync/lock dingen bestaan is wel enorm stoer. Ervanuitgaande dat je er ooit mee gespeeld hebt: hoe efficient is dit? Worden applicaties er veel trager van? Ik ga d'r vanuit dat je het met X shmem of no-shmem kan vergelijken, en dan is no-shmem geen pretje. .

Nee, applicaties worden nauwelijks trager van t.o.v. normaal en al helemaal niet trager t.o.v. een normale openmosix cluster (het tegenovergestelde zelfs uiteraard).
Uiteraard heb je last van overhead maar zolang je niet over te veel nodes praat zal dat (het netwerk dus) niet echt hele grote problemen opleveren.

Probleem was destijds alleen dat ik ten eerste sterk verschillende hardware had draaien in een 3 nodes homebrewed clustertje, waardoor ik geen goede tests kon draaien. Daarnaast was migshm op dat moment nog niet zo ver en wilde het wel eens gebeuren dat de boel een klein beetje crashte