Svenska ElektronikForumet

> Icecap: det känns som att du glömmer hela historien med virtuella maskiner, som java bygger på.

Och JVM'en är det som interpreterar bytecoden.
Prestandaprobleme med JVM'erna är välknda, därav alla olika
nyheter som har kommit de senare åren för optimeringar av JVM'erna.
HotSpot och allt vad de kallas...

$tiff skrev: Ett bra exempel är att kurser i realtidsprogrammering ges i Java, och då kan man flytta fokus från krångliga realtidskärnor till de mer centrala; användandet av semaforer, blockerande händelser och köer. Allt utan att använda en enda funktionspekare!

Så man lär altså ut realtidsprogramering med hjälp av java i något högnivåsimuleringssystem? Sen får man gå en kurs till för att lära sig realtidsprogramering på "riktiga" system? Eller finns det något java realtidsystem?

Jag kanske hoppar över lite, jag vet att det finns försök på att bygga µC som kör Java-bytekod direkt, dessa är/var avsedda att lägga in i andra system som en co-processor. Jag har för mig att det stöp på att det numera finns så pass effektiva översättningsplattformar att det inte var värd den extra ström- och penningkostnad.

Och OK, "bytekod" är när java är "kompilerat" till en .JAVA-fil, jag använde fel ord när jag menade att ett program i "valfritt" språk kan kompileras till en EXE-fil.

Och virtuella maskiner... när har DET höjd prestanda? Jag glömmer dom inte, jag anser bara att oavsett om man ska köra en JAVA-fil (bytekod) på en PC måste en interpeter utföra en JIT-kompilering (= översättning), det sänker prestanda i programmet.

Om denna översättning utförs till den valda plattform på en gång är det väl OK, det tar tid ändå och som alla andra språk behöver det optimeras för att få full fart på programmet, detta tror jag inte utförs dock men jag kan ha fel.

Dock är JAVA så pass specificerat att bytekoden är optimerat för att köra på det vis och jag tror att skillnaden kan vara minimal mot ett "riktigt" kompilerat program, enda kruxet är att man måste avsätt minne till att bilda det "egentliga" programmet, översätta Java-programmet och SEDAN köra det.

För att få upp farten finns det varianter av java virtual machine som allt eftersom kompilerar om bytecode till "native" binärkod...

Steget till ren binärfil är ju inte speciellt långt då...

Sen finns det lösningar som "kompilerar" in en javaVR in i binärfilen... så att man tror att det är en native kompilerad binär man exekverar... fast man egentligen kör en javaVR innan man kommer till sin kod...

Att kompilera Java till native binärkod tar helt klart bort en del av idén med Java... men jag ser poängen med att kunna det... för varför måste jag lära mig två språk när jag kan nöja mig med ett...

Jag har jobbat med den värsta bastardformen av Java... hårdvarunära java kod... detta var ett helvete... kommer ALDRIG göra om det...

Men jag kommer definitivt att jobba med det där det passar... dvs. hårdvaruOBEROENDE kod

Jag har ett antal program som är gjorda i java...

Hur många av dina program vet du vilket språk det är skrivet i? Jag vet inte om jag alla andra är skrivna i C eller C++... Skulle tro att många är i VB (huga!)

Jag ser inte att man brukar poängtera språket när man installerar... många Java program av större art gissar jag installerar en JRE under installationen om de inte finner en kompatibel redan installerad...

En JVM kan antingen interpretera bytekod eller native-kompilera den allt eftersom (JIT - Just-in-Time-kompilering)
Bytekoden är på inget vis javakod utan kompilerad kod som lika gärna kan vara kompilerad från C, ADA eller vad som helst.

Sodjan:

eftersom detta är en tråd om Java och dess användningsområden antog jag felaktig att alla kände till att (nästan) alla nya mobilspel är skriva i ren Java :)

> alla nya mobilspel är skriva i ren Java...

Ja visst, visst, det var inte så jag menade.
Utan vad *mobiler* har med "riktig" programmerig att göra.
Det är en väldigt specifik/unik plattform, med väldigt sällan mer
än en användare (åt gången)...

> Bytekoden är på inget vis javakod...

Nja, den bytecode som en JVM interpreterar (eller JIT-kompilerar) är tätt
kopplad till den spec för Java bytrecode som SUN har koll på.
Och som javac och liknande verktyg genererar.

> utan kompilerad kod...

Ja, kompilerad *bytecode*, vilket har väldigt lite med maskinkod att göra.
Och det är ju faktiskt själva iden med det hela...

> som lika gärna kan vara kompilerad från C, ADA eller vad som helst.

Som exempel ? Alltså exempel på en C eller ADA kompilator som
generar bytecode ?

icecap:
låt oss ta den från början:

en kompilator som GCC kompilerar koden till ett internt P-kod [1] som ska köras på en fiktiv stack-baserade maskin (eller ibland en maskin med oändlig många register). Det absolut sista man gör i kompilatorn är att översätta P-koden till "native" kod, typ x86 maskinkod eller vad det nu kan vara.

Vad Java gör är att den väntar med det sista steget. Man översätter P-koden (eller byte code som det heter i Javas fall. detta är vad du hittar i en .CLASS fil) till maskinkod först när programmet startar. Man kan göra all översättning i början, detta kallas Ahead-of-Time (AOT) [3], eller så kan man översätta koden först när den behövs för exekvering, detta kallar man Just-in-Time (JIT) [2]. Det finns också möjlighet att översätta java koden (dvs .JAVA-filen) direkt till exekverbar .EXE-fil, detta är vad GNU's java kompilator GCJ gör [4].

I vilket fall som helst, idag kör man aldrig .JAVA filen direkt, alltså är Java INTE interpreterad.


Påverkar den virtuella maskinen som gör JIT prestandan? Ja, det gör den. Och många gånger till det bättre [5, 6, 7]. Därför skrivs många nya "tunga" berkäningsprogram i Java idag!



[1] i GCCs fall kallas den för "RTL"-kod http://en.wikipedia.org/wiki/GNU_Compil ... #Structure
[2] http://en.wikipedia.org/wiki/Just-in-time_compilation
[3] http://en.wikipedia.org/wiki/AOT_compiler
[4] http://en.wikipedia.org/wiki/Gcj
[5] http://www.idiom.com/~zilla/Computer/ja ... hmark.html
[6] http://www.kano.net/javabench/
[7] http://www.javaworld.com/jw-02-1998/jw-02-jperf.html


sodjan:
ADA: GNU GNAT
C++: Microsoft C++.NET

Och det du säger om mobiler saknar mening. Försöker du argumenterar för argumentationens skull :)

Sodjan: förutom AAVEs exempel så har du NestedVM som konverterar mips-binär till jvm-bytekod och sen AMPC som istället kompilerar (C-kod i det här fallet) direkt.
JVM är ju en maskin med definierat ISA så det är bara till att skriva en kompilator med den maskinen som mål. Det kluriga ligger möjligtvis i att exempelvis C-kod ofta är beroende av sina bibliotek (libc osv)... men det går att lösa (och är löst) genom exempelvis JNI (Java Native Interface).

Visst visst.
Men faktum kvarstår, med alla "VM" lösningar köper man sig mer eller mindre
plattformsflexibilitet till priset av prestanda. Går inte att komma runt.

De där C-till-bytekod konverterarna finns ju inte där för prestandans skull...

självklart, Microsoft skapade .NET just för at köpa sig plattformsflexibilitet ;)

Microsoft är tillräckligt stort för att inte behöva bry sig så mycket om det (d.v.s plattformsoberoende).
Snarare för att köpa sig en gemensan RT miljö för sina olika "språk".
Jag vet inte hur .NET är med avseende på prestanda, men å andra sidan
så är den frågan mindre viktig på ett enanvändarsystem. Inte oviktig, men
mindre viktig än på system med 100 tals processer och användare.

I diskussionens hetta verkar det ha kommit fram lite intressanta fakta... Jag vet att jag nånstans i Sun's Java SDK ska kunna skapa en .exe -fil av ett javaprogram. Men vad jag förstod så var det inte en kompilering till "native"-kod utan antingen innehöll .exe -filen en JRE (Java runtime environement) tillsammans med programmet för att kunna köra det i en virtuell maskin eller så var det så att .exe -programmet var beroende av ett befintligt JRE som förutsätts ska vara installerat först. Alltså är .exe-filerna inget annat än .java - kod i förtäckt form. Eller har jag fel nu igen?

Men det kanske dessutom finns kompilatorer som översätter java-kod till verklig "native"-kod vilket i sin tur gör att kompilatorn måste kunna alla plattformat den ska kunna göra program för.

Hur som helst har jag hört att om man kör gratisversioner av java så blir det mycket långsamma program som framför allt tar mycket minne, men om man köper (dyra) java-interpreters (eller kompilatorer) så går det betydligt snabbare - därav känslan att alla amatör-java-program är så satans långsamma och sega...

Sodjan: jag menade aldrig Javascript. En "Applet" är riktig java, fast man skriver en klass som ärver egenskaper från klassen Japplet och som därmed blir garanterat kompatibel med den Java-GUI som finns integrerad i de flesta browsers, med tillhörande begränsningar)

> alla nya mobilspel är skriva i ren Java...

Man har ju talat om Java som ett perfekt språk för all möjlig elektronisk utrustning, från kaffekokare toch intelligenta tvättmaskiner till väderstationer... För mig är det svårt att förstå, då de µC som används i sådana applikationer redan från början är ganska långsamma (Mhz) samt att de ofta har extremt lite minne för program och data... Finns det java för AVR t.ex? Och hur fugerar det?

JAVA JIT är inte helt och hållet kompilering, merparten av koden är interpreterande, enbart delar av koden kompileras av JIT.
Så man kan med hävd påstå att JAVA är ett interpreterande språk.
Detta oavsett om det är java-fil eller en exe-fil.

Har hitintills inte hittat ett enda java-program som snurrar fristående utan JRE.

AndLi skrev:Så man lär altså ut realtidsprogramering med hjälp av java i något högnivåsimuleringssystem? Sen får man gå en kurs till för att lära sig realtidsprogramering på "riktiga" system? Eller finns det något java realtidsystem?

Om du med "högnivåsimuleringssystem" menar vanlig PC, så ja. Det finns (lite specialskrivna) paket för att använda Java som ett riktigt realtidsprogrammeringsspråk, inget på låtsas! Det används exempelvis i många ABB-robotar mer eller mindre direkt. Några rymdfarkoster (från NASA el.dyl.) har också kört realtids-Java läste jag i facktidningar för många år sedan.
Nu hoppar jag medvetet över det faktum att det alltid är en JVM som sitter i botten och drar i spakarna. Programmen som är skrivna har fortfarande realtidsegenskaper.

jesse skrev:(...)Finns det java för AVR t.ex? Och hur fugerar det?

Jepp, utveckalt på LTH, för realtids-java. Det är naturligtvis löjligt begränsat (typ tre trådar innan minnet tar slut i en Mega128) och urvalet av bibliotek man kan använda är också mycket begränsat.
Papper i PDF
Jag har provat det, och kommer aldrig göra det igen. Det är endast utvecklat ur akademiskt intresse för att visa just att det går.
Jo förresten, hur det funkar: Javan tolkas till C-kod och kompileras sedan för målplattformen. Väldigt äkta