Varför är inte tyngre spel skrivna i Java?

Permalänk

Varför är inte tyngre spel skrivna i Java?

Hej som titeln lyder undrar jag varför inte tyngre spel så som Sim City, Crysis etc är skrivna i java.
Antar att det har något med att de körs i en Virtual machine att göra men är det något annat?

Skickades från m.sweclockers.com

Visa signatur

Att programmera eller att inte programmera, det är frågan?

Permalänk
Medlem

Snabb sökning gav dessa svar:

Citat:

The game development world is a funny one: On one hand, they're often quick to accept new ideas, on the other hand, they're still in the stone age.

The truth is, there's rarely that much incentive in switching to .NET/Java/anything other than C/C++.

Most game companies license parts of the game engine from other companies. These parts are written in C++, and although you might have access to the source so you could port it, that takes a lot of effort (and of course, the license needs to allow it).

Also, a lot of legacy code already exists in C++. If code from previous projects can be reused (say, if you're writing a sequel), that counts even more in favor of sticking with the same language, instead of rewriting it in a new language (more so since you'll likely reintroduce a ton of bugs which you'll need to spend time ironing out.

Finally, it's rare for games to be written in 100% C++ anyway - a lot is done using scripting languages, whether they're custom or just integrating an existing languages (Lua being one of the more popular ones these days).

As far as garbage collection is concerned, that can be a bit of a problem. The problem is not so much that it exists, it's more how it works - the garbage collector MUST be non-blocking (or at least be guaranteed to only block very briefly), since it's simply unacceptable to have the game freeze for 10 seconds while it scans all the allocated memory to see what can be freed. I know Java tends to choke quite a bit in GC'ing when it's close to running out of memory (and for some games out there, it will).

You're also a bit more restricted in what you can do: you can't fully exploit the hardware due to the overhead of the runtime. Imagine Crysis being written in Java... even if that's the only visible difference, it just wouldn't be the same (I'm also pretty sure you'd need a Core i7 to run it.).

This doesn't mean these languages don't have their place in game development - and no, I'm not just referring to tool programming. For most games, you don't need that extra bit of performance you get from C++, including 3D games, and if you're writing it all from scratch, it can make perfect sense to use something like XNA - in fact, there's a good chance it will.

As far as commercial games are concerned - does RuneScape count? That may well be the most succesful Java game out there.

Källa till ovan: https://stackoverflow.com/questions/1034458/why-arent-video-g...

Citat:

Several reasons:

In the old days, you needed "direct access" for performance and UI. This predates JVM languages like Java and C#.
Most consoles (e.g., 360, PS3) do not have a JVM, so you cannot reuse code from the PC version. It is much easier to compile C++ code to support various devices.
Most mainstream game engines (e.g., Unreal) have C++ bindings. There are some Java connectors (e.g., for OpenGL) but nothing like it.
For PC gaming, DirectX doesn't really have strong Java support (if at all).
Web based games run in JavaScript or Flash. You could write them in Java though using things like GWT.
The iPhone runs an Objective-C variant.
Java is primarily used in Android games these days, simply because it's the primary language for that platform.

Källa till ovan: https://programmers.stackexchange.com/questions/55104/why-isn...

Permalänk
Medlem

Prestanda, beprövat, nästa steg från C/ASM (som var förra generationens defaultspråk), befintlig kodmängd, befintliga bibliotek i form av egen kod och tredjehandskod.

Indieutvecklare som inte har en massa befintlig kod är mer benägna att välja språk efter egen smak.

Permalänk

Som tidigare Copy paste:at, så är det inte någon idé att skriva en AAA titel då deras motorer som dom använder är skrivna till C++!

Det nya mobilspelet Deus EX The Fall är ju skrevit i java för android bl.a men där märker man att det diffar en hel från HR!

Vet inte vilket PC versionen bygger på om det är Androids verision eller iOS. simplaste hade väll varit Java verisionen då den går att porta väldigt lätt till pc men det låter jag vara osagt!

Visa signatur

12900K, 48GB DDR5, GTX Titan Xp 12GB

Sugen på att köra e-GPU?

Permalänk
Moderator
Festpilot 2020, Antiallo
Skrivet av kallepårymmen:

Hej som titeln lyder undrar jag varför inte tyngre spel så som Sim City, Crysis etc är skrivna i java.
Antar att det har något med att de körs i en Virtual machine att göra men är det något annat?

Ska göra det simpelt, java är en kod som inte blir färdig kompilierad (omgjord till instruktioner till processorn och operativsystemet att tolka till 100%). Detta gör att även om 90% av koden är klar så måste resterande 10% kompileras on the fly när man kör programmet (precis som du nämner med "virtuell maskin"). Detta ger inte bara prestandapåverkan utan även "dependables". Dvs de som skiljer operativsystem är den delen av koden som är kritisk, inga beräkningar kan göras förrän den kod är kompilerad. Koden kompileras samtidigt som programmet körs och detta är oftast en ganska svårtrådad uppgift, dvs du kan sällan använda mer än 1-2kärnor när java körs.

Där utöver är koden som kompileras långt ifrån optimerad till maskinerna och operativsystemet. Det kanske blir 4-8assemblerinstruktioner för en rad kod Java istället för 1-2assembleinstruktioner. Därutöver skall även koden köras i den virtuella miljön och hantera anrop från operativsystemet.
Så det som tar 6-8klockcykler i C eller C++ (samt annat relativt lågt programmeringsspråk) kan ta i värsta fall upp mot 40-50klockcykler i java. Sedan får man inte glömma nackdelarna med minnesanvändningen som även är högre med java.
Java är en av de språken som ligger väldigt långt från hårdvaran som den körs på, jämfört med C/C++, detta ger dålig kontroll över prestandapåverkande kod, dvs allt som är beroende av väldigt tight exekvering/begränsad minnesanvändning eller helt enkelt kräver ett extremt litet program programmeras oftast i väldigt lågnivåspråk, ibland tom i rena Assembler. Exempel är beräkningsalgoritmer, drivrutiner, bios etc.

Som en liten roligt jämförelse. Det var en kille som skrev ett Pythonprogram som konverterade Python till Java (för de som kunde Python men ville skriva Javaprogram). Och den fungerade, men 3rader pythonkod som skulle tagit kanske en 2-4rader Javakod kom ut som 1500rader efter konverteringen.
En extrem jämförelse men i grund och botten liknande problem.

Oj det blev visst lite längre än planerat.

Att hävda att det är för att alla AAA motorer är skrivna för C/C++ är inte hela historien. Det är en ursäkt, inte en förklaring om man så säger.

Visa signatur

 | PM:a Moderatorerna | Kontaktformuläret | Geeks Discord |
Testpilot, Skribent, Moderator & Geeks Gaming Huvudadmin

Permalänk
Medlem

En annan anledning än de som tagits upp är att GC-språk kräver ohemult mycket RAM om man tar dem som de är (källa). Man kan ju jobba runt det, men då kan man lika gärna köra ett språk som ger en mer direkt kontroll över minneshantering från början.

Visa signatur

.<

Permalänk
Medlem
Skrivet av DavidtheDoom:

Ska göra det simpelt, java är en kod som inte blir färdig kompilierad (omgjord till instruktioner till processorn och operativsystemet att tolka till 100%). Detta gör att även om 90% av koden är klar så måste resterande 10% kompileras on the fly när man kör programmet (precis som du nämner med "virtuell maskin"). Detta ger inte bara prestandapåverkan utan även "dependables". Dvs de som skiljer operativsystem är den delen av koden som är kritisk, inga beräkningar kan göras förrän den kod är kompilerad. Koden kompileras samtidigt som programmet körs och detta är oftast en ganska svårtrådad uppgift, dvs du kan sällan använda mer än 1-2kärnor när java körs.

Där utöver är koden som kompileras långt ifrån optimerad till maskinerna och operativsystemet. Det kanske blir 4-8assemblerinstruktioner för en rad kod Java istället för 1-2assembleinstruktioner. Därutöver skall även koden köras i den virtuella miljön och hantera anrop från operativsystemet.
Så det som tar 6-8klockcykler i C eller C++ (samt annat relativt lågt programmeringsspråk) kan ta i värsta fall upp mot 40-50klockcykler i java. Sedan får man inte glömma nackdelarna med minnesanvändningen som även är högre med java.
Java är en av de språken som ligger väldigt långt från hårdvaran som den körs på, jämfört med C/C++, detta ger dålig kontroll över prestandapåverkande kod, dvs allt som är beroende av väldigt tight exekvering/begränsad minnesanvändning eller helt enkelt kräver ett extremt litet program programmeras oftast i väldigt lågnivåspråk, ibland tom i rena Assembler. Exempel är beräkningsalgoritmer, drivrutiner, bios etc.

Som en liten roligt jämförelse. Det var en kille som skrev ett Pythonprogram som konverterade Python till Java (för de som kunde Python men ville skriva Javaprogram). Och den fungerade, men 3rader pythonkod som skulle tagit kanske en 2-4rader Javakod kom ut som 1500rader efter konverteringen.
En extrem jämförelse men i grund och botten liknande problem.

Oj det blev visst lite längre än planerat.

Att hävda att det är för att alla AAA motorer är skrivna för C/C++ är inte hela historien. Det är en ursäkt, inte en förklaring om man så säger.

Att java inte skulle vara optimerat är fel då java kompileras med jit mot just din dator vilket gör det väldigt optimerat då den vet exact vilken hårdvara du har. Om du har en nyare cpu kommer java att använda dom nya instruktioer som eventuellt inte finns i de äldre. Om man instället ska kompilera innan körning så måste man ta hänsyn till även de äldre cpuerna.
Det krävs ganska många anrop innan java kör dom extrema optimeringarna för funktionen, men det går att lösa detta med smart kodning.

Visa signatur

Macbook Air 13" (2012)

Permalänk
Medlem

DirectX har inte javabindningar från leverantör

Permalänk
Medlem
Skrivet av DavidtheDoom:

Koden kompileras samtidigt som programmet körs och detta är oftast en ganska svårtrådad uppgift, dvs du kan sällan använda mer än 1-2kärnor när java körs.

Där utöver är koden som kompileras långt ifrån optimerad till maskinerna och operativsystemet. Det kanske blir 4-8assemblerinstruktioner för en rad kod Java istället för 1-2assembleinstruktioner. Därutöver skall även koden köras i den virtuella miljön och hantera anrop från operativsystemet.
Så det som tar 6-8klockcykler i C eller C++ (samt annat relativt lågt programmeringsspråk) kan ta i värsta fall upp mot 40-50klockcykler i java. Sedan får man inte glömma nackdelarna med minnesanvändningen som även är högre med java.
Java är en av de språken som ligger väldigt långt från hårdvaran som den körs på, jämfört med C/C++, detta ger dålig kontroll över prestandapåverkande kod, dvs allt som är beroende av väldigt tight exekvering/begränsad minnesanvändning eller helt enkelt kräver ett extremt litet program programmeras oftast i väldigt lågnivåspråk, ibland tom i rena Assembler. Exempel är beräkningsalgoritmer, drivrutiner, bios etc.

Det är inte svårare att göra ett program som trådar bra i Java än i C++ och du är inte alls begränsad till 1-2 kärnor utan kan använda så många du vill.

Koden som kompileras är MER optimerad för hårdvaran än en vanlig C++ binär. Detta för att koden kompileras när programmet körs och kan dra nytta av funktionen som processorn klarar (som t.ex. SSE4) medan C++ koden som kompileras en gång och måste funka på alla processorer kanske måste begränsa sig till SSE2.

Garbage Collectorn är inte heller ett jätteproblem då du inte har råd att skapa en massa skräp oavsett om du själv måste rensa upp det eller om någon annan gör det åt dig.

Permalänk
Medlem
Skrivet av Pie-or-paj:

Koden som kompileras är MER optimerad för hårdvaran än en vanlig C++ binär. Detta för att koden kompileras när programmet körs och kan dra nytta av funktionen som processorn klarar (som t.ex. SSE4) medan C++ koden som kompileras en gång och måste funka på alla processorer kanske måste begränsa sig till SSE2.

Nu kan man ju faktiskt ha olika "code paths" där man kan ha en för "low end" och en annan för "middle" och en för "high end processors" i de sektioner som det lönar sig att ha optimeringar för x86-tillägg.

Permalänk

Utöver det som redan har sagts:
Java saknar användardefinierade "value types". Detta innebär att om Vektorer/Matriser implementeras som klasser så kostar det en minnesallokering på heapen för varje Matris/Vektor som skapas vilket är byggstenarna i 3D grafik. Detta gör Java opraktiskt att användas i 3D grafik.

Permalänk
Datavetare
Skrivet av Pie-or-paj:

Det är inte svårare att göra ett program som trådar bra i Java än i C++ och du är inte alls begränsad till 1-2 kärnor utan kan använda så många du vill.

Koden som kompileras är MER optimerad för hårdvaran än en vanlig C++ binär. Detta för att koden kompileras när programmet körs och kan dra nytta av funktionen som processorn klarar (som t.ex. SSE4) medan C++ koden som kompileras en gång och måste funka på alla processorer kanske måste begränsa sig till SSE2.

Garbage Collectorn är inte heller ett jätteproblem då du inte har råd att skapa en massa skräp oavsett om du själv måste rensa upp det eller om någon annan gör det åt dig.

Problemet med detta är att man (skriver man för det är väldigt många som brukar påpeka just det du skriver) inte jämför äpplen med äpplen här.

I fallet C++ går jag från en beskrivning av programmet med ganska mycket information, C++ källkoden, direkt till maskinkoden på den CPU-arkitektur jag ska köra på.

I fallet Java går jag från en beskrivning av programmet med ganska mycket information till en ny beskrivning på mycket lägre nivå, bytekod. Bytekod vet inget om SIMD (SSE/AVX) så Java-konstruktioner som effektivt skulle kunna använda SSE är nu uppbrutna i flera bytekod instruktioner. JIT-kompilatorn ska nu översätta bytekoden till underliggande maskinkod, viss får den använda vilka instruktioner som helst men input är i princip maskinkod från en rätt simpel maskin så JIT-kompilatorn ska i princip lyckas lura ut de övergripande strukturen för att kunna göra några riktigt bra optimeringar.

Om Java-modellen var bättre skulle man kunna få snabbare C++ program genom att kompilera till säg en generell ARM CPU och sedan använda maskinkodsöversättning från ARM -> x86 där man får använda precis alla instruktioner på den CPU-modell man faktiskt kör på och tro att det blir snabbare. Faktum är att Android x86 exakt gör detta i fallen när NDK-kod sakar x86, man når faktiskt 85-95% av hastigheten mot att direkt gå till x86 men det är <100%.

Sedan så utför varken Javas eller C#s JIT-kompilatorer den optimering du beskriver.

Den optimering som Java dock utför, men .Net inte utför för tillfället, är att byta ut virtuella funktionsanrop (anrop via funktionspekare) till direkta anrop. DET är en stor optimering och förklaringen till varför Java idag i vissa fall kan vara flera gånger snabbare än C#. Samma sak förklarar också varför std::sort() är runt dubbelt så snabb som qsort() i C och standard sort i Java/C#, alla de senare måste använda funktionspekare i sin compare funktion medan C++ baserar sitt på templates så att kompilatorn kan eliminera alla virtuella funktioner.

Skrivet av Sven slaggare:

Utöver det som redan har sagts:
Java saknar användardefinierade "value types". Detta innebär att om Vektorer/Matriser implementeras som klasser så kostar det en minnesallokering på heapen för varje Matris/Vektor som skapas vilket är byggstenarna i 3D grafik. Detta gör Java opraktiskt att användas i 3D grafik.

Exakt, allt annat som nämns i denna tråd kring skillnader mellan Java/C# och C++ är avrundningsfel jämfört med detta. Och det går längre än så, i C++11 finns flera nya saker som gör det möjligt att använda "value types" i ännu flera fall.

Förutom minnesallokeringen, vad mer är fördelen med "value types"?

En fördel är att man aldrig läcker minne, en annan fördel är att multitrådning är enklare då man jobbar på värden och inte pekare/referenser till någon delad minnesplats som kan kommas åt från flera trådar.

Men allra viktigast är hur C++ lägger saker i minne när man använder "value types", de ligger "på rad" något som leder till att CPU-cachen fungerar mycket mer effektivt än den någonsin kan göra i Java/C# där "collections" av objekt alltid kommer leda till minnesaccesser som är lite var som helst i RAM (sett från CPU-prefetcherns synvinkel).

En bra föreläsning kring detta ges av Herb Sutter här, börjar ca 23min in i videon men hela denna föreläsning är värd att se.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

En bra föreläsning kring detta ges av Herb Sutter här, börjar ca 23min in i videon men hela denna föreläsning är värd att se.

Kaffe och Sutter, lysande sätt att börja morgonen på.

Citat:

This is var, spelled A-U-T-O.

Visa signatur

.<

Permalänk
Medlem

Kan förtälja att på Universitetet i Karlstad har man valt att helt slopa Java i grundutbildningen för data, istället väljer man att fr.o.m. nu satsa på C.

Anledningarna är flera, däribland:
* Elever som lär sig Java som första programspråk har mycket svårare att lära sig andra programspråk som ex. C/lisp/prologue m.m. jämfört med de som börjat med att lära sig C.
* Java ligger långt ifrån verkligheten, det är byggt för att dölja hur datorn arbetar.
* Eleverna lär sig att för att göra något så krävs det bibliotek, i C är detta inte lika omfattande och mycket av det grundläggande skrivs av eleven själv.
* Java slösar mängder med resurser för att utföra beräkningar. Detta dels p.g.a. att koden är halvkompilerad och behöver kompileras före/under körning, dels för att kompilatorn inte utnyttjar de genvägsinskriptioner som finns på ett system bra eller över huvud taget.
* Java är properitärt och kräver licenser för att få köras på olika enheter. (Är det inte du som skrivit koden? Bör inte du få bestämma var den skall få köras?)
* Java anses inte vara ett lika framtidssäkert språk som C. (Delvis av de problem nämnda här)
* Javakompilatorn anses vara en vektor för attack av ett system.

Mer kan nämnas.

Visa signatur

Kör Linux - Yes! We are the 2 percent! And growing... Föreslå inte ens något Windows-exklusivt om jag inte specifikt frågar efter något till Win.
2600K - 18GB RAM - 1TB HDD - 64GB SSD - GTX 650 Ti Boost
Minnesvärda trådar: 1, 2

Permalänk
Medlem
Skrivet av Erwya:

Kan förtälja att på Universitetet i Karlstad har man valt att helt slopa Java i grundutbildningen för data, istället väljer man att fr.o.m. nu satsa på C.

Anledningarna är flera, däribland:
* Elever som lär sig Java som första programspråk har mycket svårare att lära sig andra programspråk som ex. C/lisp/prologue m.m. jämfört med de som börjat med att lära sig C.
* Java ligger långt ifrån verkligheten, det är byggt för att dölja hur datorn arbetar.
* Eleverna lär sig att för att göra något så krävs det bibliotek, i C är detta inte lika omfattande och mycket av det grundläggande skrivs av eleven själv.
* Java slösar mängder med resurser för att utföra beräkningar. Detta dels p.g.a. att koden är halvkompilerad och behöver kompileras före/under körning, dels för att kompilatorn inte utnyttjar de genvägsinskriptioner som finns på ett system bra eller över huvud taget.
* Java är properitärt och kräver licenser för att få köras på olika enheter. (Är det inte du som skrivit koden? Bör inte du få bestämma var den skall få köras?)
* Java anses inte vara ett lika framtidssäkert språk som C. (Delvis av de problem nämnda här)
* Javakompilatorn anses vara en vektor för attack av ett system.

Mer kan nämnas.

Även om jag anser att Karlstad har tagit ett rätt okej beslut att slopa java även om det inte är fel med oo-språk som andra språk.
Men jag gillar inte fud och halvsanningar.

* Eleverna lär sig att för att göra något så krävs det bibliotek, i C är detta inte lika omfattande och mycket av det grundläggande skrivs av eleven själv.
Detta är en halvsanning utan dess like då du inte kommer långt utan stdlib men visst det är mer uppenbart i oo.

* Java slösar mängder med resurser för att utföra beräkningar. Detta dels p.g.a. att koden är halvkompilerad och behöver kompileras före/under körning, dels för att kompilatorn inte utnyttjar de genvägsinskriptioner som finns på ett system bra eller över huvud taget.
Visst detta var klart sant innan JIT hur sant det är nu förtiden överlåter jag åt nån annan att utröna men det känns som en halvsanning

* Java är properitärt och kräver licenser för att få köras på olika enheter. (Är det inte du som skrivit koden? Bör inte du få bestämma var den skall få köras?)
Detta är också en halvsanning. Den kod du har skrivit kan du köra på alla plattformar där java finns implementerat utan vidare licenser. Att det kräver licenser för att implementera java på en ny plattform är inte direkt programmerarens problem.

* Java anses inte vara ett lika framtidssäkert språk som C. (Delvis av de problem nämnda här)
Anser vem?

* Javakompilatorn anses vara en vektor för attack av ett system
Detta känns rent felaktigt. JVM:en kan möjligen vara ett attackmål men kompilatorn som generar bytekoden låter som ett mål av samma typ som det Ken Thompson tar upp för c och unix i "Reflections on Trusting Trust"

Permalänk
Hedersmedlem
Skrivet av Erwya:

Kan förtälja att på Universitetet i Karlstad har man valt att helt slopa Java i grundutbildningen för data, istället väljer man att fr.o.m. nu satsa på C.

Anledningarna är flera, däribland:
* Elever som lär sig Java som första programspråk har mycket svårare att lära sig andra programspråk som ex. C/lisp/prologue m.m. jämfört med de som börjat med att lära sig C.
* Java ligger långt ifrån verkligheten, det är byggt för att dölja hur datorn arbetar.
* Eleverna lär sig att för att göra något så krävs det bibliotek, i C är detta inte lika omfattande och mycket av det grundläggande skrivs av eleven själv.
* Java slösar mängder med resurser för att utföra beräkningar. Detta dels p.g.a. att koden är halvkompilerad och behöver kompileras före/under körning, dels för att kompilatorn inte utnyttjar de genvägsinskriptioner som finns på ett system bra eller över huvud taget.
* Java är properitärt och kräver licenser för att få köras på olika enheter. (Är det inte du som skrivit koden? Bör inte du få bestämma var den skall få köras?)
* Java anses inte vara ett lika framtidssäkert språk som C. (Delvis av de problem nämnda här)
* Javakompilatorn anses vara en vektor för attack av ett system.

Mer kan nämnas.

Jag är ingen Javafantast, och tycker specifikt inte att det är en speciellt smidig introduktion till programmering i ljuset av vad som finns, men om de där punkterna var direkta anledningar till att skippa Java så känns det som att de byggde sitt beslut på en blandning av 10–15 år gamla anekdoter och ren ignorans (vilket jag i sig inte har någon anledning att tro skulle vara fallet, så deras resonemang såg nog annorlunda ut).

Att en datateknolog kan ha nytta av att tidigt lära sig ett mer hårdvarunära språk är det enda som känns relevant och inte helt eller delvis felaktigt (men om argumentet tillåts stå ensamt så måste ju assemblyspråk vara det enda rätta); samtidigt så är en "Introduktion till programmering" på högskolenivå ofta en uppsamlingskurs från "Hello, world"-nivå, och de kommer säkert läsa andra kurser som mer specifikt lär ut C.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem

Men om vi öppnar ögonen för andra programspråk än just Java, vilka andra programspråk kan man tänka sig ge bra prestanda förutom C och C++? Låt oss säga att man kan starta utvecklingen från scratch.

Permalänk
Skrivet av phz:

Att en datateknolog kan ha nytta av att tidigt lära sig ett mer hårdvarunära språk är det enda som känns relevant och inte helt eller delvis felaktigt (men om argumentet tillåts stå ensamt så måste ju assemblyspråk vara det enda rätta); samtidigt så är en "Introduktion till programmering" på högskolenivå ofta en uppsamlingskurs från "Hello, world"-nivå, och de kommer säkert läsa andra kurser som mer specifikt lär ut C.

Man kan också resonera att det blir mindre intressant att veta hur "datorn" fungerar, och mer intressant att lära sig hur VM:en funkar. Att lära sig förstå bytekod på JVM:en eller MSIL är inte direkt mer högnivå än assembly.

Visa signatur

System.out.print(madness ? this.is.SPARTA : "");

Permalänk
Datavetare
Skrivet av ronnylov:

Men om vi öppnar ögonen för andra programspråk än just Java, vilka andra programspråk kan man tänka sig ge bra prestanda förutom C och C++? Låt oss säga att man kan starta utvecklingen från scratch.

Beror på vad du ska göra, trist svar men så är det.

Om vi skippar assembler, det är inget som används i mer än extremfall idag, så är det bara C och C++ som ger den kontroll som behövs för att kunna göra en rad optimeringar som kan ge rejäla prestandavinster framförallt på multi-core system.

Om man vidgar vyerna från spel så kan man få riktigt imponerande prestanda med Go och Erlang i de fall programmet gör mycket I/O och framförallt om man måste hålla reda på stora mängder samtida sessioner. Går att göra samma sak i C, C++ och även Java men kräver långt mer från programmeraren för att nå samma prestanda.

För matematiska beräkningar är det inget, inklusive C & C++, som slår Fortran. Men rent generellt är Fortran ett rätt föråldrat språk som är svårt att hantera.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Beror på vad du ska göra, trist svar men så är det.

Om vi skippar assembler, det är inget som används i mer än extremfall idag, så är det bara C och C++ som ger den kontroll som behövs för att kunna göra en rad optimeringar som kan ge rejäla prestandavinster framförallt på multi-core system.

Om man vidgar vyerna från spel så kan man få riktigt imponerande prestanda med Go och Erlang i de fall programmet gör mycket I/O och framförallt om man måste hålla reda på stora mängder samtida sessioner. Går att göra samma sak i C, C++ och även Java men kräver långt mer från programmeraren för att nå samma prestanda.

För matematiska beräkningar är det inget, inklusive C & C++, som slår Fortran. Men rent generellt är Fortran ett rätt föråldrat språk som är svårt att hantera.

Tack för svaret. Googlade lite och hittade även språket D som verkar kunna ge bra prestanda i vissa fall.

Permalänk
Medlem

Känns som jag framstår som en lögnare på tonen i alusers kommentar, men jag hittar inget konkret. Definiera halvsanning, vad är korrekt eller felaktigt?

Jag ser däremot ett felaktigt motargument gällande licenser. Datorer är redan automatiskt licensierade med gratislicenser vilket jag antar att Swecare redan vet. Hade det inte funnits en licens för en enhet hade det varit olagligt att köra Java på den.

Att det inte skulle drabba programmeraren är också felaktigt. Det gör det även om det inte är direkt riktat dit. T.ex kan de som skall välja ett system välja bort Java p.g.a. licenskostnader. Får inte programmeraren mindre profit på de programvaror hen säljer i Java då? Om det är ett företag emellan kan man börja tala om att större händelser som minskade chanser att få jobb samt nedskärningar blir vanligare.

------------------

Det är intressant att D nämns. Jag har lite nyfiket tittat på programspråket. Det intressanta i sammanhanget är att det utvecklas som open source vilket inte C gjorde från början. Det har också en dynamik som skall tillåta användaren både att programmera i assemblerkod men också mer på högre nivå. Det har bättre stöd för Unicode vilket jag upplever som hemskt att arbeta med i C.

Det har utvecklats med inspiration både från C/C++ och Java så jag tror att det kommer att passa en mycket bred programmerargrupp i framtiden. Dessutom skippar man den halvkompilerade koden för att istället kompilera den direkt till det system det är avsett att köras på. Jag tror att många duktiga Javaprogrammerare kommer ha glädje av programspråket, dels för den ökade prestandan det ger med helkompilerad kod men även dels för att de slipper problemet med att det står ett företag bakom kulissen som tickar in pengar på deras prestationer.

D har utvecklats mycket snabbt de senaste tre åren och nu kan det vara dags att seriöst börja arbeta med det. Förra gången jag kollade på det kändes det inte riktigt redo än.

Visa signatur

Kör Linux - Yes! We are the 2 percent! And growing... Föreslå inte ens något Windows-exklusivt om jag inte specifikt frågar efter något till Win.
2600K - 18GB RAM - 1TB HDD - 64GB SSD - GTX 650 Ti Boost
Minnesvärda trådar: 1, 2

Permalänk
Medlem
Skrivet av Erwya:

Känns som jag framstår som en lögnare på tonen i alusers kommentar, men jag hittar inget konkret. Definiera halvsanning, vad är korrekt eller felaktigt?

Jag ser däremot ett felaktigt motargument gällande licenser. Datorer är redan automatiskt licensierade med gratislicenser vilket jag antar att Swecare redan vet. Hade det inte funnits en licens för en enhet hade det varit olagligt att köra Java på den.

Att det inte skulle drabba programmeraren är också felaktigt. Det gör det även om det inte är direkt riktat dit. T.ex kan de som skall välja ett system välja bort Java p.g.a. licenskostnader. Får inte programmeraren mindre profit på de programvaror hen säljer i Java då? Om det är ett företag emellan kan man börja tala om att större händelser som minskade chanser att få jobb samt nedskärningar blir vanligare.

Intressant, vad jag vet är nämligen OpenJDK fritt tillgänglig under GPL vilket innebär att man är fri att bland annat göra ändringar, vidaredistribuera och kompilera källkoden på valfri plattform.

Vilken licenskostnad är det du pratar om?

Visa signatur

Kom-pa-TI-bilitet

Permalänk
99:e percentilen
Skrivet av phz:

Att en datateknolog kan ha nytta av att tidigt lära sig ett mer hårdvarunära språk är det enda som känns relevant och inte helt eller delvis felaktigt (men om argumentet tillåts stå ensamt så måste ju assemblyspråk vara det enda rätta); samtidigt så är en "Introduktion till programmering" på högskolenivå ofta en uppsamlingskurs från "Hello, world"-nivå, och de kommer säkert läsa andra kurser som mer specifikt lär ut C.

Under första året på Datateknik på Chalmers lärde vi oss följande språk i kronologisk ordning:

  1. Haskell (funktionellt språk besläktat med Erlang)

  2. (Maskinkod och) Assembly för HC12

  3. Java

  4. C

Att man har valt Haskell som första språk beror på att ingen har skrivit funktionellt innan och alla därmed har samma förutsättningar. Tydligen ska funktionella språk som Haskell och Erlang också vara mycket effektiva till vissa typer av tillämpningar (inte spel) samtidigt som de, åtminstone av förespråkare, sägs vara "renare" och enklare att debugga.

Litet Haskell-exempel som tar en lista av heltal som argument och returnerar en lista med de udda talen:

oddInts :: [Int] -> [Int] -- typdeklaration oddInts xs = [x | x <- xs, odd x]

Visa signatur

Skrivet med hjälp av Better SweClockers

Permalänk
Medlem

Intressant.

Sist jag hörde om det hade det proprietära komponenter inbakade vilket i sin tur skulle kunnat användas för att styra hur användningen av Java fortskred. Dessutom var det uppstyrt vad som fick implementeras i koden. De användare som granskade och godkände koden för att lägga in det i programmet hade varit tvungna att skriva på ett avtal innan. Även om man kallade det OpenJDK föll det inte under vad jag anser vara öppen källkod och GPL.

Läste sedan om hur utvecklingen av OpenJDK fortskridit. Ser att man sedan några år tillbaka tagit bort alla proprietära komponenter ur JDKn, bra! Dock så är gemenskapen fortfarande ganska hårt uppstyrd så även om mycket har hänt till det bättre så vill jag fortfarande vara försiktig med att kalla det helt öppet.

Citerat från Wikipedia:

Citat:

The source code for Sun's implementations of Java (that is the de facto reference implementation) has been available for some time, but until recently the license terms severely restricted what could be done with it without signing (and generally paying for) a contract with Sun. As such these terms did not satisfy the requirements of either the Open Source Initiative or the Free Software Foundation to be considered open source or free software, Sun Java was therefore a proprietary platform.

Det är ganska nyligen det blev möjligt att implementera Java utan licenskostnader - Det blev heller inte automatiskt GPL och Open Source med OpenJDK. Att det skulle kunna distribueras fritt har det talats om länge, fast med någon hake bakom som i praktiken inte gjort det möjligt. Den nyheten att det nu går att göra på riktigt hade inte nått mig men är nu uppdaterad. Tack för påpekandet, Teknocide!

Visa signatur

Kör Linux - Yes! We are the 2 percent! And growing... Föreslå inte ens något Windows-exklusivt om jag inte specifikt frågar efter något till Win.
2600K - 18GB RAM - 1TB HDD - 64GB SSD - GTX 650 Ti Boost
Minnesvärda trådar: 1, 2

Permalänk
Inaktiv

Java är ett fantastiskt språk och JVMen är sinnesjukt bra optimerad. Det klart du KAN skriva mer optimerad kod i C/C++ men vill du lägga halva ditt liv på att lära dig hur man gör innan du kan göra det bra? Lära sig C/C++ är ett livsåtagande och är du bara intresserad av själva kodningen så visst, men vill du producera nått inom de närmsta tjugo åren lär dig ett annat språk! Det fanns ju en anledning till att Microsoft kopierade Java och kallade det C# ist för att lära alla C++ och det var ju inte för att de hade tråkigt eller för att Java var så dåligt. I Java behöver du istället bara lägga några månader så är du igång och producerar. Sen att Java skulle vara ett dåligt språk att lära sig programmera i? Jag kodade basic och assembler på åttitalet, E på 90talet och sen Java på 2000talet och det är ju samma skit bara olika syntax. Du ska ha in programmeringstänket sen spelar det ju ingen roll om det är assembler eller javascript som kommer ut.

Förövrigt förstår jag inte varför C/C++ finns i den omfattningen det gör fortfarande, borde ju vara lika marginaliserat som assembler för länge sedan. Helt övertygad om att det kommer tvingas ut från scenen inom ett par år så jag ser ingen anledning till att lära sig det alls.

Vill du ha jobb?, Lär dig javascript och Java med inriktning Android. Inga gamla rävar vågar pröva på det nya så du blir senior utvecklare på två tre år.

Permalänk
Datavetare
Skrivet av anon190955:

Java är ett fantastiskt språk och JVMen är sinnesjukt bra optimerad. Det klart du KAN skriva mer optimerad kod i C/C++ men vill du lägga halva ditt liv på att lära dig hur man gör innan du kan göra det bra? Lära sig C/C++ är ett livsåtagande och är du bara intresserad av själva kodningen så visst, men vill du producera nått inom de närmsta tjugo åren lär dig ett annat språk! Det fanns ju en anledning till att Microsoft kopierade Java och kallade det C# ist för att lära alla C++ och det var ju inte för att de hade tråkigt eller för att Java var så dåligt. I Java behöver du istället bara lägga några månader så är du igång och producerar. Sen att Java skulle vara ett dåligt språk att lära sig programmera i? Jag kodade basic och assembler på åttitalet, E på 90talet och sen Java på 2000talet och det är ju samma skit bara olika syntax. Du ska ha in programmeringstänket sen spelar det ju ingen roll om det är assembler eller javascript som kommer ut.

Förövrigt förstår jag inte varför C/C++ finns i den omfattningen det gör fortfarande, borde ju vara lika marginaliserat som assembler för länge sedan. Helt övertygad om att det kommer tvingas ut från scenen inom ett par år så jag ser ingen anledning till att lära sig det alls.

Vill du ha jobb?, Lär dig javascript och Java med inriktning Android. Inga gamla rävar vågar pröva på det nya så du blir senior utvecklare på två tre år.

Eftersom du själv nämner Microsoft och undrar varför C och C++ finns kvar i så stor utsträckning: Microsoft själva säger att hela deras företag, och för den delen hela datorvärlden, är byggd på C och C++, inte så konstigt att det finns kvar så stor utsträckning då.

Sedan verkar många C#/Java-programmerare missat att C++ har fått en rejält språkmässig lyft i.o.m ISO C++ 2011. Går att skriva modern C++11 väldigt ett-till-ett mot C# om man så önskar (inte ens delete eller free behövs anropas i moden C++ om man inte vill), skillnaden är bara att C++ programmet blir rejält mycket snabbare i de flesta fall. Att man lägger så mycket resurser på C++ (även C har fått en del förändringar 1999 och 2011) idag beror främst på två saker, mobila enheter och "molnet". I mobila enheter vill man ha väldigt effektiva program då det förbättrar batteritiden, i molnet vill man ha väldigt effektiva program för man betalar i praktiken för spenderad klockcykel.

Lyckas man då få C++ till ett modernt språk med bibehållen effektivitet (vilket man verkat lyckats med i 2011 och 2014 års standarder) så kommer det nog få ökat intresse igen.

Att skriva effektiv C++ är inte speciellt svårt, en väldigt bra grundregel är: använd vector<> så långt det bara går. vector<> är en extremt "CPU-cache-friendly" struktur och den överlägset största orsaken till att Java-program i praktiken aldrig bli lika snabba som C++. I Java (eller C#) finns inga datastrukturer som organiseras i minnet på samma effektiva sätt som vector<T> gör, vector<unique_ptr<T>> är väldigt likt det man får i Java/C# sett till hur saker ligger i minnet och jämför man prestanda på dessa två kommer det vara minst ett par heltalsfaktorer i prestandaskillnad om man använder vektorn i tighta loopar.

Däremot har man med Minecraft visat att det definitivt går att göra framgångsrika spel även i Java

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer