» »

Londonska borza z Linuxom podira rekorde

1 2
3
4

Brane2 ::

Mavrik je izjavil:

techfreak :) je izjavil:


Windows lahko uporabljaš samo na tistih napravah, ki jih podpira Microsoft. Linux lahko uporabljaš skoraj kjerkoli želiš, tudi na budilki.


Če parafriziram: Linux pa lahko uporabljaš tam kjer ga podpirajo Kernel razvijalci. Isto je.



V bistvu ne ravno. Na Gentooju imaš tipa, ki uštimava zadeve za Loongsoona, ki kitajska izvedenka MIPSa.

Ravno tako lahko narediš recimo kako platico z recimo ARMom, ColdFireom ali nečimn tretjim in pač sportaš kernel in ostalo tja.

Ni pogoj, da so razvijalci kernela predvideli verzijo ravno za tvoj stroj.

Saj tudi če pogledaš kernel-sources, boš videl, da je strojno odvisen relativno majhen del pod "arch". Tja pašejo zadeve, ki se tičejo upraavljanja z MMU enoto, določene specifike glede grafikulj, mehanike bootanja itd. Praktično vse ostalo se pa ne sekira dosti za tip tvojega CPUja...
On the journey of life, I chose the psycho path.

darkolord ::

Ravno tako lahko narediš recimo kako platico z recimo ARMom, ColdFireom ali nečimn tretjim in pač sportaš kernel in ostalo tja.

Ni pogoj, da so razvijalci kernela predvideli verzijo ravno za tvoj stroj.
A če sportaš kernel, nisi razvijalec kernela?

Brane2 ::

Mavrik je izjavil:


Java se jasno ob izvajanju takoj prevede v strojno kodo (če uporabljaš privzeti "server" VM) oz. se postopno prevajajo v strojno kodo samo vroče točke (če uporabljaš "client" HotSpot VM).

Preberi si kaj o JIT prevajalnikih.


Tisto prevajanje je bolj bedno glede na optimizacije, ki jih sicer lahko izvede pošten compiler...

darkolord je izjavil:

Ravno tako lahko narediš recimo kako platico z recimo ARMom, ColdFireom ali nečimn tretjim in pač sportaš kernel in ostalo tja.

Ni pogoj, da so razvijalci kernela predvideli verzijo ravno za tvoj stroj.
A če sportaš kernel, nisi razvijalec kernela?


Če tako definiraš "razvijalec", super. Problem rešen.

Originalna trditev se torej zreducira na to, da tudi pri Linuxu ne moreš kernela poganjat na strojih, ki jih ne podpirajo razvijalci.

Če si to tudi ti, potem izpade, da ne moreš poganjat kernela, ki ga nisi prilagodil. Kar v splošnem nikoli ni problem.
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

darkolord ::

Tisto prevajanje je bolj bedno glede na optimizacije, ki jih sicer lahko izvede pošten compiler...
Ne nujno. Tisto prevajanje lahko sproti prilagaja način in vrsto optimizacije glede na arhitekturo sistema in glede na to, kako program dejansko laufa. Po defaultu, seveda. Lahko se seveda tudi tu spustiš na kakšen nižji nivo...

Brane2 ::

Nisem ravno pisec compilerjev, poznam pa ta trik že doolgo časa.

Prvič sem slišal zanj pri razglabljanjih o konceptih za novi QL-ov Superbasic, kjer naj bi interpreter compilal kodo med izvajanjem.

Ampak tam imaš zelo omejene resurse- tako CPU čas kot realni čas, razpoložljivi pomnilnik in kodo, ki ti je na razpolago.

Klasičen compiler ima na voljo praktično poljuben čas, pomnilnik in kodo. Tako se lahko odloči recimo, da bo neko funkcijo včasih inlineal, včasih pa ne. Lahko se odloči na podlagi profila, da bo nek loop razsekal in razrolal do skrajnosti. Ali pa ne.

JIT pa ima na voljo zelo omejen čas in vpogled v zelo omejen kos kode- ta drobec, ki naj bi se izvedel. Tudi nima časa neke težke optimizacije. Zanj je glavnina dobička že, če se znebi interpretiranja določenega ukaza, sploh če je ta v prometnem loopu. Tudi brez optimizacije je boljše kot nič...
On the journey of life, I chose the psycho path.

kopernik ::

Kot sem že povedal, v Londonu *niso* podrli svetovnega rekorda. Let it sink ...

Java pa je lahko zelo hitra in se jo uporablja tudi na borzah za avtomatsko trgovanje, kjer je hitrost ključnega pomena. Ali je hitrejša od X oz. ali bi lahko bil Y 100-krat hitrejši, tu nima veze. Uporabljajo jo in očitno zadostuje.

Mavrik ::


Klasičen compiler ima na voljo praktično poljuben čas, pomnilnik in kodo. Tako se lahko odloči recimo, da bo neko funkcijo včasih inlineal, včasih pa ne. Lahko se odloči na podlagi profila, da bo nek loop razsekal in razrolal do skrajnosti. Ali pa ne.


Kaj točno od tega je omejeno samo na ne-JIT prevajalnike? Edina omejitev ki jo JIT sploh ima je ta, da zgubi podatke, ki jih lahko celosten prevajalnik prenese iz prvih stopenj prevajanja do vmesne kode. Kar ni spet tako veliko, še posebej če si broken jezik kot C++, ki se vztrajno trudi prevajalniku otežiti delo. Vse ostalo lahko JIT dela komot isto kot "tapravi" prevajalnik. Prav tako spet pozabljaš da je koda do bytekode tudi prevedena in tam se jasno stvari kot je loop unrolling, inlining seveda dogajajo.

JIT pa ima na voljo zelo omejen čas in vpogled v zelo omejen kos kode- ta drobec, ki naj bi se izvedel. Tudi nima časa neke težke optimizacije. Zanj je glavnina dobička že, če se znebi interpretiranja določenega ukaza, sploh če je ta v prometnem loopu. Tudi brez optimizacije je boljše kot nič...


No, ni res. JIT ma na pogled prav celo kodo če hoče (recimo Oracle JVM v Server VM konfiguraciji lepo prevede vse classe in ma celoten pregled) in večina kode se veselo izvaja kar na nativni ravni.

Tisto prevajanje je bolj bedno glede na optimizacije, ki jih sicer lahko izvede pošten compiler...


No katerih optimizacij pa Java/C# JIT ne bi mogel narediti kar jih recimo C/C++ prevajalnik lahko? Pri tem prosim upoštevaj da je zaradi designa jezika optimizirati Javo/C# veliko lažje kot pa C/C++ (statična analiza kode je preprostejša zaradi večje varnosti tipov in scopinga). Templati recimo v C++u naredijo tako štalo compilerju da se compiler designerji resno sprašujejo zakaj je te bedarije bilo treba.
The truth is rarely pure and never simple.

darkolord ::

Brane2 je izjavil:

Klasičen compiler ima na voljo praktično poljuben čas, pomnilnik in kodo. Tako se lahko odloči recimo, da bo neko funkcijo včasih inlineal, včasih pa ne. Lahko se odloči na podlagi profila, da bo nek loop razsekal in razrolal do skrajnosti. Ali pa ne.
No sej JIT tudi počne vse to (s tem da profile dela dinamično)...

Sicer je res, da lahko pri statičnem kompajlanju nardiš precej htiro zadevo s profili in vsemi agresivnimi optimizacijami, se pa potem zelo hitro omejiš na določeno arhitekturo ali celo točno določeno konfiguracijo in tudi usage (ker nimaš run-time metricsov - npr. že s časom (ko raste količina podatkov ali se določen del zaradi hwja pohitri) se potrebe po optimizacijah spremenijo). Pa še morebitne izboljšave JIT compilerja se direkt manifestirajo na vseh aplikacijah, ki ga uporabljajo.

Definitivno ni zadeva tako "bedna"...

Zgodovina sprememb…

  • spremenilo: darkolord ()

noraguta ::

eh za javo/.net ravno tako obstaja llvm backend kot za "prave" compilerje.
Pust' ot pobyedy k pobyedye vyedyot!

Brane2 ::

Mavrik je izjavil:



Kaj točno od tega je omejeno samo na ne-JIT prevajalnike? Edina omejitev ki jo JIT sploh ima je ta, da zgubi podatke, ki jih lahko celosten prevajalnik prenese iz prvih stopenj prevajanja do vmesne kode. Kar ni spet tako veliko, še posebej če si broken jezik kot C++, ki se vztrajno trudi prevajalniku otežiti delo. Vse ostalo lahko JIT dela komot isto kot "tapravi" prevajalnik. Prav tako spet pozabljaš da je koda do bytekode tudi prevedena in tam se jasno stvari kot je loop unrolling, inlining seveda dogajajo.


Če bi bilo ta tako malo, ne bi bilo novih verzij gccja in Openxx compilerjev. Nihče se ne bi trudil "gledat" skozi RTL layer. Pa očitno ni tako.

No, ni res. JIT ma na pogled prav celo kodo če hoče (recimo Oracle JVM v Server VM konfiguraciji lepo prevede vse classe in ma celoten pregled) in večina kode se veselo izvaja kar na nativni ravni.


Seveda. Ampak kaj potem ostane od smisla JIT zasnove ? Saj potem lahko stranki v končni fazi daš kar source in ga sama scompila in zažene s kakim batchem. Če je včasih lahko compile time bistven faktor pri klasičnem prevajanju je toliko bolj lahko v zasnovi, kjer se greš compiling med/pred vsakim zagonom.


No katerih optimizacij pa Java/C# JIT ne bi mogel narediti kar jih recimo C/C++ prevajalnik lahko?

Odvisno od tega, do kod misliš raztegnit koncept glede na smiselnost. Kot rečeno, verjetno lahko narediš marsikaj, če ne vse, a kaj potem ostane od smisla zadeve ? Tudi kravo lahko verjetno predelaš da zmaguje na konjskih dirkah, a vprašanje je koliko bo še krava, kar se dajanja mleka tiče...


Pri tem prosim upoštevaj da je zaradi designa jezika optimizirati Javo/C# veliko lažje kot pa C/C++ (statična analiza kode je preprostejša zaradi večje varnosti tipov in scopinga). Templati recimo v C++u naredijo tako štalo compilerju da se compiler designerji resno sprašujejo zakaj je te bedarije bilo treba.


Če bi bilo to res, bi omenjeni izpodrivali C v speed-critical operacijah, pa ga ne.
Če te kaj moti pri C++, pač to ne uporabljaj. Razen če mi hočeš reči, da že sama možnost uporabe templateov zjebe kodo.
So mi pa te zadeve precej nove. Kot sem jaz slišal, lahko C++ poljubno približaš k C, če RTTI in podobnih zadev pač ne uporabiš...
On the journey of life, I chose the psycho path.

noraguta ::

Če bi bilo to res, bi omenjeni izpodrivali C v speed-critical operacijah, pa ga ne.
saj c nibil nikoli cpeed critical , fortran je ;~).
Pust' ot pobyedy k pobyedye vyedyot!

Brane2 ::

Eh ja, zdej si najdu rešilno bilko.

Ja, fortran je za kojekakva matematična premetavanja predvsem zaradi upadenjanih masivnih knjižnic.

Ampak za take splošne zadeve je pa C še kar pojem.
On the journey of life, I chose the psycho path.

kitaj ::

sirotka je izjavil:

kitaj je izjavil:

Ste opazili, da je zadnje čase vedno zraven kaka kitajska ali indijska firma, ki prevzame oziroma se ji naprti vso krivdo?

Si kdaj pomislil, da morda pa so krive?

Ja, seveda! Neka kitajska firma si sposodi OSS kodo, jo zapakira za Windowse in reče Microsoftu: "Hej, sprogramirali smo neko zadevo, a bi jo lahko "prodajali" pod svojim imenom?"
Neka Indijska firma reče Microsoftu: "Daj posodite nam ime, da zmagamo na nekem razpisu, nič vam ne bo treba delat, zraven boste samo na papirju."
Microsoft veselo reče: "Seveda, ni problema, saj nas nič ne stane"

MrStein ::

JIT lahko dela stvari, ki jih statični prevajalnik ne more.
Recimo optimizirati glede na vrednosti, ki so v runtime konstantne,v compile-time pa neznane.

> a kaj potem ostane od smisla zadeve ?
Ostane, da še vedno lahko isti "binary" deployaš desktop uporabnikom, server uporabnikom in uporabnikom z super-duper tri-dni-prevaja JIT-om.
Pomnoženo z različnimi CPU arhitekturami in OS-i.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

sirotka ::

kitaj je izjavil:

sirotka je izjavil:

kitaj je izjavil:

Ste opazili, da je zadnje čase vedno zraven kaka kitajska ali indijska firma, ki prevzame oziroma se ji naprti vso krivdo?

Si kdaj pomislil, da morda pa so krive?

Ja, seveda! Neka kitajska firma si sposodi OSS kodo, jo zapakira za Windowse in reče Microsoftu: "Hej, sprogramirali smo neko zadevo, a bi jo lahko "prodajali" pod svojim imenom?"
Neka Indijska firma reče Microsoftu: "Daj posodite nam ime, da zmagamo na nekem razpisu, nič vam ne bo treba delat, zraven boste samo na papirju."
Microsoft veselo reče: "Seveda, ni problema, saj nas nič ne stane"


Morda je pa dost odvisno od sposobnosti zaposlenih?

Brane2 ::

MrStein je izjavil:

JIT lahko dela stvari, ki jih statični prevajalnik ne more.
Recimo optimizirati glede na vrednosti, ki so v runtime konstantne,v compile-time pa neznane.


In kaj ostane od pospeška, ko odšteješ čas optimizacije ?

Sicer ti pa to komot naredim tudi s statičnim compilerjem, če ravno siliš. Scompilem kodo z nekimi defaulti in vključenim profiliranjem, nato pa iz same kode poženem compiler, ki na podlagi profila opravi dodatne optimizacije in izpljune nov binary in tega poženem na preostanku date.
On the journey of life, I chose the psycho path.

jype ::

Brane2> In kaj ostane od pospeška, ko odšteješ čas optimizacije ?

in potem

Brane2> Sicer ti pa to komot naredim tudi s statičnim compilerjem, če ravno siliš. Scompilem kodo z nekimi defaulti in vključenim profiliranjem, nato pa iz same kode poženem compiler, ki na podlagi profila opravi dodatne optimizacije in izpljune nov binary in tega poženem na preostanku date.

JIT je malo manj štorasta reč kot "iz kode poženem prevajalnik".

MrStein ::

Saj to je finta. Pri JIT je to vse avtomagično.
Ne rabi ne developer ne user nič... čarati. ;)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Brane2 ::

MrStein je izjavil:

Saj to je finta. Pri JIT je to vse avtomagično.
Ne rabi ne developer ne user nič... čarati. ;)


Avtomagija stane.
Tip se je zajebaval z avtomagičnim prstanom in nastalo je sranja za celo serijo Lord Of The Rings...
On the journey of life, I chose the psycho path.

sammy73 ::

Brane2: tudi ko so se pojavili prevajalniki za višje jezike, je bilo polno strokovnjakov mnenja, da sami sproducirajo mnogo optimalnejšo in boljšo strojno kodo.

Brane2 ::

Pa saj ta koncept je med nami že dolgo časa.

Zakaj se še ni prijel povsod, če je res tako dober ?

Si že videl kak soliden kernel narejen s tem ?

NI ti treba biti raketni zannstvenik, da vidiš tradeoff.

Poleg tega, kot že rečeno, to lahko dosežeš tudi s klasičnim compilerjem.

Sploh pa, kako recimo izvedeš kakovostno zaščito kode, če dovoliš programu da sam piše po sebi in se spreminja ?

Ja, lahko imaš kodo posebej, a to je povezano z dodatnimi časi za skoke v kose kode itd...
On the journey of life, I chose the psycho path.

jype ::

Brane2> Zakaj se še ni prijel povsod, če je res tako dober ?

Saj se je. Praktično za vse že imaš implementacije JIT, uporablja (ne da bi moral programer to vedeti) se pa seveda predvsem tiste, ki so jih implementirali snovalci jezikov in so vedno priložene (C#, Java 2).

Brane2 ::

Fajn. Zdaj mi pa pokaži nek res soliden, low overhead kernel, narejen s tem.

Ali pa kak res intensive number-crunching app, ki bi ga težko naredil v kakem klasičnem Cju...
On the journey of life, I chose the psycho path.

kitaj ::

sirotka je izjavil:

kitaj je izjavil:

sirotka je izjavil:

kitaj je izjavil:

Ste opazili, da je zadnje čase vedno zraven kaka kitajska ali indijska firma, ki prevzame oziroma se ji naprti vso krivdo?

Si kdaj pomislil, da morda pa so krive?

Ja, seveda! Neka kitajska firma si sposodi OSS kodo, jo zapakira za Windowse in reče Microsoftu: "Hej, sprogramirali smo neko zadevo, a bi jo lahko "prodajali" pod svojim imenom?"
Neka Indijska firma reče Microsoftu: "Daj posodite nam ime, da zmagamo na nekem razpisu, nič vam ne bo treba delat, zraven boste samo na papirju."
Microsoft veselo reče: "Seveda, ni problema, saj nas nič ne stane"


Morda je pa dost odvisno od sposobnosti zaposlenih?

Microsoftovih? Ko je imela Toyota težave z stopalko zavor jim ni prav nič pomagalo, da stopalke izdeluje neka ameriška firma.

jype ::

Brane2> Fajn. Zdaj mi pa pokaži nek res soliden, low overhead kernel, narejen s tem.

Ti bi od mene rad 200 kilogramov težko jedrsko podmornico za balistične izstrelke, narejeno iz steklenih vlaken? Ain't gonna happen.

JIT je za vse kar je nad takim kernelom, ne (še - brez težav si predstavljam, da bodo kmalu tudi taki) za kernele.

MrStein ::

Brane2 je izjavil:


Sploh pa, kako recimo izvedeš kakovostno zaščito kode, če dovoliš programu da sam piše po sebi in se spreminja ?

Torej Java, CLR in drugi niso dovolj zaščiteni?
Več o tem problemu?
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Terman ::

sammy73 je izjavil:

Brane2: tudi ko so se pojavili prevajalniki za višje jezike, je bilo polno strokovnjakov mnenja, da sami sproducirajo mnogo optimalnejšo in boljšo strojno kodo.


Saj jo.
Trajanje razvoja je problem.

Brane2 ::

MrStein je izjavil:

Brane2 je izjavil:


Sploh pa, kako recimo izvedeš kakovostno zaščito kode, če dovoliš programu da sam piše po sebi in se spreminja ?

Torej Java, CLR in drugi niso dovolj zaščiteni?
Več o tem problemu?


Če so dovolj zaščiteni trpijo speed penalty zaradi skokov iz interpreterja v poseben segment s compilano kodo in obratno- če tega ni in je vse skupaj v enem segmentu, potem je zaščita problematična. Vsaj tako je videt.
On the journey of life, I chose the psycho path.

darkolord ::

Singularity je en Microsoftov koncept (research project) managed OS-a ravno na to temo

Singularity OS is a Microsoft Research Project, a very interesting project: it's a microkernel OS based on the idea of running everything on managed code (JIT compiled code) including drivers and everything else than the micro-kernel!

The main idea is to get ride of CPU-based memory protection and IO protection, everything is running without any protection, the protection itself is based on static code analysis and dynamic checking. For this to work, any code must in form of an intermediate representation (often incorrectly called bytecode), that is analysed at load, interpreted or compiled on-the-fly with security checks.

The interesting thing is that code is "naturally" protected from buffer overrun, or any kind of attack, as any code is suspect by default, and on the other way switching from one thread to the other is lightning fast as no context change must be done.


pa recimo

A Singularity application specifies which libraries it needs, and the Bartok compiler brings together the code and eliminates unneeded functionality through a process called "tree shaking," which deletes unused classes, methods, and even fields. As a result, a simple C# "Hello World" process in Singularity requires less memory than the equivalent C/C++ program running on most UNIX or Windows(R) systems. Moreover, Bartok translates from Microsoft(R) intermediate language (MSIL) into highly optimized x86 code. It performs interprocedural optimization to eliminate redundant run-time safety tests, reducing the cost of language safety.

Zgodovina sprememb…

  • spremenilo: darkolord ()

Brane2 ::

In kaj od tega je neizvedljivo s klasičnimi orodji ?

Na netu imaš folk, ki ročno izdeluje miniaturne elf-e in tja tlači čuda stvari.

Hello World baš neki ni aplikacija za superračunalnik.

Sploh pa mi nisi odgovoril na vprašanje kako to koda spreminja samo sebe na varen način in tako, da se ne zaplete ob obstoječe varovalne mehanizme.

Kot vem, je kodni segment na solidnih strojih "read-only". Sploh pri segmentih, ki lahko laufajo v velikem številu procesov to poleg varnosti prinese še to, da je potrebna za vse samo ena fizična kopija. Če se koda spreminja, tega več ni.

EDIT: Ah, ja, stvar laufa brez MMUja in podobnih zaščit.

Oslanja se na analizo kode. Fajn ideja, ampak zeloooo eksperimentalno in daleč od kakršnihkoli omembe vrednih realnih primerov...
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

Mavrik ::

In kaj od tega je neizvedljivo s klasičnimi orodji ?


Vse je izvedljivo s pisanjem števil nabora ukazov procesorja. Pa vseeno tega ne delaš a ne?
The truth is rarely pure and never simple.

Brane2 ::

V glavnem ne. Zato ker imam orodje, ki mi zagotavlja enakovredno funkcionalnost, brez bistvenih slabih strani.

Tako mi ni treba razmišljat o kompromisih. Koneckoncev se lahko spustim tudi na nivo podajanja ukazov binarno v assemblerju, če mi tako zapaše.

Sedaj mi pa ti pokaži enako razmerje pri JIT zadevah.

Če bi bilo razmerje res enako, bi jih sedaj uporabljali VSI in nihče se ne bi matral s klasičnimi izvedbami.

Že samo ta statistični pristop ti pove, da zadeva le ni brez hib...
On the journey of life, I chose the psycho path.

Mavrik ::

Če bi bilo razmerje res enako, bi jih sedaj uporabljali VSI in nihče se ne bi matral s klasičnimi izvedbami.


A si ti zgrešil kje dejstvo da so trenutno najbolj uporabljani programski jeziki za nove projekte vsi bytecode jeziki z JITom?
The truth is rarely pure and never simple.

Brane2 ::

KAtere projekte ? Web aplikacije ?
Mogoče. Kaj pa je z ostalimi projekti ?

Pa tudi če slednje pozabimo za trenutek- kaj ti pravi da je JIT "prava stvar" ne pa samo korak od interpreterjev do compilerjev ?
On the journey of life, I chose the psycho path.

Brane2 ::

@darkolord:

Še eno vprašanjce o Singularityju- a je M$ žer dal odgovor, kako to ne misli laufati kot Open Source projekt ?
Mislim, za takele trike ti mora biti source prosto dostopen, to pa M$ju nekako nikoli ni dišalo, a ne ?

Bo za to oblikovan novi Skunkworks team ali pa je odgovor že v imenu- takrat bomo itak vsi v "Thomasovi" Singularnosti in bo vse v bistvu "open" ?
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

MrStein ::

Brane2 je izjavil:

Vsaj tako je videt.

To je vse? OK, sem pomirjen.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Brane2 ::

Pomiri še mene, prosim.

Kje se motim ?
On the journey of life, I chose the psycho path.

darkolord ::

Kaj pa je z ostalimi projekti ?
Enako. Vedno več je takšnih, ki se odločajo za to. Ni videt, da bi bilo kaj veliko takih, ki bi se vračali nazaj...

kaj ti pravi da je JIT "prava stvar" ne pa samo korak od interpreterjev do compilerjev ?
To, da ponuja best of both worlds?

Še eno vprašanjce o Singularityju- a je M$ žer dal odgovor, kako to ne misli laufati kot Open Source projekt ?
Saj je praktično vse (razen Bartok compilerja, je pa trenutno na voljo malo enostavnejša alternativa) na voljo na CodePlexu. Da bi pa to furali kot resen projekt, pa že od začetka ni bilo namena (sami to verjetno furajo dalje v ločenem projektu), ne preprečujejo pa nikomur, da bi to storil...

Zgodovina sprememb…

  • spremenilo: darkolord ()

Brane2 ::

Kaj pa je z ostalimi projekti ?
Enako. Vedno več je takšnih, ki se odločajo za to. Ni videt, da bi bilo kaj veliko takih, ki bi se vračali nazaj...


Kam "nazaj" ? Na interpreterje/klasične VM ? Verjamem da ne.


kaj ti pravi da je JIT "prava stvar" ne pa samo korak od interpreterjev do compilerjev ?
To, da ponuja best of both worlds?


Se pravi, recimo kernel in vsaj bistveni del infrastrukture v recimo Win8 lahko pričakujemo izdelan v JIT obliki ?

JIT je fajn, če ga primerjaš z interpreterji. Malo manj pa, če ga primerjaš s kakim solidnim compilerjem. Sploh pa, njegova osnovna ideja takrt rahlo izgublja smisel. Če izvajaš bytekodo, imaš vsaj univerzalnost. Enkrat ko imaš za stroj XYZ izdelano VM, pač bytekoda teče.

Če se pa greš JIT, ti je pa duh problema nezdružljivosti kode spet ušel iz steklenice- spet rabiš na vsakem stroju JIT compiler za točno to arhitekturo itd. Pa še čas prevajanja in optimizacije se direktno prišteva k času izvajanja. Pa kup stvari se ti podre, recimo deljenje kode med preocesi itd. Pa seveda imaš zraven še kup čisto strojnih, mesenih problemov s spreminjanjem kode on-the fly. Omenil sem že varnostne.

A če te ti ne zanimajo, si poglej v x86_64 User Manual, kaj se zgodi, če spremeniš kos kode, ki je v instrukcijskem L1. Intel totalka sflusha cacheline. AMD pa si vzame čas za sinhronizacijo I in D L1 cachelinea.
Not pretty. Ampak če si pravkar presedlal z interpreterja na nek polcompiler potem tega seveda še opazil ne boš. Ali pa, če v bistvu en spreminjaš kode ampak ustvarjaš novo, kamor skačeš v krajše ali daljše subrutine. Ampak tudi takrat plačuješ penale za vse te skoke tja in nazaj in s tem povezana flushanja in polnjenja L1...

Da bi pa to furali kot resen projekt, pa že od začetka ni bilo namena (sami to verjetno furajo dalje v ločenem projektu), ne preprečujejo pa nikomur, da bi to storil...


Dobro. Torej ne gre za resen projekt, ki bo že jutri pojedel svet, ampak bolj za igranej s konceptom ? Fajn, ni problema, samo potem to ni primer, ki bi kazal neke konkretne moči te zasnove, kot sem razumel tvoj post.
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

darkolord ::

Dobro. Torej ne gre za resen projekt, ki bo že jutri pojedel svet, ampak bolj za igranej s konceptom ? Fajn, ni problema, samo potem to ni primer, ki bi kazal neke konkretne moči te zasnove, kot sem razumel tvoj post.
Seveda ne. Singularity je (bil) pač raziskovalni projekt, s katerim so pokazali, da je stvar potencialno zelo uporabna; en koncept, iz katerega se zadeve sedaj razvijajo.

Ti izgleda pričakuješ, da bo nekdo kar naenkrat iz rokava privlekel kar že en fully functional OS kaj podobnega. Kot pri nobeni drugi tehnologiji čez noč to ne gre (vse kar je trenutno "top shit" je bilo prežvečeno že desetletja nazaj), se pa vse premika ravno v tej smeri. JITtanje na GPU, mmmmmmm...

Malo "outside the box" je treba razmišljat, da se znebiš miselnosti, ki izhaja še tam nekje iz luknjanih kartic (da lahko prideš do kakšnih takih idej (ne, ne bo še požrlo sveta, you're safe for now ;)).

Zgodovina sprememb…

  • spremenilo: darkolord ()

Brane2 ::

darkolord je izjavil:


Ti izgleda pričakuješ, da bo nekdo kar naenkrat iz rokava privlekel kar že en fully functional OS kaj podobnega.


Če mi nekdo reče, da je JIT "taprava stvar", tradicionalni compilerji pa so inferiorno orodje kremenčkovih, potem v bistvu ja.


Kot pri nobeni drugi tehnologiji čez noč to ne gre (vse kar je trenutno "top shit" je bilo prežvečeno že desetletja nazaj), se pa vse premika ravno v tej smeri. JITtanje na GPU, mmmmmmm...


Mater je mentalne hrane za umske ofce okrog... Kaj misliš, zakaj so recimo GPUji tako "hitri" ? Zato, ker ob svoji paralelnosti bolj malo odločajo.
Ja, lahko premečejo šitload podatkov skozi skorajda SIMD mašino. A odločanja je tu bolj malo. Naredi algoritem, kjer bo vsak shader lahko skočil nekam po svoje in si naj*. Ja, naredili bodo GPU, ki bo znal tudi to brez prevelikih penalov, ampak vprašanje je koliko bo ostalo od njegovega paralelizma in flat-out-engine-in-the-red-zone hitrosti.

Ne pravim, da se nujno ne splača. Pravim, da stvari niso tako rožnate, kot jih razni marketinški oddelki kažejo.


Malo "outside the box" je treba razmišljat, da se znebiš miselnosti, ki izhaja še tam nekje iz luknjanih kartic (da lahko prideš do kakšnih takih idej (ne, ne bo še požrlo sveta, you're safe for now ;)).


Domišljija nikoli ni bila moja šibka stran. Le roke so jo redko dohajale.
On the journey of life, I chose the psycho path.

jype ::

Brane2> Mater je mentalne hrane za umske ofce okrog... Kaj misliš, zakaj so recimo GPUji tako "hitri" ? Zato, ker ob svoji paralelnosti bolj malo odločajo.

In zakaj ti misliš, da JIT ne more offloadat na GPU vseh (izjemno enostavnih in kot ulitih za GPUjev pipeline) rutin, ki jih nonstop kliče določen video codec decoder?

Well, it can, če imaš pod sabo koncept, kakršen je singularity.

To je nekaj takega, kot je bila Java leta 94 (the next big thing z builtin alokacijo pomnilnika in garbage collectionom, čemur so včasih rekli "brez pointerjev", ki dela na VSEH računalnikih).

Brane2 ::

jype je izjavil:

Brane2> Mater je mentalne hrane za umske ofce okrog... Kaj misliš, zakaj so recimo GPUji tako "hitri" ? Zato, ker ob svoji paralelnosti bolj malo odločajo.



In zakaj ti misliš, da JIT ne more offloadat na GPU vseh (izjemno enostavnih in kot ulitih za GPUjev pipeline) rutin, ki jih nonstop kliče določen video codec decoder?


In zakaj jih ne more klasično compilan program ?

Sicer pa sem ga jaz razumel v smislu, da bi rad CPU breme recompilinga samega programa preložil na GPU...
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()

jype ::

Brane2> In zakaj jih ne more klasično compilan program ?

Ker "klasično compilan program" nima mehanizmov, ki mu bi omogočali ugotavljati posebnosti strojne opreme, na kateri teče - JIT pa to lahko.

noraguta ::

Eh v nativu se vse da naredit, samo vprašanje je kako. Konec koncev lahko embedaš tudi interpreter. V klasičnem c-ju pa vendarle ne moreš verificirat kode (oz lahko prek različnih teorem proverjev). Ravno tako je s schedulerji, lahko spišeš svoje super duper s konkretno situacijo in izuljaš toplo vodo, ampak v jit svetu so to že predvidene situacije, razvoj je lažji in hitrejši. Saj če dela en sam človek je native povsem lepa rešitev ko pa pride do komplesnejših rešitev je pa zadeva okorna in nevarna.
Pust' ot pobyedy k pobyedye vyedyot!

Zgodovina sprememb…

  • polepsal: Mavrik ()

Brane2 ::

jype je izjavil:

Brane2> In zakaj jih ne more klasično compilan program ?

Ker "klasično compilan program" nima mehanizmov, ki mu bi omogočali ugotavljati posebnosti strojne opreme, na kateri teče - JIT pa to lahko.


Od kod ti to ?

Seveda jih ima. Tvoj program se lahko zlinka na library, ki uporablja GPU X, GPU Y ali library, ki opravlja delo ročno. At runtime.
On the journey of life, I chose the psycho path.

noraguta ::

Razlika je v tem, da vsakič znova odkrivaš toplo vodo kar je v jvm ter pripadajočem frameworku je pri c nek lahko zelo posrečen še verjetnjeje pa ponesrečen kup zunanjih knjižnic. Doler se sam boriš s kodo je vseeno ko pa gre za skupino programerjev pa že ni več tako. Podobno je z nitkanjem. Kjer je recimo v f# actor sistem dokaj integriran že v jezik pri nemerlu pa lahko določene napake poloviš celo v compile timu. Tega pač c compiler ne more, ker so njegove paradigme drugačne.
Pust' ot pobyedy k pobyedye vyedyot!

Zgodovina sprememb…

  • polepsal: Mavrik ()

jype ::

Brane2> Seveda jih ima. Tvoj program se lahko zlinka na library, ki uporablja GPU X, GPU Y ali library, ki opravlja delo ročno. At runtime.

Za to potrebuješ API in ustrezne knjižnice. JIT lahko to počne brez tega, z generičnimi programi. Na GPU lahko offloada tudi povsem običajen integer math, če ve, da bo šel tam hitreje skozi.

MrStein ::

Compilers suck, ML rules.

Tako nekako Brane2 izgleda v tej temi.

Seveda imajo oboji svoje prednosti.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Brane2 ::

jype je izjavil:

Brane2> Seveda jih ima. Tvoj program se lahko zlinka na library, ki uporablja GPU X, GPU Y ali library, ki opravlja delo ročno. At runtime.

Za to potrebuješ API in ustrezne knjižnice. JIT lahko to počne brez tega, z generičnimi programi. Na GPU lahko offloada tudi povsem običajen integer math, če ve, da bo šel tam hitreje skozi.


Fajn. Daj mi soliden real-life primer.

MrStein je izjavil:

Compilers suck, ML rules.

Tako nekako Brane2 izgleda v tej temi.

Seveda imajo oboji svoje prednosti.


Ti boga, tole me je na rit vrglo.

Oboji majo svje prednosti, praviš.

Kaj se je zgodilo z "JIT will rule the world" ?
On the journey of life, I chose the psycho path.

Zgodovina sprememb…

  • spremenil: Brane2 ()
1 2
3
4


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Londonska borza prešla na Linux, rezultat zmeda (strani: 1 2 3 )

Oddelek: Novice / Znanost in tehnologija
12823062 (18240) denial
»

Londonska borza dopoldne ustavila trgovanje zaradi tehničnih težav

Oddelek: Novice / Znanost in tehnologija
439055 (6892) hook
»

Londonska borza z Linuxom podira rekorde (strani: 1 2 3 4 )

Oddelek: Novice / Ostala programska oprema
15138852 (34707) MrStein
»

Londonska borza opušča Microsoft platformo? (strani: 1 2 3 4 5 )

Oddelek: Novice / Ostala programska oprema
21318609 (12839) BlueRunner

Več podobnih tem