Fejlődik a C, avagy struktúrák másolása

Fórumok

Adhattam volna címnek azt is hogy „újszülöttnek minden vicc új”, vagy hogy „ma is tanultam valamit”...

A lényeg ez a titokzatos sor (én írtam):

//tokencopy(f,g,g+1);
f->T[g]=f->T[g+1];

Mármint, ugye nem 1 hanem 2 sor. Ezek egy általam írt programban vagynak benne (a legújabb programnyelvemről van szó de tökmindegy). Előbb azt a sort tettem csak bele ami itt ki van kommentezve. Ez ugye egy (globális)függvény, ami annyit csinál, hogy egy struktúrákat tartalmazó tömb 2 elemét átmásolja, a g+1 -ediket a g-edik elembe, annak régi tartalmát felülírva. (Az "f" is egy struktúra amúgy, de most nem arról van szó, hanem a T tömbről aminek az elemei struktúrák maguk is). Persze senki ne gondoljon olyan böszmeségre, hogy a struktúra minden mezőjét külön másolom, csináltam 2 pointert mindegyik struktúra kezdetére mutatva, majd castoltam őket unsigned long long * típusúra, aztán egy ciklussal át lett másolva minden unsigned long long érték, a ciklus addig ment amennyi a struktúrám sizeof() értéke... Így jó lesz akkor is ha a struktúra mérete megváltozik. Arra kell csak ügyelnem, a mérete mindig az unsigned long long méretének többszöröse legyen.

Na de ez majdnem mellékes volt. A lényeg tehát hogy ezt a függvényt megírtam, amikor jött egy fura ötletem. Az, amiért kikommenteztem a tokencopy sort ami meghívná a függvényemet s leírtam helyette az alatta levő sort. Mert hátha van már olyan okos a C nyelv hogy képes ő maga is struktúrákat másolni... Tudtam ugyan, az eredeti Kernighan/Ritchie könyv szerint struktúrák esetén az egyetlen művelet a pointerük képzése, de a C++ esetén már rég úgy van (amennyire tudom legalábbis) hogy képes a struktúrák másolására. Gondoltam, hátha ezt az okosságot átemelték már a C nyelvbe is azóta!

És voila, behold meg hasonlók - simán lefordult a programom így is, még csak nem is warningolt!

Lehet hogy most megkapom a trolloktól a kiosztást hogy ez ilyen meg olyan ősrégi feature már, miért is nem tudtam róla korábban... Hja, kérem, nekem senki nem oktatta a progranyozást főiskolán, magam tanultam, És az eredeti Kernighan könyvből. Az, hm, talán mégse a legújabb verziója a C nyelvnek... Szóval, ezt most fedeztem fel és kész... De örülök neki! Nagyon jó kis feature.

Jó pap holtig tanul ugye. Sőt még az is aki nem pap.

Hozzászólások

Szerkesztve: 2020. 10. 21., sze - 07:27

Nem ismerem a változók típusait.
A kontextusból kiragadott 2 sorod alapján nem látom, hogy miben több ez sima értékadásnál.

Nem tobb, sima ertekadasrol van szo. Viszont az nem minden nyelven mukodik, es nem minden tipusra (van, hogy referenciat/pointert masol, van, hogy copy construktort hiv, vagy hibat dob, stb..). C-ben strukturara epp mukodik, ezt realizalta epp Poli.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

AFAIR ez mindig is mukodott strukturara. Talan meg a K&R konyv szerint is, de nem emlekszem, reg olvastam mar. Mindenesetre jo feature.

Egyebkent ha nagyobb dolgokat akarsz masolni, nem kell long long-os hackkel szorakozni, van memcpy fuggveny is!

void *memcpy(void *dest, const void *src, size_t n);

Illetve ott a memmove tarsa, arra az esetre, ha az src es dest atlapolodhat. Ha szerencsed van, akkor az architekturadon olyan az implementacioja, ami a DMA vezerlot hasznalja, es sokkal gyorsabb (es CPU kimelobb) is lesz.

A konyvedhez meg hajra! ;)

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Ha userspace, akkor olyasmit kereshetsz mint a `man 2 splice`, de DMA az annyira hardverkozeli, hogy csak zeng. 

Ugyanakkor persze a dolog letezik oprendszer szinten. Pl beagyazott MCU-knal is mar vannak effele featurak ahol siman "belefer" hogy a kedves felhasznalo igy masol(gat) adatokat a memorian belul, es akkor a DMA host controller szol ha kesz. STM32F4-esen pl mar jatszasbol csinaltam ilyet, elesben (eddig meg) nem kellett. 

Közelítünk ... a splice() picit másabbról szól, de már közelít.

Igazság szerint kettő dolog is jól jött volna egy régebbi melómnál:
   a.) nagyobb adatmennyiség kópiája a CPU szabadon hagyásával (RAM --> RAM)
   b.) realloc() szerű dolgoknál ha elfogy a folytonos logikai cím, másik logikai címen kell elérni. Ez nem csak másolással oldható meg, hiszen ott az MMU. Gyorsabb lenne a realloc() ha lenne ilyen MMU-s rendszerhívásra lehetőség. Nagyobb adatblokkok move-olásánál szintén sokat gyorsítana az MMU-s trükk.

Lehet, hogy csak az én figyelmemet kerülte el, ezért kérdezem hogy tudunk-e a.) ill. b)-re CPU-t elkerülő okosságot.

Illetve:

realloc() szerű dolgoknál ha elfogy a folytonos logikai cím, másik logikai címen kell elérni. Ez nem csak másolással oldható meg, hiszen ott az MMU. Gyorsabb lenne a realloc() ha lenne ilyen MMU-s rendszerhívásra lehetőség. Nagyobb adatblokkok move-olásánál szintén sokat gyorsítana az MMU-s trükk.

Olyan rendszerhivas hogy malloc() meg realloc() meg free() nincs. A libc az mindig az adott hardver lehetosegeit nezi, es egy (P)MMU-s architektura felett ott van joesellyel az mmap() meg mremap() meg az munmap() ugyanerre a celra. Az meg mar pontosan azt csinalja amit mondasz. A malloc() meg a mmap() es baratai altal adott memoriat fragmentalja meg tovabb igeny szerint. 

Tehát ezek szerint a libc-s realloc() ha elfogy a folytonos logikai cím, akkor az új logikai címtartományra való átállást minimális adatmásolással oldja már meg és másolás helyett ma már inkább az MMU-ra támaszkodik?
Na ezt kimérem x86_64 és AArch64 architektúrákon. Ez öröm lenne.

$ apt source glibc

glibc-2.32/malloc/malloc.c  3150. sora körül. Sajnos ha új logikai memóriacímmel tér vissza, az adatátrakáshoz memcpy()-t fog használni.
A memcpy-t pedig a glibc-2.32/sysdeps/x86_64/multiarch/ mappában találod x86_64-re. Sajnos csak assembly-ben optimálisra gyúrt SSE regiszteres másolást látsz benne, rendszerhívást nem.

Pedig olyan szép lenne
   - DMA elérése másoláshoz
   - átrakásnál pedig MMU és a teljesen kitöltött 4k lapokat másik logikai címre mappelni.

... ha már az architektúra tud ilyen szépségeket.

Nem csak ezert mert OS limit, ott van is neha ertleme, nagy gepen kevesbe.

micro controller orajele nagyon alacsony es memoria is tobb portos is lehet,
csak core -ok nem is biztos, hogy el tudjak foglalani a teljes lehetseges savszelt.

Egy desktopon, egyetlen szal is megkozelitheti a max memoria savszelleseget, 2 -nel meg el is fogyott.

Kis adat menyiseg eseten, DMA -nak elmagyarazni, hogy csinaljon valamit tobbe kerulhet.

Tegyuk fel hogy egy PC/server -ben raveszed a DMA enginet, hogy masoljon neked,
cserebe elveszi toled a memoria hozza ferrest (vagy csak a savszel nagyat).
Mit nyertel ? lehet hogy mar mW -al kevesebbet fogyaszt, nem latszik a topban, hogy a process enne CPU -t, de
ha tobb szalu az appod, az a szal var a masolasra aminek tenyleg  kell, valoszinuleg semmit sem vesztettel.

Ha eszkot kersz meg bus mastringre, akkor neki a savszellesege joval alacsonyabb (PCIe vs memory bandwith).
 - jobban kihasznalja a PCIe busz adta frame meret lehetosegid
 - (*mov*,..) utasitas altal masolas device access latency -t kapna, ami joval hoszabb varakozas, mint a memoria eleres.
        (spicialis cache flagek kellenek ahhoz, hogy okosan flusoljon, egyebken eleg buta, eszkoze valogatja)

A lassabb eszkozok DMA -val valo kezelese micro controlleren is megeri -> kevesebb core wakeup kell.
Tobnyire pont hogy a lassu eszkozoknel erdekes ;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"micro controller orajele nagyon alacsony" ... sok mikrovezérlőnek alacsony az órajele (< 80 MHz), de némelyike a zabálós Pentium4 alapú asztali PC procit is túlszárnyalja számítási sebességben.
https://www.st.com/content/ccc/resource/sales_and_marketing/promotional…

Megváltozott ez a piac is. Az biztos, hogy a mikrovezérlő olyan jószág, amelyben a CPU+flash+RAM IC-n belül található. Belső RC oszcillátorral külső alkatrész nélkül, mindössze tápellátás biztosításával képes futni.
De ha valahova kell erős darab, akkor a gyengébb egykártyás számítógépeket is bőven maguk mögött hagyják számítási teljesítményben a mai legerősebb mikrovezérlők.

A konyvedhez meg hajra! ;)

Köszi, bár attól tartok elírtad, és a programnyelvemre gondoltál... Bár, ettől még természetesen valóban dolgozom könyvön, nem is egyen. Nálam egészen természetes hogy egyszerre sok regényt írok. Bár bevallom, egyetlen regény csak az már amit igazán szeretnék befejezni, az amelyikben azt írom le, hogyan tanultak meg a tündéreim varázsolni... Ezzel bizonyos értelemben „teljes” lenne a sorozatom. Ekkor már hogy úgy mondjam „nyugodtan halhatok meg”, ha akármi is történik. Az összes többi leendő regény mind olyasmi ami csak kiegészítés, mindenféle mellékszálak, stb.

Visszatérve a struktúrákra: majd ha ez a programnyelvem már jól működik, kipróbálom a memcpy megoldást is, de tulajdonképpen ez nem egy sebességkritikus rész a nyelvemben, eleve az egész struktúra csak 128 bájt méretű (illetve, valamivel kisebb ennél is), ráadásul bár ez a másolási művelet többször lefut, de kizárólag a tokenizálás alatt. Vagy hogy pontosabban fogalmazzak, a szintaktikai elemzés során. Szóval amikor a program fut, akkor már nem. Azaz nem érdemes agyonbonyolítani. Bár eléggé sebességmániás vagyok, tudom magamról is, de itt tényleg fontosabb az olvashatóság, az áttekinthető kód.

Amúgy, ez a nyelvem különben se lesz sebességbajnok. Előre tudom, az eddigi nyelveimen szerzett tapasztalataimból, „érzésre”, hogy a natív kódnál 20...50 -szer lesz lassabb, legvalószínűbben olyan 30 környékén... Persze feladattól függően. De nem izgat, mert ez épp arra van/lesz kihegyezve hogy a sebességkritikus részeket a Felhasználó C/C++ -ban kell megírja hozzá. (illetve bármilyen neki tetsző nyelven amin lehet libraryt írni).

Ez a nyelvem garantáltan használhatatlan lesz ugyanis önmagában. Ez egy keretrendszer lesz, ami arra való hogy mindenki megírhatja benne a neki tetsző nyelvet, hehehe... Nyilván persze megteszem ezt én is, írok benne egy a Furorhoz nagyon hasonlót hogy demonstráljam a lehetőségeket, de ez bizonyos értelemben már nem lesz a keretrendszerem része. Ugyanis rengetegfajta más nyelvet is lehet majd alkotni arra épülve. Ezzel kihúzom a kritikák méregfogát nagyobbrészt. Akinek nem tetszik a nyelvem, definiálhat más, neki tetszőt az „alapokra” épülve. Akár infix notation jellegűt is, ha neki nem tetszik a verem alapú. A verem attól még ott lesz, de ha nem akarja, semmit nem fog észrevenni belőle.

Na de ezt fejezzük is be, nem akarok egy újabb vitát a dologról senkivel se, csak ha már „jókívánságoskodtál”...

Amit ismét köszi.

Én is menet közben jöttem rá, de sok éve használom már a struktúrák közti értékadást.

> Sol omnibus lucet.

Az ANSI C (c89, ld pl: gcc: -std=c89, -ansi) mar tudja ezt architektura-fuggetlenul. Szoval legalabb ~31 eves featura :) 

Még régebbi, épp hogy kimaradt a K&R-ből: http://cm.bell-labs.co/who/dmr/cchanges.pdf. 1978, 42 éve.

Előkaptam egy PDP-11 emulátort, Unix V7-tel, 1978-ból:

# Restricted rights: Use, duplication, or disclosure
is subject to restrictions stated in your contract with
Western Electric Company, Inc.
Thu Sep 22 05:49:30 EDT 1988

login: dmr
$ ls -l /
total 643
drwxrwxr-x 2 bin      2512 Sep 22 05:32 bin
-rwxr-xr-x 1 bin      8986 Jun  8  1979 boot
drwxrwxr-x 2 bin       160 Sep 22 05:47 dev
drwxrwxr-x 2 bin       336 Sep 22 05:49 etc
-rwxr-xr-x 1 sys     53302 Jun  8  1979 hphtunix
-rwxr-xr-x 1 sys     52850 Jun  8  1979 hptmunix
drwxrwxr-x 2 bin       320 Sep 22 05:33 lib
drwxrwxr-x 2 root       96 Sep 22 05:46 mdec
-rwxr-xr-x 1 root    50990 Jun  8  1979 rkunix
-rwxr-xr-x 1 root    51982 Jun  8  1979 rl2unix
-rwxr-xr-x 1 sys     51790 Jun  8  1979 rphtunix
-rwxr-xr-x 1 sys     51274 Jun  8  1979 rptmunix
drwxrwxrwx 2 root       32 Sep 22 05:48 tmp
drwxrwxr-x12 root      192 Sep 22 05:48 usr

$ cat t.c
struct Foo {
  int x;
};

main() {
  struct Foo a;
  struct Foo b;
  a.x = 42;
  b = a;
  printf("answer: %d\n", b.x);
}
$ pcc t.c
t.c
$ ./a.out
answer: 42

Szóval valóban tudta a struct értékadást.

Eléggé félrevezető a cím, plusz lemaradt a [HK] is belőle...

Ja. Régen volt már. Tanították, hogy a felesleges másolások elkerülése érdekében inkább pointereket használjunk nagyobb méretű adatok kezelésénél.

Gondoltam érdemes megnézni, hogy mit kezdenek vele a fordítók, különösen ha "sok" adatot kell átmásolni. Szerencsére mindenre van online tool, összehasonlítás a gcc, clang és msvc fordítókkal x86-64 targetre.

Ha a struktúra megfelelően kicsi, akkor nagyjából ugyanazt csinálja mindhárom, szépen átmásolja 8 byteonként az adatot. Abban nincs egyezség, hogy mi számít kicsinek, ez a gcc-nek 256, a clangnak 32, az msvc-nek csak 8 byte. Továbbá apró különbség, hogy a gcc egyszerre két regisztert használ, a clang és az msvc csak egyet.

Ha a struktúra megfelelően nagy, akkor nagyobb az eltérés. A gcc és az msvc a rep utasítást használja, előbbi movsq, utóbbi movsb utasítással. A clang egyszerűen meghívja a memcpy-t.

A C fordítást érdemes minimum -O2 -vel végezni, ha életszerű tempó is kell.
A fenti példát korrigálnám:
    https://godbolt.org/z/zqdvKK
    https://godbolt.org/z/6v4Y33

További demó, ahol szintén jól látszik a C fordítási opció általi eltérés is:
    https://c.godbolt.org/z/Mjfja3
    https://c.godbolt.org/z/r4GhnW

Rust esetén pedig így fordul, fordítási opciótól függően:
    https://rust.godbolt.org/z/MT6oK7
    https://rust.godbolt.org/z/MG5h6P

Jól megfigyelhető, hogy például az utolsó példánál az AVX regiszterbe szívná be/pumpálná ki az adatot, de ha általános kódot fordítasz, az bármely x86_64-en el kell hogy fusson, tehát a Core i3..i7-en kívül például egy j1900-as Celeron procin is, amiben nincs AVX. Ergó alapértelmezetten csak a közös utasításkészletből építhet bele.

A klasszikus x86-nál ez még szemléletesebb. A sima -O2 mindenféle architektúrabeli engedély nélkül tényleg csak azokat az utasításokat fogja beépíteni, ami i386 ... a mai prociig mindenhol megvan. Ez a korlát pedig meglátszik a futástempóban, főleg jelfeldolgozás esetén. Itt ha tempósabb kód kell, akkor muszáj a fordítónak az "optimalizálj!" kapcsolón túl megadni az engedélyt arra, hogy bizonyos architektúrát meghaladó vagy definiált utasításkészletet felhasználhasson.

De pont erre van az -march kapcsoló, az -O-nak enélkül nincs értelme, mert mihez optimalizálod. Nyilván, ha AVX-es procira akarod fordítani, akkor annak az architektúrakapcsolóját adagolod be.

Az x86-ot meg ezért is irtják tűzzel-vassal. Nem a 32 bit a baj, hogy az kevés lenne, hanem túl nagy időtávot foglal magában, i386-i786-ig, és elég nehéz előfordított binárisokat optimalizálni. Előbb az i386-ot dobta a legtöbb disztó, aztán az i486-ot, majd utolsóként a nagyok közül a Debian az i568-ot. Már a 32 bitet támogató disztrók mind i686-osra vannak fordítva, de ennél is nehézség, hogy még MMX-et sem lehet feltételezni, nem hogy SSE-t. Míg x86_64-nél pl. biztosan van SSE2 is.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

A -O2 -nek és társainak mindenképpen van értelme. Például az alábbi kód C-be is szépen végigszimulálódik -O2 hatására és a futásidejű ciklus helyett csak az eredmény jön vissza.
Rust esetén szintén amit a fordító a -O hatására ki tud számolni, azt kiszámolja fordításkor. Az hogy használhat-e AVX-et azokhoz, amiket futásidőben kell hogy számoljon, az a -march=....

https://c.godbolt.org/z/aMzhbn
https://rust.godbolt.org/z/v6hdj1

Megjegyzem, a -march=... x86, x86_64 és AArch64 esetén megy frankón, ARM32 esetén úgy nézem a GCC-ben hatástalan a -march=..., helyette -mcpu=... -mfpu=neon-.. opciók kellenek.
A 486-ra azért limitálták hamar a Linux kernelt + glibc-t, mert a CMPXCHG atomi utasítás még nem volt a 386-ban. A szemaforozást ez a félbeszakíthatatlan utasítás nagyon egyszerűvé teszi. A pentiumokban szintén bejött néhány jóság, amire hatékony támaszkodni.

Köszi a tippet. Azt hittem eddig, a -O2 esetén magától is van annyi esze a C nyelvnek hogy eleve arra az architektúrára optimalizáljon amire ő maga is lett fordítva annak idején... De kiderült hogy nincs ennyi esze. Mert most a régebbi nyelvemet, a Furort kipróbáltam az

-march=x86-64

direktívával, és a benchmarkjaim alapján a korábbiakhoz képest majdnem kétszeresére nőtt a sebessége! A prímszámok keresésében például az előző időszükséglet mindössze 55 százalékát igényli. Azaz most a natív prímkereső C változat idejének csak a 9.5 -szörösét igényli, természetesen akkor ha a natív programot is ugyanígy optimalizálom. Érdekes azonban, annak a sebességén alig dob valamit ez a -march kapcsoló... Úgy tűnik minél komplexebb a program, annál érdemesebb ezt az -march dolgot "belevenni"...

Kipróbáltam a -march=corei7 kapcsolót is, úgy még gyorsabb a nyelvem, de az előző x86-64 -es optimalizáláshoz képest csak kb 5 százalékos a javulás már.

Amúgy elkezdtem emiatt utánanézni hogy pontosan miket tud speciálisan linux terén ez a gcc... kiderült, akadnak azért jó szolgáltatások itt amikről még nem is hallottam. Bár jobbára csak „szépségtapaszok”, de mert elég maximalista fickó vagyok, örülök nekik. Például ez:

__attribute__ ((noreturn))

Meg ez a lehetőség is nagyon tetszik:

__attribute__ ((unused))

Úgy értem hogy eddig egyáltalán nem is volt megadva semmi -march paraméter, maga a kulcsszó sem, totál semmi, mindössze a -O2 volt ott egymagában.

Most ezzel fordítom:

CFLAGSINANE = -O2 -march=x86-64 -funsigned-char -funsigned-bitfields -Wall -Wno-long-long -Wextra -Wunused -Wunknown-pragmas -Wredundant-decls -Wunreachable-code

(A CFLAGS gondolom érthető, az INANE meg azért van ott mert ez a legújabb programnyelvem neve. Egyelőre legalábbis.)

Korábban meg tök ugyanez volt szintén, csak a -march=x86-64 rész hiányzott a sorból és kész ennyi.

-march=x86_64  ... generic x86_64 binárist fordítson, ne használjon olyan speciális utasításokat, amik a te CPU-dban megvannak. Tehát bármely 64 bites architektúrán elfusson. Ez az alapértelmezett.
A -march=native hozhat előnyt, ha az architektúrát tudja a fordító detektálni. Ez 32 bites ARM-okon tipikusan nem teszi a dolgát.

Vagy a native helyett specifikálsz egy CPU-t, amit elérő képességű procin fut csak a progid.
$ gcc -march=akármi teszt.c

Bővebben:
  $ sudo apt install gcc-doc
  $ info gcc

'-march=native' causes the compiler to auto-detect the architecture
     of the build computer.  At present, this feature is only supported
     on GNU/Linux, and not all architectures are recognized.  If the
     auto-detect is unsuccessful the option has no effect.

Egyébként gcc -S ... és assembly kódot fordít, amit megnézhetsz különböző fordítási kapcsolókkal. A másik dolog az időmérés, azaz kimérni hogy mely opció hatására gyorsul fel erőteljesebben a lefordított függvény.

Amikor -O2 -vel lefordítják a Linux disztribúciót, akkor nem arra vagy afölötti vasra tudod kizárólag telepíteni, hanem mindenre, ami a minimum követelmény felett van.
Ha magadnak akarod kihegyezni valamelyik szoftvert, akkor a saját architektúrádra fordítsd le, engedve a spéci utasításokat.

Már írtam, x86_64 esetén az AVX/nincs AVX kivételével alig van még nyereség. Viszint a klasszikus 32 bites vonalon nem mindegy, hogy i386-ig kell visszanyúlni, vagy Core2 és felette kell csak futni a szoftvernek.
ARM esetén szintén. A 32 bites az ARMv5 ... ARMv8.2-ig széles skálán mozog, a kompatibilitás lassít. AArch64 módban végig ARMv8 ... ARMv8.2, így itt nincs jelentős sebességtöbblet.

Nálam Archon és Gentoo-n nem hatástalan az -march. Továbbá nem csak ilyen általános x86, x86_64, stb-t. elhet neki megadni, hanem konkrétabb architektúrát is, pl. -march=sandybridge, akkor pl. tényleg 2. gen Core i-re fog fordulni (egyben modern 64 bites rendszeren x86_64-re, hacsak nincs átállítva), és minden használt utasításkészlet és optimalizáció el lesz döntve, nem lesz gond az AVX, stb., igaz a kód nem is fog olyan gépen futni, ami valamelyik feature-t nem támogatja. Szóval ezt akkor kell használni, ha konkrét gépre optimalizáltan kell fordítani.

De a Gentoo Wiki azért is ajánlja az -march=native kapcsolót, mert akkor a gcc felismeri, hogy milyen architektúrán fut, és arra optimalizál. Nem általános, hanem pontos architektúrára, nálam pl. az i5-2520M-es szubnotin a native-re sandybride-et ad vissza, nem csak egyszerűen x86_64-et.

386-nál meg nem a kernelre gondoltam, mert valóban, a 3.8-tól a Linux kernel dobta az i386 támogatását (min. i486 kell neki x86-os fronton), de szinte az összes nagyobb disztró már évekkel korábban dobta, nem csináltak hozzá binárist, az előfordított binárisok már jó ideje i686-ot igényeltek, tehát nem kernelkorlátról van csak szó.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

így már legalább értem hogy miért kell neked saját nyelv, a meglévőket nem voltál képes megtanulni :)

// Happy debugging, suckers
#define true (rand() > 10)

Nem erről van szó. Viccen kívül:

Képes vagyok megtanulni nyelveket, meg is tanultam jóegypárat az életem során... az más kérdés, mára már majdnem mindet elfelejtettem. Hanem inkább arról van szó, hogy épp abból lett elegem, hogy állandóan újra meg újra programnyelveket kell tanulnom, mert a régiek kimennek a divatból. Például az egyik első magas szintű programnyelv, amit megtanultam, a PL/I meg a PLIOPT. Ugyan már hol használják ezeket manapság... Jó, biztos találni pár ilyen helyet is. De sok tutira nem lehet belőlük...

Ott a Pascal. Bevallom, sose voltam belőle nagy ász. De csak azért nem, mert mire úgy-amennyire megtanultam, az alapjait, rájöttem nem érdemes folytatni, mert az is kiment a divatból.

És akkor még megemlíthetem a Ti-58 programozható zsebszámológép nyelvét (ez abszolút a legislegelső volt amit megismertem...), ott a C-64 Basicje, ott egy csomó másik Basic változat, ott a C-64 assemblyje, ott a Fortran, és pár másik nyelv is amit ugyan sokkal kevésbé ismertem meg, de valamekkora energiát mégis beléjük feccöltem...

Mindez súlyosbítva van azzal, hogy teljes architektúrák is villámgyorsan válnak elavulttá. Először az derült ki hogy a Ti-58 felejtős (bár most nosztalgiából beszereztem ám egy ilyet magamnak...), aztán az ESZR gépekről derült ki hogy minden tudásomat amit ott megszereztem, dobhatom ki a fenébe... aztán a C-64... A ZX-81, ZX-spectrum, a Primo, aztán a PC gépeknél a DOS, na oké, az nem architektúra, de ott is igaz volt hogy ami tudást megszereztem, az már sehova se kell. Beleértve a DOS környezetben futó assembly programok írásának tudományát is, amibe szintén sok tanulást beleáldoztam. Belefektettem. Az időmet rááldoztam. A semmiért.

És lassan már a Linux maga is kezd elavulni, olyan értelemben hogy már a C/C++ is egyre kevesebb helyre kell, mert már mindent dzsuvaszkriptekben írnak meg, és online működik, hálózatban, felhőkön. Na erre a vonatra már nem szállok fel, túl vén vagyok, nyugalmat akarok. Nekem már a programozás hobby marad, s ehhez megteremtem a magam környezetét, „platformját”, olyat, ami ha nem is tart ki örökké de az életem végéig igen. Ennek érdekében igyekszem minden függőségtől távol tartani magamat, mint a heroin-, koffein-, nikotin- és mindenféle külső libek függőségei. Nekem elég a sima C és annak leggyakrabban használt libraryjai.

P.S.: Egy perccel ezelőtt jutottam el oda az új nyelvemben hogy ha nem is a teljes csontváza de legalább a gerincoszlopa már megvan: képes már a legfontosabb dolgokat felderíteni, betokenizálni, és stringkonstansokat kiírni az stdoutra... azaz működik a tokenvégrehajtó főciklus is.

Innentől már szép lassan akkor is megcsinálom ha 40 fokos lázban fetrengek, mert a többi már játék.

Ez ilyen, a korai architektúrák gyorsan haltak kifelé. De az x86 az azért elég hosszú távú, és még jó darabig velünk marad. A C/C++ ráadásul architektúrafüggetlen is, kb. soha nem fog elavulni, OS kernel írására még mindig a C a legjobb. Dzsuvaszkripten nem tudsz ilyet írni, Rust-ban lehet, a fanjai szerint, de nem látom, hogy ontanák az abban írt kerneleket. Ha x86-ra fejlesztesz kernelt, drivert, compilert, stb., akkor az sem baj, ha tudsz egy kis ASM-et, az sem volt kidobott idő.

A Pascal-lal szerintem semmi baj nem volt, egyszerűen megrekedt tanulónyelv státuszban, eleve annak is készült, de annál nagyobb potenciál volt benne, mint amennyire vitte. Én sajnálom, mert anno nagyon jól megtanultam, OOP-s részét is, és elpocsékolt időnek érzem. Annak ellenére, hogy még mindig írnak alkalmazásokat Delphiben, pl. Total Commander, és keresnek is cégek Delphi-fejlesztőket, igaz nem sokan, de azt megfizetik. A BASIC-et nem sajnálom, mert az nagyon primitív, és az egyértelműen tanulónyelv, annak nem is az volt a lényege, hogy abban programozz egy életre, hanem a programozás elvi alapjait megtanuld, legalább a lineáris és strukturális alapokat. Bár egyébként annyira a BASIC sem avult el, mert Office makrókat még írogatnak benne, meg .NET-es szutykokat is, szóval vannak emberek, akiknek az se volt kidobott idő.

Fortran-ért megint kár, igaz azt még használják, de egy elég szűk réteg, a metamatikai felhasználását viszont kiszorították a matekszoftverek nyelvei, MatLab, Octave, meg az univerzális Python, ami szerintem nem egy jó nyelv, de annyi matekos lib van hozzá, hogy kvázi sztenderd lett. Ennek ellenére mérnöki területen használgatják a Fortrant is.

Saját nyelvet ne hozz létre, hacsak nincs tényleg valami forradalmi ötleted. Ezét van jórészt ez a nyelvi káosz, mert valamikor mindenki úgy volt vele, mint most te, hogy nem tetszett neki egyik nyelv sem, létrehozott egy sajátot, saját szájíz szerint, aztán az egész semmire nem volt jó, mert csak lett egy n+1. nyelv, ami csak tovább növeli a káoszt.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Én is elég sok nyelvet és technológiát kipróbáltam (többek közt Pascal/Delphi, VB6, MFC, Maple, Lisp, AVR asm, Erlang) amik a kihalás szélén állnak, de sose éreztem kidobott időnek, sőt kifejezetten élvezem mikor látom, hogyan lehetne valamit más eszközökkel is megoldani.

Poli nyelve miatt meg ne aggódj, nem fogja növelni a káoszt, megreked ott azon az egy PC-n, amin írták. De sok ifjú titán ismerhetné kicsit jobban a történelmet, talán kevesebbszer lenne feltalálva a melegvíz.

Poli nyelve miatt meg ne aggódj, nem fogja növelni a káoszt, megreked ott azon az egy PC-n, amin írták.

Erre én magam is bő 99% fölötti esélyt látok.

Azt felejtitek el azonban mindig, pedig már hányszor leírtsm, hogy az én célom ezzel nem is igazán az hogy elterjesszem tűzzel-vassal!

Hanem MŰVÉSZI céljaim vannak vele. A szememben ez egy műalkotás, vagy legalábbis annak része. A regényeimhez kell. Olyasmi, mint mittudomén egy illusztráció, ami például lehet egy térkép, mely bemutatja milyen a földrajza annak a területnek ahol a sztori játszódik. Például Tolkien műveihez vannak ilyen térképek. Mégis, mi egy ilyen térkép HASZNA?! Lényegében semmi: nem szokás kitenni képként a nappali falára hogy gyönyörködjenek benne naponta; nem lehet felhasználni tájékozódásra, hogy általa eljussunk a célunkhoz a Földön...

Mégis, valamiféle értelemben igenis haznos: amikor olvassuk a sztorit, általa jobban beleéljük magunkat annak a HANGULATÁBA. Szóval stilisztikai értéke van bizonyos elvont értelemben!

Na nekem erre kell elsősorban. Másodsorban meg perrsze tényleg van konkrét haszna, amennyiben segít nekem megírni a nekem kellő szkripteket a gépemre, de az előző célhoz képest a szememben még ez is mellékes.

Tehát nem, nem hiszem magam se hogy elterjedne, de emiatt nem is izgatom magamat szemernyit se. Legjobb esetben annyi történhet, hogy a regénysorozatom borzasztó híres lesz (bár ennek esélye már magában véve is elenyésző) és akkor lesz talán két-háromszáz lelkes rajongó aki annyira belezúg a sorozatomba és a nyelvbe is, hogy elkezdi tanulni, és írnak e nyelven talán egy tucat programot is, aminek a minősége eléri egy jobb Basic program szintjét. Tudod, ez olyasmi lesz mint amikor manapság nélhányan nagy erőfeszítéssel mondjuk Naavi nyelven tanulnak vagy Tolkien Tünde-nyelvei közül valamelyiken. Attól se kell félni szerintem hogy e nyelvek rohamosan elterjednek, ez lesz a világnyelv és neked muszáj lesz megtanulni...

Szóval ez ilyen a programnyelvemmel, nem látom esélyét magam se hogy valaha is igazán népszerű legyen.

Több mint 50 regény már elkészült belőle. Azért írom hogy „több mint ötvcn”, mert ötvenig számoltam, aztán meguntam, szóval már magam se tudom konkrétan mennyi. A legutóbb befejezett kettő (vagy három..? lusta vagyok utánanézni...) kivételével mind fenn van magyarul a MEK-ben. Vagy nincs. Én mindenesetre beküldtem oda mindet, aztán hogy felrakták-e, fene se tudja, nem is érdekel. De nagyon sok elérhető, az biztos, azt tudom.

Ja: Csak a 60 ezer szónál hosszabbakat nevezem regénynek, a kisebbek a szememben csak kisregény vagy novella. De azok nincsenek is beleszámolva ebbe az ötvenes számba... A legtöbb regényem amúgy bőven 100 ezer szó fölötti, szóval ha a teljes sorozatomat el akarod olvasni, ahhoz, hm... szóval, jelentős elszántság kell, finoman fogalmazva is. Ennek ellenére, több olyan halandóról is tudok aki elolvasta már a teljes sorozatomat. És mindegyiknek tetszett. Még szép hogy mindnek tetszett, ha ugyanis nem tetszenek valakinek a műveim, az első fél tucat után legkésőbb abbahagyja az olvasást, és nem olvassa el a többi még minimum negyvenvalahányat is ugye...

Három alkotásom (egy kisregény, egy novelláskötet, meg egy másik mű ami nem is része a sorozatomnak) angolul is elérhető amúgy.

De előre szólok (már bocs ha rosszat tételezek fel rólad, de az irányomban tanúsított eddigi modorod erre alapos gyanút ad) hogy felesleges most gyorsan megkeresned egy vagy egypár művemet, beleolvasni, kiragadni belőle valami részletet amit ideidézel a kontextus nélkül, netán valami jelentéktelen helyesírási vagy központozási hibát, aztán mint büszke troll elkezdeni gúnyolódni hogy hú de rossz amit írtam, és lám ezért nem vagyok még világhíres, vagy akármi!

Tényleg felesleges. Nem mintha nem tudnának a trollok kihozni a sodromból, tudjuk jól hogy ez lehetséges, volt már rá számos példa. Ez azonban messze nem ilyen eset. Régen talán sikerült volna, elismerem, de most már teljesen immunis vagyok rá, s amiatt mert én már az angol kiadásokra hajtok, én már konkrétan ballisztikus ívben leszarom, a magyarok közül ki meg hányan olvassa/olvassák a könyveimet. Nyilván persze még most is örülük neki ha többen olvassák, de ez a szememben már egy huszonhatodrangú jelentéktelen részletkérdés csupán.

Ebből egyenesen következik, hogy nem izgat ha akármiféle helyesírási vagy más hiba is van a műveimben. Régen se nagyon izgatott, mert nem is mindenben értek egyet a magyar helyesírási szabályzattal; ("kisbetu" a megmondhatója, erről rengeteg vitánk volt egykoron) másrészt azonban minthogy az angol kiadások érdekelnek már, ez irreleváns is, mert ott mások a szabályok.

Ugyanez igaz a stilisztikára. A fordítás néha igencsak megváltoztat dolgokat. Tökmindegy milyen a magyar stílus, az angolban ritkán lehet visszaadni mindent ami a magyarban benne van, persze ez fordítva is igaz. Cserébe viszont az esetleges hibák, pongyolaságok is eltűnnek a fordítás során. Igaz, simán belekerülhetnek újabbak...

Szóval igen, fenn van RENGETEG művem, elérhetőek ingyen, olvasd őket ha akarod, sok sikert, és minden korábbi konfliktusunk ellenére is őszintén kívánom hogy leld bennük nagy örömödet!

De kritikára nemcsak igényt nem tartok, még segítő szándékúra se, de még trollkodni is felesleges, mert nemhogy az, de igazából még a magyaroktól jövő __elismerés és dicséret__ is meglehetősen hidegen hagy.

És amiatt hagy hidegen, mert ha beképzeltségnek tűnik is, de én teljes mértékig biztos vagyok benne hogy „igazam van”, azaz jól írok. Sőt, mi az hogy jól, zseniálisan! Ha valaki nem így gondolja, vállat vonok és elintézem azzal, hogy „na megint itt egy kultúrbarbár”. Ha meg dicsérni kezd, akkor bár jólesik kissé, de akkor meg az van hogy úgyis csak azt mondja amit úgyis tudok rég: hogy jól, sőt kiválóan írok!

Tehát ez van. Bocs meg medve.

Ahogy a költő (nem én) mondta:

„Nyugodt vagyok, tudom mit érek, s nekem elég ez öntudat!”

Mindenki magából indul ki, nem azért akarom elolvasni, hogy kritizáljalak, ha jó lesz akkor olvasom, ha nem és untat akkor max 100 oldal után befejezem. Egyszerűen a kíváncsiság hajt, semmi több. Ha sikerül kiolvasnom egy könyvet is azt meg majd a megfelelő fórumon közzéteszem. Egyébként utánanéztem mit írnak mások a könyveidről, hát ... Na veszek egy mély levegőt és meglátjuk.

Nahát, már írnak is a könyveiről? Megleptél. Eddig erről se volt tudomásom, nem néztem utána. Eddig csak azon visszajelzésekről volt tudomásom amiket közvetlenül nekem címeztek, emailban.

P.S.: Arra figyelmeztetlek, nem mindegy melyik regénnyel kezded az olvasást, nem mindegyik érthető tökéletesen az előzményregények nélkül.

Hát, a sorozat időrendjében bár nem ez a legelső, de én mindenképp azt ajánlanám, hogy "Kajjám, a Tévedés".

Ez ugyan a leghosszabb (azok közt amik fenn vannak, azóta írtam egyet ami ennél másfélszer hosszabb...), de mégis jó ha valaki ezzel kezd, mert ez afféle „központi” eleme a sorozatnak, rengeteg regény kapcsolódik hozzá többé-kevésbé. Bár akadnak benne szereplők akiknek akad „előélete” időrendben korábbi regényben is, például ilyen a Badzsahárata nevű, de mégis, e regény tökéletesen érthető az előzmények nélkül is. Ebben „debütál” a Kajjám nevű varázslóm (megismerhetjük a gyermekkorát például), aki rengeteg másik regényben is központi szereplő. Innen lehet a legtöbbet megtudni a tündérekről is...

DE, és ez FONTOS, csak akkor ajánlom ezt kezdésnek ha amúgy szereted a fantasy műfaját, vagy legalábbis az ókori/középkori környezetben játszódó áltörténelmi regényeket!

Ha azonban azokért nem vagy oda, ellenben szereted a sci-fit, de nem azt ami a világűrben játszódik, hanem a mai(hoz hasonló) társadalomban, emberek közt, akkor az Y címűt ajánlom, az a legkifejezettebben „klasszikus” scifi szerintem a műfaját illetően. Igen, egyetlen Y betű a címe.

Amennyiben szereted ugyan a fantasyt, de nem azt ami középkorias környezetben játszódik, hanem azt ami a mi mostani világunkhoz hasonlóban, tehát a „modern korban” játszódik, na akkor meg épp az általad említett Lidércgyermekek címűt ajánlom.

Amennyiben a sci-fit szereted, de abból inkább olyat ami világűrben játszódik elsősorban, akkor... Hm, most bajban vagyok, mert akad ugyan ilyen művem is, de ahhoz ismerni kéne sok előzmény-regényt... azaz ezt inkább hagyjuk. Bár, végülis van egy novella ami nagyjából ilyen, s érthető is az előzmények nélkül... szóval nem regény, de hátha épp a novellákat szereted... a címe: "A szeretett nő".

Ha szereted azt a műfajt ami modern korban játszódik és vegyíti a fantasy elemeket a sci-fi elemekkel mert mindegyik van benne, akkor ajánlatom: Badzsahárata. (de készülj fel rá, ez is nagyon hosszú...)

Ha kifejezetten áltörténelmi regényt szeretnél, nagyjából minden csicsa, sci-fi és fantasy beütés nélkül, akkor ajánlatom: "Zardán, a zsarnok". De szóbajöhet az is, hogy "A pénz vonzása".

Ha állatregényt szeretnél: "Nyau története". Ez egy hiúzról szól, de akadnak benne más állatok is. Mondjuk ehhez nem árt kissé ismerni az előzményregényeket, de azért szerintem még élvezhető azok nélkül is.

Ha szereted az olyan sztorikat amikben világszimuláció szerepel (s ezokból nyilvánvalóan sci-fik), akkor: Őrördögök.

Ha szereted az olyan scifit ami tiszta scifi, de nem a mi világunkban játszódik, ugyanakkor világűri kalandok se akadnak benne, mert teljes egészében egy másik bolygón játszódik, ottani lények közt, magas technikai fejlettségű környezetben, akkor: "Szivárványtündér". (Azóta a címét már megváltoztattam, de a MEK-ben még így szerepel). Ez amúgy kifejezetten romantikus sztori, szép szerelmi szállal.

Ha szereted a más bolygón való kalandokat, azok közül is azokat ahol a lényeg hogy egyetlen ember vagy emberek egy pici csoportja egy idegen társadalomba csöppen, ahol valami konfliktus van épp, s ezt ők az emberek oldják meg, akkor e 3 művet ajánlom, ami egy minisorozat a sorozatomon belül, és okvetlenül ebben a sorrendben kell olvasni őket (bár a középsőben nem szerepelnek emberek):

Rockzene (ez csak egy rövid novella)

A zene hatalma

Specialisták

Végezetül a biztonság kedvéért megemlítem, a MEK-ben nem csak Viola Zoltán néven vannak fenn dolgaim, de a sorozatom egy része Fossil Codger név alatt van fenn. Ez ne zavarjon téged.

Saját nyelvet ne hozz létre, hacsak nincs tényleg valami forradalmi ötleted. Ezét van jórészt ez a nyelvi káosz, mert valamikor mindenki úgy volt vele, mint most te, hogy nem tetszett neki egyik nyelv sem, létrehozott egy sajátot, saját szájíz szerint, aztán az egész semmire nem volt jó, mert csak lett egy n+1. nyelv, ami csak tovább növeli a káoszt.

https://xkcd.com/927/

Seneca mondta, hogy meg mindig jobb feleslegeset tudni, mint semmit. Tovabbra is igaza van. Az lehet, hogy X nyelven nem fogsz mar kodot irni, ha van a celra jobb, de a szemlelet, a szintaxis ismerete, a fuggvenynevek tovabbra is jol johetnek, mert X+1 nyelv szintaxisa mar ismeros lesz, es mar tudod mit milyen neven keress.

Van olyan nyelv, amit kb. 15 eves koromban vettem elo utoljara (x86 ASM), van, amit egyetemen (Prolog), es mar a szintaxisaval is gondban lennek, de kb. tudom, hogy egy fordito mit mire fordit, es a mintailleszteses, rekurziv szemlelet is jol jott mar azota, teljesen mas nyelven. A C ismerete a szintaxis miatt teljesen mas jellegu scriptnyelveknel is hasznos, akkor is, ha webre fejlesztesz, es nem kernel modulokat. Volt egy (talan hupos talan stackoverflow-os) kerdes, amire amiatt tudtam, hogy a Levenshtein tavolsag a valasz, mert valamikor regen a PHP doksiban meglattam.

Persze van hatranya is, amikor epp nyelvet valtasz, nyitott doksi nelkul lassabb vagy, es tobbet hibazol. No meg ha egesz eletemben csak Pythont hasznaltam volna, akkor abbol nyilvan jobb lennek (csomo egyebet meg nem tudnek).

Egyebkent te hobbistakent pont megengedhetned magadnak, hogy valassz egy nyelvet, es ha elavultnak tartjak, akkor is tovabb hasznald. Ha aktivan fejlesztesz, es abbol elsz, erre nincs mod.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

hogy állandóan újra meg újra programnyelveket kell tanulnom, mert a régiek kimennek a divatból.

Ezt a problemat most megkerulod azzal, hogy letrehozol egy programnyelvet, ami soha nem is lesz divatban? :)
 

Nem teljesen ertem, mi a kulonbseg (marmint az alkotoi buszkesegen kivul) abban, hogy irsz/hasznalsz egy sajat programnyelvet, amit eselyesen senki mas nem fog, vagy fogsz egy programnyelvet, amit mar megirtak, es annal maradsz, ignoralva a divatot.

Engem iszonyúan zavart, amikor naponta jött egy fél könyv a blogban a programnyelv-fejlesztésről, úgy, hogy még egy kétsoros tl;dr összefoglaló sem volt bennük, de magát a tevékenységet (mint hobbi), meg kell, hogy védjem. Igazából kokózhatna is, akkor a programnyelv-fejlesztés már mégiscsak hasznosabb. :)

Nem teljesen ertem, mi a kulonbseg (marmint az alkotoi buszkesegen kivul)

Akkor ezt a kérdést gondolom meg is válaszoltuk :)

Ezt a problemat most megkerulod azzal, hogy letrehozol egy programnyelvet, ami soha nem is lesz divatban? :)

Nem, ezt a problémát messze nem oldja meg, de talán nem is ez volt a fő cél. Amúgy meg erre van a bootstrapping: megírod az első compilert valamelyik éppen divatos nyelven (pl. itt C-ben), a második verzió már lehet self-hosted, azaz hogy a compilert is az új programnyelven írod meg, és a bootstrap compilerrel fordítod.