Új üzenet küldése







TCH
2019.07.10. 15:50:48
MG:
Így ahogy elkezdtem nézni, kb. 5-10 sec után az tört ki belőlem, hogy "mi ez a retardált, kakofón buzizongora alatta?" Aztán mikor mentek dekkával, meg bringával, meg kosaraztak, meg hegyet másztak, akkor az a csicska reklám jutott eszembe, ami a chropera debütálását előzte meg, ahol légiszörföztek, meg hegyről-lesiklottak; ott is, itt is: mi köze ennek a termékhez? Mi ez az "életérzés-közvetítés"? Ezért instant versenyzongora jár. Semmi nem derül ki belőle, ez nettó agymosás.
Szóval akkor nintendon't tényleg átáll handheld-onlyra? (Cián, sárga, meg szürke? Kimaradt a magenta... :P ) Ez lesz full konzol helyett? Aztán mikor megjelent a választék a csávó mögött, akkor pause és nézem: 9 féle márijó, meg kétféle pokémon, meg kétféle kirby, meg pár RPG...jó nyilván nem ez az összes, de valami diverzebb palettát nem tudtak volna, ami nem márióval van telebaszva csüdig?
Azon meg konkrétan leszakadt az arcom, hogy ez a feltupírozott gémbojklón feleannyiba kerül, mint egy PS4, aztán kb. egy erősebb tablet lefingja az asztalról.

Sauron:
A Java VM-ben futó kóddal szerinted mégis mit kell csinálni, ha nem interpretálni? Interpreter = értelmező. Minden futtatható bináris kód interpretált, még a gépi kód is, csak az hardware-esen van interpretálva és a CPU bontja szét belül a saját elemi műveleteire. Csak nem szokták annak hívni, mert általában a szoftveresen interpretált kódot hívják annak.
Ezt a "gépi kód sebességgel fut" dolgot meg felejtsd már el: semmi nem fut gépi kód sebességgel, csak a gépi kód.

A column store annyit tesz, hogy az oszlopokat tárolod le szekvenciálisan. A forráskódban nincsenek oszlopok. Az, amit leírtál, mint tömörítés, az Speccy 48 alatt sosem működne, mert kinő a szakállad, mire egy szót kicsomagol. Arról nem is beszélve, hogy a szóalapú tömörítés egy fejlettebb nyelv forráskódjával teljesen értelmetlen egy karakteralapú huffmannal szemben, hiszen baromi sok - akár több, mint száz - kulcsszavad lesz, míg a karakteresben van 26 betű, 10 szám, meg pár írásjel.

Ne mérd már össze a doszospécét a Speccy 48-cal. Bármiféle interpretált nyelvet töltesz be rajta, kurwa lassú lesz.
E-Mail
Sauron
2019.07.10. 15:26:03
Az utolso uzenetem a rohadt vonatmiatt elszallt mert nincs interner a hudson alatt. Usa total le van maradva meg mindig.
Szoval 135k. Azt valaki valahol valamiert dosra birta portolni mert iszonyi reszeg vagy drogos vagy mindketto lehetett. Szoval optimalixacio levagna a felere vayy harmadara.
De en arrol is beszeltem hofy nem nell annyi kulimasz mert a perl4 40 szazaleka is elef. Es arrol is, hogy perl sem kell, hanem valami egyszeru perl fele dolog, amit betolthetek a hasznalhatatla. Speccy rom gelyett vagy interfacere vagy akar a memoba, kulonbozo optimalizalt verziokat ami futtattja azt a kodot nagyon gyorsan ami a use caseem.
E-Mail
Sauron
2019.07.10. 15:08:00
Szoval a magas szintu nyelv tomorseget a gepi kodhoz kepest vitatnam, mert pl a magas szi tu nyelvben en mondom meg mi legyen a nyelv, a gepi kodban meg a cpu meg hardver architectura diktal. Illetve ami fontos, en felhasznaloi progikra gonsolok itt, nem a motorra, amit persze gepi kodban kene megirni es betolteni valahova, celszeruen a hasznalhatatlan spextrum rom helyere amit siman ki lehet venni a gepbol es masikat beledugni mindenfele vilagraszolo hardver modositas nelkul (utobbi feltetelezes, bizonyitasra szorul).
Szoval ha negvan a motor, akkor odaul a pici felhasznalo a pici spectru.hoz, beir egy.pici perlhez hasonlo kodot, general hozza adator (vagy betolt) es a motor futtatja neki. Hasonlokeppen ahogy a rom a basicet de en amint irtam egy igazo objekt kodrol irok, ami lassan 40 evvel a spectrum szuletese ota talan megoldhato ott is csak elhatarpzas kerdese.
E-Mail
Sauron
2019.07.10. 15:03:14
Jo reggelt!
Az elso amit irsz szoval igen, tokenizalva tarolja le a speccy a basicet a memoban, de utana futaskor interpretalja, nincs kozbulso objekt kod ami a java byte kodja vagy a fox-e, vagy ha igen (nem ismerem melysegeben a java es fox byte kodot) akkor is lenyegesen gyorsabban futnak,.mint az interpretalt kod, legalabbis ez a feltetelezesem mert hogyan tudna pillanatok alatt gepi kod sebesseggel futni valami addicionalis eloforditas vagy hasonlo nelkul a hayterben? Mindent a cpu gyorsasagnak tudsz be? Lehet, bar megis ketlem...

Column store. Ez a dolog.kismillio dooogra jo. Tegyuk fel program forraskodot akarok tarolni, 10szer annyit 10k ban mint lehetne byersen, tehat 100knyit. Mar sima tomoritessel is 50szazalrk a nyereseg minimum, de a column storeban letarolok minden kodszot egyszer, es az eloforsulasait pedig vektorban, ahogy a column store csinalja. Ezek utan az egesz.kod szekvencialisan osszeallithato egy full scannel ami osserakja mergeli a pozixiokban levo egyedi tokeneket. Persze kell hozza meg kulimasz, kert ahogy irod pl operanduspkat stb nehezebb, de megkockaztatom, az is menbe alapbol jo szaftos nyereseggwel. Es nem ilyen elvetemult basicnek csufolt dolgot amiben sys hivasok vannak es basicnek xsufoljak hanem valami strukturalt nyavajat ahol van 4 vezerlo meg 2 kondicionalis meg 3 ertekado utasitas azt csokolom, pl C vagy.perl.

E-Mail
mutantleg
2019.07.10. 14:48:30
Nem tervezzuk, nem lesz, nem dolgozunk rajta, itt van rovat:
https://www.youtube.com/watch?v=59yuBFRSZdg
E-Mail
TCH
2019.07.10. 13:55:11
De, a Spectrum BASIC az ugyanolyan tokenizált byte kód, mint a CBM BASIC, vagy bármelyik másik. Az összes 8-bites gép BASIC tudta a tokenizált byte kódot, mert nem tudott volna máshogy működni. Te kevered az interpretálást a parse-álással. Szövegből gép által értelmezhető kód készítése: parsing, kód értelmezése: interpreting. A 8-bites BASIC-ok meg úgy működtek, hogy amikor te beírtál egy BASIC sort (10 PRINT "KECSKE" : REM WHATEVER), akkor azonnal parse-álta és tokenizálta, a memóriába pedig már a tokenizált bytekód került. Ez így ment CBM gépeken is, de a Sinclair gépeken is. Majd minden PRINT-et letárolnak egyesével a memóriában, elbaszván 5 byte-ot, ahelyett, hogy leírnák egy egybyte-os tokennel ($F5)...

A column store azt jelenti, hogy nem a sorokat, hanem az oszlopokat tárolod le szekvenciálisan. Egy nyers kódnál az adat egy blob, se sor, se oszlop; mit akarsz ott egy DB tárolási megközelítéssel?

Nem csak az utasítások számossága számít, mert egy utasításnak vannak paraméterei is. Mondok egy példát: CBM BASIC-ben egy adott címre a SYS paranccsal lehet ugrani. Tehát 0 SYS 2061 ugraszt a 2061-es címre. Ez a CBM BASIC tokenizált bytekódjában így néz ki: $0b $08 $00 $00 $9e $32 $30 $36 $31 $00 $00 $00, azaz 12 byte. Ugyanezt assemblyben a JMP 2061 csinálja. Ez binárisan: $4c $0d, $08, azaz 3 byte. Egyáltalán nem szükségszerű, hogy a magasszintű interpretált nyelv kisebb kóddal dolgozzon, mint a gépi. Ennyit arról, hogy a bytekód nagyon kicsi. A generálásáról meg annyit, hogy a szövegek parse-álása még PC-n sem egyszerű, meg CPU/memória kímélő, nemhogy csóri Spectrum 48-ason.

8-bites gépeken, ha bármi komolyat akarsz, akkor ott csak gépi kódban van értelme bármit csinálni. Régen még volt értelme a nem sebességkritikus részeket megírni a gép saját BASIC-jében, vagy valami más magasabb szintű programnyelven (C, Pascal, FORTRAN, whatever) és a többit assemblyben, de a mai korban, amikor egy húszmilliószor kifinomultabb környezeted van (fasza szövegszerkesztők, macro assemblerek egy raklapnyi előre megírt makróval és kóddal, debuggeres emulátorok, mittudomén), semmi értelme mást használni, mint assembly-t.

Sz*rk: Alámpostoltál. Szóval 135k a Perl 4. Az ugyanúgy nem fér bele még a Spectrum 128k memóriájába sem, mint a 2 MB-os Perl 5, tehát mindegy, hogy 135k vagy 2 MB...
10k-ba te semmi olyat nem fogsz megírni, amiről itt beszélsz. Valami hullaprimitív 8-bites BASIC-et meg lehet, hiszen azt meg is csinálták, de azzal ugyanott vagyunk, mint a már meglévőkkel, könyörgöm...
E-Mail
Sauron
2019.07.10. 13:29:16
Tevedtem, perl 4 8086-ra mindossze 135kb :). http://ftp.gnome.org/mirror/archive/ftp.sunet.se/pub/simtelnet/msdos/perl/
Es ebbol sokat lehetne sporolni, mert nem kell bele csomo funkcio. Illetve megint mondom, hogy nem ezt,hanem falami vegtelenul fapados dolgot gondolok ami tud alap funkciokat igeny szerint es belefer mondjuk 10k-ba.
E-Mail
Sauron
2019.07.10. 13:11:43
Szoval a byte kod mar onmagaban nagyon kicsi, de ha generalhato gyorsan, akkor nem is kell tarolni csak atmenetileg, es a forras meg tomoritheto orult hatekonysaggal.
E-Mail
Sauron
2019.07.10. 13:09:49
A perl 4 talan 400k volt de lehet hogy kevesebb, meg kell nezzem. De megint kiemelem, nem fontos a teljes nyelv, annak csomo libje van stb. A perl se fontos. Valami nyelv, basic is ok, csak gyors es byte kod, hogy tomoritheto legyen. Ezt nem tudom mennyire igaz. A spectrum basic az nem byte kod hanem.sima interpretalas. En byte kodrol regelek,.ami a fox, a mod perl meg a java, amik nagysagrendekkel gyorsabbak az.interpretaltnal.
A kod tomoritest nem.gepi kodra ertem, hanem a byte kodra. Forraskodot a column store modszerrel is, de mas modszerrel talan meg jobban akar 100 1 lehetne tomoriteni (hasbol kapott ertek de ott lehet a legtobbet nyerni mert nagyon keves utasitas van)
E-Mail
TCH
2019.07.10. 12:30:28
De itt bináris programokat akartál tömöríteni, azoknak pedig az entrópiája magas. Azok is igazi adatok. (És teljesen mindegy, hogy ez egy interpretált nyelv tokenizált bytekódja, vagy gépi kód, mert mind a kettő változékony bináris adathalmaz.) Mégis mit szeretnél letömöríteni 10:1 aránnyal; pár nevet meg születési dátumot? Azt le lehet tömöríteni még jobb tömörítési aránnyal is, de minek? Hogy járul ez hozzá ahhoz, hogy több férjen bele a Speccybe? Az a baj, hogy te kipécéztél egy adatsémát, amit jól lehet tömöríteni és ezt akarod ráhúzni egy másikra, amit nem lehet jól tömöríteni.

Amit a Fox kitalált (vagy lenyúlt) azt pécére találta ki. Van bytekódos megoldás Speccyn, mondom, a BASIC-je. Mire megyünk vele? A Java meg minden, csak nem hatékony. Iszonylassú, memóriazabáló és instabil. Programozni meg agyfasz benne, túlerőltetett, kierőszakolt OOP és exception-handling. Pfúj. Sokkal hatékonytalanabb, mint a C/C++, meg az assembly. A teljesítménye pedig csak atomerőműveken elfogadható. Azt pedig nyugodtan el lehet felejteni, hogy egy interpretált nyelv Speccyn a gépi kód sebességével fusson; még egyszer: egy magas szintű utasítás több tíz vagy akár száz darab gépi kódú utasításnak felel meg. Turbózott BASIC-et lehet csinálni, de még az is lassú és nagy lesz. A perl portolását viszont el lehet felejteni bármilyen 8-bites gépre. 2 MB csak maga a perl bináris.
E-Mail
Sauron
2019.07.10. 10:22:41
A perl dos alatt is futtattam annak idejen egy banki projekten es irto jol ment, igaz, azok a gepek is 90es evek kozepen mar igen combosak voltak a 100as pentiummal a kis 3.5Mhz z80 hoz kepest, de itt megint csak a techikat hangsulyoztam, nem magat a.megoldast es.kornyezetet, hanem azt, hogy mivel a perl jo volt adminra es CGI re de lassu web alkalmazasokra, ezert a mod kiterjesztessel felturboztak. Na.ezt.is lehetne.csinalni, megirni egy egyszeru felturbozott basic vagy perl modult ami gepi kodhoz hasonlo gyorsasaggal futtatja a.kodot anelkul hogy leforditana.
E-Mail
Sauron
2019.07.10. 10:18:15
A fox amit kitalalt (mondjuk lehet hogy mas talalta ki, ok csak alkalmaztak vagy siman elloptak) az ms doson volt az os idokben. A technikat hangsulyozom itt, nem a gep es kornyezet erejet. A byte kod szerintem spectrumon is siman mehetne ez alapjan es megnyitna az utat joval nagyobb programok joval kenyelmesebb irasara, mint a hagyomanyos forditott kod.
A javaban keresomotorokat es egyeb eleg harver kozeli ketyereket irtak es nincs alapveto gond a sebesseggel. Inkabb a stabilitassal es a nagysagaval de az mas teszta. De a javat csak azert irtam mert a fox siman az elohirnoke, es bizonyitja a potencialjat. Mindenkeppen joval hatekonyabb mint C.C++ vagy Assembly es a teljesitmenye legtobb esetben elfogadhato.
E-Mail
Sauron
2019.07.10. 10:12:23
Kod tomoritesre nem ezt hanem a byte.kodot javasoltam, de meg akar a column store is segithet mert a kod megint csak nagyon jol t9moritheto, ha magas szintu (nem assembly)
E-Mail
Sauron
2019.07.10. 10:10:53
Bar igaz amit irsz az entropiarol, de ez lenyegtelen, mert a gyakorlati eletben igazi adatok vannak, nem pedig veletlen szamok, es ez igenis lehetove teszi a 10 1 es magasabb tomoritesi aranyt. Kerlek ellemorizd le a hivatalos benchmarkokat vagy futtass par tesztet sajat magad, es latni fogod.
A spectrum memoriajaba pedig szerintem belefer, mert itt megint nem irdatlan adattomegrol van szo, hanem a meglevo memoria a 48k kb megtizszerezeserol plusz hardver vagy hattertar megoldas nelkul. Ami azt jelenti hogy ha 48k ban durva leegyszerusitessel le tudok tarolni mondjuk 300 rekordot, akkor 480k ban le fogok tudni tarolni 3000et. Nem hatalmas de kisebb feladatokhoz megnyitja az utat. A dolognak tovabbi optimalizacios szintjei is vannak egyebkent, mert a 3000 rekord lehet 3000 rekord aggregalva, amik mindegyike mogott van 3000 rekord, amit nem mutatunk vagy tartunk keszen memoriaban, tehat ez majdnem 10 millio rekord reprezentsciojat adja.
E-Mail
TCH
2019.07.10. 08:46:22
Nem érted. Nem maga a column store teszi lehetővé a drámai hatékonyságú tömörítést, hanem az oszlopokon belüli alacsony entrópia. Próbálj már meg ilyen drámai hatékonyságú tömörítést elérni egy olyan bazi nagy táblával, aminek az oszlopait csupa véletlenszámmal töltötted fel, tömöríts le valamit ami kvázi maximum entrópiával bír... (A kód pedig általában ha nem is maximum, de magas entrópiával bír.) És már megint Linuxon csináltad, ahol van memória arra, hogy olyan "bloated" adatszerkezeteket használj, mint egy DB tábla; egy 48k-s Speccy-n nincs erre lehetőség.

Nem tudom mit talált fel a Fox, de már megint PC. Már megint a gőzhajót hasonlítod össze a dzsunkával. Azt meg, hogy a Java sebességével nincsen gond, már nem is minősíteném: a Java sebességével irtózatos gondok vannak; a Java egy bloated csigafosrakás, csak azért tűnik gyorsnak egy-egy Java program, mert manapság iszonyat gyors gépeink vannak.
Igen BASIC interpretert simán lehet írni Speccyre, de minek? Az már benne van a Speccyben. Csak ugye "jó gyors". Na, így lehet elképzelni a bye bye assembly-t egy Speccy-n: sehogy.
Utánanéztem a Perl-nek; az sem gépi kód szintű gyorsulás, hanem egyszerűen csak megint egy jó erős PC-n futtattad a tokenizált bytekódot. Speccy-n ez baromi lassú lenne, ahogy leírtam az előző posztomban.
E-Mail
Sauron
2019.07.10. 00:15:08
Hanem olyasmire, amit a fox talalt fel annak idejen a pc-n, hogy atmeneti kodot, biz objekt kodot generalt ami pici volt es gyakorlatilag ugyanolyan gyors, mint a leforditott, mert overlaybol vagy a rak tudja honnan huzta be a szukseges funkcio vagy gepi kod snippeteket futaskor. Foxpro hasonlokepp mukodik, irsz egy eleg nagy programot tobb szaz kepernyovel meg riporttal meg logikaval es egy viszonylag kicsi, par szaz k filet general. Exet is lehetett generalni de nem volt ertelme , ugyanolyan volt a sebessege, csak tobb megabyte lett.
A java is a byte.kodjaval hasonlot csinal es nincs komoly gond a sebessegevel. Gepi kod persze gyorsabb, de eleg gyors a java is majdnem mindenhez.
Erre gondolok, ugyes kis byte kodot generalo rendszer amihez szinten kicsi, igeny szerint particionalt overlay lib van. Vagy, alap esetben az se, es elbol interpretal, ami a vicc kategoria, ahogy irod, de a vicc is lehet megfelelo sok esetben, pl irto sok basic ben vagy basic es nemi gepi kod keverekevel irt.jatek es user progi is van es.koszonik jol vannak.
A perl is alapbol interpretalt de a browserben lassu volt ezeet a mod perl apache libet hasznaltuk amivel gepi kod szintre gyorsult a joszag, forditas.nelkul.
E-Mail
Sauron
2019.07.10. 00:08:34
Interpretalas. Nem direkt forditasra jitre gondolok.
E-Mail
Sauron
2019.07.10. 00:08:03
Abban igazad van, hogy a column store adatbazis technika, de eppen az teszi lehetove a dramai hatekonysagu tomoritest.
A sajat adatteszteimen infobrighttal 10 1 hez siman elertem es ez a rendszer alap metricje is, ennel rosszabat csak nagyon specialis adatok eseten kapsz, pl binaris vagy kep, de most itt en elsosorban szoveges illetve numerikus adatokrol es idosorokrol beszelek.
E-Mail
Sauron
2019.07.10. 00:01:32
Hat azert mondom. Adattarolasrol beszelek, adatot lehet tarolni tobbfelekeppen. Ha column storeba szervezed, akkor altlagosan 10 1 tomoritesi aranyt erhetsz el, neha sokal nagyobbat, akar 40 1 is. Szoval az adatokat mint pl nevsor, szul evek, fizetes stb kepzeld el adstnak, es kulonbontva az adstelemeket teljes oszlopot tarolni. Csinaltam ilyet linuxon, jol mukodoty egyszeru fileokkal is es binaris keresessel.
E-Mail
TCH
2019.07.09. 21:17:56
10:1 arányban tömörít kicsi CPU igénnyel...ezeket te honnan szeded? Kezdjük azzal, hogy a tömörítés hatékonysága nem csak az algoritmuson múlik, de a tömörítendő adatokon is. Ennek megfelelően generikus 10:1 arányú tömörítő nincs. A column store pedig teljesen más, nem is értem, hogy jön ide, hiszen az egy DB tárolási megközelítés, nem tömörítés.
Ami pedig az interpretált futtatást illeti, az meg tényleg a totál vicc kategória... Szerinted egy interpretált magas szintű kód mikor lesz gyorsabb, mint a gépi? Megmondom: soha a büdös kurwa életben. Az interpretált kód egy-egy elemi utasítása akár több tíz, vagy akár több száz gépi kódú utasításból is állhat. Nincs okos interpreter, ami elég gyorsan fut. Olyan van, hogy JIT, de az pont az, hogy az interpretálandó kódot megfelelteti gépi kódú utasításoknak, tehát ott vagyunk, ahol a part szakad.

Olyat lehet, hogy lecseréled a 16k ROM-ot, de akkor megint eljutottunk oda, hogy bővítünk és akkor meg már miért nem úgy bővítünk, hogy legyen értelme is, csak akkor az éppen már nem Speccy lesz.
E-Mail
Sauron
2019.07.09. 14:51:08
A tomoriteshez egy otlet. Szerintem a legnagyobb elorelepes a programozasban az objektum kod vagy egyenesen interpretalt kod gyors futtatasa. Ha lehetne irni egy ugyes ertelmezot speccyre, ami eleg gyorsan fut (na nem mint a basic) akkor bye bye assembly es a kapott kodot pedig irtozatosan ossze lehet tomoriteni. Szoval mondjuk 16k rom helyett 16k okos.interpreter, es a 48 k ban pedig akar 640 k-nyi tomoritett kod.
E-Mail
Sauron
2019.07.09. 11:42:51
Illetve ne.feledjuk a 16k romot siman felul lehet irni egy kulso megoldassal, es gondolom akar tobb-bel is, szoval akkor az egesz 48k megmarad tomoritett adatnak es programnak.
Volt egy jatek, a Shadow of the Unicorn a Micro Gen tol, ami egy 16k interfeszt tartalmazott pontosan erre a celra. Radugtad a spectrumra, atlapozta a Romot, es kaptal egy 64k jatekot. Csak megjegyzem, beletehettek volna 10 16k romot is, es akkor az mar joval nagyobb, csak nem arra ment a fejlodes.
E-Mail
Sauron
2019.07.09. 11:36:39
A tomoritessel kapcsolatban nem hagyomanyos huffman es tarsaira gondoltam, hanem egeszen masfajta tomoritesre, ami az adatmintakat akar 10:1 aranyban tomoriti igen kicsi cpu igennyel, a kicsomagolas pedig gyakorlatilag nem is nagyon igenyel cput. Ott vannak a column storeok, ezek mind ilyen alapon mukodnek.
E-Mail
Sauron
2019.07.09. 04:58:24
Egyebkent irod video kezeles. En csak szoveges modban gondolkodtam, abbol is meg ablakokban sem, csak ket harom nyavajas terminalablakban.
E-Mail
Sauron
2019.07.09. 04:56:54
Hat igen. Szomoru vagyok. Most egy darabig nem megyek falnak...
E-Mail