Diskussion kring operativ system och dess teknologier

Håller med, men när programmen blir stabila och feature-komplett är valet lätt.

+25% CPU-tid kan lätt räknas om i minskad batteri-tid på en laptop.. då bryr man sig. Annars kan du alltid att räkna om det i el-räkning.

Vilka program vet du om där man spikat att nu, nu är det klart, buggarna är helt fixade, alla features är klara och koden låsas för gott?

Låt oss då räkna om belastningen Dia -> jPicEdt.
Jag kör EN instans av ett program som använder obetydligt mängd CPU-tid. Hmm.
Eller kanske en FTP-klient? Eller en IRC-klient? Comix som jag använder flitigt är skrivet i python (vilket är slöare än Java i alla benchmarks jag har sett). Tror inget av de programmen ens lyckats få min centrino att gå upp en nivå i CPU-användning.
Nej. Det finns absolut ingen anledning att bry sig för många vanliga program. Min dator drar precis lika mycket ström som om dom hade varit skrivna i C. Eller assembler.

mats42
Och sedan crashar ditt program. Men sånt kostar ju inget...

lallassu
Jag kan säga samma sak. Program är inte bara mjukvara som körs på stora serverfarmar.
Frågan som hettade upp denna diskussion har iaf inte från min sida varit "Varför är inte ALLA program skrivna i Java?" utan "Varför är nästan allt skrivet i C?"

Du bör använda det språk som gör att du kan skriva ett sånt bra program som möjligt
Men ni antar att det är precis samma algoritm, som är perfekt implementerad, garanterat buggfritt, och sedan jämför ni. Varför? Ett sånt scenario händer aldrig utanför benchmarks.
Varför stannar ni vid C isåfall? Perfekt optimerad assembler klår allt.

Nu räknar vi om till en mer relevant storlek till det enda någon motiverat Java till:
1 program som inte använder betydelsefull mängd resurser oavsett språk
Jag har inte sagt något om vad beräkningsprogram på serverfarmar skall vara skrivet i.
Däremot har jag läst motargument till varför java i princip aldrig skall användas, även för applikationer på persondatorer.

Här är en till intressant tanke om slöseri
Om jag använder Dia kommer det minst ta dubbelt så lång tid för mig att bli klar med de diagram jag behöver (jmf. med jPicEdt)
Så alltså vinner java-programmet helt överlägset i energi, och min personliga tid. Det skulle vinna även om den tog 100% cputid.
(Anledning: Crashar, problem med exportering, avsaknande av nödvändiga funktioner som rotation och TeX-formler i texterna i Dia.)
Och för övrigt så skulle inte +25% cputid märkas på den här datorn. Den skalar inte processorhastigheten == exakt lika strömslukande som när den idlar 99%.
Slutsats: Användaren är ofta den största flaskhalsen.

Poängen här är att vissa program kan bli bättre i Java än i C (givet lika lång utvecklingstid)
Inte alla, men troligtvis mer än de väldigt få Javaprogram jag har installerade hemma.

Här är lite roligt exempel:

	int x;
	double tid = csecond();	
	double a = 0, b = 0, c = 0, d = 0, e = 0, f = 0, g = 0, h = 0, i = 0, j = 0; 
	for (x=0; x < ADDITERATIONS; x++) {
		a++;b++;c++;d++;
		a++;b++;c++;d++;
		a++;b++;c++;d++;
		....
	}

	int x;
	double a = 0, b = 0, c = 0, d = 0, e = 0, f = 0, g = 0, h = 0, i = 0, j = 0; 
	double tid = csecond();
	for (x=0; x < ADDITERATIONS; x++) {
		a++;b++;c++;d++;
		a++;b++;c++;d++;
		a++;b++;c++;d++;
		....
	}

taget ur en gammal lab jag hade i en kurs om högprestandaberäkning. Kompilerad med gcc -O3
Den senare, där bara deklarationen flyttats upp en rad, är 40% långsammare.

Dual Core AMD Opteron(tm) Processor 875
gcc version 3.4.6 20060404 (Red Hat 3.4.6-9)

Men ni litar verkar lita på gcc's optimeringar för att ni sett en överarbetat benchmark?

Testet med Phoronix, Linux vs Solaris vs FreeBSD säger inte hela saken. Linux vinner i flest tester, följt av Solaris och sist FreeBSD. Som väntat vinner Solaris filtesterna, pga ZFS.

För desktop så vore kanske Linux och ZFS bäst. Men som någon påpekade: det är oftast för små skillnader för att man ska vara helt säker. Spelar det någon roll om det tar 2 min och 24 sek eller 2 min och 18 sek?

Sen är det oxå så att t.ex. Solaris är till för stora system där man har många CPUer och trådar. För enstaka CPUer så är faktiskt Solaris inte vidare snabbt. Detta beror på att det är stor skillnad i design och komplexitet om du designar för en/två CPU som Linux gör dvs desktop, eller om du försöker bygga en skalbar lösning oavsett hur många CPUer dvs server. Att bygga bra trådade program är väldigt svårt, som vi alla vet. Se t.ex. spelprogrammerarna. När det gäller stora servrar med flera CPUer så är Solaris kanske bäst, eftersom det skalar så bra. Men när det gäller en enda CPU så är Solaris inte vidare bra. Solaris drar igång en stor apparat i bakgrunden för att hantera många CPUer, men det straffas på desktop. Trots det är Solaris bäst på vissa av dessa desktop benchmarks. Föreställ er hur bra Solaris presterar på många CPUer istället där alla andra OS har problem. Det är alltså helt andra krav för serverOS och för desktopOS. Detta benchmark visade Desktop grejer. Där gör Solaris och FreeBSD sämre ifrån sig än Linux. Men Solaris och FreeBSD är ju mera server OS.

Angående Java vs C. C är ju snabbast rent generellt. Men det är mycket meckigare och kan leda till svårfunna fel. Java är lättare att programmera, och hyfsat snabbt. Men Java duger inte för lågnivå grejer, som drivrutiner, OS, etc. Så länge man inte ska göra lågnivå grejer på bitnivå skulle jag använda Java. För lågnivå grejer så är C eller assembler det självklara valet. Men hellre C förstås, än asm. Java är nog skrivet i C. Däremot är inte C skrivet i Java. Det finns en god anledning för det.

Jag tänkte mig en traditionell 1.0 release. Sedan finns det ingenting som säger att det är svårare att skriva program i C, eller att det genererar fler buggar. Argument ditåt är rent skitsnack. För enskilda individer må det vara hänt.

Python går att kompilera till en körbar fil med betydande prestanda-vinst. Dessutom är det ju väldigt lätt att bygga c-extentions till den [Pyrex] eller inline:a c++ med tex Weave.

Jag har inget emot högnivå-språk men "core"-funktionalitet bör ligga i C, dels för prestandan, och dels för att C-bibliotek är det mest portabla där ute. Därför gillar jag initiativ som gstreamer, cairo, gegl, vtk etc. Vart GUI-klicken håller hus känns ganska redundant, där kan tom Python vara att föredra då det blir enkelt att kustomisera.

Och majoriteten av alla desktopdatorer kör Windows, men det betyder inte att den är bäst på att ens hantera en kärna

Jag vet inte om du har läst min tråd om ZFS och Solaris?
http://www.sweclockers.com/forum/showthread.php?s=&threadid=8...

Där skriver jag bl.a. att Linux skalar dåligt vid stor last, och har där flera länkar som pratar om det. För små laster duger Linux utmärkt, men Linux koden är ganska buggig och rörig. Bl.a. finns en länk i tråden från Linux kernel developer Andrew Morton som pratar om alla buggar och problem. Linux kernel koden är på ~6.4 milj rader kod och >10 milj rader om man räknar med alla kommentarer (enligt källa på idg.se, kan försöka leta fram den om någon vill), dvs det är helt omöjligt att hålla den buggfri. Ju mindre kod, desto bättre. Här finns några mjukvaror och respektive antal kodrader (tänk på att siffrorna behöver uppdateras)
http://en.wikipedia.org/wiki/Lines_of_code

Jovisst finns Linux på de flesta massiva kluster (dvs superdatorer), men som jag pratar om i min tråd, så gör de klustren inget annat än en enda sak, typ. Och Linux är enkel skräddarsy till en enda speciell sak. Men för generellt OS arbete, så finns det många källor som säger att Linux skalar mindre bra, se tråden. Självklart skalar Linux mycket bättre än normala Windows för vanligt OS arbete. Men vill man bara göra en sak; tugga siffror så vill du ha en simpel kärna som är optimerad för bara det. Du vill rippa ut all onödig kod, drivrutiner för webkameror, etc. Vill du ha ett bra trådat generellt OS, så krävs komplex struktur och mycket overhead. Detta leder till att för en enda kärna så är inte Solaris överdrivet snabb. För många kärnor så rockar Solaris.

Men det är ju självklart att Linux har problem, Linux är en ung kärna. För Solaris tog det många år innan de fick till trådningen bra, första versionen dvs SunOS sög. Det var en vanlig trådningsmodell. Att skala bra kräver mycket erfarenhet och djup kunskap, man bör ha gjort några försök innan. Nästa revision av Linux kommer nog skala bra.

Här är en lite töntig video om ZFS:
http://link.brightcove.com/services/player/bcpid1640183659?bc...

Snubben kraschar 2 drivar och ZFS raid fortsätter. Sen reparerar han raidet med 1 kommando.

Här finns en VMware image med den nyaste senaste ZFS teknologin att prova på:
http://ebberstwork.blogspot.com/2008/11/sun-unified-storage-7...

SUN släpper nya storage 7000 burkar, med revolutionerande ny mjukvara och GUI. Testa det om man vill prova på hur enkelt ZFS är. Det unika DTrace är oxå inbakat, och visar jättemycket data om vilka filer som accessas, etc.

Ok, det verkar som Solaris i Phoronix benchmarks ska ligga mycket högre. Klåparna använde 32 bits vid gcc för Solaris, inte 64 bits som för de andra. När man använder 64 bits vid kompileringen så kan benchmarks öka mellan 60% till 100% i dessa två exempel. Och därigenom tar Solaris lätt även toppositionen i dessa två benchmarks:

"It is possible some of the performance differences are due to the
gcc version being used as Solaris bundles gcc 3.4.3 and other distros may bundle 4.x, but it is much more likely due to the default ABI used by the bundled gcc. "gcc -O" on Solaris will default to ia32/x87, whereas on the other "64 bit" distros tested it will default to amd64. The performance difference can be seen in the two Byte Computational benchmarks on page 7 where Solaris appears to lag: Dhrystone 2 (./Run dhry2) and Floating-Point Arithmetic (./Run float). These tests are compiled with "gcc -O" which produces ia32/x87 code. When adding "-m64" which puts Solaris on par with the other distros, the performance jumps quite a bit. Measured on a Intel QX6700, dhry2 goes from 9307771.4 to 13421763.5 and float goes from 707932.5 to 1477185.6."

Reactos är nåt som verkar ganska intressant i mina ögon dom jobbar ganska fort dockså är den i alpha ännu ingen beta har kommit.

www.reactos.org <-- står även på svenska vilket är ett plus.

dom villl göra det xp kompatibelt.

Det funkar i VirtualBox har jag fått höra. Så slipper man partitionera om, om man vill testa det.