Vilka program är optimerade för 2 processorer och/eller G5-processorn?

Adobe's program varor är nog gjorda för 2 processorer osv..
det är vad jag tror ganska säkert på eftersom Adobe jobbat nära med Apple i samband med G5an

Mvh

Martin

I OS X så sköter systemet om det där med dubbla processorer. Det var i OS 9 som stöd för dubbla processorer behövde fixas i varje program för sig.

Jag är ingen expert på detta men det är så jag har för mig det är.

Däremot så kan det fortfarande behövas optimering för G5 om programmet är skrivet med G4 i åtanke. Adobe släppte t ex en G5-plugin till Photoshop när G5 lanserades.

Hmm... jag har läst påstående som detta ett antal gånger när OS X introducerades men det är ju iofs ingen garanti att de var riktiga. Har du någon bra sida med mer info?

Det nämns heller aldrig "optimized for dual processors" i reklam för mjukvaran vad jag kan se. Betyder det att de flesta program inte är optimerade för dubbla processorer eller betyder det att det är så vanligt nu att det är underförstått?

För att utnyttja flera processorer måste ditt program använda mer än en tråd. En tråd kan bara köras på en processor åt gången, men om du har flera trådar, kan de köra på varsin processor, d v s samtidigt.

Här följer min uppfattning som programmerare om vilken arbetsinsats som krävs för att utnyttja flera processorer. Av beskrivningen nedan bör framgå att ett program inte automatiskt utnyttjar flera processorer, programmeraren måste utföra mer arbete för att detta skall ske.

Vi tänker oss ett hypotetiskt program som har ett grafiskt gränssnitt. I detta gränssnitt finns minst en knapp, som får programmet att utföra något beräkningskrävande arbete.

För det första gäller att det grafiska gränssnittet körs i en egen tråd, GUI-tråden. När du trycker på någon knapp i gränssnittet är det GUI-tråden som blir informerad. Som alla trådar, så kör GUI-tråden bara på en processor i taget.

Därför faller det sig naturligt för den late programmeraren att utföra arbetet i GUI-tråden, på samma ställe i programkoden som han får reda på att knappen blivit nedtryckt.

Medan GUI-tråden jobbar med detta, kan den inte utföra sina vanliga uppgifter, t ex svara på nya "events": inmatningar och musklick. Dessa events läggs i en kö. Om GUI-tråden misslyckas med att processa events under en lång tid, så visas den snurrande badbollen. För att undvika detta, så kan den programmeraren säga att "när GUI-tråden får tid över, skall den utföra en liten del av arbetet, och sen återgå till att hantera events". Men det finns ett bättre sätt...

Den mer ambitiöse programmeraren startar istället en så kallad "worker thread". Denna tråd får inte ändra i gränssnittet, det får bara GUI-tråden göra. Därför måste arbetar-tråden kommunicera med GUI-tråden för att gränssnittet skall kunna ge någon feedback på hur arbetet fortgår.

En programmerare som vill utnyttja flera processorer skapar flera stycken worker threads, minst en per processor, och listar ut ett sätt att dela upp arbetet mellan dessa trådar så att de kan arbeta oberoende av varandra. Om de inte kan det, utan en arbetartråd måste vänta på att en annan ska bli färdig, så har man inget vunnit.

Ett exempel. Photoshop vill applicera ett filter på en bild. Om Adobe's programmerare är lata, så appliceras filtret på hela bilden ifrån gui-tråden. Då svarar inte programmet under tiden, utan visar i bästa fall bara en progressbar.

Om de är lite mer ambitiösa, så startar de en worker thread som gör jobbet, så att man kan göra annat i gränssnittet under tiden, t ex trycka på en "Cancel"-knapp i progress-dialogen.

Om de vill utnyttja flera processorer, t ex 4 stycken, så delar de upp bilden i fyra bitar, och applicerar filtret på varje bit för sig med fyra olika trådar.

Hittade på en artikel i ämnet nu. Vad betyder alltså detta?

"The arrival this week of the new Mac operating system, Mac OS X, brings added support for machines with multiple processors. The new operating system contains built-in support for symmetric multiprocessing--dividing most computing work between two or more chips.

While certain applications already take advantage of more than one chip, Schiller said that Mac OS X allows many more applications to take advantage of an extra chip by automatically dividing computing tasks."

http://news.com.com/2100-1040-254554.html?legacy=cnet

Hur pass stor prestandavinst dubbla processorer ger varierar mycket beroende på program och applikation. När det gäller exempelvis 3D-program måste de skrivas på ett sådant sätt att båda processorerna används vid diverse operationer. Exempelvis rendering kan relativt enkelt delas upp på flera processorer och ger då ca 175-190 % verkningsgrad med dubbla processorer. Andra operationer i programmen lämpar sig inte för multi-trådning (exempelvis scene-redraw osv) och sköts därför bara av den ena processorn.

Alltså är en Dual G5 180 % snabbare vid rendering än en single, men de är båda ungefär lika snabba när du sitter och animerar (gäller i detta fall Cinema 4D).

Så det beror helt enkelt på vilka program du kör och vad du gör hur pass väl dina båda processorer utnyttjas. Är programmen bra multi-trådade (vilket de flesta moderna program är) gör de dubbla processorerna också att du får bättre respons från datorn när du arbetar med flera operationer samtidigt. Exempelvis kan du utan större prestandaförlust rendera och arbeta vidare i exempelvis Photoshop på en dual-maskin eftersom photoshop i det fallet använder den ena processorn och renderingsprocesserna den andra...

Finder är ganska bra trådat och ger bättre respons med dubbla processorer. Vidare är MacOS X bra på att distribuera beräkningar mellan olika program och flera processorer vilket gör att du blir mer produktiv med en dual-maskin eftersom du kan utföra fler kommandon samtidigt utan att datorn slöas ner.

Utöver detta så kan program optimeras för G5-arkitekturen. Detta innebär att de kompileras om för att utnyttja de nyheter som finns i G5-processorn. Apples Pro-program är numera optimerade för G5-arkitekturen och är bra mycket snabbare på en G5 än en G4 per megahertz räknat, dual som singel. Rendering Cinema 4D uppvisar en prestandavinst på nästan 30% vid optimering för G5-arkitekturen. Det motsvarar ca 600 Mhz extra kraft per processor på ett dual 2 GHZ-system, vilket inte är helt fel

Att ett program körs som 64-bitars innebär inte att det automatiskt blir snabbare, utan beräkningsprestandan blir ungefär densamma som för motsvarande 32-bitarsprogram. &4-bitar innebär att programmet kan adressera mer minne. För 32-bitarsprocesser finns ett minnestak vid 4GB tror jag, eller om det är aningen lägre. Ett 64-bitarsprogram kan adressera i princip hur mycket minne som helst, i alla fall så mycket som system tillåter det (dvs, om systemet stöder 64-bitar). När man arbetar med stora datafiler som måste läsas in i ram och dessa överstiger 4 GB i storlek (oavsett hur mycket RAM du har i burken) på ett 32-bitarssystem måste datorn börja använda virtuellt minne (hårddisken) vilket slöar ner beräkningarna ordentligt. På ett 64-bitarssystem kommer dessa beräkningar inte slöas ner så länge du har tillräckligt med ram-minne, dvs i detta fallet mer än 4 GB - exempelvis 8 GB.

Bra sammanfattning Akesson.

En sak förstår jag fortfarande inte. Vad menar egentligen Schiller när han säger "... Mac OS X allows many more applications to take advantage of an extra chip by automatically dividing computing tasks"

Helt enkelt att Mac OS X är bättre än exempelvis MacOS 9 och tidigare på att distribuera beräkningar över flera processorer. Mac OS X är faktiskt riktigt bra på att distribuera beräkningar mellan processorerna när flera eller (och) bra trådade program beräknar parallelt. Detta beror på att kärnan hela tiden aktivt arbetar för att distribuera processer mellan processorerna, vilket inte var fallet i exempelvis Mac OS 9 och tidigare.

Det där är enligt min åsikt en mening skriven på språket "marketing speak". Man ska inte tolka in för mycket i formuleringar som är skrivna i detta språk. Andra exempel på "marketing speak" är "PowerMac G5 är världens snabbaste persondator".

Edit: ett exempel från Redmond: "Windows är mer kostnadseffektivt än Linux"

Det ska sägas att det mesta skrivet i Cocoa blir flertrådat, fönstren och interface går i en annan tråd än det bakomliggande "programmet", så viss vinst med dubbla processorer blir det vare sig man vill eller inte.

Sen handlar den mycket om hur parallellt man kan göra programet. Är det lite data och samma data som ska behandlas (den får plats i processorns cache) så är det väldigt liten vinst med dubbla processorer är det massor med data i en ström som ska behandlas så kan vinsten med dubbla processorer närma sig det teoretiska.

Sen har man alltid en rejäl vinst när man betänker att Mac OS X i grunden är en 30+ trådar som kan fördelas på processorerna, vill en otrådad mp3 codec t.ex. äta väldigt mycket av en processorn så kan systemet tugga vidare snabbt och fint på den andra processorn (med undantag för att det kan bli lite trångt i bussar och annat under väldigt korta stunder.)

Ursäkta franskan, men det där är rent nonsens. Kan du skicka mig ett xcode-projekt med källkod som demonstrerar ditt påstående? mer specifikt, att när man kör ditt program så använder processen flera trådar utan att du uttryckligen skapat dem i programkoden?

Ta vilket cocoa program som helst du har kompilerat och starta i ThreadViewer (ett av hjälp programmen) så ser du 2 trådar, fler om du skapar fler själv. Och ja, den visar bara dom trådar som startas av din applikation. Det är bara en process men 2 trådar.

Ursäkta min dåliga franska Det hade varit strålande om det var som du säger, men jag har inte sett några bevis för det... Mina program visar bara en tråd i Thread Viewer, kanske eftersom jag inte skapat några andra trådar än GUI-tråden.

Det stämmer inte riktigt att allt som är skrivet i cocoa blir automatiskt flertrådad. Programmet måste vara programmerad att använda fler trådar men även när programmet inte är det så används båda processorer i OS X. T ex flera spel t använder endast en tråd för hela spelet och körs endast på en processor men eftersom OS X använder båda CPUn så kör den spelet på en CPU på 100% och resten (Finder/Nätverk eller vad som du nu har öppet) på den andra oanvända processorn. Det kan ge en förbättring med 15-20% gentemot att köra på en dator med endast 1 CPU. Om spelet är multitrådad kan det ge upp till 40-50% bättre prestanda eftersom ljudet kan köras på andra CPUn.

//Rob

Men, jag skulle inte kalla dom "optimerade" för två processorer, för trådarna jobbar nästan aldrig samtidigt.

Det var som attan, jag har då två trådar när jag testar mitt bpmcalc och även lite andra av mina kreationer. Och jag är rätt säker på att jag inte skapat några fler trådar än vad appkit skapat åt mig.

Nu är alla applikationer jag har gjort "document based", kanske har med det att göra.