A programozáshoz nem logika kell, hanem nyelvtudás?
2020. június 15. írta: Curiocity

A programozáshoz nem logika kell, hanem nyelvtudás?

Ha azt gondoltad, hogy a programozás csak a kockáknak való, akik algoritmusokkal kelnek és fekszenek, meg fogsz lepődni, milyen eredményre jutott egy friss kutatás, melyben programozók agyát szkennelték. Ami arra is rávilágíthat, miért van annyi bug (hiba) a programokban.

szamitogep_program.jpeg

A hollywoodi filmeknek és sorozatoknak köszönhetően, a programozásról a legtöbbünknek az jut eszébe, hogy egy zseni ül a számítógép előtt, végeláthatatlan számsorok és hieroglifáknak látszó kódok futkorásznak előtte, miközben lázasan veri a klaviatúrát. A programozót pedig olyasvalakinek képzeljük, aki világ életében kiváló volt matematikából, és a legbonyolultabb problémát is képes algoritmusok nyelvére fordítani.

De vajon mi játszódik le a programozó agyában, amikor egy programozási feladatot kell megoldania? Erre kereste a választ Janet Siegmund a Chemnitzi Műszaki Egyetem professzora, neurológusokkal közösen.

Hogyan lehet mérni, mi játszódik le az agyban programozás közben?

Az agykutatásban előszeretettel használt MRI vizsgálatok segítségével feltérképezhető, hogy különböző feladatok megoldása közben mely agyterületek aktívak és melyek nem. Agyunk különböző területei eltérő feladatokban működnek közre, nagyon leegyszerűsítve, van amelyik a beszédért, van amelyik a számolásért felel. Ha egy feladat megoldása közben a tesztalany épp egy MRI-ben fekszik, a "szkennelés" eredményeképpen kiderül, melyik agyterületét használta közben, és melyeket nem, melyből rengeteg hasznos következtetést lehet levonni a jövőre nézve.   

A dolog onnantól válik nehezebbé, hogy az MRI vizsgálatok rendkívül drágák, ráadásul egy huzamban csak nagyon rövid idő, legfeljebb néhány perc áll rendelkezésre ahhoz, hogy az agyműködést vizsgálják. Ez azt is jelenti, hogy nem lehet például olyan komplex programozási folyamatot vizsgálni, mint mondjuk egy mobil applikáció fejlesztése.

A kutatók ezért a következőt találták ki. 17 programozónak két programozói feladatot adtak. Első feladatként a tesztalanyok rövid programkódot láttak, amiről ki kellett találniuk, milyen feladatot hajt végre. Kis szünet után egy másik programot kaptak, amiben szintaktikai hibákat (programnyelvben ez olyan, mint a helyesírási hiba – a szerk.) kellett keresniük. Az MRI mindkét feladat során rögzítette, hogy a programozónak mely agyterületei voltak aktívak. Mivel az ilyen kutatások esetén fontos annak megállapítása, hogy az eredmények mennyire véletlenszerűek, vagy mennyire mutatják ugyanazokat a mintázatokat (konzisztencia), a feladatot különböző kódsorokkal többször megismételték.

Logika és matematika helyett beszéd- és olvasásközpont?

programertes_mri.jpgGondolkodás szempontjából az első feladat a program megértését igényelte, azaz az agynak nem volt elég felismernie, rá kellett jönnie, hogy a programsorok milyen feladatot hajtanak végre. A második feladat ehhez képest sokkal kisebb kihívást jelentett, a szintaktikai hibák keresése nem igényel megértést, csak egyszerű észrevételt (önkéntes nyelvi lektorok figyelem:) - a szerk.). A más vizsgálatoknál is alkalmazott ún. kivonásos módszer segítségével a kutatóknak azt kellett megnézniük, mely területek maradnak aktívak, ha az összetett gondolkodást igénylő feladatnál aktív területekből kivonják azokat, amik a szintaktikai hibák keresésénél is izzottak. És itt jött a megdöbbentő felfedezés.

Miközben a kutatók azt várták, hogy a programkód megértéséhez az agy matematikai, logikus gondolkodásért felelős agyterületei lesznek aktívak, a tesztalanyok a feladat végrehajtása közben szinte egyáltalán nem vagy alig használták agyuk ezen területét, annál inkább a munkamemóriáért, a megosztott figyelemért, illetve a beszélt és  olvasott szöveg megértéséért felelős agyterületeket. Mindez arra engedte következtetni a kutatókat, hogy a program megértésekor (és feltételezhetően a program írásakor is) az agy sokkal inkább támaszkodik a nyelvhasználatra, mint a logikai-matematikai gondolkodásra. Azaz a programírás sokkal inkább hasonlít egy idegen nyelv megtanulásához és elsajátításához, mint egy matematikai probléma megoldásához. (a teljes kutatásról készült összefoglaló itt olvasható >>>)

Azért még sem árt gondolkodni, mielőtt nekiesünk a programírásnak?

Arra persze a kutatók és más korábbi kutatások is rávilágítanak, hogy a programírás merőben más folyamat, mint magának a programnak a kitalálása, megtervezése, amihez már szükségesek, vagy legalábbis nem ártanának a logikai-matematikai készségek, illetve az algoritmus alkotás képessége.

Dr. Leslie Lamport számítógép tudós, aki 2013-ban Turing díjat kapott (adott évben a számítástechnika tudományának fejlődéséhez leginkább hozzájáruló személy kapja meg), éppen arra hívta fel a figyelmet az idei év elején, hogy a legtöbb programozó manapság úgy esik neki a programkód megírásnak, mint török gyerek a kenyeresszakajtónak. A már ismert rutinok alapján megírják a részfeladatok kódjait, ahelyett, hogy a teljes problémához vezető leghatékonyabb algoritmust találnák ki és csak azután látnának hozzá a programkód megírásához. Mintha a villanyszerelők tervrajz nélkül, rutinszerűen húznák be a kábeleket az újonnan épülő lakásokba, anélkül, hogy figyelembe vennék hol vannak az elosztók, hova kellene tenni a konnektorokat stb. Éppen ezért az így megírt programok sokkal több hibával működnek, itt-ott összeakadnak, nagyobb erőforrást igényelnek és sokkal kevésbé hatékonyan oldják meg a feladatokat, mint lehetne.

Neked mi a véleményed?

 

Ha tetszett és szeretnél még hasonló érdekességekről olvasni, lájkold és oszd meg ismerőseiddel!

 

A bejegyzés trackback címe:

https://curiocity.blog.hu/api/trackback/id/tr3215809462

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Alick 2020.06.15. 22:13:08

Félrevezető a kísérlet eredményeinek értelemzése, mert nem "a" programozói gondolkodást vizsgálta, hanem annak passzív megértő-feldolgozó fázisát... ebből éppen a szoftver létrehozásának közvetlen műveletei hiányoznak.

droid_ · http://matyiszuro.blog.hu/ 2020.06.15. 22:15:09

" A már ismert rutinok alapján megírják a részfeladatok kódjait"

vagy kimasoljak (juk). van az poen hogy a szenior kerdi a juniort, honnan masolta a programot. a valasz stackoverflow. szenior: na jo, de a kerdesbol vagy a valaszbol? egyik munkahelyemet egyszer blokkolta a stackoverflow mert azt hittek hogy dos tamadas. ez nem vicc :) kicsit mas volt a helyzet internet nelkul regen. persze akkor nem nagyon volt olyan, hogy "nem ismered ezt a keretrendszert/nyelvet/konyvtarat/akarmit? akkor hozzaadunk egy napot a hataridohoz". a multkor nem vettem eszre keso delutanig, hogy nem volt netem munka kozben. buszke voltam magamra.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.15. 23:03:04

Faszság. Nem hatékony algoritmusokat kell írni, hanem átlátható, egyszerű kódokat, amit a következő, középszerű programozó is megért. Ha írok egy assembler kódot és nem kommentezem, vagy agyafúrt megoldást találok ki, egy hét múlva magam sem tudom mit csináltam.

droid_ · http://matyiszuro.blog.hu/ 2020.06.15. 23:55:04

@Kurt úrfi teutonordikus vezértroll: ritka hogy egyetertunk (assembly! :) meg annyi hogy nem kozepszeru programozonak se mindegy, hogy ujra tudja-e hasznalni a kodot vagy nem. most tervezek kidobni kb egyhavi munkamat evekkel ezelottrol, mert mindekinek aki oda akar nyulni, ujra el kell magyaraznom, mert ertik ok hogy gozgep de mi hajcsa (a jelenlegi kollegaim kozott nincs kozepszeru, ez eleg meglepo nekem). ugyanez a baj a regexszel is, ha kicsit komplikaltabb, akkor a kovetkezo ember inkabb csinal egy masikat mint hogy kibogozza es modositsa. azaz write-only hiaba jo cucc.

nyu 2020.06.16. 00:18:11

"hogy a legtöbb programozó manapság úgy esik neki a programkód megírásnak, mint török gyerek a kenyeresszakajtónak. A már ismert rutinok alapján megírják a részfeladatok kódjait, ahelyett, hogy a teljes problémához vezető leghatékonyabb algoritmust találnák ki és csak azután látnának hozzá a programkód megírásához."

Nyilván lehet elmélkedni arról, hogy mi hány ordó, de azt meghagyjuk a matematikusoknak, hogy dolgozzák ki papíron ceruzával.

Gyakorlatban meg határidők is vannak, amik hamarabb lejárnak, mint hogy a matematikusok végeznének az előző ponttal.

Meg az sem mindegy, hogy a vevő kifizeti-e a legoptimálisabb megoldáshoz szükséges többlet fejlesztési időt.
Általában csak arra van pénz, hogy egy nagyjából jól működő programot összelapátolj.

Mad Marx 2020.06.16. 06:18:49

A cikk első és második része közt nincsen ok-okozati összefüggés, két független, de legalább angol tudósos szintű "tanulmány" lett tessék-lássék módon összepakolva egy bejegyzésbe. Az első fele egy olyan kisérletről szól, ami módszertanilag hibás, vagy egy légből kapott elmélet alátámasztására végezték el szándékosan rosszul, vagy csak a kutatási pénzek lenyúlásához kellett valami mindegy, hogy mi, csak legyen jelegű munka. A második fele sem tanúskodik túlzott hozzáértésről. A legnagyobb probléma mostanában a szakmában az, hogy a feszített tempóba nem fér bele a normális tervezés és a rendes projekt management, meg lássuk be nem biztos, hogy a megrendelő hajlandó/képes lenne kifizetni az ezzel járó pluszköltségeket.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 07:34:00

@droid_: Az IBM világban - tudom, kicsi és nem túl régi cég :-)) - assemblernek írják. Biztos hülyék hozzá, a Holdra szállást is elbaszták.

www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.asma400/asmr102112.htm

"Assembler language

HLASM Language Reference
SC26-4940-06

The assembler language is the symbolic programming language that lies closest to the machine language in form and content. The assembler language is useful when:
You need to control your program closely, down to the byte and even the bit level.
You must write subroutines for functions that are not provided by other symbolic programming languages, such as COBOL, Fortran, or PL/I.
The assembler language is made up of statements that represent either instructions or comments. The instruction statements are the working part of the language and are divided into the following three groups:
Machine instructions
Assembler instructions
Macro instructions"

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 07:39:59

@droid_: Az assembleren kívül 1ébként 1etértünk.

@nyu: No meg ha az adott gép sebessége elegendő a kívánt válaszidőre, qrvára nem érdekel senki mennyire optimális a program. Egy 20 elemes rendezésre, nem fogom szuper rendező programok behívását beprogramozni, hanem bebaszok egy primitív buborék algoritmust. A spéci rendező program felhívása és inicializálása több CPU időbe kerül.

Kopasz Szuzukis 2020.06.16. 10:14:38

A mai "pogromozókkal" az a legnagyobb gond, hogy képtelenek algoritmikus gondolkodásra! Fossuk a kódot, oszt jólvanazúgy! Mert megabájtra fizetnek.
Anno (1980-as évek eleje), mikor a programozást tanultam, tilosvolt egyetlen egy kódsort is leírni, míg nem volt felállítva a tökéletes, és optimális algoritmus.
Ésigen! Ahová elegendő egy egyszerű buborékrendezés, nem kell többmegabájtos rendezőelméletet felállítani. Csak azért, hogy tele legyen a tár.

nyu 2020.06.16. 10:40:54

@Kopasz Szuzukis: Hetvenes-nyolcvanas években még a fizikai vas volt a drága, nem volt elég memória, tárhely, muszáj volt optimalizálni a kódot.

Mostanra teljesen megfordult a helyzet, a fejlesztő ideje a drága, hardverek ára viszont annyira leesett, hogy olcsóbb az utóbbit bővíteni, mint az optimalizációt kifizetni.

Meg amúgy is a programok többsége az idő 80%-ában áll, mert vár a felhasználói inputra.

midnight coder 2020.06.16. 10:43:13

@Kopasz Szuzukis: Na, ez jó sok marhaság igen kis helyre összeírva.
Rádásul önellentmondással, mert hogy a bubule sort speciel az az algoritmus ami semmiképpen nem nevezhető optimálisnak, neki az ez egyetlen előnye, hogy egyszerű. Méretben viszont nem sok különbség van Pl. a quicksorthoz képest. Pláne, mert a mai rendszereknél már eleve benne vannak a standard libekben a rendezésre is képes konténerek. A Commodore 64 persze anno egy másik világ volt, ott a high score rendezéséhez a játék végén bőven elég volt a bubble sort.

Ami az optimalizált kódot illeti, az egyik oldalon van az optimalizálás, a másik oldalon pedig az, hogy záros határidőn belül produkálj működő, lehetőleg hibamentes, és ráadásul még mások által is olvasható kódot.
Na, ez a két szempont erősen üti egymást. Általában az utóbbira van szükség, és a sebességkritikus részeket szoktuk optimalizálni. Másrészt, ez az optimalizálás gyakran architekturális szinten történik, nem magában a kódban. Sokat változott a világ a 8 bites gépek óta.

qwertzu 2020.06.16. 10:57:45

@Kurt úrfi teutonordikus vezértroll: @Kopasz Szuzukis: Ki ne találjuk már, hogy egy átlag programozónak egy magas szintű nyelvben akárcsak érdemes megfontolnia, hogy milyen rendező algorirtmust használjon.

Minden nyelvben a beállított alap rendezést.
C#: www.dotnetperls.com/sort

Bármilyen business kódban, kód reviewn izomból dobnának vissza bármilyen custom meg egyedi rendezési megoldást.

midnight coder 2020.06.16. 11:01:17

@qwertzu: Arról nem is beszélve, hogy általában az adatot eleve rendezve szeded elő az SQL szerverből, ami hatékonyabban rendez mint bármi amit te kód oldalon csinálhatsz.

qwertzu 2020.06.16. 11:08:32

@midnight coder: Itt most inkább arra gondoltam, hogy ha kódban kell rendezni. Olyat nyilván senki sem csinál, hogy felnyal egy táblát majd a memóriában rendezi.

steery 2020.06.16. 11:42:21

A programnyelvhez természetes, hogy nyelvtudás kell. Az algoritmus tervezéséhez kell matematikai tudás. Sokat segített volna ezen a kísérleten, ha a tudósok tudják, mit csinálnak, mert ez így, ebben a formában eléggé félrevezető eredményeket produkált.

droid_ · http://matyiszuro.blog.hu/ 2020.06.16. 11:54:34

bogosort? :)
1. ha a lista rendezett, stop
2. keverjuk ossze a listat veletlenszeruen
3. goto 1

midnight coder 2020.06.16. 12:12:26

@qwertzu: Láttam én már karón varjút :-)

2020.06.16. 12:21:33

Én a türelemre szavaztam, mert ugyan az első négy is szükséges, mégis rengeteg ember van, aki mindegyikben jó, de valahogy mégsem képes programozóként dolgozni, és ennek oka a türelem hiánya. Alapvetően három dologhoz kell türelem, az egyik a probléma újabb és újabb újragondolásához, többféle megközelítésből, hogy rájöjj, hogyan oldjad meg. A másik a próbálkozáshoz, hogy ha valami valahogy technikailag nem megy, akkor újabb és újabb módszerekkel vagy paraméterekkel próbálkozzál, akár elvetve a korábbi koncepciókat, teljesen előről kezdve, míg rá nem jössz hogyan működik (nyilván nincs minden rendesen dokumentálva). Végül pedig a kereséshez, dokumentációk átnyálazásához kell türelem, mert nem mindig a google első találat az, amit keresel, bármennyire is jók a kereső kifejezéseid.

2020.06.16. 12:30:57

@Kurt úrfi teutonordikus vezértroll:
Normális esetben nem írsz semmilyen rendező algoritmust, mert meglévő kódot használsz újra.

2020.06.16. 12:33:12

@midnight coder:
Mondjuk ez az általános eset, mivel speciális esetekben meg előfordul, hogy az adatbázisban eleve nem adott, vagy nem úgy adott az információ, ami alapján rendezni akarod.

2020.06.16. 12:37:24

@Kurt úrfi teutonordikus vezértroll:
Én azt az elvet tartom helyénvalónak, hogy tervezd, írd meg a kódot úgy, hogy könnyen értelmezhető és bővíthető legyen, a részfeladatok jól szét legyenek választva, és ha ez megvan, akkor lehet optimalizálni, ha az szükséges. Mert egyrészt fordítva nem működik, ha optimalizálás céljából tesznek bele "hackeket", akkor ott csak egyre nagyobb lesz a káosz, másrészt a középszerű programozó nem kell hogy hozzányúljon azon modulokhoz, amelyeket matematikusok fejlesztettek, elég ha meghívja az ő metódusaikat.

Kovacs Nocraft Jozsefne 2020.06.16. 12:51:05

@Kurt úrfi teutonordikus vezértroll:

Helyesen valóban assembly a nyelv neve, az assembler az a program, amely előállítja a gépi kódot (a linkerrel együtt).

Más kérdés, hogy a valóságban az van, amit te is írsz, azaz a legtöbben a nyelvet is assemblernek nevezik.

_B_ 2020.06.16. 13:08:54

Szóval kiderült, hogy egy programNYELVen írt kód olvasása az agy nyelvi területeit aktiválja? Nemá :)
Magát a problémamegoldás részét kellett volna profilozni. Csak valami móriczka feladattal, ami pár perc alatt implementálható egy kis gondolkodás után.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 13:21:03

1*re válaszolok többeknek. Nekem sajna muszáj assemblerben nyomnom, oka van. Az egyik az hogy geci troll vagyok és ebbe a kódba más nem üti az orrát. :-)) Ott nincs rendezésed alapértelmezésben. Továbbá még ha SQL-t alkalmazok, ha nekem szekvenciálisan kell feldolgoznom, sokkal gyorsabb lesz ha fizikai sorrendben nyalom fel a táblát és nem rendezetten. Ebben az esetben meg nem érdekel a rendezettség.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 13:25:00

@Zabalint: Amikor 30 éves fájlszerkezeteből, dokumentáltság, struktúra leírás nélkül, dumpok alapján kell adatokat kivadászni két-három nap alatt, max 200 soros programmal, akkor nem tervezgetünk semmit.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 13:27:32

@qwertzu: Bár azokat a programokat is visszadobták volna amivel nekem most szívnom kell!

Alick 2020.06.16. 13:28:14

@Kurt úrfi teutonordikus vezértroll: Nincs probléma, IBM-es saját terminológia, mindenki más az assembly-t használja a nyelv elnevezésére.

igazi hős 2020.06.16. 13:35:24

@midnight coder: "ami hatékonyabban rendez mint bármi amit te kód oldalon csinálhatsz" "Lófaszt, mama!", hogy irodalomilag pontos legyek. Ha nem pont a használt index szerinti sorrendet kéred, akkor ugyanolyan hatékony a kliensen rendezni, ha egyáltalán tudsz a szerveren az adott kifejezésre rendezni. De ha a rendezés miatt még 3 táblát be kéne joinolni, akkor simán gyorsabb berántani a rendező kifejezést egy dictionarybe és a kliensen rendezni. És a kliensen arányában több a CPU és a memória is.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 13:41:16

@Alick: Csak azért rágódunk rajta, mert ezzel már sok vita volt hogy szerintük az assembler helytelen. Egyébként más architektúrákban is gyakran nevezik assemblernek.

alalala 2020.06.16. 13:42:53

@igazi hős: "És a kliensen arányában több a CPU és a memória is. "

Mint a szerveren?

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 13:45:39

gugli "java assembler code"
9 700 000 találat
Hülye IBM, hülye Java-sok. :-))

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 13:46:32

@alalala: Szerintem általában véve igaza van, mert a szerveren osztoznod kell.

Kovacs Nocraft Jozsefne 2020.06.16. 13:55:42

@midnight coder:

"ez az optimalizálás gyakran architekturális szinten történik"

Ez pontosabban mit jelent a gyakorlatban?

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 14:02:51

@Kovacs Nocraft Jozsefne: A rendszer és az adatbázis kezelő maga épít fel a memóriában gyorsító tár részeket a teljesítmény adatok alapján. Na meg lehet hogy a programhoz hozzá sem kell nyúlni, mert ugyan a fasz programozó olyan lekérdezést használ, amit szekvenciálisan olvas, holott indexet kellene rá építeni akkor ha ezt az adatbázis adminisztrátor meglátja a monitorok alapján, tesz rá egy indexet.

CyberPunK 2020.06.16. 14:03:24

@Kovacs Nocraft Jozsefne: Azt hogy manager írta, és pár fancy kifejezésen kívül fingja sincs semmiről. :D

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 14:06:24

@Kovacs Nocraft Jozsefne: Jó, kérdés mit értünk architektúrális szintnek. Van olyan gép ahol a kódkonverzióra gépi utasítások vannak már, ahol csak a konvertálandó adat területeket kell megadnod, a kódtáblát nem.

fhdgy 2020.06.16. 14:26:27

@Kurt úrfi teutonordikus vezértroll: Igen, hülye volt az IBM! Amikor a 70-es években programozást tanítottak nekem, én pedig tanultam azt, az oktatók, akik értettek a dolgukhoz, felhívták a figyelmünket, hogy az IBM az assembly nyelvet is assemblernek hívja, pedig annak azt a programot kell(ene) nevezni, ami az assemblyről fordít. Más nagy software gyártók jól is nevezték a dolgokat.

Bambano 2020.06.16. 14:28:41

a fő kérdés az optimalizáláskor valójában az, hogyha példányosítok egy keretrendszerből egy objektumot és csak a metódusait hívogatom, akkor kb. mit is tudok optimalizálni ahhoz képest, amit a keretrendszer a mélyben krahácsol?

droid_ · http://matyiszuro.blog.hu/ 2020.06.16. 14:35:04

azert azt is meg kell adni, hogy fordito nem optimalizal algoritmust. kodot azt igen, utasitasokat rendez at, parhuzamosit, hivasokat kod bemasolasaval helyettesit vagy egesz programreszeket kidob, de egy negyzetes komplexitasu algoritmus az is marad, es nem fog soha megverni egy linearisat eleg sok adatra. ezert is mondjak, hogy a programozo ne gyors kodot akarjon irni, az nem az o dolga, hanem gyors algoritmust.

de azzel is vigyazni kell, pl kiokosodunk egy jo kis adatstrukturat, ami keresztbe hosszaba hivatkozik mindenkire masra, jo gyors lesz tole a kereses az adatokon, mert csak kovetni kell a referenciakat, elvileg, aztan kiderul, hogy a memoriaban innen-onnan osszevadaszott hivatkozasok annyi cache miss-t okoznak, hogy egy brute force kereses lenyomja ha az adatok kozel vannak egymashoz es cache-ben le tud futni az egesz. van a youtube-on par erdekes video errol.

s 2020.06.16. 14:38:10

@Kurt úrfi teutonordikus vezértroll: "Faszság. Nem hatékony algoritmusokat kell írni, hanem átlátható, egyszerű kódokat, amit a következő, középszerű programozó is megért."
Attól függ. Ha csapatban dolgozol egy zsáknyi seggfejjel, akkor igen. Ha magadban tolod, és a forráskódot a kutya fasza sem látja rajtad kívül, akkor csinálhatsz olyasmit, ami kurva jól megy, és mindenki csak pislog. Már ha van idő rá. Persze az idő sem komoly akadály, ha elég okos vagy.

s 2020.06.16. 14:47:26

@Kopasz Szuzukis: Mert a mostani divatos programozó iskolák fossák ki magukból az egyébként gyenge képességű, programozónak csúfolt egyedeket. Megy a higítás ezerrel, ennek a szakmának gyakorlatilag vége. A kísérlet azért mutatta azt, amit mutatott, mert itt lényegében egy kód fordításról van szó. Az pedig valóban inkább nyelvi készséget használ, mint bármi mást.
Az algoritus tervezés inkább kíván matematikai megközelítést. Ezt viszont elvégzi a szakma krémje, a csicska melót meghagyva a kódíróknak. A kódolás lesz egyébként az első munka, amit az AI ki fog szorítani. Hiba nélküli kódokat termel, fáradhatatlanul. Az egy alantas munka.

s 2020.06.16. 14:49:48

@nyu: Az igazán mély problémákra a számítási sebesség növekedése nem megoldás. Azért nem látszik ez, mert kevés az igazán nagy probléma. De azért vannak.

droid_ · http://matyiszuro.blog.hu/ 2020.06.16. 14:51:52

birom az ilyen "egyebkent" joslatokat :)

s 2020.06.16. 14:52:54

@steery: Az első értelmes hozzászólás.

CyberPunK 2020.06.16. 14:54:54

@Bambano: Most programozásról beszélünk vagy legózásról?

droid_ · http://matyiszuro.blog.hu/ 2020.06.16. 14:55:01

"egyebkent" az igazan mely problemkra fogjak az AI-kat elsokent hasznalni, de nekem nehezemre esik nem ideirni hogy szerintem.

CyberPunK 2020.06.16. 15:03:28

@droid_: Szerintem mire eljutunk ide az emberek 80%-a kiváltásra került AI által és túl leszünk három buttleri dzsihad-on...

qwertzu 2020.06.16. 15:14:08

@s: "Hiba nélküli kódokat termel, fáradhatatlanul. Az egy alantas munka."

:) Ezt 20 éve hallgatom. :)

Akkor lesz ilyen, amikor erős MI lesz, de akkor a jelenlegi értelmiségi munkák 99%-a megy a levesbe.

Ez úgy a soha napján kiskedden ideje.

A probléma a következő: a feladat egzakt specifikációja, ami alapján kódot lehetne generálni, 100% pontosan ugyanolyan bonyolult megírni mint a kódot, és ebből következően pontosan ugyanazok a készségek kellenek hozzá, és ugyanannyi munkaidő.

2020.06.16. 15:38:48

@droid_:
Szerintem akkor veszi át a programozók szerepét az AI, ha a megrendelő is AI lesz. Mert a legnehezebb munka a programozásban, programtervezésben minden esetben az, hogy az önellentmondásoktól nem mentes megrendelői igényeket tedd konzisztenssé, formalizálhatóvá. Ha tényleg mindig egyértelműen specifikált dolgokat kellene leprogramozni, akkor már most nem lenne szükség programozókra, a helyzet az, hogy valójában ez az egyértelmű specifikáció a legtöbb esetben már maga a kód.

RHalacska 2020.06.16. 16:16:06

@Kurt úrfi teutonordikus vezértroll: Az agyafúrt, nem kommentelt megoldásokra mondta a tanárom: "Amikor megírtam ketten értettük: Isten és én. Most két hét múlva már csak Isten érti"

s 2020.06.16. 16:36:02

@droid_: Szerintem túl sokat várnak az AI-től. Mindig is ezt csinálták, ebben nincs változás.
Miért, szerinted az lesz, hogy az AI kitalálja az algoritmust, a gyerek meg, aki épp most gurult ki a CodeBerry -ből, az meg leveri a kódot?
Szerintem fordítva lesz. Azzal a különbséggel, hogy AI nem megy a CodeBerrybe. Ennyi esze azért lesz neki.

apro_marosan_petergabor 2020.06.16. 16:45:31

Mi a program (picit leegszerüsítve):
- bemeneti változók
- kimeneti változók közé fv-ek beépítése, összehangolása
Mi kell a jó programozónak:
- feladatmegértő képesség
- feladat definiáló képesség
- átlátás
- strukturált gondolkodás
- absztrahálóképesség
- gyakorlat (részfeladatokra ismert receptek, melyeket alkalmaz)
- precízség, hibafelismerő képesség (itt jön a szöveg, szintaxis értelmezés,
a "helyesírási", nyelvi képességek)
- a hardware környezet ismerete (ha olyan a feladat, elengedhetetlen)
- logikai képességek, rendszerben gondolkodás
- matematikai képességek (algoritmusok fejlesztéséhez, alkalmazások)
- kiegészítő ismeretek (elektromosság, fizika, biológia stb.)
Namost, amit itt (nagy vonalakban) áttekintettünk, annak egy sora érinti a poszt felvetését, azaz csak azzal elég vérszegény programozókat tudunk generálni.
tegyük hozzá, hogy nem mindegy miről beszélünk részprogramozórol, vagy rendszer programozóról, hiszen a komolyabb programok csapatmunkában készülnek, a rendszerprogramozónak pedig
tudnia kell, hogy arészletekben mi valósítható meg, mekkora erőforrásokat igényel, hogyan lehet behatárolni, elosztani az igényelt erőforrásokat + figyelembe venni a kollégák képességeit stb.
analizáló és integráló képesség (a feladat részekre bontása és integrálása)

Mindez egy kicsivel több és más, mint amiről hallottunk...

droid_ · http://matyiszuro.blog.hu/ 2020.06.16. 16:51:06

@s: nem talalja ki. magaban foglalja. nem kell kulon ember arra hogy megirjon egy programot ami megvalositja amit az AI kitalalt, hogy azzal megoldjon problemakat. az AI oldja meg magat a problemat. igy kepzelem.

mgdé 2020.06.16. 16:54:41

@apro_marosan_petergabor:

No, akkor eljutottunk oda, - csendes tó vízébe csapódó szikla -, miért jóval kevesebb a JÓ szervező, mint a jó programozó. Mert a szervezés/tervezés komplexebb feladat. :)

s 2020.06.16. 16:57:45

@qwertzu: ":) Ezt 20 éve hallgatom. :)"
Akkor talán lehet is benne valami, nem? Bár kétségtelen, hogy nem mindegy az sem, kitől hallod. Egy buzeráns marketing gecitől a számviteli és kommunikációs faiskola elvégzése után kerek négy hónappal, vagy valaki mástól. Az a valaki más én vagyok.

"Akkor lesz ilyen, amikor erős MI lesz, de akkor a jelenlegi értelmiségi munkák 99%-a megy a levesbe."
A jelenlegi értelmiségi munkák 99%-a nem értelmiségi munka, maradjunk ennyiben. Nem fizikai, az tény, de ettől még nem értelmiségi.

"Ez úgy a soha napján kiskedden ideje."
Rám sem jellemző a túlzott optimizmus. :-)

"A probléma a következő: a feladat egzakt specifikációja, ami alapján kódot lehetne generálni, 100% pontosan ugyanolyan bonyolult megírni mint a kódot, és ebből következően pontosan ugyanazok a készségek kellenek hozzá, és ugyanannyi munkaidő."
Nagyjából jól látod. Az igazán erős AI viszont ezt már nem fogja igényelni. Olyan problémákat old majd meg, amit az emberek (a vezető tudósokról beszélek most) nem is értenek. Azt sem fogják tudni, hogy azok éppen micsodák, és honnan kerültek oda. Nem az lesz a kérdés, hogy mi hogyan magyarázzuk el a problémát. Az lesz a kérdés, hogy nekünk hogyan magyarázzák el. Az AI ezen a ponton az ember számára természeti jelenséggé válik, amit éppen úgy nem ért majd, ahogyan a mai természeti jelenségek egy részét sem. Ebből a szempontból nem megoldás lesz, hanem probléma. Nem lesz hamar, de egyszer ez is eljön.

s 2020.06.16. 17:06:31

@droid_: Jól gondolod. AI nem fog egy embernél is hülyébb géppel kommunikálni. Az sem biztos, hogy az emberrel fog, de ebben azért reménykedjünk.

s 2020.06.16. 17:13:03

Van itt egy kettősség, ami felett elsiklunk. Mi azAI? Sokan szeretnek rá úgy gondolni, mint egy okos szolgára. Mintha kutya lenne, vagy ilyesmi. Okosan mozgatja a redőnyt, hogy ne süssön a szemebe a Nap. Ezzel szemben a valódi AI titok lesz az ember számára. Szerintem azt sem fogjuk észrevenni, hogy már kialakult.

droid_ · http://matyiszuro.blog.hu/ 2020.06.16. 17:21:14

@s: nahat, koszi hogy jovahagyod a velemenyem :)

Bambano 2020.06.16. 17:54:15

amíg nem lesz masszívan párhuzamosítható hardverünk, addig ai-nk se lesz, csak ilyen marketingkamu cuccok.

Alick 2020.06.16. 18:29:02

@s: Az erős AI még odébb van, egyelőre a specializált gyenge AI-ket próbáljuk jól használni.

midnight coder 2020.06.16. 19:51:55

@s: "A kódolás lesz egyébként az első munka, amit az AI ki fog szorítani. Hiba nélküli kódokat termel, fáradhatatlanul."

Ja, valóban alantas automatizálható munka. De a munkának hívott emberi tevékenységek 99%-a sokkal inkább az. Előbb megy a levesbe a jogász, az orvos, a nővér, az újságíró, a zenész, a grafikus, és sok más kreatívnak gondolt szakma. És ami utoljára megy a levesbe azok a fejlett vizuális és manuális képességeket igénylő munkák mint Pl. a vízvezetékszerelő.

a nagy hohohorgász 2020.06.16. 20:29:44

@a nagy hohohorgász: azert valjuk be aki specifikaciovsl dolgozik az droid, aki meg nem specifikacioval az maga az isten... na istennel en meg nem talalkoztam a 15 eves 10 cegnyi vallalat iranyitasi rendszer bevezetesnel..... writline" nem vagyok okos, de legalabb sokat fizetnek"

a nagy hohohorgász 2020.06.16. 21:12:13

@a nagy hohohorgász: mert a proli a kulalakot nezi a fizeto ceg meg az eredmenyt olcsobban :)))) aki az algoritmusokat tudja az a kiraly :)

Alick 2020.06.16. 21:40:32

@a nagy hohohorgász: Az Excelben a Solver nagyon jó dolog, viszont egy szoftver többnyire nemcsak képletek kiszámolásából áll.
Persze ha valamivel összetettebb számolási feladatról van szó, akkor még mindig ott van a Matlab...

droid_ · http://matyiszuro.blog.hu/ 2020.06.16. 22:00:42

huha, ugy latom sok itt a kompenzalnivalo :)

CyberPunK 2020.06.16. 22:04:17

@a nagy hohohorgász: Az a bibi, hogy normális fejlesztő nem iszik munka közben, legalábbis nem sokat, míg a te algoritmusodnak max picsarészegen lehet értelme. Ahogy a mondanivalódnak is.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 22:14:51

@fhdgy: Az IBM-nél programozók dolgoztak, nem nyelvészek. :-))

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 22:18:25

@s: Ha én lennék a főnököm, szétrúgnám a picsámat. Direkt használok olyan utasításokat amelyek alig ismertek, szívatom a kontárokat. De én egy spéci helyzetben vagyok. 30 éves, dokumentálatlan kódokat kell túrnom.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 22:20:50

@qwertzu: "A probléma a következő: a feladat egzakt specifikációja, ami alapján kódot lehetne generálni, 100% pontosan ugyanolyan bonyolult megírni mint a kódot" - szerintem több és a hibák kezelésére megy el a programozás 70 százaléka.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 22:22:44

@RHalacska: :-)) Bizony! Már az adott feladathoz hasonló programomat is nehéz előkeresni, hogy ne kelljen nulláról írni. Van vagy ezer darab.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 22:25:28

@apro_marosan_petergabor: Fontos dolog kimaradt, a hibák és kivételek kezelése. Egy nagy programrendszernél az a meló legnagyobb része és hosszú idő alatt jön össze. Hadd ne meséljek neked a BM nyilvántartásairól!

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 22:26:43

@mgdé: " miért jóval kevesebb a JÓ szervező, mint a jó programozó. Mert a szervezés/tervezés komplexebb feladat." - pontosan

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 22:29:25

@a nagy hohohorgász: Na! Mutatja a képességeidet, ha az excelt te programozásnak gondolod. :-))

Visceroid 2020.06.16. 22:40:20

A programozással kapcsolatban egy a lényeg: felesleges bele éveket ölni, meg nehéz vizsgákon átmenni, egyetemi tanulmányokat folytatni, programozási- és idegen nyelveket tanulni, nehéz munkahelyi felvételi teszteket írni, amikor egy pár hetes tanfolyam elvégzésével simán az ölébe hull az embernek a havi milliós állás. Ráadásul most az állam is támogatja! Iratkozzon be Ön is!

s 2020.06.16. 22:44:30

@Bambano: Ja. Az intelligencia alapja a kiszámíthatatlanság. Kvantumgép előtt esély sem lesz rá.

"Nem biztos csak a kétes szememnek
S ami világos, mint a nap: titok;
Hiszek a véletlennek, hirtelennek,
S gyanúm az igaz körül sompolyog;"

Francois Villon
( Szabó Lőrinc fordítása )

s 2020.06.16. 22:46:51

@Alick: Az nem AI, hanem messziről annak látszó valami.

s 2020.06.16. 22:50:28

@midnight coder: "azok a fejlett vizuális és manuális képességeket igénylő munkák mint Pl. a vízvezetékszerelő."
Jobban örültem volna, ha szobrászt mondasz.

Pontosan erről beszéltem pár kommenttel feljebb. A ma értelmiséginek nevezett munkák nagy része nem az.

2020.06.16. 22:50:57

a mai (átlag) programozónak a nyelvtudás kell, hogy megtalálja a már mások által megírt kódrészleteket. ami nem is lenne baj addig/akkor, ha jó megoldást talál(na), de vsz. az első működőt fogja, és ha az két szám összeadásához egy excel objektumot osztályt használ, az is belefér, elbírja a gép :)

s 2020.06.16. 22:59:25

@Kurt úrfi teutonordikus vezértroll: "Ha én lennék a főnököm, szétrúgnám a picsámat."
Ha én lennék a főnököd, akkor nem tenném. :-) Csak finoman jelezném, hogy nem kellenek a felesleges gabonakörök. El tudom dönteni, hogy ki a jó és ki nem az. Így azt is, hogy ki marad és ki megy.

s 2020.06.16. 23:03:00

@Visceroid: A smilet nem találtam. Volt pedig?

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 23:06:21

@s: Az egész egy nagy smile, nem is kérdés. Felesleges lett volna kitennie.

s 2020.06.16. 23:07:05

@szénáspop: "a mai (átlag) programozó" nem programozó. Azok hívják így őket, akik csak ritkán és régebben találkoztak programozóval. Végül is a programozókra hasonlítanak a legjobban, nem például a villanyszerelőre.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.16. 23:28:33

@a nagy hohohorgász: Az a helyzet, ha nem vetted volna észre (nem), hogy itt különböző politikai nézetű, különböző területeken és architektúrákon/környezetekben dolgozó informatikusok diskurzusa folyik. Te itt nagyon ciki vagy. :-)) Kb. mikor az autógyárban beleszól a takarító a robotokat tervező mérnökök szakmai eszmecseréjébe.

RHalacska 2020.06.16. 23:58:08

@s: :) hát igen. Ma a kódolókat hívják programozónak. Pedig a programozó az, aki valamit fel tud programozni az igények alapján. Pl. egy fűtésvezérlést. vagy bármit. És nem a programnyelv számít, hanem ez elmélet. Én vagy min 10. programnyelvvel találkoztam az elmúlt 30 évben... Ahogy anno mondta a tanárom, a programnyelv nem fontos, a algoritmus igen.

2020.06.17. 06:15:31

Szerintem a magyarázat kézenfekvő: attól függ, mit látsz, amikor egy programozási feladatra nézel.

Láthatsz egy spagettivel kipipálandó feladatlistát, amit valamilyen környezetben ki kell kalapálnod. Erre elég egy pár hónapos gyorstalpaló vagy akár egy egyetemi képzés. Az eredmény az, amiben ma élünk. Lásd még Bob Martin: Future of Programming - youtu.be/ecIWPzGEbFc?t=3059

Vagy láthatsz függetleníthető szegmenseket (domain) komponenseket "saját tudással" és az ennek leírására, használatára alkalmas nyelvekkel (DSL), amelyekből majd fel fogod építeni a rendszert. Begépeled valamilyen nyelven, rájössz, hogy nem jól húztad meg a határokat, tehát a működő rendszer alatt elkezded átalakítani a modulok nyelveit. Ez a refactor, amikor baromi sokat dolgozol azért, hogy a rendszer ugyanazt csinálja mint addig - de stabilabb legyen, jobban "értse" a saját állapotát, tovább tudd fejleszteni, a benne lévő modulokat újra tudd használni. És amit jellemzően mindenki utál körülötted. Ahogy téged is amiért csinálod. Ha ezt sokáig csinálod, ugyanúgy rögzül mint az asztalos mester kezében a derékszög (láttam ilyet és próbáltam utánozni, vicces volt). Mivel erre tanítottad be a neuronhálódat, már az agyad műveli "magától": nyelveket alkot és optimalizál, mielőtt egy sort is gépelnél. Amikor idegen kódot olvas, ezt a nyelvet térképezi fel. ("A Mátrixnál túl sok az adat ahhoz, hogy dekódolhassuk. Megszokod. Én már nem is látom a kódot, csak szőkéket, barnákat, vörösöket....")

Szerintem ezt sikerült elkapni a kísérletben. Persze egy komolyabb informatikai képzés során előkerülnek a Chomsky nyelvosztályok, az automaták és a Turing gép viszonya, a megértés és tudás fogalma is (fordítóprogramok, esetleg annak felismerése, hogy minden informatikai rendszer "fordítóprogram", jönnek a rekurzív környezetek, LISP, ...)

Szóval az említett "meglepetés" inkább azokat éri, akik ezt nem tanulták és értették meg.

Bambano 2020.06.17. 07:36:43

@midnight coder: úgy érted, tele van szórva a világ masszívan párhuzamosított architektúrákkal? a masszív alatt ne 64-et érts, mint a mostani ryzenben, meg ne is 5-6 ezret, mint egy videokártyában, hanem mondjuk 3 milliárdot, mint egy agyban.

nincs három milliárdosan párhuzamosított cuccunk, pláne nincs annyi belőle, ahány tesla meg önvezetést hazudó autó, "okos telefon" meg mesterséges unintelligencia alkalmazás fut a világban. mind marketing hazugság.

amíg nincs, addig ai sincs. vagyis még nagyon sokáig nem lesz.

apro_marosan_petergabor 2020.06.17. 07:43:19

Azért a kutatók nem lehettek túl erősek a kutatott témában...:)

2020.06.17. 08:12:03

@apro_marosan_petergabor: Én húsz év ipari tapasztalat után visszaülve az "iskolapadba" egy gyors MSc és (bebukott) PhD körre, találkoztam sok masszív zseni kutató munkájával. Először a fejemet vertem a falba a "miért nem tudtam én erről?" kérdéssel, de aztán rájöttem. Persze egyetemi tanárok sem ismerik a munkájuk jelentőségét, de én se értettem volna valós tapasztalat és saját kínlódás nélkül. "Nincs királyi út"... és pont ezért nem látszanak ki az "ismert nevek" mögül. Mert nem népszerű amit mondanak. Helyette marad a "közérthető" marketing, és viszi magával a színvonalat. Amit ezek a fickók pontosan láttak előre :-(

Serény Vélemény 2020.06.17. 08:34:02

@a nagy hohohorgász: Persze. Megírod excelben az összetett képletet, de azt, hogy 10 ezer, 20 ezer, vagy 21 ezer sor után fog beborulni az egész, hosszú tízpercekre, úgy lefogva az egyébként nem gyenge számítógépedet, hogy egy egyszerű egérkattintásra sem válaszol, azt nem tudod megmondani. És nagyjából senki sem tudja megmondani. Csak egy dologban lehetsz biztos: van egy határ, ami után beborul.

Serény Vélemény 2020.06.17. 08:46:42

@s: na ja. Aztán az ai úgy fogja megoldani a problémákat, ahogy mondjuk az Én a Robot c. filmben a robot: a baleset után megmenti a rendőrt, aki ettől kissé pszichopata lesz, viszont nem menti meg a gyereket, mert annak a megmenekülése kisebb valószínűségű.
És igen, amit te az ai-tól vársz, az egy olyan világ, ami jobb lenne, ha nem jönne el.

GyMasa 2020.06.17. 11:29:35

@nyu:
Ezzel kicsit vitatkoznék.
Az autóiparban azért ma is kb. a legfontosabb, hogy "olcsó legyen" amit csinálsz.
A mostani projektünkben a komplett applikáció valami <600kB.
Ebben van:
- Elsődleges és másodlagos boot loader
- OaBr Stack
- Real time OS
- Állapotgép
- Diagnosztika
- termikus védelem.
Szóval, vannak iparágak, ahol nem megy a "majd veszünk erősebb vasat" hozzáállás, mert pl az általunk használt mikrovezérlő családnak nem is nagyon van ennél több memóriával elérhető változata.

s 2020.06.17. 11:45:55

@Serény Vélemény: Csak mi, emberek gondolkodunk emberként. Más értelmes entitás nem biztos, hogy felmutat emberi jellemzőket, de ettől még értelmes.
Biztosan ismered a történetet, amiben hajócsatákat vívnak meg egy stratégiai játék keretében. Bajnokságokat rendeznek belőle, és egy alkalommal benevezték az AI-t is, mert jó teszt terepnek ígérkezett. Az AI fölényesen nyert az emberrel szemben. Ugyanis olyan pontozási rendszer működött, hogy a játékos flottájának átlag sebességének függvényében lehetett plusz erőforrásokhoz - üzemnyag, lőszer, hajók stb. - hozzájutni. Az emberi játékos bevontatta a sérült hajóit a dokkba, és megjavította. Az AI kilőtte a saját lassú hajóit. Nem azt mondom, hogy az emberi gondolkodástól teljesen idegen ez, de manapság már nem annyira elterjedt. A rómaiak mindenestre még alkalmaztak valami hasonlót az úgynevezett tizedelés formájában. Ha nem volt elég lelkes a légió, akkor minden tizediket kinyírtak, a miheztartás végett. Lelkesebbek ettől talán nem lettek, de elszántabbak mindenképp. A római légiók embertelenségük ellenére meglehetősen hatékonyak voltak.

s 2020.06.17. 12:06:51

@Kedves Loránd x: "Az informatikai hardver teljesítménye sok évtized óta exponenciálisan növekedett (megint Bob Martin idézet: a saját karrierje alatt 22 nagyságrenddel). Ez nem tükröződik vissza a napi gyakorlatban"

A hardverek teljesítményére létezik felső korlát. Ezek fizikai rendszerek, és bármennyire gyorsan is nő a teljesítmény kezdetben, egy határ után - hacsak nem helyezik teljesen új alapokra a fizikai megvalósítást - kifullad a nővekedés. Egy közismert problémára - utazó ügynök probléma - viszont a mai napig nincsen igazolt, legjobb megoldás. Itt a világ leggyorsabb hálózazban párhuzamosan számoló gépei is falakba ütköznek a pontok számának a növekedésével.
A napi gyakorlatban a teljesítmény növekedése azért látható. Jó kép- és hangminőségű videókat nézegetünk, filmeket töltünk le, banki rendszereket működtetünk, mobil kommunikációt, gps-t, használunk. Mindez nem lenne lehetséges a számítástechnika fejlődése nélkül. Viszont a kemény problémák, amikre jelenleg csak exponenciális időalapú algoritmusok vannak, azok nem lesznek megoldva az informatika fejlődésével.

Bambano 2020.06.17. 12:48:51

@Kedves Loránd x: "Az informatikai hardver teljesítménye sok évtized óta exponenciálisan növekedett": a kilenc évvel ezelőtt vásárolt desktopom meg a másfél éves desktopom között a cpubenchmark.net szerint nincs egy kettes szorzó se. Se egy szálon, se összesen.
már nagyon régen egy helyben toporgunk teljesítmény terén. Az intel processzorok egy szálas teljesítménye alig nőtt a 2000-es széria óta.

látszólagos teljesítménynövekedés van amiatt, hogy nem egymagos, hanem többmagos a proci. aminek külön örülünk, mióta annyi lyuk van az intel procikban, hogy nem bírom összeszámolni őket.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.17. 13:08:25

@s: A hardverek fizikai felső korlátja sokkal magasabban van mint a kémiai folyamatokon alapuló emberi agyé. Csak az AI algoritmusa még messze van attól az algoritmustól (???) amivel az emberi agy működik.

alalala 2020.06.17. 13:19:46

@Bambano: "a kilenc évvel ezelőtt vásárolt desktopom meg a másfél éves desktopom között a cpubenchmark.net szerint nincs egy kettes szorzó se"

Az exponenciális növekedést én is megkérdőjelezem, de ezt nem arra alapoznám, hogy épp mit veszel, hanem inkább arra, hogy hol tartott az adott évben a technológia.

Egy felhasználónak amúgy nem mindegy, hogy a magok számának növelése vagy az adott mag teljesítményének növelése (vagy a memória, videokártya, stb..) miatt számol gyorsabban a számítógép? A teljesítmény szempontjából úgyis a végeredmény a lényeg.

Hogy valami érdekeset is mondjak. Igaz nem mai alkotás, de azért mutatja a tendenciát: www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch-2011.pdf

qwertzu 2020.06.17. 13:19:56

@Bambano: Ellenben GPU-ból ugyanannyi pénzért sokkal erőssebbet kapsz. És egyre több dologra vannak használva.

GyMasa 2020.06.17. 13:23:54

@Bambano:
"már nagyon régen egy helyben toporgunk teljesítmény terén. Az intel processzorok egy szálas teljesítménye alig nőtt a 2000-es széria óta."
Mondjuk, ennek nem elsősorban a technológia az oka, hanem az INtel üzletpolitikája.
Mivel nem volt neki érdemben konkurenciája abban az időszakban, így simán behúzta a féket, és csak ilyen alibi "újításokkal" tartotta fenn a látszatot.
Amióta az AMD ismét nyeregbe szállt, azért érdekes módon az Intel is tud a consumer piacra 300USD-ért is gyártami 10 magos HT-s CPUkat. (eddig is tudott volna, de mivel nem volt igazi verseny, így inkább a kaszát választotta helyette.)
Az mondjuk engem is meglepett, hogy annyira amatőrök voltak, hogy úgy tűnik, a K&F-sel is teljesen leálltak. Én azt hittem, van annyi eszük, hogy arra továbbra is szánnak pénzt (csak elteszik a fiókba), és amikor az AMD visszatér a piacra (ami lássuk be, teljesen nyilvánvaló volt minden értelmes embernek, hiszen már megcsinálták egyszer azelőtt is), akkor pár hónap alatt gyártásba is viszik azokat.

"látszólagos teljesítménynövekedés van amiatt, hogy nem egymagos, hanem többmagos a proci."
Lásd fentebb, ez az elmúlt 10 év egy szégyene lesz az Intelnek.
(másrészről a részvényesek viszont igen jól jártak a nyereségoptimalizált üzleti döntéssel.)

" aminek külön örülünk, mióta annyi lyuk van az intel procikban, hogy nem bírom összeszámolni őket. "
Mondjuk, ezek a lyukak eléggé kevéssé érintenek egy átlagos felhasználót, mert igen fontosnak kell lenned, hogy olyan módon akarják megszerezni az adataidat.
Ha meg érintenek is, vagy van rá már javítás, vagy vehetsz jobb ár/érték arányú AMD rendszert, aminél még nem tudsz a hasonló lyukakról, merugye a Zen architektúra vagy 2 éve van a piacon a Core meg a 10 generációját tapossa, lényegében változatlan architektúrával.

Kovacs Nocraft Jozsefne 2020.06.17. 21:14:26

@alalala:

"Egy felhasználónak amúgy nem mindegy, hogy a magok számának növelése vagy az adott mag teljesítményének növelése (vagy a memória, videokártya, stb..) miatt számol gyorsabban a számítógép?"

Szerintem a feladattól függ. Ha erősen párhuzamosítható, akkor számít a sok mag vagy a HT. Ha nem, akkor kevésbé.

Kovacs Nocraft Jozsefne 2020.06.17. 21:21:20

@Kedves Loránd x:

"az igazi kalapács a 22 nagyságrend.
"

Ami vsz. kis tévedés. Egy mai processzor órajele legyen 5GHz, ha ebből leveszek 10 nagyságrendet, akkor kapok 0.5Hz-et. Ezek szerint a mai processzor felépítésének még további 12 nagyságrenddel kellene jobbnak lennie egy akkori processzorénál.

Ehhez képest egy Z80-as processzor elment 4MHz-en, ami órajelben máér csak 3 nagyságrendnyi arány, így egy mai processzor felépítésének 19 nagyságrenddel kellene jobbnak lennie.

Lehet, hogy igaz, de akkor mihez kell viszonyítani?

s 2020.06.17. 23:00:50

@Kurt úrfi teutonordikus vezértroll: A kémia nagyon gyors. Elég a robbanásra gondolni, de pl. a DNS másolás is elképesztő sebességgel zajlik. A másolás során végigfut a szálon egy hibajavító enzim. Akkora fordulatszámon, ami szinte felfoghatatlan. Igaz, az ember neuronja kb. 100 Hz tempóra képes csak, ez az órajele. Az agyban algoritmus nincs, de nagyon sok neuron van, és nem determinisztikus a működése a rendszernek. AI -nek sem lesz algoritmusa. Ha lenne, akkor értenénk, hogy mit csinál. Öntanuló rendszer lesz, nagyon sok neuronnal (kapcsolóelem), ami nem 100 Hz -en működik majd, hanem gyorsabban. Ezeket tippelések során hangolja finomra, próba - szerencse alapon, baromi rövid ciklusidővel. A kimenet (válasz) nem determinisztikus, hanem valószínűségi, épp úgy mint az emberi agy esetén. Tehát bekapcsolva hagyják két hétig, és profi lehet bármiből, anélkül, hogy értené bárki is, hogyan csinálta.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.17. 23:35:56

@s: Ne hasonlítsd a robbanást a szerveskémiai folyamatokhoz! Az ingerületátvitel kémiája lassú. Viszont valóban, minden sejt szinte egy pici processzor.

Alick 2020.06.18. 14:20:12

@Kurt úrfi teutonordikus vezértroll: "Az ingerületátvitel kémiája lassú. Viszont valóban, minden sejt szinte egy pici processzor."

Nem túl szofisztikált axonos I/O-val...
:)

a nagy hohohorgász 2020.06.18. 16:43:07

@Serény Vélemény: a kapacitas problemat alairom de magyarazdd mar el a megkurt trollnak hogy aki az algoritmushoz nem ert az csak egy droid aki tud szamitogepul.... viszont jol fizetett droid. Nem irigylem senkitol de sztem ez az igazsag.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.18. 21:56:12

@a nagy hohohorgász: Milyen algoritmushoz kellene érteni? Melyik problémához, melyik algoritmus? Például a GIRO utalási algoritmus? A TAJ nyilvántartás? A lakcím nyilvántartás? A családtámogatás megállapítása? Az árvasági ellátás megállapítása? A TAJ szám ellenőrzés? Na mi a TAJ szám ellenőrzés algoritmusa?

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.19. 17:16:36

@a nagy hohohorgász: Te még életedben nem láttál specifikációt, igaz? Rendszertervet adnak, szó sincs arról hogy lépésről lépésre leírják. Aszongyák ott van egy adatbázis táblában az utalandó lóvé, keressem ki melyik mezőben és melyik nincs visszatartva, és adott az Elektra terminálnak szükséges fájl szerkezete. Ennyi. Meg GIRO megmondja mennyi utalás mehet csomagonként. Az algoritmust a programozó találja ki. Neked fingod nincs arról mi a programozás, szervezés, specifikáció.

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.19. 17:20:49

@a nagy hohohorgász: 10 év? Az lófasz! Én 35 éve nyomom több különböző programozási nyelven. C-ben, 2 assemblerben, Cobolban, Pascalban, PL1-ben, Fortranban. A tranzakció, adatbáziskezelő rendszereket nem is számolom.

a nagy hohohorgász 2020.06.19. 18:54:44

@Kedves Loránd x: akkor ugyanarrol beszelunk. Azt is hulyenek tartom aki meg sem tudja mondani a programozonak hogy mit akar... en olyan spcifikaciot adok amiben benne van mit mivel honnan hova es mi az osszefugges es mire kell figyelni. Az en 10 eves tapasztalatom alatt a specifikaco nelkul senki nem tudta volna megoldani csak problemaleirassal. Korubelul 6 vallalatiranyitasi rendszer cegeivel dolgoztunk. A legnagyobbak ifs, sap a tobbi kisebb ceg. A sajat szoftverjuket nem ismerik... En ebbol indulok ki. Sorry

a nagy hohohorgász 2020.06.19. 18:58:19

@a nagy hohohorgász: bmeg levelben leirja a paraszt hogy a program nem tud vmit mert o nem tudja hogy kell lefejleszteni.... en azert irtam az excelt mert amit ott lehet azt programban is lehet.... lehet h en talalkoztam selejt programozokkal, na de ennyivel?????

a nagy hohohorgász 2020.06.19. 19:32:01

@Kedves Loránd x: amugy pont hogy korrekt acsarogni. Szerinted a vevo mit akar hogy 20.ra is szart kapjon vagy hogy masodikra legalabb jot???? Sz hogy igy a cegednek kevesebb a gempa... ja inkabb irnak egy 200 oldalas programleirast amit meg ti sem ertetek hogy szerzodesileg ala legyen tamasztva.

a nagy hohohorgász 2020.06.19. 20:56:46

@Kurt úrfi teutonordikus vezértroll: tudod en az algoritmusokbol keresem a penzem. Biztos luzer vagyok ha baltol jobbig kapom a felkereseket, es mindenki tudja mi a hitem megis kellek nekik....

mgdé 2020.06.20. 01:38:05

@a nagy hohohorgász:

Valahogy sejtettem, hogy te egy saphuszár féle lehetsz. S stimmt. :)

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.20. 06:55:08

@a nagy hohohorgász: Azt sem tudod mi az algoritmus, a rendszerterv és a szervezési dokumentáció között a különbség.

apro_marosan_petergabor 2020.06.20. 09:27:27

Summázunk miután nagyon elsüllyedünk itt a részletekben.
Amit a cikk leírt - nem hülyeség, marhaság.

mgdé 2020.06.20. 15:21:25

@szpidigonzálesz:
erdészke, te foglalkozz inkább a gallyazással meg a falopásokkal

boborján20 2020.06.20. 17:08:07

@mgdé: nem nyugszik ez a szerencsétlen bolond. nincs hét, hogy ne csináljon egy újabb nicknevet. de mindig kilóg a pata a reverenda alól:)))

Kurt úrfi teutonordikus vezértroll · https://hatodiklenin.blog.hu/ 2020.06.20. 21:19:57

@a nagy hohohorgász: Hülyegyerek! Ennek hol az előzménye? Ez válaszolt az exceles baromságodra. @Alick:

mgdé 2020.06.20. 22:55:25

@a nagy hohohorgász:

Mert már első ránézésre is amolyan 'tanácsadó' fejed van,
s a dumád is elég önhitt. :D

GyMasa 2020.06.21. 13:33:53

@a nagy hohohorgász:
"Te odamesz informatikuskent egy allashirdetesre , egy semmihez nem erto hres a sablon kerdesre a sablon valaszokat varja,..."
Érdekes, én villamosmérnökként az elmúlt 15 évben semelyik állásinterjúmon sem kellett ezekre a hülye, hr-es kérdésekre egyszer sem válaszolnom, pedig hidd el, már be voltak készítve a vicces kis válaszaim.
Mindegyik alkalommal bent volt az interjún a leendő főnök, és jobbára vele beszélgettem szakmai, meg a leendő pozícióval kapcsolatos kérdésekkel kapcsolatban.
A hr-es általában a végén a bér körüli témában szólalt meg először.
Persze, nyilván lehet, hogy nekem van csak szerencsém, hogy keresett szakmám van.
süti beállítások módosítása