Új üzenet küldése








FUCK SPAM!

Sauron
2019.07.10. 23:40:48
Jo hat en ertem es sajnalom ha meguntad mert en szeretek ilyesmirol ertekezni. Ha pontatlant is irtam, az megesik, akkor javitom,.hisz ez a kommunikacio, ket fel informaciot cserel es neha meg kell allni,.korrigalni,.mit.is.mondott a.masik,.esetleg.hiba is.lehet.benne. az.objekt kod eliras.pl,.oda.a.byte.kodot.jellett vokna irjam de ez szerintem nem perdonto.
A tobb reszben postolasert es.h8bakert elnezesed kerem de a telefonon nem konnyu foleg miota ninca normalis keyboard csak ez az.on screen szar, es.mikor nagyon hosszut irsz, nem.latom az.egeszet egyben hogy egeszben valaszoljak. Plusz.itt vannak ezek a franya alagutak meg aluljarok ahol total eltunik a service, es ha nem.kuldom el gyorsan,.akkpr neha elvesztem az egesz cuccot amit irtam.
En azert.hiszek a.dologban es.a kedvem is egyre jobban megjott ennek valamifele kidolgozasahoz.legalabbis eloszpr is elvben.
E-Mail
Sauron
2019.07.10. 23:33:34
Illetve ha a valtozok pl var0..255 akkor a tomoritesem csak a szamot fogja tarolni mint kulonbseg, amit meg meg leheet azzal is spekelni hogy a szamot mondjuk 1 byteon tarolja tehat egy azonosito max 256 db, es akkor mindegyik csak 1 byte lesz a vektorban.
E-Mail
TCH
2019.07.10. 23:27:54
Az XT nem volt sebes gazella, csak épp egy cca. másfélszer gyorsabb (4.77/6 MHz) 16-bites (8088/286) CPU volt benne (kb. 4x-es különbség), meg 13x annyi RAM (640k), mint a Speccyben... Ja és nemhogy floppy, de még HDD is volt benne. Végülis éppenséggel nüansznyi a különbség közte és a Speccy között...olyan laza tíz-tizenötszörös erőfölény az XT javára.

Direktben értelmezte, ja a tokenizált bytekódot. Az előbb mutattam meg, hogy amit te beírsz, az a Speccyn sem szövegként van a memóriában, mert azonnal parseálja és tokenizálja.

Én nem azt írtam az object code-ról, hogy az is csak egy byte kód. Azt írtam, hogy az egy konténer, amiben byte kód is lehet, meg gépi kód is, akár vegyesen, meg különféle metaadatok a különféle linkelésekhez... Ott valaminek lenni kell, ami a gyorsaságot biztosítja? Igen, azok a szekciók, amik gépi kódban vannak. Nem tudom ennél már egyértelműbben, vagy egyszerűbben leírni és nem is fogom. Ugyanazokat a köröket futjuk újra és újra. Legalább ötször írtam már le mindent, legalább ötfelől cáfoltam már mindent, de te csak mondod ugyanazt, újra és újra, hatodjára is... Én viszont meguntam.

Sz*rk: Megint alámpostoltál, mert szokás szerint megint hat darabban küldöd el, amit írsz. Ez amit írtál, soha a büdös életben nem fog emberi sebességgel futni a Speccyn, de ezt is leírtam már. Egy pécén futó Fox elszórakozhat ezzel, ott van rá elég kakaó, de ezt is leírtam már. És ez még mindig nem column store és nem is hasonló, de ezt is leírtam már. Mindegy, hagyjuk, mondom én már unom ugyanazokat a köröket futni.
E-Mail
Sauron
2019.07.10. 23:21:27
Column store es.szotar.
Szerintem felreertettel. Nem csupan szotarrol beszelek. Column store hoz az.elv hasonlo amit kigondoltam, de nem egyertelmuen az. Minden szo egy oszlop, es a vektor pedig a szo elofordulasi helyet jelzi, mondjuk valami kalkukacioval ami vagy sima poziciot vagy akar oldal per szo poziciot jelent. Igen, keves szoval szamolok, DE hasznalnek hozza egy run lengh compressionnal tomoritett vektort, ahol a szavak sorba vannak rakva, es csak azt a reszet kell egy szonak odairni, ami mas az elozotol. Igy tomoriti peldaul a foxpro az akkor meg uj compact idx eket,.visszafejtettem onnan tudpm. Szoval nem csupan standard column storra gondolok hanem egy specire ahol a oszlopok ertekeit a tomoritett vektorbol, azok elofprdulasait pedig mar a column storehoz hasonloan a vektorbol veszem.
A szavak elofordulasi szamanak korlatoltsaga nem olyan nagy baj szerintem mint leirod, oda kell kicsot fgyelni a valtozo nevekre es szamokra de kisebb scriptekben amugy sincs sok es ha.igen irjal.ujat, abban meg megint ismetlodhetnek a nevek.
E-Mail
Sauron
2019.07.10. 23:10:54
Hat amikor en hoskodtem a speccyvel, interpretalasnak azt hivtuk, amikor a gep direktben ertelmezett (forditott) es futtatott basicet. Ebben a parsing nyilvan mar benne ertendo
Ugyszinten, a dbase 2 meg 3 is ezt csinalta. Viszont az az objekt kod amirol irogatok, mas volt, es ertem,.azt irod,.hogy az.is csak egy byte kod, de megis.nagysagrendekkel gyorsabban futott, mint peldaul a dbase 3, es.fuggetlenul, hogy mennyire gyorsabb gepen. Szoval azert.ott valaminek lenni kell ami a gyorsasagot.biztositja, mert a gyorsasag elkepeszto volt es nem.volt nagy kulonbseg egy pascal vagy c bol exet gyarto gepi kod sebessege es a fox kozott.
E-Mail
Sauron
2019.07.10. 23:04:26
Az nem baj hogy x86, a xt se volt valami sebes gazella, es ami megy nagyobb gepen, tobbszorosen bizonyitottak, hogy bar egyszerusitesekkel, de atultetheto kisebbre is. Az allitas onmagaban semmit se bizonyit.

E-Mail
TCH
2019.07.10. 17:40:36
Nem érted meg, hogy a Fox az x86-on futott neked elfogadható sebességgel?

Mi az, hogy a forrás interpreter, meg a java byte kód között nincs különbség? Ez a mondat teljesen értelmezhetetlen.
A forrás átalakítása a gép által emészthető formátumra, az a parseing. A bináris kód futtatása, az az interpreting. A compiler az a fordító, az egyikről fordít a másikra. A Perl nem olyan gyors, mint ha lefordítottad volna gépi kódra, hanem erős hardware-en futtattad és nem érzékeled a különbséget. Már sokszor leírtam ezeket. Mi az, hogy nem egyenesen interpretál, hanem "objekt kódot" csinál? Ezt is leírtam, hogy mindennemű bináris kód futtatása interpretálás. Meg mit kevered ide állandóan az object code-ot, mintha az valami harmadik féle kód lenne, amit varázslatosan nem a CPU futtat és nem is software-es interpreter? Ilyen nincs. Egy kód vagy hardware-esen, vagy software-esen van interpretálva. Én úgy látom, hogy az alapfogalmak sincsenek meg:
- Gépi kód: Az a kód, amit a CPU egy az egyben futtatni tud.
- Bytekód: Az a kód, amit egy szoftveres interpreter futtatni tud.
- "Objektumkód": Egy konténerfájl, amiben szeparált "objektumok" vannak, amik vagy bytekódot, vagy gépi kódot tartalmaznak, vagy pedig különféle metaadatokat arra vonatkozólag, hogy az objectet hogy lehet összekapcsolni más objectekkel, hogy vagy gépi, vagy bytekódot fordítson belőle.
Nincs harmadik féle kód. Szoftveresen vagy hardware-esen interpretált kód van és ez vonatkozik a Perlre, a BASIC-re, meg mindenre. Mindenre is. Vagy bytekód, vagy gépikód. Gépi kód sebességgel, meg semmi nem fut. Semmi se. Csak a gépi kód. És minél kisebb a hardware teljesítménye, annál nagyobb lesz a sebességkülönbség a gépi kód javára.

Ez amit te írsz, ez nem a DB féle column store, ezt úgy hívják, hogy szótár. Ez egy mezei lista (tömb) a szavakról, amiből egy indexszel ki lehet választani egyet. Igen, így is lehet tömöríteni szövegeket, de ez azzal jár, hogy nem tudsz akármit leírni, csak ami a szótárban van. Ez az egyik. A másik meg az, hogy ellentétben a byte-alapú tömörítéssel, ahol a tree maximum pár byte lesz, itt a szótár vaskos kB-okat fog felfalni, hiszen valahol tárolni kell a memóriában azt a többezer szót, hogy lehessen velük dolgozni, nem? 2000 szó, ha, átlagosan 5.1 karaktert számolok egy szóra + terminátor byte, akkor 2000 * 6.1 = 12200 byte. Ami egy 48k-s Spectrumban sok. És ez ugye a dinamikus hosszúságú szavak miatt szükségszerűen szekvenciális keresést igényel, ami kurwa lassú lesz. Ha pedig fix hosszúságú szavakat használunk, hogy a keresés gyors legyen, akkor meg vagy az van, hogy minden szót csonkolva kell használni, vagy pedig még több helyet zabál a lista. Vagy lehet a dinamikus hosszúságú szavakra indextáblát csinálni. Az újabb 4000 byte.
Ennek megfelelően egy kalandjátékban még csak-csak elmegy egy ilyen technika, de egy shellben? Egy játéknál minden erőforrást felhasználhatsz, de a shell-nél ugye kéne, hogy maradjon másnak is, elvégre multitasking OS-t akarsz, nem?
Forrástömörítésre a szótár alapú tárolás meg kb. teljesen alkalmatlan, ahol a változókat, eljárásokat úgy nevezed el, ahogy akarod. Ha meg elkezded butítani az egészet, hogy csak pár parancs legyen, meg pár lehetséges argumentum, hogy a tokenizált kóddal elbírjon a hardware, akkor előbb utóbb eljutsz a Sinclair BASIC szintjéhez és feltaláltad a kereket. Sok értelme volt.
E-Mail
Sauron
2019.07.10. 17:06:30
Tehat mod perl nem interpretalt hanem forditott, szerintem a java is de olvasni kell rola hogy a jvm-ben igazan mi is tortenik...
E-Mail
Sauron
2019.07.10. 17:05:19
Csak kis info a mod_perl rol, ami kompilalt, de ezt valahogy iszonyatosan gyorsan, lathatatlanul teszi. https://perl.apache.org/docs/2.0/user/intro/overview.html

" This port enabled mod_perl to compile and run in a threaded windows environment, with one major caveat: only one concurrent mod_perl request could be handled at any given time"
E-Mail
Sauron
2019.07.10. 16:45:57
Column store. Valoszinuleg nem ertjuk egymast, mert a chat egy tokeletlen kommunikacios forma.
Leirtam alabb mire gondolok. A tarolas egy dolog, lenyeg, hogy irto tomor, es abbol bizzony az egesz forraskodot vissza tudod nyerni. Ez a lenyeg. Masfajta tomoritessel ezt nem nagyon lehet szeintem megcsinalni.

A tomorites hufffman nal is valami ertelmezesi kulonbseg van kozottunk mert bizonyosan tomorebb par szaz szot tomoriteni, raadasul rendezetten, mint azok karaktereit , raadasul rendezetlenul (huffman). Nem tudom hogyan examplifikaljam jobban mukodo pelda nelkul, de pl kb hasonlot hasznalt a szoveges kalandjatekaiban eloszor a Level 9, aztan mindegyik szoftver haz aki lemasolta. Mert a kaland progiban is van kb mondjuk 2000 szo, es azokra valo 2 byteos hivatkozasokat letarolva es a darabszamot igen nagy tarmegtakaritast ert el emberunk, ha jol emlekszem ketszer annyit tett a 48k-ba mint lehetne, mert kulonben az epikus meretu jatekai mint Worm in Paradise meg Color of Space meg Adrian Mole stb nem birtak volna mukodni. Illetve maradt helye, hogy nemi grafikat is becsempesszen ami igen jol hatott.
Ez a technika korabban ismeretlen volt, o talalta fel, elotte az Adeventure meg tarsai szanalmas meretuek voltak, meg a Hobbit se hasznalt semmifele tomoritest amennyire en tudom, es hat kicsike is volt.
E-Mail
Sauron
2019.07.10. 16:39:25
Szoval java vm. Ennek utana kell olvassak mert bevallom nem ismerem a reszleteit. De nem vagyok meggyozodve, hogy nincs kulonbseg a forras interpreter es a java byte kod kozott. kell lenni, mert javac compiler is csinal valamit ugyebar. Illetve a perl is alapbol kicsit (nagyon, nezopont kerdese) lassu, de mod perl olyan gyors mintha leforditottad volna gepi kodra, es meg sincs ilyen lepes. Tehat nem egyenesen interpretal, hanem valamilyen modon objekt kodot csinal, ami gepi kodhoz hasonlo sebesseggel akar tobb szalon fut. Ezt mondhatom egesz bizonysaggal mert eleg sok ilyen web szervert es mod perles applikaciot futtattam.
E-Mail
Sauron
2019.07.10. 16:36:33
Szia TCH,

Egyetertek a gepi kod sebesseg csusztatas de azert irtam mert ha veszed a fox-ot akkor amit abban irtal, es az nem igenyelt (eroteljes) forditast, ugy futott a progi (a hatter overlay libeket hasznalva) mintha le lett volna forditva es szerkesztve gepi kodra. A tobbi xbase termek ezert kicsit hatterbe szorult mert pl a Clipper meg sokaig keptelen volt exe gyartas nelkul, ami egy hosszadalmas es CPU terhes folyamt volt, futtathato programot gyartani. Aztan ott a dbase 3 meg akar a 4 is amik irto lassuak voltak, valszeg mert direkt interpretalt nyelv volt, ok se etudtak az objekt kod futtatast megoldani (igy kell hivjam mert tobb mint forras kod de kevesebb mint gepi kod)
E-Mail
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