Som svar på den ursprungliga frågan ...
... tycker jag att det finns två sätt att se det. Tycker du programmering och hårdvara är kul ska du fundera på att välja ett språk med lägre nivå. C är ett bra ställe att börja. Jag började själv med Basic sedan Fortran och sedan assembler. Sedan blev det PL/M och assembler igen. Sedan 20 år tillbaka är det mest C men assemblern har jag stor nytta av i t ex debugging och för att interfacea mina C-program mot speciell CPU-funktionalitet som t ex blockinstruktionerna. Jag arbetar både mot IT-branschen och mot inbyggda system.
Tycker du hårdvara är jobbigt så välj ett språk som är lite längre bort som t ex C# och Java.
Sedan 10 år kan jag inte längre skriva assemblerkod som är snabbare än vad min kompilator (OpenWatcom) kan generera :(. Däremot tror jag att jag vet jag hur jag ska uttrycka mig i C för att kompilatorn ska kunna göra snabbast möjliga assemblerkod av det :). Med detta sagt menar jag inte att jag skriver program som inte går att förstå eller underhålla.
Det är lättare att bli riktigt duktig i C än i C++. Jag kan ärligt säga att jag bara träffat en riktig superstar i C++, samma sak i C (tyvärr inte jag ). Men steget under är det betydligt mer tunnsått på C++ folk.
À propos algoritm kontra programmeringsteknik. För ett tag sedan skulle jag implementera en multitrådad RAM-baserad sorteringsalgoritm som skulle exekvera på ett multikärnesystem. Jag fann, ev felaktigt, att en Shell-sort skulle vara lättare att implementera än en Quick-sort. I enkeltrådad form är det inte jättestor skillnad i prestanda mellan dem, några tiotals procent.
Mitt testdata bestod av en miljon unika poster sorterade i stigande ordning. Testet var att sortera den (logiskt, med index) i fallande ordning alltså sista posten ska vara först och tvärtom.
Sagt och gjort. Jag började med att dela upp Shell-sorten så att varje kärna sköter en del av arbetet. Körde med tidtagning och vad fann jag? Att den multitrådade versionen behövde 32% längre tid att exekvera än den enkeltrådade.
Eftersom jag inte gärna ville tro att en multitrådad Shell-sort inte kunde vara snabbare än en enkeltrådad började jag analysera. Det visade sig att ett problem hade med sorteringstatistiken att göra: trådarna krockade när de skulle inkrementera samma statistikvariabler (ncompares och nswaps). En annan sak var att jobben som fördelades ut till resp tråd inte var cacheanpassade och dessutom på två olika sätt.
Jag har nu en snabb Shell-sort som blir snabbare ända upp till tre samtidiga trådar, sedan blir den långsammare igen. På en Core 2 Quad Q9300 och tre trådar sorterar den en miljon poster på 0,7 sekunder vilket jag är nöjd med.
Vad vill jag säga med detta? Jo hade jag inte varit intresserad och kunnig i assembler, hårdvara och prestanda hade jag inte vetat var jag skulle börja angripa multitrådningsproblematiken. Att sorteringstatistiken var en bov i sammanhanget var en riktig slamkrypare.
Bara för att man har en bra algoritm att utgå ifrån betyder det inte att vem som helst kan göra en kompetent implementation av den. Det omvända är också sant: det går att göra programmeringstekniskt och prestandamässigt mycket kompetenta implementationer av dåliga algoritmer. Vitsen är att göra en kanonimplementation av en bra algoritm.
Så gosh, var du än är, så har du mer rätt än du får credit för.
