Ny programvara oftast slöseri med resurser [delad, blåskärm]

[Pajn]

4 och 6 håller jag med om. 1, 2, 3 och 5 får du motivera.

[TomasL]

Sammanfattning:

Vi har alltså dessa sex bovar till kodineffektiva program och därmed långsammare 32-bit SC-maskiner än nödvändigt:

1) Högnivåspråk
2) Lättläst kod
3) Mindre bra kompilatorer
4) Klåfingriga programmerare (där varken typ av språk eller kompilatorkvalitet hjälper)
5) Onödiga finesser
6) Klart igår...

MVH/Roger

1, ingen bov, snarare tvärtom, bättre och snabbare program blir resultatet
2, samma som ovan
3, finns säkert dåliga kompilatorer, men knappast de som är mest vanliga, dvs MS kompilatorer, Borlands och GCC
4, Ja naturligtvis, det finns sådana personer som inte skall röra vid ett tangentbord, precis som i alla yrken.
5, tja, det är ju vad konsumenterna vill ha, så.....
6, som ovan.

Så nej, du är helt ute och reser och pratar i nattmössan.

[Andax]

Intressant är att om man kör Windows 7 på en MacBook Pro så har man ca halva batteritiden än om man kör osx vid lite standardmässig slösurfning.
Gissar att apple har optimerat drivrutinerna ganska hårt. Det är väl fördelen med en hårt specad hårdvara.

[Pajn]

Nej,det visar bara att Apples Windows drivare suger. Linux krossar OSX på Apple hårdvara http://www.phoronix.com/scan.php?page=a ... untu&num=1

[Spisblinkaren]

4 och 6 håller jag med om. 1, 2, 3 och 5 får du motivera.

Med risk för att göra bort mig fullständigt skriver jag nu detta sista inlägg för ärligt talat kan jag, som ni märker, ingenting om datorer. Jag bara gnäller för jag har inget liv. Och det som irriterar mig mest i mitt liv, förutom den ofrivilliga ensamheten, är all denna datakomplicering och tvångsmässiga mutationer av applikationers användargränssnitt.

Så ta hand om Er!

Det har varit mycket intressant och roligt!

1) Assembler är det språket som mest liknar ren maskinkod. De få skillnader jag känner till är att OP-koderna har tydliga namn (Mnemonics) istället för rena hextal. Dessutom kan man namnge adresser så att brancher och subrutinanrop kan göras lättare. Mycket mer vet jag inte men detta innebär att man är mycket nära den verkliga maskinkoden som kommer ur en kompilering på denna låga nivå vilket får till följd att man har full kontroll över hur man vill att processorn med dito hårdvara skall arbeta.

Detta kan dock inte sägas om högnivåspråk där resulterande maskinkod helt är upp till kompilatorns kvalitet och att man inte alltid har full koll på hur den allokerar minnet. Rätta mig gärna om jag har fel.

2) Lättläst kod är bara bra ur ett mänskligt perspektiv dvs det ser trevligt ut och man tror sig ha koll. Dessutom blir det lätt för någon annan programmerare att sätta sig in i koden och ta över.

Men där tar fördelarna slut. För lättläst kod är sällan samma som effektivast tänkbara kod. Tror jag iaf.

3) Det finns bra och dåligt av allt så självklart, kompilatorer kan vara dåliga och kanske inte genererar den där optimala maskinkoden som man förutsätter att den skall göra. För det gäller trots allt att den ska utnyttja precis dom där optimalt få OP-koderna/instruktionerna som krävs för att lösa uppgiften.

5) Om vi vänder på frågan då? En browser t.ex, vad behöver den egentligen ha för finesser? Jag ser bara fem dvs den ska kunna läsa (ner) sidor på nätet, man ska kunna klicka på länkar för kunna komma till annan sida, man ska kunna skicka information, den bör ha flikar och den bör gärna ha möjlighet att spara bokmärken.

Alla andra finesser tycker jag är helt onödiga.

Utom möjligtvis FWD/BACK samt att kunna skriva ut en sida.

RAO

[TomasL]

1,2,3: Ja assembler ÄR maskinkod, med lite mer lättlästa namn, MEN när programmen blir lite komplicerade, så blir assembler fullständigt och totalt oöverskådlig, dvs den blir väldigt ineffektiv, dessutom blir det per natur extremt mycket buggar, eftersom man liksom inte kan hålla reda på några miljarder rader maskinkod.
Läste någonstans att Autodesk Inventor har runt 50 miljoner rader kod, Detta skrivet i C, C++ och C#, i maskinkod blir det väl runt 5 miljarder rader assembler kod.
Det är naturligtvis svårt att hålla reda på 50 miljoner rader kod och få det att funka, än värre om det är 100 gånger mer.

I vårt lilla inbäddade styrsystem har vi i nuläget runt 250 000 rader C-kod (förvisso med kommentarer och tomrader, så säg att det är runt 25 000 rader effektiv kod), vilket motsvarar runt 100 000 rader assemblerkod, vilket naturligtvis är ännu mer o-hanterligt.

Så nej, du är helt ute och reser, och har noll begrepp om vad det egentligen handlar om.
Att använda högnivåspråk, standardiserade bibliotek, skriva läsbarkod är en fullständig nödvändighet, om man skall få något att funka , någorlunda buggfritt, och även skapa en möjlighet att fixa till buggar.

Du kan vara lugnt övertygad om att alla kommersiellt använda kompilatorer är oerhört mycket effektivare än någon programmerare, på att skapa så effektiv kod som möjligt.

Beträffande nummer 5, jag är rätt övertygad att de flesta vill kunna läsa PDF-dokument, titta på bilder, Titta på u-tube, läsa elektronikforumet mm i sin browser, föreslår faktiskt att du använder till exempelvis LYNX i stället http://en.wikipedia.org/wiki/Lynx_(web_browser) om du vill slippa alla extragrejjor.

[Andax]

Möjligheten att porta kod mellan olika processorarkitekturer minskar brutalt om man kör assembler.

[TomasL]

Ja, den blir per natur fullständigt icke-existerande.

[blueint]

Bara att instämma i de två senaste inläggen av TomasL (#p1082033) & [url=http://elektronikforumet.com/forum/viewtopic.php?p=1082034#p1082034]Andax (#p1082034).

De ineffektivitetsbovar som man kan rikta in sig på är:
1) Klantprogrammerare där inget verktyg hjälper
2) Finesser som inte tillför tillräckligt för att motivera sin existens
3) Orimliga tidsmål för projekt
4) Rent slarv (Oracle Java)
5) Intriger från större aktörer som Trusted-Computing (TPM), UEFI låsning, kodsignering (undantaget Chromebook), avsiktlig inkompabilitet (MS-DOS) och brist på dokumentation (NVidia) etc.

Man kan se detta på t.ex dekoderboxar där programvaran som medföljer i firmware har en massa buggar. Det kommer möjligtvis 1-2 uppdateringar efter att boxen släppts. Men i stort sett så köper man boxen som den är, ev buggar struntar tillverkaren i. Och tillgång till källkod mm eller objektfiler kan man glömma. Dreambox är boxertillverkarnas och operatörernas stora skräck.

[TomasL]

Nu håller jag inte riktigt med bluint's foliehatsförklaringar, framförallt på nummer 5.

[Nerre]

Men det här är vad jag tror.

Folk spelar inte så mycket spel. Speciellt inte resurskrävande spel.

Du känner uppenbarligen inte så många tonåringar.

[Larsson90]

Nä, folk spelar väl fortfarande Röj, Harpan och eventuellt Sims 1 och Rollercoaster Tycoon 1?

[TomasL]

Commander Keen

[Pajn]

Detta kan dock inte sägas om högnivåspråk där resulterande maskinkod helt är upp till kompilatorns kvalitet och att man inte alltid har full koll på hur den allokerar minnet. Rätta mig gärna om jag har fel.

Kompilatorns kvalité är i de flesta fall bättre än normalprogrammerarens kvalité. Om det dessutom
var upp till programmeraren att hantera minnet skulle du ha många fler heartbleed som berodde
på att man använt en osäker kopieringsfunktion. Med assembler finns det ingen säker kopieringsfunktion.

Dessutom har du inte full koll med assembler heller på en modern processor då den inte bara sitter
passivt och väntar på att bli matad med instruktioner utan aggressivt går ut och plockar de som den
kan köra parallellt (vilket tas upp i filmen jag länkade).

2) Lättläst kod är bara bra ur ett mänskligt perspektiv dvs det ser trevligt ut och man tror sig ha koll. Dessutom blir det lätt för någon annan programmerare att sätta sig in i koden och ta över.

Men där tar fördelarna slut. För lättläst kod är sällan samma som effektivast tänkbara kod. Tror jag iaf.

Fel. Hur ska man optimera något om man inte vet hur det funkar? För att inte tala om alla buggar!
En kompilator eller VM har dessutom möjligheten att statiskt analysera hela programmet, räkna ut alla
codepaths och bygga upp den minneshierarki som passar bäst.

3) Det finns bra och dåligt av allt så självklart, kompilatorer kan vara dåliga och kanske inte genererar den där optimala maskinkoden som man förutsätter att den skall göra. För det gäller trots allt att den ska utnyttja precis dom där optimalt få OP-koderna/instruktionerna som krävs för att lösa uppgiften.

Dåliga kompilatorer används inte (eller ja, det kanske de gör om än försumbart).

5) Om vi vänder på frågan då? En browser t.ex, vad behöver den egentligen ha för finesser? Jag ser bara fem dvs den ska kunna läsa (ner) sidor på nätet, man ska kunna klicka på länkar för kunna komma till annan sida, man ska kunna skicka information, den bör ha flikar och den bör gärna ha möjlighet att spara bokmärken.
Alla andra finesser tycker jag är helt onödiga.

Utom möjligtvis FWD/BACK samt att kunna skriva ut en sida.

Parsa HTML, CSS, JS, bygga upp ett DOM-träd, hantera mus, tangentbord, touch, gps, mikrofon,
accelerometer, och flera andra input enheter, ladda ner filer över HTTP, kryptering, säker lagring
av lösenord, lagring av kakor, filtring av vilka resurser får tillgång till kakorna, ladda ner bilder,
decoda bilder i flera olika format, rendera DOM-trädet till skärmen skalad till 96DPI, kompilera
JS, optimera JS och en jäkla massa annat.
Webbläsaren är troligtvis det mest avancerade programmet i din dator.

Vilka finesser vill du avstå ifrån?

[Spisblinkaren]

Oj, vad jag har trampat i klaveret!

Det jag ärligt talat är mest rädd för nu är att bli hackad av nån av Er.

Eller nån som läser mitt korkade inlägg.

Jag skäms över min egen okunskap!

MVH/Roger