Jump to content

2010, En milstolpe för prestandan


Guest al6
 Share

Recommended Posts

Som ni säkert hört har man gått över till att göra processorer med flera kärnor, istället för att höja klockfrekvensen. Detta för att sätta ett stopp på den exponentionellt växande energiförbrukningen.

Men med flera kärnor kommer stort ansvar. Mjukvaran måste trådas upp, dvs splittras i smådelar som sedan kan köras på de olika kärnorna samtidigt. Detta har visat sig vara enormt svårt och tidskrävande, och de språk som tidigare varit i centrum, C och C++, blir mer och mer ett minne blott.

Men ska man verkligen tvingas gå över till de mer upptrådade, men allt för sega språken, Java och .NET? Svaret är nu NEJ ;D

C++ får en ny standard (den nuvarande är i stort sett från 1998) och en ny utvecklingsstudio år 2010 (uppskattningsvis). Denna standarden av C++ är lite speciell, eftersom den inför så enormt mycket nyheter som verkligen behövs i dessa tider. En enormt uppdaterad grund som tillåter en kraftig men samtidigt simpel multitrådning står på menyn. Låt mig berätta lite vad genierna kommit fram till :)

Förutom den efterlängtade klassen std::thread heter räddningen lambda, vilket är ett simpelt sätt att uttrycka ett programs algoritmer i små paket som sen kan köras oberoende på en kärna. Lambda är alltså ett sätt att ta delar av kod från en algoritm och lägga i små paket, där man sen kan inkludera en liten miljö, så att det blir som ett oberoende miniprogram som kan köras på en egen kärna.

På detta sättet kan man nu göra om en seriell algoritm (en bit kod som inte är trådad) till en parallell algoritm (en trådad bit kod) på ett ganska simpelt sätt.

Vad detta betyder för er, slutanvändare, är att fler programmerare (inklusive jag själv) kommer börja programmera parallellt i framtiden, och därmed höja prestandan på programmen betydligt. Goda nyheter som borde passa alla som tycker det går för sakta ;)

Link to comment
Share on other sites

Nej, jag tror du har fel...

Det absolut viktigaste ingrediensen är att ett operativsystems kärna har inbyggt stöd för virtualisering.

Longhorn-servern ska ha det nu och Windows 7 klienter vete tusan...

Sen viket språk det blir det dividerar de vise om....  Jag vet inte viken mijlö det blir i Azure men förmodigen NET...  spelar mindre roll hursomhelst.

Link to comment
Share on other sites

Kul med kommentarer, men mitt meddelande var egentligen inte förhandlingsbart utan mer ett sammandrag om hur C++ 2010 och Visual Studio 2010 kommer att bli.

Mitt inlägg är alltså inte spekulation, utan ren flytande fakta som grundar sig både i Microsoft (filmer från PDC 2008, och channel9.msdn.com), Bjarne Stroustrup (skaparen av C++, professor) och ISO/IEC 14882 (den faktiska standarden), men framför allt min egen kunskap. För att kunna utnyttja fler kärnor måste man programmera annorlunda, och C++ 2010 låter en göra det på ett bättre sätt.

Men jag måste tyvärr påpeka att ditt meddelande faktiskt inte stämmer. C++ är ett välkänt och välspritt språk som både .NET och Java är implementerade i. C++ är alltså grunden för i princip allt som har med högnivåprogrammering att göra. Denna nya standarden är efterlängtad och kommer förenkla för oss seriellprogrammerare att gå över till parallellprogrammering, vilket kommer sluta i betydligt bättre prestanda i diverse mjukvaror. :)

Nej, jag tror du har fel...

Det absolut viktigaste ingrediensen är att ett operativsystems kärna har inbyggt stöd för virtualisering.

Longhorn-servern ska ha det nu och Windows 7 klienter vete tusan...

Sen viket språk det blir det dividerar de vise om.... Jag vet inte viken mijlö det blir i Azure men förmodigen NET... spelar mindre roll hursomhelst.

Det här meddelandet är faktiskt helt fel, du kan inte få ett seriellt program att köras på mer än en kärna, spelar ingen roll hur operativsystemet är, det går bara inte (framtiden vet jag inget om).

Det är själva grunden i definitionen "seriell"; det måste köras seriellt, en instruktion i taget, på en kärna.

Parallella program är ju program som kan delas upp på flera miniprogram och köras parallellt med varandra, utspridda på flera kärnor. För att göra om ett seriellt program till parallellt krävs att man bryter ut delar av algoritmerna och skapar oberoende, små program med hjälp av lambda.

Lita på mig; du vill inte gå emot mig på hemmaplan, C++ är vad jag fastnat för och jag kan min sak. Jag vill även passa på att säga att man gärna får kommentera även om man inte kan så mycket, bara man inte går emot mig fullständigt, eftersom detta är ren, konfirmerad fakta. Jag vill inte verka mallig men jag måste säga att jag blev paff av pluns inlägg. Detta är liksom centrum av min allra bästa kunskap.

Link to comment
Share on other sites

Ännu mer konfirmation, nu från Intel:

http://www.intel.com/cd/software/products/.../eng/399359.htm

Introducing Intel® Parallel Studio software tools for Microsoft Visual Studio* C/C++ developers. Add parallelism for multicore that forward scales to manycore.

http://www.go-parallel.com/

Translating Multicore Power into Application Performance

Trots det faktum att kompilatorn är på min sida så ville jag visa mer källa, så jag kan sova länge imorron utan att behöva gå upp och se fler inlägg i tråden, som saknar sanning.

Go Parallel ;D

Link to comment
Share on other sites

Guest DimensionX

Ingen som helst kritik mot dig al6, utan lite tankar om programmering och program.

Vad man vill se är lite effektivitet.

1.Så små program som möjligt, utan en massa onödig kod, sk bloat.

2.Helst komprimerat (lzma eller liknande) för att pressa storleken ytterligare.

3.Helst en optimerad portabel version

4.Optimering av all hårdvara, inklusive äldre. Dvs ett program skall pressa nästan max ur all hårdvara.

Och inget slöseri, vi sitter alla med monsterdatorer, det skall märkas på programmen också.

Var tog all effektivitet vägen?

Vi sitter med monsterburkar allihopa, när skall man böja utnyttja något av den kapaciteten? Utan att vi måste köpa ny hårdvara hela tiden? Kör man Puppy Linux så får man känna på lite hur kraftfull hårdvara man egentligen har. Mer sånt. :)

Jag vill se ett Windows som funkar på en gammal 800Mhz, som plötsligt verkar 3 gånger så snabb.

Vart tog den effektiviteten vägen? när skall man börja göra saker som "inte går" med hårdvaran? som på Amiga/Atari tiden? då var det effektivitet till max som gällde och man sprängde gränserna titt som tätt för vad maskinerna klarade av och slog den gränsen med flera tusen procent i slutändan. Samma sak med SNES och Megadrive, till och med Playstation. Jag fick en fartökning på 1380% på min Atari ST när jag använde en accellerator för GEM Windows systemet som bytte ut delar av C koden med ren maskinkod. Sånt på PC, är det möjligt?

Jag vill se en ny Firefox som klarar att hantera 60 flikar, utan att slöa det minsta.

Sedan vill jag ser mer välskrivna program i klass med Total Commander och Notetab Pro. Små, blixtsnabba och otroligt effektiva istället för det mesta av MS bloat. Det enda som inte är bloatat är Paint och Notepad.

Vad jag menar är att det går att pressa hårdvara ordentligt, men det gör man ju aldrig, vi får köpa nytt, nytt och nytt.

Link to comment
Share on other sites

Mycket intressant läsning al6! Att applikationer enklare eller bättre kan multitråda är guld värt och är det största problemet vi har idag.

Jag håller alltså inte med plun om att virtualisering är viktigare men jag undrar om du har lust att utveckla vad du menar?

Sedan har vi det här med storleken på ett program, det får gärna vara litet men idag med den mängd minne som finns både på lagringssidan och i form av arbetsminne så tycker jag det spelar mindre roll om ett program tar 1MB eller 10MB, eller 10MB eller 50MB.

Link to comment
Share on other sites

Guest DimensionX
Mycket intressant läsning al6! Att applikationer enklare eller bättre kan multitråda är guld värt och är det största problemet vi har idag.

Jag håller alltså inte med plun om att virtualisering är viktigare men jag undrar om du har lust att utveckla vad du menar?

Sedan har vi det här med storleken på ett program, det får gärna vara litet men idag med den mängd minne som finns både på lagringssidan och i form av arbetsminne så tycker jag det spelar mindre roll om ett program tar 1MB eller 10MB, eller 10MB eller 50MB.

Lite kod = effektiv snabb kod

Mycket kod = bloat = slöare program

Sen spelar inte 5, 10 eller 30 MB så stor roll egentligen.

"Den kod" som "är" programmet bör vara så liten som möjligt med så lite onödiga instruktioner som går, för att maximera snabbhet och effektivitet. Samt utnyttja hårdvaran så maximalt som går.

Man märker program...som är kanske bara 1/20 så stort, ändå innehåller beydligt fler funktioner, plus att det är otroligt mycket snabbare.

= effektivisering av kod.

Link to comment
Share on other sites

Mycket intressant läsning al6! Att applikationer enklare eller bättre kan multitråda är guld värt och är det största problemet vi har idag.

Jag håller alltså inte med plun om att virtualisering är viktigare men jag undrar om du har lust att utveckla vad du menar?

Sedan har vi det här med storleken på ett program, det får gärna vara litet men idag med den mängd minne som finns både på lagringssidan och i form av arbetsminne så tycker jag det spelar mindre roll om ett program tar 1MB eller 10MB, eller 10MB eller 50MB.

Jo du håller ju själv på och botaniserar i Hyper-V konceptet....  ;)

Att köra olika miljöer i skilda kärnor är framtiden och uppe bland molnen kommer det här att explodera för att köras i olika klientdatorer..

Virtualbox har ju kommit så långt att man kör det helt "sömlöst"... du märker inte vilken miljö som är vilken.

Sen skulle jag sätta en $ på att NET programmering inkl Silverlight är något att satsa på...

För friknådaren då Mono... http://www.mono-project.com/Main_Page

AZURE... ;)

En annan osäkerhet är Googles Androidkoncept och det körs ju med Java huvudsakligen.

Apple har ju sedan verkligen fått fart på konceptet med en riktig marknad för tjänster o mjukvara.

Summa summarum så är jag övertygad om att framtidens användare vill köra lite av varje, helt sömlöst och då är riktig virtualisering ett måste...

Ett operativsystem kommer att bli ganska värdelöst i framtiden.... tjänster och bra slutanvändarapplikationer som gäller som enkelt kan köpas typ Apples marknad.

Link to comment
Share on other sites

Ok plun, då förstår jag vad du menar. Virtualisering är en viktig del av framtiden men är intressant främst på företagssidan i dagsläget, och jag vill ändå framhäva stöd för multithreading som det absolut viktigaste för alla användare.

Nej det tror jag inte... .

Jag brukar kolla in Channel 9 lite då och då eftersom de är lyckligt befriade från "dödgrävare" och det är kul läsning från riktigt kunniga och insatta användare inkl utvecklare.

http://channel9.msdn.com/

David Reveman, Novell har sjösatt Nomad som körs inkl 3D....

http://en.opensuse.org/Nomad

Du kan ju redan nu starta ett het OS på några sekunder...

Link to comment
Share on other sites

Jag såg pluns inlägg och förstår nu vad han menar med vritualisering, han har helt rätt i att man förmodligen kommer gå över till molntjänster och att köra virtuella miljöer. Men man kan ändå inte bara blunda för sanningen och bara tänka att man ska jobba med .NET eller Java, eller köra genom VirtualBox så löser det sig.

Java, .NET, VirtualBox, Mono, Windows, Linux (C, men skitsamma) är alla skrivna i C++ och därför har alla dessa mjukvaror direkt koppling med tråden, eftersom dom alla bygger på vad som nu förbättras med den nya standarden. VirtualBox är inte något som faller ner från himmeln, utan det måste vara någon som skriver koden, och det sker i C++.

Men även om vi mer och mer går upp i molnen kommer vi aldrig att kunna hålla oss där helt. Exakt alla spel är i princip skrivna i C++, att spel skulle köras genom molnen är helt otänkbart eftersom spelindustrin hela tiden pressar prestandan och absolut inte skulle nöja sig med någon molntjänst.

Tänk er Crysis på molnet, man hade fått mäta i "bilder per timme" ;)

Så C++ är inget som kommer försvinna, och eftersom nästan all mjukvara är skriven i C++, och fortfarande görs, kan denna nya standarden höja prestandan betydligt.

Link to comment
Share on other sites

Virtualbox tog jag som ett exempel på sömlöshet.....

Sen i slutändan handlar det om en ny modell för att leverera tjänster via mjukvara.

Apples koncept har ju blivit en kanonsucce där utveckare lägger upp sina applikationer i en marknad.

Billigt, enkelt och snabbt.

Link to comment
Share on other sites

Jag måste säga att det kommer rätt bra inlägg, jag tror ni har bättre koll på det här med moln och så.

Det min tråd grundades på var att man nu uppdaterat C++ till att klara av multitrådning (plus massa mer), och det på ett bra sätt. Sen om C++ är framtiden eller inte vet jag inte, men en sak är säker och det är att C++ nu konkurrerar med Java och .NET, igen.

Det gör ju att vi lättare kan utnyttja fler kärnor, vilket är bra från alla synpunkter. Sen är ju som sagt spelindustrin beroende av C++.

http://channel9.msdn.com/pdc2008/TL13/

Link to comment
Share on other sites

Ingen kritik "här" heller,

som DimX skriver är det möjligt med en kombination av lågnivå-högnivå språk ?

Eller är det omöjligt eftersom hårdvaran "byts" ut för snabbt ?

Har faktiskt undrat länge över detta och pc.  question?

Glömde svara på detta, ja man kan blanda låg och högnivå hur man vill. Hårdvaran ändras inte, man har ju fortfarande arkitekturen intel x86-x64. Men man kan inte flytta lågnivåkod mellan arkitekturer.

Link to comment
Share on other sites

Guest DimensionX

Personligen så föredrar jag riktiga program framför onlinetjänster. Program som jag kan starta och köra helt oberoende från allt annat.

Det kommer nog alltid finnas en marknad eller behov av ett operativsystem. Anta att jag vill starta upp datorn, helt oberoende från precis allt annat, till och med internet. Då måste jag ha ett operativsystem som klarar sig helt och hållet på egen hand.

Multithreading i alla ära, det skulle vara skönt att se lite förbättring även för alla andra äldre processorer också, optimering.

På Megadrive/SNES tog det runt 4-5 år innan man började kunna maxa ut hårdvaran och prestandan var inte ens jämförbar med de första spel som kom. Samma sak med datorerna, Atari ST/Amiga tog flera år att maxa ut hårdvaran på. Samma sak på PSX.

Man var så illa tvungen eftersom det inte fanns någon annan hårdvara.

Idag är det så mycket lättare om kunden helt enkelt köper nyare och bättre hårdvara, man struntar i att maxa ut den som finns. Visst förbättrar man programmen, men bara en bråkdel av vad man skulle kunna göra, det finns inte tid helt enkelt.

Det som al6 talar om är väl inte fel, förutom det att alla inte ens har sådana processorer. När skall man maxa ut den gamla hårdvaran? Det blir att skaffa ny hårdvara helt enkelt. Jag skulle gärna se effektivare programmering som gynnar alla datorer, gamla som nya. :)

Link to comment
Share on other sites

Alltså, egentligen är multitrådning bara ett annat sätt att programmera, ingen riktig optimering. Det har egentligen bara en fördel, och det är att programmet blir vansinnigt mycket snabbare på nya processorer.

Men att köra program med fler trådar (multitasking) har man kunnat göra sedan Windows 1.0, så ett flertrådat program kan fortfarande köras på gamla datorer, fast utan den prestandavinst så klart. Multitrådade program är helt klart framtiden, varesig om det är i molnen eller lokalt på datorn.

Jo men spelindustrin är ju svårt sargade av piratkopiering...

Jag förstår inte vad piratkopiering har med multitrådning att göra? Menar du att spelindustrin kommer försvinna för att det är för hög grad av piratkopiering?

Link to comment
Share on other sites

Ingen kritik "här" heller,

som DimX skriver är det möjligt med en kombination av lågnivå-högnivå språk ?

Eller är det omöjligt eftersom hårdvaran "byts" ut för snabbt ?

Har faktiskt undrat länge över detta och pc.  question?

Glömde svara på detta, ja man kan blanda låg och högnivå hur man vill. Hårdvaran ändras inte, man har ju fortfarande arkitekturen intel x86-x64. Men man kan inte flytta lågnivåkod mellan arkitekturer.

Ahaa, tack. Tänkte egentligen bakåt till Amiga tiden, där optimerade man till olika chip,

det var lite så jag menade.

Link to comment
Share on other sites

Alltså, egentligen är multitrådning bara ett annat sätt att programmera, ingen riktig optimering. Det har egentligen bara en fördel, och det är att programmet blir vansinnigt mycket snabbare på nya processorer.

Men att köra program med fler trådar (multitasking) har man kunnat göra sedan Windows 1.0, så ett flertrådat program kan fortfarande köras på gamla datorer, fast utan den prestandavinst så klart. Multitrådade program är helt klart framtiden, varesig om det är i molnen eller lokalt på datorn.

Jo men spelindustrin är ju svårt sargade av piratkopiering...

Jag förstår inte vad piratkopiering har med multitrådning att göra? Menar du att spelindustrin kommer försvinna för att det är för hög grad av piratkopiering?

Nej det handar nog mer om parallell trådning samt låta olika kärnor sköta isolerade processer eller hela operativsystem

Spelindustrin har förmodligen ett stort intresse i moln eftersom man då kan låta ett spel snurra lokalt i "molnet", då slipper man att någon crackar ett spel...

Sen verkar du inte ha kollat in Chanel9 än....

Här har du en början från en snubbe som vet.... ;)  Tar lite tid men är klart intressant !

http://channel9.msdn.com/posts/Dan/Soma-on...-and-Windows-7/

Osv....

Link to comment
Share on other sites

Jo, jag är medlem på channel9, det är därifrån jag fick reda på hur enormt man kan snabba upp sina program med dom nya biblioteken och med lambda i Visual Studio 2010. Dock hänger jag mer på 10-4 avdelningen som handlar om Visual Studio 10 (2010) och .NET 4. Jag ska ta en titt på din film, det är ju mycket intressant på channel9 som du säger.

Link to comment
Share on other sites

Jag laddade hem en CTP för Visual Studio 2010, en tidig beta, där jag gjorde två fibonacciräknare. En seriell och en parallell:

<se bifogad bild>

Som ni ser använder den seriella endast 50% CPU-tid när den räknar ut fibonaccitalen, detta eftersom jag har en dualcore (2 kärnig) CPU, men ett program med endast en tråd (seriellt). Däremot kunde den multitrådade räknaren utnyttja 100% av min CPU-tid, eftersom den räknaren delar upp arbetet på flera parallella trådar, som kan räknas ut av många kärnor (2 i detta fallet).

Däremot var faktiskt den parallella räknaren betydligt långsammare än den seriella. Detta har jag inte så jättebra koll om, men enligt många presentationer på channel9 verkar det som att man egentligen inte tjänar så mycket på att köra multitrådat på fåkärnade CPU:er, det blir för mycket overhead för att det ska jämna ut sig. Däremot finns det en film på channel9 där man kör denna fibonacciräknaren (samma kod) på en 8-kärnig CPU, där prestandan är hela 5 gånger högre än när man kör den seriella.

Nåja, det viktiga är att det var fruktansvärt simpelt att tråda upp denna fibonacciräknaren med Visual Studio 2010, men jag har mycket kvar att lära om den parallella världen ;)

Edit: Som ni ser så använder den seriella räknaren faktiskt båda kärnorna, men jag skulle gissa på att det är operativsystemet som skickar den enda tråd som är igång, mellan dom båda kärnorna, så att inte en enda kärna får göra allt, och bli helt överhettad. Som ni ser så använder den seriella aldrig mer än 50% CPU-tid, vilket är logiskt, eftersom det bara finns en tråd som sagt.

Link to comment
Share on other sites

Eftersom denna tråden slutade i en gigantisk antiklimax, då prestandan blev flera gånger sämre än från början, fick jag tänka om för att få ett bättre slut. Jag ändrade lite i koden som Microsoft visat på Channel9, så att den parallella koden nu blev dubbelt så snabb som den seriella. Här kommer mina tester utförda på en dualcore CPU under Vista:

Att räkna ut det fyrtionde (40) fibonaccitalet, kortare tid är bättre:

Seriellt program, referens: 4313 millisekunder

Parallellt program, min kod: 1891 millisekunder (Edit: Gjort med Microsofts nya bibliotek)

Parallelt program, Microsofts kod (lämpat för extremt stora system): hela 171 sekunder (Edit: Detta är galet långsamt och måste bero på att jag testade deras pre-beta version, måste vara något fel som ska fixas sen!)

Så för att summera tråden; med dessa nymodigheter i C++, och de nya bibliotek som Microsoft gör, kommer man att kunna klämma fram rejäl prestanda från de nya CPU:erna, även när det bara gäller två kärnor! Speciellt intressant vore om man gjorde ett komprimeringsprogram som arbetade parallellt. Jag har hittils bara sett seriella komprimeringsprogram, men som ni förstår kunde dessa köras dubbelt så snabbt.

Link to comment
Share on other sites

Tycker inte att denna tråden ska dö ut så fort eftersom detta är högst intressant. Jag kollade på pluns film där "Soma" snackar lite om diverse nymodigheter, bland annat säger han citat "om du frågar intel, amd eller någon annan som tillverkar chip kommer dom alla säga att multicore / manycore -system är framtiden." sen nämner han lite om vad jag i första tråden skrev.

Jag har kollat in ännu fler presentationer där jag fick reda på att Microsoft använder C++ till exakt allting. citat "jo men visst är Microsoft ett företag som arbetar främst i C++". Det tar inte så lång tid att lära sig något som är intressant, och sedan mitt första inlägg har jag lärt mig enormt mycket om parallellprogrammering. Vill man få ett ordentligt ord om vad det går ut på bör man kolla in Rick Molloy på channel9, vem är Program Manager på deras "Concurrency runtime", alltså den som jobbar med och vet mest om parallellprogrammeringen.

Det är inte bara själva C++-standarden som är nyheten, utan alla dessa nya bibliotek som Microsoft gör för att underlätta parallellprogrammeringen. Dock är lambda grunden för exakt alla parallellbibliotek dom gör.

Det är kanske inte lika intressant för er, men är man utvecklare och förstår vad som händer så fattar man snabbt att 2010 kommer bli en enorm vändpunkt för prestanda per antal rader kod. Jag vet nu även hur man gör parallellprogrammering utan lambda, och det är enormt mycket mer komplicerat och stökigt.

Ta en titt på Rick Molloys bibliotek, jag tror ni som inte kan läsa kod ändå förstår hur lätt det blir:

http://mschnlnine.wmod.llnwd.net/a1809/d1/...ernsLibrary.wmv

Link to comment
Share on other sites

  • 3 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...