Londonska borza z Linuxom podira rekorde

Mavrik je 23. okt 2010 ob 15:13 izjavil:

techfreak :) je 23. okt 2010 ob 15:10 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...

Mavrik je 22. okt 2010 ob 16:14 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 26. okt 2010 ob 01:42 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.

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č...

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.

eh za javo/.net ravno tako obstaja llvm backend kot za "prave" compilerje.

Če bi bilo to res, bi omenjeni izpodrivali C v speed-critical operacijah, pa ga ne.

saj c nibil nikoli cpeed critical , fortran je ;~).

sirotka je 25. okt 2010 ob 21:51 izjavil:

kitaj je 25. okt 2010 ob 21:24 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"

kitaj je 26. okt 2010 ob 13:27 izjavil:

sirotka je 25. okt 2010 ob 21:51 izjavil:

kitaj je 25. okt 2010 ob 21:24 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> 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 je 26. okt 2010 ob 15:54 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...

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...

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.

driver_x je 27. okt 2010 ob 06:46 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.

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.

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?

Č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?

@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" ?

Pomiri še mene, prosim.

Kje se motim ?

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.

darkolord je 28. okt 2010 ob 04:02 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.

jype je 28. okt 2010 ob 09:14 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...

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.

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.

Compilers suck, ML rules.

Tako nekako Brane2 izgleda v tej temi.

Seveda imajo oboji svoje prednosti.