Inlägg

Jag har köpt Erlang-boken men inte gjort mer än att läsa om språket än. Mitt intryck är att det är ett domänspecifikt språk snarare än ett generellt användbart språk. Men nästa gång jag ska skriva en server eller liknande för personligt bruk är det troligt att jag ger Erlang en chans.

Förhoppningsvis kommer de grejer som är bra med Erlang att tas med i andra framtida språk som är mindre nischade.

Hur mycket trafik per månad har du då?

Jag funderar på att starta upp en site med syfte att få in pengar via AdSense, men jag vet inte hur mycket trafik som behövs för att tjäna tillräckligt mycket för att motivera besväret.

Grejen är att du ibland är tvungen att använda länkade datastrukturer pga hur ditt problem ser ut och för att få vissa garantier när det gäller tidskomplexiteten. Dessa datastrukturer hanteras dåligt med nuvarande tekniker men en teknik som fungerar ganska bra är att ändra layouten, dvs vilka objekt som ligger intill varandra. Detta kan en garbage collector göra åt dig. Det finns garbage collectors till C++ som kan göra detta, men de kan inte göra det lika väl som Java pga skillnader i hur språken är uppbyggda.

Jag kommer antagligen inte att skriva så mycket mer i den här tråden nu så jag sammanfattar kärnan i det jag har skrivit om i de senaste inläggen:

Många optimeringar går inte att utföra lika bra för C som för Java eller liknande språk på grund av hur språken är uppbyggda. Ett av de största problemen är aliasing. Om en optimering som är viktig för ditt program går att utföra när programmet formuleras i Java men inte i C++ så kan det vara så att du får bättre prestanda med Java. Att c-programmerare tvingas koda mot minsta gemensamma nämnare medans Java-program kan dra fördel av hårdvara som inte ens fanns när programmet skrevs är ännu en stor fördel för Java.

Detta handlar ofta om specialfall -- i de flesta fall är verkligen C++ snabbare. Men C++ är inte alltid snabbare, vilket var vad jag invände emot.

Spatial och temporal lokalitet är centrala begrepp för alla som jobbar med optimering; Därför tog jag för givet att du kände till dem. Se nedanstående länkar för förklaringar. Om det är några fler ord jag har använt som du undrar över så får du fråga eller googla själv.

Det finns för dålig information om prestandaoptimering på den här nivån för att det ska gå att hålla sig till svenska, så du får nöja dig med engelska länkar.

http://en.wikipedia.org/wiki/Locality_of_reference
http://groups.google.com/group/comp.lang.asm.x86/browse_threa...
http://en.wikipedia.org/wiki/Alias_analysis
Sök även på "pointer-chasing code" för beskrivningar av problemet jag pratar om.

Det jag menar är att det pga aliasing och låg typsäkerhet är svårt att flytta minne i C men inte i t.ex. Java. Detta medför att det inte går att flytta om noderna i länkade datastrukturer på ett sätt som gör att noder som accessas efter varandra läggs efter varandra i minnet. Eftersom iterationsordningen inte är känd vid compile-time och antagligen inte är konstant hela tiden så behövs det runtimestöd för detta. Java gör detta automatiskt utan att programmeraren behöver göra något själv eller ändra sin kod. Detta är möjligt pga Javas semantik och pga att koden kan optimeras vid runtime. Det har alltså inte med programmerarnas kompetens att göra.

Eftersom dessa tekniker inte är applicerbara i lika hög grad för C och andra äldre språk så har forskarna utvecklat flera andra metoder för att prefetcha data istället. Men dessa tekniker behöver av tidigare angivna skäl också runtimeinformation. Därav tekniker som Speculative precomputation, som alltså innebär att man försöker optimera vid runtime i hård- eller mjukvaruform genom att prefetcha data till cachen.

Dessa tekniker är dock inte lika effektiva som att arrangera om datastrukturerna efter deras traverseringsmönster, eftersom det är svårt att förutse hur olika grenar ska falla ut även med runtimeinformation. Och om man ändå ska optimera vid runtime kan man ju lika gärna använda Java som designades för det från början.

edit: nu börjar arbetsveckan och då kommer jag inte ha tid att diskutera lika mycket.

Du kände inte till prefetchinstruktioner, trodde att tillägg i instruktionsuppsättningen var något ovanligt, kände inte till speculative precomputation eller vad länkade datastrukturer har för cache-egenskaper, men ändå säger du att jag ska uppdatera mig?

Det du pratar om här är spatial lokalitet. Den hjälper dig inte att få in nästa objekt i cachen om inte objekten ligger intill varandra. Om iterationsordningen ändras så förlorar du även den temporala lokaliteten.

Ja, det har jag. Jag tror att de flesta kan se på vad jag har skrivit i tråden att jag "har en aning om vad jag pratar om".

Mitt förra inlägg var antagligen inte tillräckligt välstrukturerat för du verkar helt ha missat budskapet. Eftersom iterationsordningen inte är känd eller konstant så går det inte att förlita sig helt på statisk information. Det har ingenting med programmerarnas kompetens att göra. Det är därför Intel och andra företag/forskare har undersökt tekniker som Speculative Precomputation för användning även i C-program. Har du någon anledning att tvivla på Intels bedömning?

Layouten av enskilda medlemsvariabler har ingenting med saken att göra. Det är layouten i minnet av objekten, inte medlemsvariablerna, det handlar om.

Prefetchinstruktioner liknar mov-instruktioner, med skillnaden att datan laddas till någon cache-nivå och inte till register eller main memory (eller ignoreras helt, eftersom processorn som sagt vanligtvis ser dem som tips). Det är en av de tekniker processortillverkarna började erbjuda när problemen med minneslatens blev stora i mitten på nittiotalet. Kolla i t.ex. Intels manualer för detaljer, de finns att läsa gratis på nätet.

Din fråga om storleken på ett objekt förstår jag inte meningen med. Det är inte en manuell teknik jag skriver om. Den virtuella maskinen håller givetvis reda på storleken på varje objekt, men varför jag som programmerare skulle behöva en sizeof i det här sammanhanget förstår jag inte.

Jag tänker inte sitta och googla fram kod åt dig, men jag kan ta ett generellt exempel. Ponera att du har ett problem som kräver att du använder en länkad datastruktur (t.ex. ett träd eller en graf) och att behandling av den är en central del av ditt program.

Om den innehåller mycket data så kommer cachemissar att vara ett stort prestandaproblem för det här programmet, eftersom länkade datastrukturer har notoriskt dålig spatial lokalitet. För att lösa detta kan man försöka arrangera datastrukturen på ett sätt som motsvarar iterationsordningen (om man vet att nod B alltid accessas efter nod A så kan man allokera B intill A), men om denna inte är känd eller skiftar under programmets körning så måste man antingen ordna om datastrukturen under körningen eller använda prefetchinstruktioner om processorn stödjer det. Att försöka upprätthålla en viss nodlayout medför dessutom problem med insättning och borttagning av noder.

Prefetchinstruktioner fungerar inte lika bra som att arrangera datan spatialt, eftersom man ofta tvingas använda någon heuristik för att avgöra vad man ska prefetcha (t.ex. alla barn till nuvarande nod), vilket leder till att man prefetchar mer data än nödvändigt. Processorn ignorerar dessutom ofta prefetchinstruktioner eftersom de ses som tips och inte krav.

Att C tillåter godtyckliga pekare och inte är typsäkert gör att kompilatorn inte kan hitta alla alias för en given minnesposition. Detta medför i sin tur att det inte går att flytta datan till en ny plats. I språk som Java går det däremot att flytta objekt, eftersom alla pekare till varje objekt är kända och kan uppdateras med den nya addressen. Därför kan objekten packas ihop på ett sätt som förbättrar cacheprestandan, och eventuellt packas om ifall iterationsordningen skiftar men är fasbetonad.

En lösning på problemen med traversering av länkade datastrukturer som används av C-kompilatorer är faktiskt runtimeoptimering. Googla t.ex. på Speculative precomputation som används i Intels kompilator.

Först och främst vill jag betona att jag inte påstår att Java alltid har bättre prestanda, eller ens att det särskilt ofta är så. Det jag argumenterar emot är ditt påstående att Java aldrig kan vinna över C.

Det krävs inte att man jämför med gamla C-kompilatorer. Allt som krävs är att du inte vet exakt vilken processor kunden har eller att inte alla kunder har samma processor, för att du ska vara tvungen att antingen koda mot minsta gemensamma nämnare eller själv skriva olika funktioner för olika processorer och välja någon av dem vid runtime (vilket skulle innebära ökad komplexitet och testkostnad).

Det är inte ovanligt att det kommer utökningar av instruktionsuppsättningen, speciellt inte på x86. MMX kom 1997, SSE 1999, SSE2 2000, SSE4 2006. Utöver detta så skiljer sig rekommendationerna om hur man ska optimera från modell till modell och från tillverkare till tillverkare. Många mjukvarusystem har livstider på mer än ett årtionde.

Javakoden kan vara likartad med C++-koden men ändå dra bättre fördel av hårdvaran. I de fall då koden ska köra länge så minskar de flesta av Javas nackdelar (tiden för runtimekompileringen t.ex) i betydelse. Nu när det blir vanligare med multicore kommer det dessutom att gå att lägga ut optimeringsuppgifter på andra cores, vilket kan göra det möjligt att göra tunga optimeringar oftare eftersom det då krockar mindre med själva javaprogrammet (om det är enkeltrådat).

Det är inte heller så att den kontroll som du pratar om alltid är en fördel för C++. Tvärt om kan det göra vissa optimeringar svårare eller rent av omöjliga. Javas typsäkerhet och uteslutning av pekararitmetik möjliggör i vissa fall fler eller kraftfullare optimeringar. Återigen -- om ditt program gör saker som faller inom kategorin av saker som JVM'en kan optimera bättre än C-kompilatorn så kan det hända att Java-koden presterar bättre.

Jodå. Det finns tillfällen då en JVM kan göra optimeringar som inte en C++-kompilator kan göra, eller ens en människa. Om en prestandakritisk del av programmer råkar tillhöra denna kategori så kan det mycket väl hända att det går snabbare med Java.

Antag till exempel att ditt program gör en massa tunga numeriska beräkningar. Antag vidare att du skrev det i C++ före SSE2 var vanligt, eller inte kunde utgå från att alla kunder hade datorer med stöd för SSE2. Då var du tvungen att kompilera koden för minsta gemensamma nämnare, dvs den gamla FPU'n (x87).

En JVM kan däremot optimera koden för den processor som kunden faktiskt har, oavsett om den ens fanns på marknaden när du skrev ditt program. Det gör det möjligt att dra fördel av nya features och nå bättre prestanda.

Det är nonsens, eller trams.

Hehe, det kanske var lite överilat av mig att tillskriva dig den åsikten. Sorry.

Roligt att höra!

Jag håller med om att titeln "civilingenjör" smäller högre än datavetare ute i samhället, men det är en annan sak än den bedömning en initierad person gör. Är man inte själv yrkesverksam inom ett område så har man inte så mycket att gå på utöver titlar och formella beteckningar när man värderar en person. Bland studenter så är det ofta dessutom så att varje sektion odlar en kultur som säger att just vi som har valt den här utbildningen kommer att lyckas bäst. Men det går över när man lämnar universitetet. När man har jobbat ett tag så inser man att kopplingen mellan examina och prestation är väldigt svag.

När man söker sitt första jobb så har de flesta inte så mycket mer än sin examen att visa upp. Då kan det hjälpa att kunna hänvisa till att man är civilingenjör, speciellt om man pratar med en personalvetare eller ekonomutbildad person som inte har möjlighet att bedöma din kompetens. Men de som har mest att säga till om vid anställningen är de som har teknisk kompetens och som du kommer att jobba med eller för. Då gäller det att kunna svara bra på frågor där ren kunskap är avgörande. De kommer inte att bli imponerade av att du är civilingenjör. Civilingenjörer finns det ju i varenda buske nu för tiden.

För löneutvecklingen efter den första anställningen spelar titlar ännu mindre roll. Då gäller det i stället att kunna peka på saker man har åstadkommit eller erfarenhet av.

Det låter lite som om du tror att arbetsgivaren själv sätter priset på arbetet. Så är det inte. Om jag kräver x tusen i månaden för att börja jobba hos någon så ställs de inför valet att förlora mig eller så får de punga ut. Att säga "men vi tycker att du ska jobba för oss för 3000 mindre i månaden för att du inte är civilingenjör" håller liksom inte. Priset (lönen) sätts gemensamt.

Det vore intressant att se statistik på det här. Jag kan tänka mig att ingångslönen är en gnutta högre för civilingenjörer, men det jämnar antagligen ut sig. Flera av de datavetare jag känner har idag löner som ligger över medlet för civilingenjörer med motsvarande erfarenhet.

Vi läste till stor del samma kurser.. Skillnaden var att när civilingenjörerna läste elektronik så fördjupade vi oss i programmering. Dessa fördjupningskurser var inte lätta. Flera av dem var på doktorandnivå.

Kopplingen mellan "svår" utbildning" och "hög kvalitet" finns bara så länge som svårigheten är relevant. Om du skulle tvinga dem att tentera rysk grammatik eller något annat lurigt så skulle de inte bli mycket bättre ingenjörer för det.

Arbetsgivarna är inte så dumma som ni tror. De fattar att skillnaderna mellan datavetare och civilingenjörer är mycket mindre än de individuella skillnaderna. Därför handlar urvalsprocessen och löneförhandlingarna mer om personer än om examina. Det är bara att titta i annonserna - - civilingenjör eller motsvarande sökes står det för det mesta.

Om ni vill fortsätta att diskutera det här så vore det kul om ni försökte stödja era påståenden mer med erfarenhet eller fakta istället för att vädra fördomar. För det är väl det det handlar om? Ni förknippar en fin titel med prestige och tar för givet att denna prestige speglas i lönerna.

Varför skulle du betala mer för en civilare då? Det är ingen skillnad i kompetens när det gäller mjukvara. Möjligtvis har datavetarna lite övertag.

De arbetsgivare jag har pratat med har inte gjort någon skillnad på datavetare och civilingenjörer. Har inte märkt någon löneskillnad mellan civilingenjörer och datavetare bland kollegor eller kompisar heller. Examen spelar hur som helst mest roll när du söker ditt första jobb, sedan är det erfarenhet som avgör.

Jag gick Datavetenskap på LiU för några år sedan och antar att utbildningen är ungefär densamma fortfarande.

Kort sagt är det varken webbprogrammering eller programutveckling man lär sig på Datavetenskap, utan datavetenskaplig teori. Utbildningen är alltså inte inriktad på att lära studenterna praktiska färdigheter som hur man använder olika verktyg/språk eller olika projektmodeller, även om det går att välja sådana kurser också.

Om du är intresserad av en forskningskarriär eller verkligen vill lära dig programmering på djupet så är Datavetenskap kanske rätt för dig. Om du mest vill ha ett jobb och egentligen inte "brinner" för programmering så finns det nog andra program som passar dig bättre.

Antag till exempel att du vill lära dig allt om hur programmeringsspråk fungerar och implementeras. Då kan du inom ramen för Datavetenskap lära dig hur man bygger en egen kompilator eller hur man med hjälp av matematiska modeller för ett programmeringsspråk kan bevisa olika egenskaper för program skrivna i språket. På mer praktiskt orienterade utbildningar handler det istället mer om hur man använder språket, plus att de ofta innehåller fler traditionella ingenjörskurser som mekanik.

Här är några saker som jag tycker var bra respektive dåliga med Datavetenskap:

plus:
* man kan fokusera på datavetenskap och skippa elektronik och andra traditionella ingenjörskurser. Det ger dig mer tid för fördjupning.
* Pga alla valfria kurser så blir det lite så att man komponerar sin egen utbildning. Detta kan leda till att man lär sig att ta mer ansvar själv och blir mer självständig

minus:
* Det är lätt att välja för många teorikurser vilket leder till att man inte får ihop så många praktiska färdigheter att skriva i sin CV
* Andra program verkade från utsidan vara mer genomtänka. En del kurser var designade för studenter från andra program med andra förkunskaper bakom sig (jag saknade t.ex. förkunskaper som aldrig förklarades i en kurs eftersom de andra redan kunde det från en tidigare kurs).

Kort sagt: välj Datavetenskap om du vill bli jävligt bra på programmering och är mogen nog att kunna hantera valfriheten. Om du är intresserad på riktigt så lär du dig den praktiska biten ändå (på fritiden eller genom att välja sådana kurser. Din djupa teoretiska förståelse hjälper dig såklart även med den praktiska biten).

Om det är webbdesign och webbprogrammering du är intresserad av så är nog inte Datavetenskap rätt utbildning eftersom dessa yrken inte kräver mycket teoretisk kunskap.

Angående löner så tror jag att Azoapes är för pessimistisk: 24000-28000 som ingångslön efter datavetenskap stämmer nog bättre.

Det finns många sätt för en kompilator att koda switchsatser på. Vanligast är antagligen jumptables när case-alternativen bildar en hyfsat tät tabell. Om tabellen skulle bli för gles så kan kompilatorn välja att generera en sorterad tabell för binärsökning istället, eller en rak kedja av if-satser.

En jumptable är en tabell som innehåller en post för varje tal mellan det case-alternativ med lägst nummer och det med högst nummer. Varje post innehåller offsetten till koden för motsvarande case. På detta vis kan man hitta rätt kodblock på konstant tid (istället för linjär tid som med en kedja av if-satser) genom att använda värdet av villkorsuttrycket som index till tabellen.

edit:
Här är en länk med mer info: www.cs.jcu.edu.au/ftp/pub/techreports/94-3.ps.gz

Skulle du inte kunna göra en polygon eller path (polygon där en edge kan vara en bezierkurva) av linjen istället? Då kan du ju använda din kod för tunna linjer för att rita konturerna med AA, men rita innanmätet av linjen genom att fylla polygonen.

Hej.

Jag får intrycket av att du är väldigt fokuserad på att göra rätt hela tiden och på att memorera detaljer som vad olika förkortningar står för. Mitt främsta råd till dig är att försöka sluta hänga upp dig på sådant och istället bara kasta dig in i smeten med huvudet före. Nybörjare tror ofta att det är väldigt viktigt att välja rätt språk från början, men det viktigaste är att börja över huvud taget. Välj något bara och sätt igång! Det räcker ändå inte med att kunna bara ett programmeringsspråk. Se till att göra massor med misstag för det är det du lär dig mest av

Python är antagligen ett bra språk att börja med. Basic skulle jag däremot inte rekommendera eftersom det ger dåliga vanor och antagligen inte har en ljus framtid.

Det finns inget språk som är "mest allsidigt" eller bäst för alla situationer. Olika verktyg har olika användningsområden.

Java och C# är antagligen de språk som är mest eftertraktade på arbetsmarknaden just nu, men när du är färdigutbildad programmerare kan det ha ändrats.

I princip alla språk kräver att du har saker installerade på datorn för att kunna köra dem. Skillnaden är om de kommer förinstallerade med Windows (som libbarna för C) eller om använderaren måste installera saker själv (som Java).

Ja, det går oftast att blanda olika språk på olika sätt.

En kompilator är ett program som översätter källkoden för andra program till maskinkod som kan köras direkt på processorn. En decompiler försöker göra motsatsen (omvandla maskinkod till något som är lättare att läsa för människor).

En assembler är en kompilator som översätter källkod i ett assemblerspråk till motsvarande maskinkod.

En tolk/interpreter är ett program som kör ett annat program genom att själv utföra det andra programmets instruktioner. Tolken har hela tiden kontrollen och det tolkade programmet körs inte direkt på processorn.

För många språk finns det flera kompilatorer att välja på. För andra språk finns det bara en. Vissa kostar pengar och andra inte.

Nu orkar jag inte svara på fler frågor. Godnatt.

Det är mycket lättare att börja med Python än med C++.

Jag jobbar som programmerare sedan några år, men inte inom spelbranschen. Anledningen till att jag inte nämnde C++ är dels att det är för likt Java, vilket du ju redan kan, och dels att jag inte gillar språket (trots att jag jobbar mycket med det). Många nybörjare gör misstaget att tro att komplicerat och svårt är detsamma som avancerat och kraftfullt. Fall inte i den fällan. C++ är kraftfullt, men också onödigt snårigt av historiska skäl. Samtidigt finns det inga bättre alternativ än C++ för vissa typer av problem, så förr eller senare kommer du antagligen att behöva lära dig det, men du behöver inte ha bråttom dit.

De flesta programmerare använder nästan ingen matte alls i jobbet skulle jag tro, men som spelprogrammerare behövs det nog en del. Jag håller helt med din far.

.