C-programmering och hårdvarunära programmering

Jo, noteringen att majoriteten av alla program inte behöver extrem prestanda syftar i detta fall främst på vanliga användning på stationär dator, eller en hel del nätansluten embedded-utrustning.

Vidare - tar man t ex en timer, så är den event-styrd. Sover 99.99% av tiden och tar något beslut i samband med timer-click. Så det är mest statisk strömförbrukning som spelar roll.

Men 10% högre CPU-last eller 10% längre exekveringstid för godtyckligt program slår ju direkt på batteriförbrukningen om plattformen är batteridriven. Och en embedded-produkt som normalt är nätdriven men har inbyggd UPS tappar ju på motsvarande sätt drift-tid på sin batteribackup.

En vanlig Android-telefon kan ofta fixa 1-2 veckor på batteri i flight-mode. Inte för att radion är så extremt hungrig utan bara för att så många grisande program har regel att de kryper ihop och sover om det saknas nät och laddning - får det något av nät eller laddning så börjar de direkt köra massiva mängder bakgrundsjobb. Varje enskilt program är skrivet med antagandet att just det programmet är viktigt.

Jag upplever att det finns ett stort gap mellan utvecklare och management - management vill ha "cool" utan att tänka på att en del av de tuffa sakerna drastiskt påverkar t ex batteritid. Extremfall är en produkt som behövde ha eco-funktion. Eco-funktionen stängde av bakgrundsbelysningen till stor eldriven apparat. Microskopisk energibesparing - men management kunde inte acceptera en bunts sekunders fördröjning för att yttre utrustning skulle bli redo för användning när man lämnar eco-mode. Men databladet måste ju få säga att apparaten hade eco-mode. Alltså dit med knapp och programvarubluff - ungefär som VW-dieslarna.

Så helt klart dyker det ofta upp kravspecifikationer som inte så där lysande matchar vad planerad hårdvara faktiskt är lämplig att klara av. Eller där tidplanen inte så där lysande lämnar nödvändig tid för att implementera den där hyper-effektiva algoritmen som är närmast rocket-science men som faktiskt möjliggör att uppfylla kraven. Så antingen blir produkten försenad eller också klagar produktägaren på att den ju inte alls blev så bra som man beställde, när produkten släpptes i tid och inom kostnadsram men med standard-kod som då inte är skräddarsydd för uppgiften.

Skall jag göra om du först svarar på hur man kan koda i java för att få träff i L1 cachen nästan hela tiden?
Skillnaden i hastighet mellan att processorn och L2 är stor, ännu större om data hittas i L3 och arbetsminne skall vi inte prata om.

Bara där har du massor av fördelar i C/C++ för det går inte att optimera den hanteringen om man inte kan hantera minnet

Nästa problem mellan java och C/C++. Java gödslar med minne, i och med att man inte bryr sig så mycket om hur minne används brukar de inte bry sig speciellt om man allokerar mer minne. Har sett statistik att språk med en GC ofta använder mer än 5 gånger mer minne jämfört med de utan GC. Förstår man hur cachen fungerar programmerar man ofta för att det cachen skall jobba optimalt, att data får plats i en Cache Line och då väljs samt att det inte cachen får kasta bort minne i onödan. Använder programmet 5 gånger mer minne blir det väldigt mycket mer att kasta bort för att byta ut mot annat.

Förstår man inte cachen så förstår man inte hur man får upp hastigheten för den är helt avgörande om man skall få upp hastighet.

Pratar vi processor utan cache då ligger det en del i vad du säger, är det ingen skillnad på minnet kan säkert java börja tävla.

I den tråden fanns endast ett vettigt inlägg, de andra tror jag inte förstår hur man får upp prestanda i krävande program.
Inlägget hittas här: https://softwareengineering.stackexchange.com/a/110716

Spekulerar lite men jag tror myten om att Java skulle kunna slå C++ uppstod med Intels "Core" processorer. En ganska märklig processor sett till utvecklingen efter och innan. Vad de gjorde var att placera en jättestor och snabb L2 cache på processorchippet. Det gjorde processorn något schizofren. Kunde prestera väldigt bra för att sedan helt dyka. På grund av denna arkitektur fick man ofta bra resultat i små eller enklare test för prestanda, allt fick plats i processorns stora och snabba L2 cache. När tester utförs brukar de också enbart testa ett program, allt annat stängs av. Det är inte normalt arbete sett till stationära datorer där denna processorn satt, det vanliga är att det är flera program som körs.
Problemet som fick processorns prestanda att dyka var nämligen att så fort L2'an inte räckte till så presterade den mycket dåligt.

När man gör enklare kodsnuttar och jämför C++ och Java, kod som oftast inte är i närheten av hur prestandakritisk kod ser ut i C++, där fick java gynnsamma resultat på "Core" processorerna.

Något som ställde till det var också att STL (standard template library) inte var speciellt effektivt innan C++ 11. STL är vanligt i C++ program och är det programmerare som inte bryr sig speciellt om prestanda och kanske inte är jättekunniga i språket så vart det lätt att klanta till det och därmed producera ineffektiv kod. Med C++ 11 fick alla de som var flitiga användare av STL en mycket stor prestandaökning efter omkompilering.

För att förstå, ett exempel på hur prestandakodning kan se ut. Metoden nedan är ganska lik de prestandaoptimerade funktionerna som finns i de flesta språk för att räkna längden på en text. Inte helt ovanligt att nedanstående metod är skriven direkt i assembler. Dagens kompilatorer är så duktiga att man kan skriva metoder direkt i C++ men ändå få likartad prestanda som direktskriven och optimerad assembler bara man anpassar något efter hur kompilatorn vill ha koden.
Koden nedan visar också hur man anpassar efter cache, prefetchers och vilka processorinstruktioner som oftast finns (kompilatorn vet i princip alltid vilken som skall väljas när man kompilerar för en viss processor). Istället för att jämföra tecken för tecken med avslutande 0-tecken jämförs 8 tecken samtidigt och de skall få plats i en cache line. Dagens processorer har något som kallas för prefetchers vilket gör att processorn kan förutse (chansa) vad för minne som kommer användas. När minne hämtas från arbetsminne (RAM) hämtas därför oftast lite mer. Och därför kan man få träff i L1 cachen hela tiden även om det är mycket långa texter som skall räknas längd på.

Tror du glömde att använda ullMask.

I ett större program (miljoner rader kod) så kan man bara mikrooptimera ett fåtal "hotspots" då det ofta finns en konflikt mellan att skriva kod som är optimal att exekvera och kod som är lätt att underhålla. I det stora hela är vi beroende av att kompilatorer kan översätta kod som människor kan läsa till kod som är snabb att exekvera. Grovt räknat kan det säkert stämma att den fördel som C/C++ har genom att vara statiskt definierat delvis kompenseras av Javas jit-optimering. Dessutom finns verktyg som Proguard som gör statisk optimering även av Javas byte-kod.

Som jag skrivit innan är data-layouten något som är mycket svårare för en kompilator att optimera. Om du analyserar cache-missar i ett större program så är det i data-accesser de stora kostnaderna återfinns. I synnerhet som många större program är trådade och trådarna både skriver och läser data, till skillnad från kod som oftast är skrivskyddad och därför inte har någon synkroniseringskostnad.

Jämför antalet cache-missar för att iterera över en vektor av typen "int []" i C, "std::vector<int>" i C++ och "ArrayList<Integer>" i Java, så tror jag du förstår vad jag menar. I C och C++ återfinns innehållet lagrat sekventiellt i minnet, medan varje element ligger slumpvis utspritt i Java. Det finns ingen kodoptimering som kan kompensera för en sådan skillnad.

Beror väl snarare på vilken nivå programmeraren har, finns inte kompetensen får man skippa prestanda för att de kan inte. Det behöver inte vara svårläst kod bara för att man optimerar den

Om man trådar upp kod tror jag de flesta vet vad de skall undvika och vad man kan göra för det är sällan en trivial sak att parallellisera arbeten. Då vet man också att det gäller att minimera mängden synkroniseringspunkter och försöka separera skrivjobben så att trådarna inte skriver till samma ställe mer än där det är absolut nödvändigt. Gör man inte det så kan det snarare blir så att koden blir långsammare, i vart fall kan det vara svårt att skala prestandaökning med mängden kärnor

Inte säker på att jag förstår men det exempel du ger här är ger C/C++ en mycket stor prestandafördel.

För att ta ett exempel. Låt säga att någon skall skriva en parser, kanske kommaseparerad textfil (CSV) eller XML fil. Gör man den i java måste man använda endast java (inte något i biblioteket skrivet i C++) medan C++ måste använda 100% C++
Tror inte det är några större problem att få C++ nära 5 gånger så snabb som javakoden för XML och kanske 2-3 gånger snabbare för CSV

Jeg har ikke satt meg inn i alt som diskuteres her. Men kan komme med mine synspunkt da jeg har jobbet med programmering i ca. 15-16år nå. Jeg behersker C/C++/C#/JAVA, og for det meste går det i C# i disse dager.

C bruker jeg til å programmere mikrokontrollere. Der timing er kritisk så går det da i ASM i tillegg til C.

C++ bruker jeg veldig sjelden utenom der lowlevel er nødvendig. Da som regel DLL bibliotek som jeg bruker i C#.

C# bruker jeg til alt av Windows/ASP programmering.

JAVA har utgått for min del for ganske mange år siden. (J2ME)

Nå er det sånn at jeg lager apper veldig mye raskere i C# enn i C++ så de har to forskjellige bruksområder for meg. Samtidig når man jobber med programmering så er effektivitet viktig, og da sitter man ikke å koder i C++.

Man har ofta ett val mellan att skriva ett fåtal rader okomplicerad kod som löser ett problem eller ett skriva fler rader komplicerad kod som löser samma problem lite snabbare. Eftersom du reflekterar över att det finns programmerare med olika kompetens så inser du också att det ena är mer krävande än det andra.

Kostnaden för att skriva ny kod kan man leva med. Det är värre när koden skall ändras för att möta nya krav. Den enkla koden är lätt att ändra utan att den blir bättre eller sämre än vad den var innan. Optimerad kod förlorad i regel sin optimalitet även vid mindre förändringar. Det räcker inte att lägga till den där raden som fattades, utan man får gå igenom hela funktionen igen och fundera över om alla alignments osv fortfarande är optimala. Det gör att kostnaden för att underhålla sådan kod är mångdubbelt högre.

I ett litet program så utgår du ifrån vilka algoritmer som skall köra och skapar datamodellen därefter. Då kan du anpassa datamodellen för ett bra flöde. Större program byggs i omvänd ordning. Först skapar man en modell över den verksamhet man skall hantera i programmet. I nästa steg skriver man programkoden. Eftersom det senare involverar många utvecklare som arbetar parallellt, så är det svårt att i efterhand göra om datamodellen för att möta enskilda komponenters behov. Normalt har man fullt upp med att hitta rätt accessvägar utan att ens tänka på sådant som dataflöde på hårdvarunivå.

Ja, den inbyggda skillnaden har förmodligen större signifikans än sådant man själv normalt kan påverka.

Större program, och då menar jag allt från större appar på mobiltelefonen, är i regel skrivna i fler än ett språk. Även program som är skrivna i Java använder bibliotek skrivna i C/C++ genom jni-bindningar. I slutänden är alla systemanrop definierade i C, vilket gör att man inte kan öppna en fil eller rita en pixel på skärmen utan att ta den vägen. Antingen genom att man använder Javas standardbibliotek eller skriver bindningarna själv.

Och det är väl en ganska glasklar förklaring till varför C++ alltid är snabbare än Java. De enda gångerna Java vinner är när någon lyckas skapa något idiotiskt exempel som aldrig inträffar.

Angående kompetens mm

Min uppfattning är att yrket programmerare har förändrats ganska radikalt om man tar ett spann på kanske 30 år. Förr programmerade man, skulle något göras vad det bara att hugga i och skriva logiken. Idag spenderar många programmerare mest tid på att leta färdig kod för att pussla ihop.

En pusselprogrammerare tror jag har svårt att hantera logik i kod överhuvud taget. De programmerare som klarar skriva logiken har inga större problem att läsa kommentarer och det är sällan speciellt svårt att beskriva om man behöver optimera. Det svåra är inte att tyda koden, men om man inte kommenterar eller gör det tydligt så kan det vara svårt och begripa en lösning där det ser lite udda ut men där syftet är att anpassa sig efter processorns sätt att arbeta, inte funktionaliteten i programmet.

Isåfall är trådning ett bra mycket större problem kompetensmässigt, det kan vara riktigt knivigt och går att trassla till ordentligt om det inte är någon erfaren och duktig programmerare som håller i det hela

Jo men jag argumenterar inte för de generella fallen.
Det är ju rätt döfött, det fattar vem som helst som programmerat i C.
Vad jag är ute efter är just de speciella fallen.
Det är de som intresserar mig och har alltid gjort.

Jag började ju programmera när man satt och räknade klockcykler för anrop när man optimerade koden och man kunde t.ex veckla ut en hel loop när det vart tidskritiskt. Så det var nog där jag plockade upp intresset för det lite udda exemplen som gjorde koden snabbare och det hänger med än idag.

Vi börjar ju få upp cacher på 256k för t.ex en i7 i L2 cachen, 8 MB för L3an, är det väl, det räcker gott och väl för ett enklare styrsystem som känner av t.ex ett gäng givare och om några ventiler är öppna eller slutna mot ett controllerkort och kan reglera dessa. Och är det, som de hävdar, att man kan trycka in interpreteraren i cachen och får plats med datan, om det nu går med java, för forth funkar det tydligen så då kommer det ju gå undan.

Oops, nej inte glömt (skall inte vara med om jag minns rätt). gammal kod jag plockade fram där jag ville kolla skillnaden på den strlen som man normalt använder och hur assemblern samt prestanda vart när man skrev ungefär samma sak i C++

En i7 på uppåt 10 A som kostar tusen gånger mer än en cortex m0 eller en atmega dom drar mA eller uA för att reglera några ventiler? Lycka till med den affärsplanen.

Forth går inte att jämföra med Java, det är ett extremt simpelt språk som man kan implementera i några hundra rader assembly. Själva programkoden i Forth tar också väldigt lite plats, speciellt om det är token threaded (då kan man t om få det mindre än ren maskinkod)