Valve lanserar Steam för Linux

Precis. DirectX bör förpassas till diket. Framåt för OpenGL!

"Those who don't understand UNIX are condemned to reinvent it, poorly"

Microsoft har aldrig förstått sig på idéerna kring UNIX som väldigt förenklat kan sammanfattas som "do one thing and do it well". D.v.s föredra små effektiva lösningar som löser exakt ett problem och se till att det sedan finns effektiva sätt att kombinera dessa program till att lösa större problem.

Fördelen med att skriva stora monolitiska program är att de ofta kan upplevas som lättare för nybörjare. Den stora nackdelen är att sådana program blir svåra att underhålla, kommer äta mycket resurser även om man bara använder en fraktion av funktionerna.

För den som är det minsta insatt i kombinatorik inser också snabbt att antalet sätt man kan kombinera relativt få enkla program snabbt blir så stor att det är totalt omöjligt för ett enskilt program att täcka alla dessa fall. Och det är orsaken till att många "powerusers" gillar UNIX, dessa användare ställs relativt ofta framför lite udda problem som ingen tidigare kanske tänkt på men det brukar ändå vara rätt enkelt att kombinera att gäng program för att lösa uppgiften.

Microsoft har gjort ett litet försök att gå åt detta håll med PowerShell, men tyvärr är PS brutalt ineffektivt jämfört med t.ex. bash (även om man kör bash under CygWin på Windows, och det bash är rejält mycket långsammare än vad man får på samma dator under Linux). Notera att jag bara refererar till runtime prestanda här, rätt använt kan PowerShell definitivt öka effektiviteten för t.ex. uppgifter som utförs av en admin.

Däremot är faktiskt inte Linux speciellt mycket mer effektivt jämfört med Windows räknat i rena OS anrop. Det var sant fram till Vista (notera att jag referera till OS-kärnan här, Vista hade en del junk i userland som togs bort / optimerades i Win7), men Microsoft gjorde ett väldigt gott jobb i att designa om OS kärnan så att det fungerar väl på dagens multicore PC. Att Linux också fungerar bra på superdatorer med 1000-tals CPU-kärnor är coolt, men för oss vanliga användare med 2-16 CPU-kärnor så fungerar även Windows 7/8 riktigt bra.

Finns några få saker där Linux fortfarande är rejält mycket mer effektiv än Windows, bl.a. tiden det tar att begära mer / lämna tillbaka minne från OSet samt kostnaden och skalbarheten att kommunicera över nätverk (fast det krävs en bra bit över 1Gbit/s innan det blir ett problem för Windows i praktiken). Tittar man på detta test (Vista mot OpenSuse) så var Linux 30-40% snabbare än Windows i Java, C++ och C# (Mono) (vettiga jämförelser då det är språk plattformar som finns på båda plattformarna utan att använda program som Wine eller likande).

De flesta har säkert hört talas om den port av Left 4 Dead 2 där Linux versionen ganska snabbt blev snabbare än Windows versionen. Man ska komma ihåg att nVidia lägger rätt mycket mer resurser på att optimera sina drivare för Windows jämfört med Linux, så mycket talar för att om nVidia/AMD/Intel verkligen fokuserade på GPU-prestande under Linux så kommer prestandadelta mot Windows att öka.

*Tråd rensad*

I SweClockers regler står bl a:

Det går att argumentera utan att kalla folk för "fanboys" eller medvetet lägga en massa ord i munnen på motparten. Kan man inte skriva sansade inlägg så är risken stor att de rensas.

Till alla: anmäl inlägg som ni anser bryter mot dessa regler.

Jag sa att jag refererade till runtime effektivitet. Test att göra t.ex. detta:
1. lista alla filer i hela systemet
2. plocka ut alla som matchar ett visst mönster, t.ex. börjar på bokstaven A
3. sortera dem efter storlek
4. skriv ut de 3 första.

Tiden det tar att göra detta kommer vara 10-100 gånger längre om det görs i PowerShell (har testat på Win7) än om du gör det i CygWin på samma system. Om det blir nära 10 eller nära 100 beror på hur snabb disk du har, ju snabbare den är desto mer CPU-bundet blir problem och desto större blir hastighetsfördelen för bash. Och problemet verkar var just att PS envisas med att kommunicera via CLR objekt, då tidsdelta mellan PS och BASH ökar med antal "steg" man har i sin kommando pipeline. Så jag drog inte detta ur tomma intet

Varför är det dumt? Att ha en enkelt metod att automatisera repetitiva uppgifter leder definitivt till högre effektivitet och även om runtime prestanda är relativt dåligt så ska det vara extremt dåligt innan en människa utför uppgiften snabbare. Att automatisera något betyder också att det alltid blir rätt när man väl fått skriptet rätt (mänskliga faktor elimineras).

Jag skrev ju att Windows kärnan, sedan Vista, fungerar riktigt bra på de system vi normal kommer i kontakt med. Microsoft hade ett väldigt stort fokus på just detta och det betalade sig. Men det är fortfarande så att Linux skalar även till extrema system med 1000-tals CPU-kärnor, något som Windows ännu inte gör, inte ens Windows Server.

Och med effektivitet menar jag: hur många CPU cykler tar ett brk() anrop jämfört med VirtualAlloc (notera att new() och malloc() är implementerade i user-space och har sin egen heap-hanterare ovanpå OS-anropen), resp hur många cykler tar send()/recv(). I båda dessa fall tar Linux 3-5 gånger färre cykler att utföra motsvarande anrop sist jag mätte, vilket var ca 6 månader sedan.

Windows tar på SNB ungefär 18k CPU cykler per anrop till send() om man skickar små TCP segment, Linux tar ca 6k cykler (OSX ligger på ungefär 10k). I mitt fall hade systemet ett "Intel Corporation 82576 Gigabit Network Connection" NIC om du vill göra om mätningen.

Det är bl.a. mitt jobb att skriva extremt optimerade multicore program, vilket är anledningen till att jag sitter och mäter OS-anrop ner på klockcykel nivå. Och i de plattformar vi bygger är helt enkelt inte Windows tillräckligt effektivt. Systemen har 2-8 10Gbit/s portar och får att nå dessa hastigheter är det rätt relevant om något tar 18k cykler eller 6k cykler. Faktum är att även 6k cykler ofta är för mycket så vi har speciallösningar som tar ner detta till betydligt mycket mindre, lösningar som är möjliga att skapa på Linux men omöjliga på OSX och Windows då man behöver tillgång till kernel koden.