Nieuw bedrijf komt met hardwareacceleratie voor Java

ZDNet rapporteert over een nieuw bedrijf - Azul Systems - dat met een speciale processor gaat komen: de Vega. De hardware hiervan is zodanig geconstrueerd, dat Java-programma's efficiënter en dus sneller gedraaid kunnen worden. Azul maakt de vergelijking met wat netwerktechnologie voor opslag heeft gedaan; een grote verzameling aan resources kan efficiënt gedeeld worden door meerdere gebruikers. Verwacht wordt dat er systemen met tot 16 processors verkocht zullen worden, die geïntegreerd kunnen worden in de bestaande architecturen voor het uitvoeren van Java-applicaties. Aangezien iedere processor 24 verwerkingseenheden heeft, wordt er in een dergelijk 16-processor-systeem ondersteuning geboden voor een gelijktijdige uitvoering van 384 virtual machines. Gezien de schaal zal de ontwikkeling voornamelijk voor grotere bedrijven nuttig zijn.

Reacties (60)

[SchizoDuckie]

Sorry hoor, maar dit is een beetje het wiel opnieuw uitvinden. Is dit een soort real-time compiler ofzow?Als er hardware aangepast moet worden op Java, is dan Java zelf niet volledig de plank misgeslagen, en moet Java zelf niet aangepast worden op de hardware?

Cross Platform is leuk, maar ten koste van wat?

[Aaargh!]

Is dit een soort real-time compiler ofzow?

Waarschijnlijk is dit een hardwarematige implementatie van de java VM.

Java wordt gecompileerd naar een instructieset voor een processor, net als normale code, het verschil bij java is dat die instructieset bedacht is voordat er hardware was die 't kon runnen, en voornamelijk op een 'virtuele' cpu draait (de java VM), wat deze lui gedaan hebben is volgens mij een hardwarematige cpu maken voor java bytecode. (zoiets bestond trouwens al)

[wutje]

Sterker nog, er is zelfs al een open source processor:

http://www.jopdesign.com/index.jsp

[Verwijderd]

Yep, en het bericht over deze java processort is ook al wat jaartjes oud: http://www.sun.com/smi/Press/sunflash/9710/sunflash.971015.1.html
Oktober 1997 om precies te zijn.

[Verwijderd]

java wordt niet gecompileert voor een processor, maar voor een virtual machine. je heb de vm nodig om het programma te draaien. als je een programma als azureus draait heet je process gewoon 'java' en geen 'azureus'.

ja, je kan ook native executables compileren (gcj), maar dan is je hele cross-platform idee weg. wat ik wel regelmatig zie is 2 verschillende versies om te downloaden: een die de VM nodig heeft, oftewel je standaard javac binaries, en een die voor een specifiek platform is gecompileert. Ik heb een programma (sancho) die geschreven is in java, maar waarvan ik toch de native executable versie gebruikt. (overigens merk ik niet zo veel verschil tussen de native en de vm versie, ook niet qua snelheid. dat java traag is is een beetje veroudert idee, want die vm wordt wel steeds sneller)

[Aaargh!]

java wordt niet gecompileert voor een processor, maar voor een virtual machine.

De naam zegt 't al, virtual machine, de VM is een softwarematige implementatie van de java instructieset, dat wil niet zeggen dat er geen hardware implementatie mogelijk is, die is er nl wel. er zijn cpu's die gewoon native java bytecode runnen.

je heb de vm nodig om het programma te draaien.

niet op een java cpu.

[TheOneLLama]

Natuurlijk wel..
Wat die chipjes doen is een groot deel van wat de VM doet uit handen van de CPU nemen en in plaats daarvan door die chipjes laten doen. Je draait gewoon nog een VM straks hoor.

[koenie]

Inderdaad. Het bestaat al een tijd. Sinds de nieuwe T-REXX MainFrame machines van IBM (z-Series) Is er ook een zogenaamde zAAP processor beschikbaar. Deze is ook speciaal geoptimaliseerd voor gebruik met Java. Deze Processor is echter alleen beschikbaar op het z/OS besturings systeem en b.v. niet in zLinux. Jammer maar helaas. Misschien dat IBM later als nog ondersteuning inbouwd in SUSE slas9, maar dat is nog (voor zo ver ik weet) niet bekend.

Voor meer info: http://www-1.ibm.com/servers/eserver/zseries/zaap/

[Verwijderd]

Waarschijnlijk is dit een hardwarematige implementatie van de java VM

Nee dat is wat heel anders. Zulke dingen bestaat ook wel, maar dit is een gewone CPU die geoptimaliseerd is voor de Java VM.

Wat is dat dan?

Normaal gesproken wordt bij het ontwerp van een CPU een diepgaande analyse gedaan van een representatieve mix van bestaande applicaties mbt de instructies die ze gebruiken en hoe ze die gebruiken. Bv welke displacements het vaakst voorkomen, welke instructies veel gebruikt worden, welke looping patronen het meest in de code zitten enz.

Wat er bij een Java VM optimized CPU gebeurt, is dat de zelfde analyse gedaan wordt, alleen nu niet voor een mix van applicaties maar slechts voor 1 enkele applicatie: de Java VM dus. Bovenop deze VM zal dan wel weer een mix van java applicaties gedraait worden.

Een voorbeeld van een typische Java optimalisatie is het beter in hardware ondersteunen van self-modifying code. Veel CPU's vinden dit niet zo leuk (ivm caching), maar dit is feitelijk wel wat er in JIT compiler gedaan wordt. Voorderest zijn het gewoon veel van de normale optimalisaties, maar dan zoals gezegd alleen voor het profiel van de enkele Java VM app.

Overigens had Sun ook al een tijd zo'n CPU, de MAJC (ook wel Magic genoemd).

[Verwijderd]

Waarschijnlijk is dit een hardwarematige implementatie van de java VM.

Dat is het niet. Het is een java optimalisatie van de microcode zodat de VM sneller kan werken. Een hele VM in de processor bakken, daar is men bij SUN, Intel en andere bedrijven wel mee bezig geweest, maar dit stuitte op twee praktische problemen: 1. De VM is voorlopig te groot om tegen een normale prijs in microcode te bakken; 2. Om te zorgen dat Java code altijd op de CPU kan draaien, moet de VM up to date blijven. Gezien de frequente wijzigingen in de Java standaard in het verleden (is nu al rustiger aan het worden, dat wel) is dat een substantieel probleem.
Iets waaraan ik net zelf nog zat te denken: een java applicatieserver laadt standaard meerdere VMs in het geheugen om (parallel) sneller te kunnen werken. Wanneer de VM alleen nog in de processor zit, dan zullen applicatieservers daarmee om moeten leren gaan.

[Left]

Java is niet alleen cross-platform. Er wordt je als programmeur ook een heleboel 'dom werk' uit handen genomen. Denk aan array bounds checking en memory allocation.
Dit kost in bepaalde gevallen wat extra cpu tijd; aan de andere kant scheelt het weer een boel ontwikkeltijd.

Met zo'n Vega processor heb je nu de best of both worlds: Weinig ontwikkeltijd en een snelle applicatie !

[Verwijderd]

wat is er mis met hardware optimisen voor de software? als je verwacht dat je er vooral java op gaat draaien wil je er toch maximum performance uit kunnen halen. tis net zoiets als een videokaart optimisen voor bijv games of video editing: nvidia maakt z'n kaarten voor gamers, andere merken hebben er hele andere toepassingen voor (matrox geloof ik 2d applicaties).

[DMT]

Ik zou het graag zien in mijn pc als een hardware addon op bijvoorbeeld 't moederbord. Als het geïntegreerd moet worden in een CPU dan zie ik het nog een lange weg afleggen...

Als er hardware aangepast moet worden op Java, is dan Java zelf niet volledig de plank misgeslagen

Nee, dat denk ik niet. Het is nog steeds crossplatform. Verschil in performance op de verschillende platforms is er altijd al geweest. Dat er nu een systeem komt dat zich op 't Java platform toe spits veranderd daar niets aan. Zolang Java zich maar niet toespitst op dat systeem.

[gimbal]

Dat is helemaal waar. Een Java applicatie debuggen bestaat hooguit uit het opzoeken van wat nullpointers die je zelf veroorzaakt. Je hoeft niet dagen lang door het geheugen heen te tracen om ergens een memory acces violation op te sporen... Daarnaast werkt het class systeem van Java ook heerlijk, classes tijdens runtime genereren, compilen en runnen is gewoon mogelijk. Prachtig voor framework applicaties.

Het enige nadeel is dat ze om Java zo snel te maken als het nu is wat nare design keuzes hebben moeten maken. Zo is om de garbage collector snel te houden het geheugen management van Java vrij vervelend. Je moet minimaal en maximaal geheugen opgeven, en dat wat Java claimt dat geeft het ook niet meer vrij totdat de JVM stopt met draaien. De hoofdreden waarom Java nog niet helemaal geschikt is voor de desktop IMO.

[Verwijderd]

ik weet niet hoeveel java applicaties jij ooit heb geprogrammeerd, maar ik heb nog nooit een min en max geheugen op hoeven geven. dat doet ie allemaal zelf.

en bovendien vind ik het argument van geheugen gebruik een beetje overbodig, aangezien de meeste recente pc's toch geleverd worden met 512Mb of meer. (alleen laptops meestal maar 256, maar minder dan dat wil je er toch niet in hebben omdat het ding dan veel te traag wordt)

[needless to say]

Niet helemaal juist. Java allocceert in Windows bvb standaard 64MB. Als je programma meer vraagt moet je dat aan de command line meegeven. Bvb, als je 200MB wil alloceren zet je als argument aan de command line: -Xmx200m. En ja, ik ben java programmeur . Zowat de belangrijkste cursus die we hebben in de licentiaat informatica.

[Verwijderd]

dat hoef je ook niet zelf op te geven, maar als jij een gave multithreaden dinges wil draaien op je bak en van al je geheugen gebruik wil maken omdat je er toch 512 in hebt hangen dan is het wel fijn als je dat kunt doen zonder speciale intructies voor je VM of het aanpassen van config files.. de max geheugen allocatie van de VM is iets van 74 meg ofzo.. dus eigenlijk net niks als je slecht progged..

[ejay79]

Als iedere programmeur er zo overdenkt is het niet gek dat iedereen z'n RAMbankjes maar uit blijft breiden...

[Verwijderd]

ja, ok, is idd erg lomp gezegd. Wat ik bedoel is dat het soms vervelend kan zijn dat de max geheugen allocatie van de VM vast staat en je dus aan je VM moet gaan tweaken. Ik zelf had dit probleem met een spider die ik had geschreven. Je wil zo snel mogelijk zoveel mogelijk links binnen halen en als je tool toch op een zware server draaid met x Gig geheugen waarom maak je er dan geen gebruik van?? Tis handig in de meeste gevallen dat het vast staat maar er is ook wat voor te zeggen dat als je meer nodig hebt je een slecht programmeur bent. (check! beetje zelfcritiek is nooi verkeerd!)
ofzo

[Verwijderd]

Als iedere programmeur er zo overdenkt is het niet gek dat iedereen z'n RAMbankjes maar uit blijft breiden...

En zo werkt het ook. Denk maar niet dat de software net zo veel versneld is als de hardware.
Van alle hardwareverbeteringen zijn het voornamelijk de programmeurs die daar van profiteren. Want de programmeur kost geld en de klant niet. Bovendien wil een programmeur zich vooral bezig houden met de structuur van het programma en de flow van de data en niet met vervelend werk wat het geheel er alleen maar onoverzichtelijker opmaakt (ook zo lastig uitbreiden later).

Dus ja, over het algemeen boeit het niet zo dat die garbage collector van Java wat extra geheugen in beslag neemt, als de klant dat geheugen toch heeft. Pas als je je geheugengebruik erg laat schommelen en je zo nu en dan wel tegen de max van je geheugen aankomt is het erg jammer dat je de garbagecollector van java niet zomaar kan overschrijven (zoals zo'n beetje alles in java) maar moet tweaken (en er zijn meer vervelende dingen aan de garbage collector dan enkel de min en max).

Maar zolang het geheugen niet een groot probleem wordt kun je beter je de mensen een reepje van 512 erin laten prikken dan onoverzichtelijke code waar niemand ooit meer wijs uit wordt afleveren zodat elke bugfix en uitbreiding in de toekomst 100 nieuwe bugs creëert en je overal veel langer mee bezig bent dan nodig.

(bovenstaande wat extreem misschien ... het moet natuurlijk wel binnen proporties blijven / geleidelijk opvoeren die systeemeisen )

[Verwijderd]

ik heb al een upload applet gecoded (zo'n ding waar je images van je harde schijf kon selecteren, en die dan als thumbnails werden weergegeven) en mijn appletje kon goed werken tot 135MB geheugen voor het java proces in het RAM

[Verwijderd]

"Een Java applicatie debuggen bestaat hooguit uit het opzoeken van wat nullpointers die je zelf veroorzaakt"

<nerd-mode>
1 Dat is dan vooral omdat je je prettig beperkt tot java. Zodat je met J2EE bezig gaat krijg je toch weer de CORBA-, Beanreentrant-, cannotserializeaccess- of de mooiste de AelfredException bij gebruik van een verkeerde versie van saxon.jar onder websphere
2 Nog steeds zwak in java dat bij een nullpointer niet aangegeven welk object nullpointered. Dat zou het al een heel stuk makkelijker maken.
3 Nooit last van indexoutofbound-, classcast-, classdefnotfound-exception o.i.d.
</nerd-mode>

[Verwijderd]

2 Nog steeds zwak in java dat bij een nullpointer niet aangegeven welk object nullpointered. Dat zou het al een heel stuk makkelijker maken.

Je kunt toch gewoon via de stacktrace kijken waar het fout ging?

Dan weet je meteen welke referentie het was. Stacktrace printen is de default actie voor exceptions die niet door de applicatie worden gehandled.

[TheOneLLama]

Je gaat toch niet debuggen met stacktraces? Stacktraces kun je gebruiken om fouten op te sporen in alpha, beta etc. tests. En desnoods als je in produktie draait.

In een stacktrace staat dan ook helemaal niet welke reference null was wat niet mocht, alleen bij welke method het fout ging. Als die method 80 argumenten heeft en 10.000 regels lang is heb je daar niet veel aan.

Debuggen doe je met de debug modus, daar zie dmv monitors wat de waarden van variablen zijn op het moment dat je programma eruit vloog. Je kan dan gaan uitzoeken waar die null vandaan komt. Tegenwoordig kun je dan zelfs "on the fly" de betrefende class recompileren en zonder je programma opnieuw te starten het opnieuw proberen.

[Verwijderd]

Je gaat toch niet debuggen met stacktraces?

Nee dat doe je inderdaad niet, maar zeg ik dat dan???

Debuggen doe je natuurlijk met een... debugger. Maar in de praktijk draai je niet altijd je code in debug mode en ook dan wil je weten wat er aan de hand is als je app exceptions genereerd. Ook als je code al bij klanten of op een server draait kunnen er exceptions voorkomen.

In een stacktrace staat dan ook helemaal niet welke reference null was wat niet mocht, alleen bij welke method het fout ging. Als die method 80 argumenten heeft en 10.000 regels lang is heb je daar niet veel aan.

Programmmeer je zelf wel in java of heb je dit alleen van horen zeggen? Iniedergeval de default exception handler van de SUN JVM geeft altijd ook het regel nummer mee. Als je dingen opschrijft als:

myobj.doSomething().doSomethingElse().doYetSomethingElse();

Dan weet je inderdaad niet welke reference nu null was, en dat is, toegegeven, mischien wel een zwakte van de default handler. Maar die 10.000 regels van je is een compleet n00b non-argument.

[Verwijderd]

[qoute]nog steeds zwak in java dat bij een nullpointer niet aangegeven welk object nullpointered[/quote]

Je bedoelt denk ik referentie, aangezien een object niet kan 'nullpointeren', want het bestaat niet. Dat is het hem juist.

[Verwijderd]

Een Java applicatie debuggen bestaat hooguit uit het opzoeken van wat nullpointers die je zelf veroorzaakt.

Dat is wel heel erg kort door de bocht!

Memory leaks of memory mismanagement zijn maar een sub classe van mogelijke bugs die in programmatuur kan zitten. Wat te denken aan logische fouten?
Overmatige resource consumptie?
Verkeerde loop condities ( oa loop die te snel afbreekt, die net te laat afbreekt, of die helemaal nooit afbreekt)? Verkeerde pre-condities bij een method call?
Threading synchronisation errors (deadlock, starvation, etc)?
...

[Fuzzillogic]

Apart, laatst bleek toch dat Java-code al vrijwel evensnel is met de hedendaagse JIT-compilers als compileerde C/++/#-code. Voor mobiel-gebruik kan ik me een aangepaste CPU wel voorstellen, daar is een JIT-compiler teveel overhead en is interpreted executie te traag.
Maar dit is duidelijk een bakbeest van een CPU/computer. Waarom dan deze oplossing? Lijkt me bepaald niet goedkoper dan een Itanium/G5/Opteron-opstelling.

[n4m3l355]

ik denk vooral het 384 systemen in 1 bak te draaien het juist interessant maakt om dit te gebruiken ipv een itanium/g5/opteron (als je die in 1 dezelfde rij uberhaubt kan noemen). verder met optimale ondersteuning voor de java wat intel/mac/amd dus niet geeft is ook een leuke meenemer natuurlijk

[gp500]

ik zou 't ook niet gek vinden als intel en AMD wat hardware instructies implementeren.

Heb je meer aan dan sse3

[MBV]

Even snel? Ook met de Java Realtime uitbreiding is het niet mogelijk om een beeld op een muur te projecteren, wat met C makkelijk kan (20.000x iets naar een buffer schrijven)

[Verwijderd]

Apart, laatst bleek toch dat Java-code al vrijwel evensnel is met de hedendaagse JIT-compilers als compileerde C/++/#-code.

Apart, de meeste C# compilers compileren helemaal niet naar native code maar naar (M)IL.

[Dreamvoid]

Krijgen we binnenkort dan ook .NET accelerated processoren met een .NET runtime environment in hardware? Aan de ene kant zou zo'n hoger niveau integratie/optimalisatie van hardware en software grote snelheids en veiligheidswinst kunnen leveren, maar je verliest wel flexibiliteit.

[Verwijderd]

lijkt me niet.
.dot is praktisch geschreven voor wintel. Daar valt al niet meer zo veel aan te optimaliseren.

java-VM zorgt er vooral voor dat java op alle platforms draait. Schrijf eenmalig in java, draaii het op AIX, linux of windows.
.net-framework zorgt er voor dat code in verschillende talen met elkaar commmuniceert. Schrijf iets in VB, C# en ASP en draai het op een windows bak.

[Verwijderd]

Niet helemaal.

In theorie is .Net niet enkel voor windows. Denk bv aan het Mono project voor linux.

Probleem is echter dat MS een (best wel) mooi framework geschapen heeft maar geen behoefte heeft het op andere OSen uit te brengen.
Dit terwijl Sun er bij Java wel voor gezorgd heeft dat de VM op verschillende OSen beschikbaar is. .

@gndehaas.
Feitelijk gebruikt .Net dus een JIT met een cache. Je hebt echter net als bij java een platformonafhankelijke pseudocode. Hoe die pseudocode wordt omgezet in instructies is een keuze van het platform. Het kan via een interpreter, maar dus ook via een JIT en een cache. Hetzelfde geldt voor Java. Je kan een Java VM maken die hetzelfde doet. Sterker nog: er zijn VMs die dat doen.
Iets wat wel een voordeel is van .Net is dat je meerdere talen kan gebruiken die allemaal dezelfde code genereren. Echter dit is maar een beperkt voordeel. Je wilt in je ontwikkelteam geen 3 man die in VB.NET programmeren, 2 in c# en de rest in c++.

[Verwijderd]

Dit terwijl Sun er bij Java wel voor gezorgd heeft dat de VM op verschillende OSen beschikbaar is. .

Mwhooaah... SUN zelf brengt zijn eigen VM maar voor een heel beperkt aantal platformen uit: Solaris, Windows, en Linux. That's it.

*bsd moet altijd met gehackte VM's werken (die het NOOIT fatsoenlijk doen ) en een andere grote speler als Apple doet komt met een eigen implementatie.

[TukkerTweaker]

Die flexibiliteit is in dit soort complexe dedicated server omgevingen niet van belang, immers overschakelen van .NET naar bijvoorbeeld Java kost dan vele malen meer dan nieuwe hardware, als het uberhaupt al mogelijk is.

[Verwijderd]

Krijgen we binnenkort dan ook .NET accelerated processoren met een .NET runtime environment in hardware?

Bij dit soort processoren gaat het er niet om dat het hele OS in hardware zit maar dat sommige erg trage instructies sneller worden afgehandeld. Net zoals je Intel cpu niet het hele windows XP ingebakken heeft maar verschillende primitieve instructies combineert zodat het OS gedraait kan worden. Maar als .NET echt een succes wordt en er duidelijk prestatievoordeel te halen is, zullen er inderdaad wel processors komen die .NET bytecodes kunnen afhandelen in hardware.

[TinusH777]

Er bestaat geen .NET bytecode. Wel IL, maar zodra je je .NET applicatie opstart, wordt de IL gecompileerd naar native CPU code. Een .NET processor is dus overbodig! Het draait immers al native op de processor. Zoek maar eens op commande NGEN, welke .NET componenten vertaal naar native machinetaal en plaats elgens in een cache.
Dat is nu het grote verschil tussen Java bytecode en .NET IL

[nxt]

..zodra je je .NET applicatie opstart, wordt de IL gecompileerd naar native CPU code. Een .NET processor is dus overbodig! Het draait immers al native op de processor.
...
Dat is nu het grote verschil tussen Java bytecode en .NET IL

en dat is nu precies wat bij java een JIT (just-in-time) compiler doet.
alleen niet tijdens het opstarten maar meestal wanneer de code voor het eerst gebruikt wordt.

IL en bytecode zijn beide een processoronafhankelijke tussenform, en beide zullen gecompileerd worden naar native code
blijft eigenlijk als enige verschil het moment waarop het gecompileerd wordt naar native code over.

[Verwijderd]

De Itanium was ook geoptimaliseerd voor Java achtige talen.. Alleen moest de compiler alle optimalisaties doen (veel meer dan op de 32bits/ amd64 chips).
Immers, je hoeft maar 1x te compilen; bij deze en oude chips gaat nog veel uitvoertijd steeds opnieuw verloren omdat de processor eigenlijk half het werk doet van de compiler.
Het werd helaas een flop omdat de uiteindelijke performance wordt bepaald aan de hand van populaire software, zoals linux, dat helemaal rondom de intel32 architectuur bij elkaar is gehacked en dus idd niet erg snel zal zijn op een Itanium platform.

[Aaargh!]

Het werd helaas een flop omdat de uiteindelijke performance wordt bepaald aan de hand van populaire software, zoals linux, dat helemaal rondom de intel32 architectuur bij elkaar is gehacked en dus idd niet erg snel zal zijn op een Itanium platform.

Waarom zou Linux het niet goed doen op een Itanium ? er zit weinig architectuur specifieke code in Linux, en IA64 is een totaal nieuwe architectuur dus die delen zijn daarvoor speciaal geschreven, de rest is een kwestie van een goeie compiler.

[TGEN]

Hij bedoelde eerder dat Java-achtige talen beter draaien op een Itanium dan diezelfde talen op andere processoren. Dus dezelfde VM draaien op zowel een Itanium als $dertien-in-dozijn-x86-proc zal een duidelijk voordeel van de Itanium naar boven brengen.

[Verwijderd]

Er bestaat al hardwareaccelatatie voor Java: Jazelle, is beschikbaar bij verschillende ARM processoren. Sterker nog, het wordt ook al daadwerkelijk gebruikt in verschillende mobiele telefoons zoals de K700. Dus wat er echt nieuw is aan dit bericht, ik weet het niet. Over hardwarematige Java ondersteuning wordt al gepraat zolang er java is en er zijn wel meer cpu's ontwikkeld.

[Verwijderd]

Ik maak me altijd druk dat je java programma's die gecompileerd zijn, zo weer terug kan compileren! Java decompiler dus.

[Verwijderd]

Ja dat kan. Of je er echt wat aan hebt is weer een tweede want de meeste mensen gebruiken wel een routine die de code onleesbaar maakt.

[JeroenTheStig]

Onder andere door je variabelenamen en functienamen te refactoren naar 0000 tot FFFF, in plaats van panelHeight, counter of fillTable.

Decompilers zijn er overigens ook voor andere talen, dus dat is niet een reden om je druk over java te maken

[Verwijderd]

Onder andere door je variabelenamen en functienamen te refactoren naar 0000 tot FFFF, in plaats van panelHeight, counter of fillTable.

Inderdaad byte code obfuscation heet dat, en wordt nog best vaak gebruikt. IHA heb je dit ook (met de techniek die BokTor noemt) voor situaties waar alleen de source code leveren een zinvolle uitlevering is. Bv PC-Lint maakt voor de UNIX versie gebruik van "shrouded C".

Decompilers zijn er overigens ook voor andere talen, dus dat is niet een reden om je druk over java te maken

Ja en nee. Ze zijn er voor elke talen, maar Java Byte-code is een iets meer high-level assembly dan bv x86 of mips assembly. In tegenstelling tot een stukje C++ wat naar MIPS assembly is gecompiled, herken je in standaard gegenereerde byte code nog heel erg veel van de originele java source. Sommige dingen lijken er wel 1 op 1 in te zitten en dat is dus bij de genoemde architecturen absoluut niet het geval.

[Pwigle]

Leuke naam, een kruising tussen Java en Viagra ?

[Verwijderd]

Volgens mij kan de MIC cpu ook al java of allicht een gedeelte daarvan realtime uitvoeren.

[Verwijderd]

het vast blijven houden aan x86 is al een probleem op zich en wordt voornamelijk veroorzaakt door windows, omdat die helemaal niet portable is. als de populariteit van windows minder zou worden zou de populariteit van andere cpu architecturen dan x86 vanzelf toenemen, en ben je snel genoeg van al je legacy troep af.

[Tijger]

Nee, daar zitten we op te wachten, 'the good old days' van tig hardware platforms waardoor alle hardware duurder wordt.

Linux is in eerste aanleg ook een x86 OS, btw, dat het op andere hardware kan draaien is irrelevant, dat kan Windows ook als daar een markt voor zou zijn, die is er dus niet.

[Aaargh!]

Er is altijd markt voor verschillende platforms, 1 general purpose cpu is niet iets wat we de komende tijd gaan zien, verschillende toepassingen hebben nu eenmaal verschillende eisen aan de CPU.
Ik hoef bijvoorbeeld geen x86 in m'n Palm, dan gaan de batterijen ongeveer 3 seconde mee.

[Aaargh!]

Wat is er mis met java dan ?
- Java is snel
- Java is clean
- Java is crossplatform

ideaale taal dus, vooral server-side erg practisch.

[TukkerTweaker]

Wat bedoel je precies? Dat ze ( ik neem aan dat je Sun bedoeld) een snellere Jvm moeten schrijven? Ik denk dat je met de snelheid van de huidige Jvm weinig te klagen hebt.
Inderdaad kan een applicatie gebruik makend van een Swing GUI traag zijn ja, maar daar zal deze processor hoogstwaarschijnlijk niets aan veranderen (is ie ook niet voor bedoeld).
Deze processor wordt ingezet in een dedicaded server omgeving waarbij het mogelijk wordt om enorm veel users te binden. Soort supercomputer voor javaomgevingen.