Durván fog gyorsulni a Python kódok futási sebessége
2022-05-19T09:55:42+02:00
2022-06-26T20:14:18+02:00
2022-06-29T08:07:28+02:00
  • Nem erről szól. A Pythontól indultunk

    Mondja Móricka, aki már egy tucat hozzászólás óta a kerneleken és az operációs rendszereken pörög - annak ellenére is, hogy többször el lett mondva neki, hogy ezeknek semmi köze a Python és a GIL-hez. Hogy nem szakad rá a plafon.

    Te valami egyetemi tanár lehetsz

    Nem, én - ahogy már mondtam - az vagyok, aki már akkor nem, hogy kernelmeghajtókat írt, de kerneleket fejtett vissza, mikrokontrollereket és szervereket programozott, fejlesztői környezetet írt és hardveresen gyorsított grafikus környezetet írt, amikor te még a csattogós lepkét tologattad otthon. Amiben adott esetben nem az az érdekes, hogy én ennyi mindent csináltam, hanem az, hogy te a skála másik végén vagy tudásban és tapasztalatban - és ennek ellenére akarod osztani az észt.

    A nagy arc ellenére gyakorlati eredmények nuku, felmutatni semmit nem tudsz pár párhuzamos portról meg Windows GDI-ről szóló doksin kívül.

    Bár ennél sokkal többet mutattam már fel eddig is, de még ez is végtelenszer több, mint amit te tudtál felmutatni. Hiszen te eddig egyetlen nyamvadt kis cikkedre, sőt, akár egy a témába vágó blog- vagy fórumposztodra sem tudtál linkelni. Kódot meg aztán végképp' nem láttunk tőled. És te mesélsz arról, hogy a másik nem tud semmit felmutatni?

    Vicces fiú vagy, na. Azért várom a linkeket a publikációidra, meghajtóprogramjaidra, vagy egyáltalán bármire, ami bizonyítja, hogy neked bármi közöd is lenne ehhez a témához, és alkottál benne bármi értékelhetőt is! Na, küldöd?

    PS:
    (felhozhattad volna még a "te érvelési hibád" című szabálykönyvet is, a többiek azt szokták.

    Ha most elmondom, hogy azt a "szabálykönyvet" is én csináltam, akkor azt hiszem tökéletesen teljessé válik az irónia mindabban, amit sikerült itt összehordanod, úgy szakmailag, mint egyébként is (tekintettel a ki-mit-tud-felmutatni vonatkozása is); egyben nyilvánvalóvá válik az is, hogy mennyire vagy képben bármit illetően is.
    Mutasd a teljes hozzászólást!
  • És mindig nem érti Móricka, hogy nem hogy kernel mód, de OS sem kell a szálkezeléshez. Ami különösen annak tükrében tragédia, hogy az egész topik valójában erről szól.

    Nem erről szól. A Pythontól indultunk, amit a gyakorlatban nem az otthon összetákolt oprendszereden fognak futtatni és futtattak eddig is, hanem kernel móddal rendelkező, szálak kezelésére alkalmas oprendszereken egy GIL-lel a Pythonon belül.

    Te valami egyetemi tanár lehetsz, aki "oprendszerek" előadásokat tart, és leginkább a '70-es évek "nagygépeit" ismeri, de egyébként leragadt 20 évvel ezelőtt. Fontos a tekintélyelv is, nem akárki vagy, hiszen felkértek már pár itthon kiadott könyv lektorálására is, és jó ideje nem csinálsz már mást, minthogy kiosztod a PhD-seidnek a témákat.
    A nagy arc ellenére gyakorlati eredmények nuku, felmutatni semmit nem tudsz pár párhuzamos portról meg Windows GDI-ről szóló doksin kívül. Sőt, még mélyebben belemenni a témába sem vagy képes, kivéve ha a "hülye vagy" panel különböző verzióinak megtervezéséről van szó (felhozhattad volna még a "te érvelési hibád" című szabálykönyvet is, a többiek azt szokták. Ők nem olyan okosak, mint te, aki már a Dunning-Krugert is ismeri).
    Csak azért akadékoskodsz, mert mindenáron bebizonyítod, hogy bizony a kvázi egyszálasra tervezett kódok mostantól márpedig gyorsulni fognak, ha többszálon futtatják őket a GIL mellőzésével. Fényképezd le a megsárgult fekete-fehér fényképeidet a telefonoddal, és hirtelen azok is színesek lesznek. :DDD

    Jó volt kiismerni téged, na szevasz.
    Mutasd a teljes hozzászólást!
  • Melyik olyan OS-nek nincs kernelmódja, ami képes szálkezelésre?

    És mindig nem érti Móricka, hogy nem hogy kernel mód, de OS sem kell a szálkezeléshez. Ami különösen annak tükrében tragédia, hogy az egész topik valójában erről szól.

    Pont a linkek végigkattintgatása után lett világos, hogy nem te vagy sem a Kovács Magda, sem pedig a Mark Russinovich. Hanem valaki, aki leragadt a DOS-os időkben

    És még mindig nem sikerült végigkattintgatni a linkeket sem. Amikben bőven vannak Windows 9X-es, Windows NT-s cikkek is. Windows NT alá írt meghajtóprogram, és Windows 9X-es kernelvisszafejtés és -javítás is. .... Vagy csak nem az van, hogy ugyan végigkattintgattad a linkeket, de egyszerűen annyira nem vagy képben a témában, hogy még azt sem ismered fel, hogy egy adott dolog a Windows NT-ről vagy a Windows 9X-ről szól? De ugye hogy ez van? Sejtettem.

    Miközben semmit nem tudsz elmagyarázni felhomályosítás gyanánt,

    Mondod, miközben épp' most kaptál linkeket több tucat cikkre, amikben pont az itt felmerült dolgokat magyarázom el (illetve magyaráztam el, már több évtizeddel ezelőtt). A valóság az, hogy nem én nem tudok magyarázni, hanem te nem értesz meg semmit, mivel alapvető szakkifejezések valódi jelentésével sem vagy tisztában. Nagy különbség. 

    (nagy kaland, még az én nevem is rajta van egy könyvön)

    Az iskolai évkönyvön, mi? Dobj már egy linket a publikációid közül párra! Vagy pár meghajtóprogramra, amit te írtál! Csak, hogy lássunk nem megint csak kamuzol, és legalább _valamit_ - ha nem is az általam hozottakkal összehasonlíthatót és témába vágót - publikáltál!


    Lényeg a lényeg: Ezt a vitát, meg az egyébként tök értelmetlen végtagméregetést annyira benézted, hogy az már nem is vicces! De hát ugye ez a Dunning-Kruger lényege. A jó hír, hogy - ahogy már mondtam - csak rajtad múlik, hogy továbbra is megmaradsz a tudatlanságodban, vagy nekiállsz elsajátítani szakmai ismereteket. Ha pedig utóbbira nincs időd, affinitásod, akkor legalább már maradj csöndben, és legalább ne a téma egy több évtizedes szakértőjével kezdj el vitázni arról, hogy egy agyműtétet hogyan is kell lebonyolítani, amikor valójában még azt sem tudod, hogy a kezdő metszést hol kell megejteni! 

    Ennyike.
    Mutasd a teljes hozzászólást!
  • Nem, mivel nincs is feltétlenül kernel mód. Semmi köze egyiknek a másikhoz.

    Melyik olyan OS-nek nincs kernelmódja, ami képes szálkezelésre?

    Nem, én az a fajta vagyok, akik nem hogy a Chip magazint, de az annál sokkal magasabb szintű szakmai magazinokat, könyveket írta, szerkesztette.Látom még a linkek végigkattintgatása is megoldhatatlan problémát okozott számodra. Ez sok mindent megmagyaráz.


    Pont a linkek végigkattintgatása után lett világos, hogy nem te vagy sem a Kovács Magda, sem pedig a Mark Russinovich. Hanem valaki, aki leragadt a DOS-os időkben, és szándékosan nem gyakorlati, hanem elméleti síkon akadékoskodik.

    A többit nem citálom részletesen, gyakorlatilag az összes válaszodnak az a lényege, hogy magas lóról, felhúzott orral közlöd, mekkora hülye vagyok.
    Miközben semmit nem tudsz elmagyarázni felhomályosítás gyanánt, sem felmutatni, azon kívül, hogy állítólag valami "magas szakmai színvonalú magazinokat meg könyveket szerkesztettél" (nagy kaland, még az én nevem is rajta van egy könyvön).
    Biztos hatalmas színvonalat képviselnek, sztem te vmi egyetemi tanszékről lektorálhattál pár itthon kiadott könyvet, nulla gyakorlati tapasztalattal.
    Mutasd a teljes hozzászólást!
  • Igen, de maga a megszakítás kernel módban van lekezelve. 

    Nem, mivel nincs is feltétlenül kernel mód, sőt, kernel se. Egyszerűen semmi köze egyiknek a másikhoz. A többszálúsághoz meg pláne nincs.

    Nem pont erről beszélek, ember?

    Nem. Össze-vissza dumálsz hülyeségeket, aztán amikor elmondják, hogy nem úgy van, akkor valami mást kezdesz el mondani, ami még mindig hülyeség persze. Aztán amikor erről is megmutatják azt, akkor valami harmadik hülyeséget írsz le. És így tovább. Mindezt csak azért, mert vagy nem tudod, vagy legalább nem tudod beismerni, hogy halvány lila segédfogalmaid, illetve maximum azok vannak a témáról.

    Értem, szóval te vagy a Chip magazinos fajta.

    Nem, én az a fajta vagyok, akik nem hogy a Chip magazint, de az annál sokkal magasabb szintű szakmai magazinokat, könyveket írta, szerkesztette. Konkrétan a Chip magazinban azért nem jelent meg írásom, mert amikor leültünk beszélgetni a szerkesztőséggel erről, akkor nyilvánvalóvá vált, hogy ők sem értik miről szólnak ezek a cikkek, illetve hogy a célközönségüknek (pl. neked) meg messze túl magasak lennének. Kb. ez volt az ok, amiért végül létrejött a prog.hu.

    Ilyeneket én is írtam 20+ éve, DOS-os idők, assembly, perifériák közvetlen elérése, stb. 

    Nem, te ilyeneket nem írtál. Sőt, ilyeneket olvasni sem olvastál, illetve érteni sem értettél. Ha ugyanis legalább érteni értetted volna azt, amit más ír ezekről, akkor nem írnál olyan orbitális hülyeségeket a megszakításokról, a meghajtókról, a többszálúságról, mint amiket itt olvashatunk tőled.

    Már értem ezt a megszakításkezelős fixációdat, akkoriban tényleg úgy ment, ahogy írod. Mert ott nem volt külön kernel/user mód, vagy ha egy DPMI-szerveren keresztül/alatt futott a DOS-os kódod, akkor a tényleges megszakításkezelésből hívódott a te handlered is, user módban. A Win98 "kernele" is erősen innen gyökerezik

    Nem, a Windows 98 kernele abszolút nem onnan gyökeredzik. A Windows 98 kernele egy teljes értékű 32-bites preemptív kernel, aminek semmi köze se a DOS-hoz, se a DPMI-hez. A user módhoz meg pláne nem.

    de nézd meg az NT-architektúrát, annak semmi köze ehhez, teljesen más. A Win32 is NT API volt

    Nem, a Win32 az egy alrendszer volt a Windows NT-ben, aminek azonban semmi köze nem volt az NT natív API-jához, és amihez hasonló több másik alrendszer is futott az NT kernel felett. Továbbá az egész Win32 csak a Win16 egy kibővítése, kiterjesztése, és semmi köze a megszakításokhoz meg a kernelhez sem, ezzel összefüggésben pedig a többszálúság megvalósításához sem. A Win32 "akármin elmegy", pl. Linuxon is, ezért létezhet a WINE, illetve ez a lényege (ti. a Win32 API megvalósítása a Linux kernel felett).

    később portolták Win95-re, ezért nincsenek benne, amiről te írsz, de egyébként más értelmes oprendszerekben sem.

    Most megkérdezném, hogy mire gondolsz, amikor "amiről te írsz"-ről beszélsz.... de inkább nem teszem, mert tudom, hogy csak orbitális hülyeségek, szalmabábok és terelések tárházát kapnám válaszként.

    Én arra lettem volna kíváncsi, hogy írtál-e Windóz (vagy más OS) alá kernel szinten drivert, komponenst vagy akár csak egy user módú kódot, ami bizonyos perifériákkal kommunikál vagy emulál.

    Látom még a linkek végigkattintgatása is megoldhatatlan problémát okozott számodra. Ez sok mindent megmagyaráz. (Ha legalább ezt a feladatot sikerült volna abszolválni, akkor tudnád, hogy még sokkal többet is csináltam, mint kernel driver írása.)

    Mondjuk hogy ezt honnan veszed, nem tudom. De mivel oldottam már meg csattogóslepke-tologatás közben (20 éve) Win98 alatt DOS-os VM-ből Win32-es kóddal történő kliens-szerver jellegű kommunikációt saját kernelkomponenssel, még mindig előttem van az architektúra nagy része, és hogy jellegéből adódóan mennyire instabil is volt az a "kernel".

    Ez teljesen egyértelművé teszi az a sok orbitális hülyeség, amit a Win32 és Win16, meg úgy általában a megszakításokról írtál. A valóság az, hogy halvány lila segédfogalmaid vannak csak a dolgokról, ami éppen arra elég, hogy azt hidd, hogy tudsz mindent, miközben még amit tudsz, azt is rosszul tudod. Az elmúlt pár hozzászólásod tökéletes bizonyítéka ennek.

    Mutass egyetlen olyan alkalmazást, ami egyproci/egyszál környezetben több szálon futtatott cpu-intenzív 

    Szóval nem csak a rendszerprogramozáshoz vagy bugyi, de a szövegértésed is nulla. Ha nem lenne az, akkor nem kérnéd újra és újra azt, amiről rég megmondták neked, hogy miért hülyeség, illetve példa rá lényegében az összes létező többszálú processzorintenzív program a világon.
    Mutasd a teljes hozzászólást!
  • ami egyértelművé teszi, hogy még azt sem érted, hogy a "megszakítási rendszert" nem te hívod, hanem ő hív téged

    Igen, de maga a megszakítás kernel módban van lekezelve. User módú kódba megszakításkezelő nem hív bele (bár Win98-on végülis erre is volt lehetőség, de azt tudjuk, mennyire volt stabil). User módba kernel objektumokon keresztül megy a további kommunikáció (időszakos peek-elés, várakozás, async olvasás/írás a potenciális várakozásokkal, stb).
    Nem pont erről beszélek, ember?
    Vagy előbb tisztázzam, mi az a user módú kód? Bármi, ami nem kernelszinten fut :D, minden szokásos mezei program ide tartozik, igen, a Python is.

    És még sokkal őtöbbet is, már akkor, amikor te még a csattogós lepkét tologattad otthon. Pár gyors kereséssel akár itt, akár az interneten rájöhettél volna.

    Értem, szóval te vagy a Chip magazinos fajta. Ilyeneket én is írtam 20+ éve, DOS-os idők, assembly, perifériák közvetlen elérése, stb. Már értem ezt a megszakításkezelős fixációdat, akkoriban tényleg úgy ment, ahogy írod. Mert ott nem volt külön kernel/user mód, vagy ha egy DPMI-szerveren keresztül/alatt futott a DOS-os kódod, akkor a tényleges megszakításkezelésből hívódott a te handlered is, user módban. A Win98 "kernele" is erősen innen gyökerezik, de nézd meg az NT-architektúrát, annak semmi köze ehhez, teljesen más. A Win32 is NT API volt, később portolták Win95-re, ezért nincsenek benne, amiről te írsz, de egyébként más értelmes oprendszerekben sem.
    Én arra lettem volna kíváncsi, hogy írtál-e Windóz (vagy más OS) alá kernel szinten drivert, komponenst vagy akár csak egy user módú kódot, ami bizonyos perifériákkal kommunikál vagy emulál.

    Ja, láttuk már eddig is. Mesélni tudnál, csak a valósághoz semmi köze nem lenne.

    Mondjuk hogy ezt honnan veszed, nem tudom. De mivel oldottam már meg csattogóslepke-tologatás közben (20 éve) Win98 alatt DOS-os VM-ből Win32-es kóddal történő kliens-szerver jellegű kommunikációt saját kernelkomponenssel, még mindig előttem van az architektúra nagy része, és hogy jellegéből adódóan mennyire instabil is volt az a "kernel".

    Na, lapozzunk!

    Szerintem is, mert csak az offtopic posztokat toljuk.

    Mutass egyetlen olyan alkalmazást, ami egyproci/egyszál környezetben több szálon futtatott cpu-intenzív (értsd: az egyes szálakhoz allokált időszeletek teljes kihasználása) kódokat. Mint pl. egy raytracer, ami minden kis csempéhez külön szálon futtatja a számításokat. Pythonban is jó lesz olyan, ami a GIL ellenrére csinálja ugyanezt. Ha van, akkor talán lesz olyan Python kód, ami tényleg gyorsul majd a GIL kiirtása után.
    Mutasd a teljes hozzászólást!
  • Kód szempontjából DE.

    Nem, sehogy sem.

    Mutass már egy user módú API-t, amin keresztül közvetlenül elérem a megszakítási rendszert.

    Már megint egy értelmetlen szósaláta, ami egyértelművé teszi, hogy még azt sem érted, hogy a "megszakítási rendszert" nem te hívod, hanem ő hív téged. Ehhez képest az, hogy a "user mód"-ot egyedül te keverted ide, rajtad kívül senki érintőlegesen sem említette, és hogy így bármi ezzel kapcsolatos megállapítást csak magadtól követelhetsz, már csak ráadás.

    Btw, neked milyen gyakorlati tapasztalatod van etéren? Kernelt programoztál pl.? Drivert, akármilyet, írtál?

    És még sokkal többet is, már akkor, amikor te még a csattogós lepkét tologattad otthon. Pár gyors kereséssel akár itt, akár az interneten rájöhettél volna.

    Én még kb. most is el tudnám mesélni egy Win98 kernel/user szintű felépítését.

    Ja, láttuk már eddig is. Mesélni tudnál, csak a valósághoz semmi köze nem lenne.

    Na, lapozzunk!
    Mutasd a teljes hozzászólást!
  • A megszakítási rendszernek semmi köze a kernelhez. Alapfogalmak sincsenek meg neked.

    Kód szempontjából DE. Mutass már egy user módú API-t, amin keresztül közvetlenül elérem a megszakítási rendszert.

    Ez megint nettó hülyeség minden szintjén és részletében - de részletekbe nem mennék, mert ennek aztán már végképp' semmi köze nincs a többszálúság témához.

    Nem is ahhoz van köze, hanem a megszakítási rendszerhez, ami gyakorlatilag ilyen formában látszódik ki user módba. 

    Na, látod, pont ezért nem kell neked leállni vitázni erről a témáról.

    Ahelyett, hogy leítad volna, milyen megjósolhatóságról beszéltél, egy preemptív rendszerben.

    Fiberek: valóban, nem windóz-specifikus dolgok. És valóban, nem volt azonnal része a Win32-nek, a Win16-os cuccok a GetMessage híváson keresztül adták át másnak a vezérlést, ha nem volt üzenet, valóban nem ismerték a fiber fogalmát. Sőt, Win16-on még processzek sem léteztek.
    Éppenséggel egyiket sem állítottam. 

    Nem. Egyrészt mondjuk el még egyszer: a "cpu-slice" az nem a többszálú/multitaszk rendszerek eredendő sajátossága, hanem kifejezetten a preemptív ütemezővel működőké. Másrészt nem igaz, hogy az egymagos környezetben futó oprendszerek (amely fogalom használatával már megint mindent keversz mindennel - de lépjünk túl ezen!) "

    Igen, az időszelet a preemptív OS jellemzője. Nem állítottam az ellenkezőjét, sőt, leírtam, hogy egy végtelen taszk kooperatív OS-en lerohaszt mindent (mert az nem időszelet alapú). Te akarod kiforgatni a szavaimat.
    Ami meg az egymagosságot illeti, nem fogom mindig leírni, hogy "egy procis egy magos rendszer". Mi a probléma?

    nem attól tudtak multitaszkok lenni, hogy a szálak többsége szinte állandóan várakozó állapotban volt...", mert ez egyrészt nem is igaz rájuk, másrészt mert ettől függetlenül is tudtak és tudnak multitaszkok és többszálúak lenni.

    Gyakorlati szempontból DE. Melyik usernek kell egy olyan OS, amelyik már 2 cpu-intenzív program egyidejű futtatásától is lerohad? Még egy mai user is panaszkodik, ha valami állandó jelleggel zabál mondjuk 5%-ot a prociból, idle állapotban.

    Megint egy értelmetlen szósaláta. Nem érted egyszerűen a fogalmakat.

    Vagy csak te nem értesz magyarul. Még példát is adtam, egy raytracer. 

    És látod, még az sem esik le neked, hogy pont ezt mondaná egy, a Dunning-Kruger hatástól szenvedő egyén.



    Igen, ismerem ezt a fajtát. Épp csak belekóstol valamibe, és mivel nulláról lehet a legtöbbet fejlődni, fél óra után ő már úgy érzi, hogy a téma nagy szagértője, mert olvasott valamit a neten.
    Meg persze van az is, amelyik már 20+ éve olvassa a Chip magazint, akár még cikkeket is ír, de saját tapasztalata semmi.

    Btw, neked milyen gyakorlati tapasztalatod van etéren? Kernelt programoztál pl.? Drivert, akármilyet, írtál? Én még kb. most is el tudnám mesélni egy Win98 kernel/user szintű felépítését. Appy time, Win16Lock (ha már a GILtől indultunk), system VM, címtér felosztása, stb.
    Mutasd a teljes hozzászólást!
  • A megszakítási rendszer egy kernel szinten létező fogalom. User módú kódba ez nem "látszik ki".

    A megszakítási rendszernek semmi köze a kernelhez. (Pl. tipikusan egy mikrokontrollernek vagy egy 8-bites processzornak is van megszakítási rendszere, akkor is, ha nem hogy kernel, meg több biztonsági gyűrűt megkülönböztető, de egyáltalán operációs rendszer sem fut rajta.) Mondom, hogy alapfogalmak sincsenek meg neked, totális félreértésben, tudatlanságban vagy az itt felmerült szakszavak jelentését illetően.

    Kernel szinten a driverek feldolgozzák a megszakításokat, és az I/O stacken keresztül átkonvertálják user módú adatokra

    Ez megint nettó hülyeség minden szintjén és részletében (pl. mert a megszakítás az egy művelet, ami nem kerül semmiféle adatokra konvertálásra, pláne nem user módú adatokra) - de részletekbe ezen túl nem mennék, mert ennek aztán már végképp' semmi köze nincs a megszakítások, de még a többszálúság témához sem.

    Nem kell itt semmit sem megjósolni (nem is értem, mire gondoltál).

    Na, látod, pont ezért nem kell neked leállni vitázni erről a témáról. Ti. mert nem is érted, hogy miről van szó.

    Egyébként meg arról, hogy pl. még olyan egyszerű dolgokat sem lehet egy általános célú rendszerben, mint a PC, megjósolni, hogy milyen gyors háttértár vagy éppen hálózati interfész kapcsolódik hozzá, arról vagy arra mennyire intenzíven jönnek majd az adatok, mennyit kell ezekre várakozni, vagy hogy az I/O mellett mennyire processzorintenzív feldolgozási feladatok kerülnek majd végrahajtásra. Mert hogy ezek mind a felhasznál céljától, módjától, a csatlakoztatott perifériáktól és a konkrét - akár időben is folyamatosan változó - körülményektől függenek, és amiből eredően ezek egyikére sem lehet olyan általános érvényű kijelentéseket tenni, mint amiket te próbálsz "eladni".


    És ha már említetted a fibereket, gyakorlatilag azoknak is a kompatibilitás volt a célja, nevezetesen hogy a win16-ra megírt, "kooperatív" azaz szekvenciális feldolgozásra alapozó cuccokhoz win32-n is legyen

    Nem, semmi köze nem volt hozzájuk. Többek között, mert
    1. a fiberek nem Windows-specifikus dolgok, koncepciók, más operációs rendszereken is léteztek, léteznek,
    2. a fibereket csak később vezették be, mint hogy a Win32 létrejött,
    3. pl. se Windows 95-ben, se az eredeti Windows NT 3.1-ben nem voltak - mégis mindegyik vidáman futtatta a Win16 alkalmazásokat, tehát semmi köze nem lehetett utóbbihoz,
    4. mert a Win16-os alkalmazások nem ismerték a fiberek fogalmát, tehát nem is lehetett szükségük arra semmilyen más rendszeren sem ahhoz, hogy ugyanúgy tudjanak működni, mint addig,
    5. mert a Win16 alkalmazások nem processzen belül voltak kooperatívak (nem is ismerték a szálak fogalmát, csak eseményfeldolgozó ciklusuk volt), hanem egymás között - a fiberek pedig a processzen belüli többszálúságot jelent, illetve valósít meg, tehát semmi köze nincs és nem is lehet a Win16 alkalmazások egymás közötti multitaszkingjához/többszálúságához.

    Szóval, a fibereknek a Win16-hoz annyira és olyan sok szinten nem hogy nincs, de nem is lehet köze, hogy az már nem is vicces. Aminek tükrében azonban kifejezetten vicces az, hogy te mégis halálbiztosan tudni véled, hogy a fiberek csakis a Win16-os alkalmazások miatt jöttek létre, került be a támogatásuk a Windows-ba, stb.

    Az egymagos környezetben futó oprendszerek pont attól tudtak multitaszkok lenni, hogy a szálak többsége szinte állandóan várakozó állapotban volt, és jellemzően egyszerre csak egy futott max cpu-sliceszal, vagy egy sem

    Nem. Egyrészt mondjuk el még egyszer: a "cpu-slice" az nem a többszálú/multitaszk rendszerek eredendő sajátossága, hanem kifejezetten a preemptív ütemezővel működőké. Ami egyben azt is jelenti, hogy semmi köze nem, hogy a hír és a topik eredeti témájához, a GIL-hez és a Python többszálúsághoz, de az itt felmerült más dolgokhoz sem.

    Másrészt nem igaz, hogy az egymagos környezetben futó oprendszerek (amely fogalom használatával már megint mindent keversz mindennel - de lépjünk túl ezen!) "nem attól tudtak multitaszkok lenni, hogy a szálak többsége szinte állandóan várakozó állapotban volt...", mert ez egyrészt nem is volt igaz rájuk, másrészt mert ettől függetlenül is tudtak és tudnak multitaszkok és többszálúak lenni.

    Egyszerűen össze-vissza keversz dolgokat, teljesen értelmetlen állításokat megfogalmazva róluk. Pl. ez az utóbbi is olyan, minth azt mondanád, hogy a "a fű azért volt zöld, mert az alma felfelé esik a fáról". Nem, hogy az általad kapcsolatba hozott dolgok között nem létezik az az összefüggés, amit posztulálsz, mert teljesen függetlenül egymástól, de sokszor még a tagmondataid is teljesen hamisak.

    Mutass olyan programot, ami egymagos környezetben teljesen kihasználva az időszeleteket, több szálon futtatott cpu-intenzív kódokat. 

    Megint egy értelmetlen szósaláta. Nem érted egyszerűen a fogalmakat amiket használsz. Ha értenéd, akkor ez a mondatod meg se született volna, hiszen tudnád, hogy bármelyik Windows-ra írt CPU-intenzív, az időszeleteket teljesen kihasználó kód elindítható egymagos környezetben is, illetve, hogy ha ott indítod el, akkor valószínűleg még jobban ki fogja használni a rendelkezésére álló időszeletet, már csak a futtatásra rendelkezésre álló alacsonyabb összteljesítmény és a magasabb overhead miatt is - tehát, hogy millió ilyen programot lehet mutatni neked, illetve, hogy pont egymagos környezetben fognak a kódok akként viselkedni, ahogy szerinted nyilván nem viselkednek.

    Nem ülök semmiféle padra. Nem támadásként, de én inkább úgy látom, neked van sok bepótolnivalód ezen a téren.

    És látod, még az sem esik le neked, hogy pont ezt mondaná egy, a Dunning-Kruger hatástól szenvedő egyén.

    "Minél kevesebbet tud valaki egy adott dologról, annál inkább hajlamos túlbecsülni a saját tudását [..] a hozzá nem értők:
    1. hajlamosak túlbecsülni a saját képzettségüket,
    2. nem képesek felismerni, ha más ért hozzá,
    3. nem képesek felismerni, hogy ők maguk mennyire nem értenek hozzá"



    A jó hír számodra, hogy "ha fejlesztenek a saját szakértelmükön, képessé válnak annak felismerésére, hogy korábban nem értettek hozzá". Persze, ezt akarni is kell.
    Mutasd a teljes hozzászólást!
  • A megszakítási rendszer egy kernel szinten létező fogalom. User módú kódba ez nem "látszik ki".

    Kernel szinten a driverek feldolgozzák a megszakításokat, és az I/O stacken keresztül átkonvertálják user módú adatokra, pl. arra, hogy egy event vagy mutex szignált állapotba kerül.
    User szinten az ezeken az eventeken/mutexeken/akármin már csak "várakozni" lehet, és bár monitoring jelleggel kicsit nehézkesen lehet akár vegyíteni más kódok végrehajtásával is (pl. egy klasszikus message loop windowsban, vagy egy async read/write file), de az igazán reszponzív feldolgozáshoz szinte mindig egy külön szálat indítanak, amely nem csinál semmit, csak várakozik ezekre az ojjektumokra, néha felébred, amikor esemény van, egy handler gyorsan feldolgozza azt, és a szál azonnal vissza is alszik, ami minimális cpu-usage-et jelent.

    Nem kell itt semmit sem megjósolni (nem is értem, mire gondoltál). Esetleg a kooperatív multitaszkingra, ahol egy végtelenségig tartó taszk lerohasztotta az összes többit (16 bites windóz tipikusan. És ha már említetted a fibereket, gyakorlatilag azoknak is a kompatibilitás volt a célja, nevezetesen hogy a win16-ra megírt, "kooperatív" azaz szekvenciális feldolgozásra alapozó cuccokhoz win32-n is legyen egy annak megfelelő infrastruktúra, amire egyszerűen lehet portolni, nagyobb átírás nélkül).

    Az egymagos környezetben futó oprendszerek pont attól tudtak multitaszkok lenni, hogy a szálak többsége szinte állandóan várakozó állapotban volt, és jellemzően egyszerre csak egy futott max cpu-sliceszal, vagy egy sem.

    Mutass olyan programot, ami egymagos környezetben teljesen kihasználva az időszeleteket, több szálon futtatott cpu-intenzív kódokat. Pl. egy tile-os raytracert. Nem volt, vagy ha igen, semmi értelme. Az ilyen gépeket már az lerohasztotta, ha két külön processz egy-egy szála maxon zabálta a procit. Az Intel hyperthreadingje segített a problémán.

    Nem ülök semmiféle padra. Nem támadásként, de én inkább úgy látom, neked van sok bepótolnivalód ezen a téren.
    Mutasd a teljes hozzászólást!
  • Nem, nem azért voltak szálak egymagos/egyprocis rendszerre.

    De, azért voltak.

    Ilyen környezetben tipikusan annak volt értelme, hogy max. egy szál dolgozik a teljes timeslice-t kihasználva, a többi pedig jellemzően várakozóállapotban alszik, és csak időnként ébred fel egy-egy nagyon rövid művelet erejéig. Ezek vmi külső eseményre várakoztak, I/O, driver, timer, ilyesmi,

    Egyrészt ehhez nem kellett több szál, ehhez elég volt a megszakítási rendszer. Sőt, még az se kellett feltétlenül, hanem pollozni is lehetett. Utóbbi persze általában kevésbé volt hatékony, bár a DMA-val ilyen problémákon általában viszonylag jól lehetett segíteni. De a lényeg, hogy ehhez semmiféle többszálú működés nem kellett.

    Másrészt az, hogy az egyes szálak mekkora időarányban dolgozhatnak, és/vagy mennyit kell I/O-ra várniuk, stb., az eleve nem, hogy nem fix, de nem is megjósolható, csak beágyazott és nagyon specifikus körülmények között működő rendszerek esetében. A PC és tipikus alkalmazási környezete nem ilyen volt, így eleve nem is lehetett ilyen feltételezésekkel élni vele kapcsolatban. Itt a lényeg, hogy arra vonatkozóan sincs értelme feltételezésekkel élni, hogy a szálak milyen arányban használták volna ki a rendelkezésükre álló időszeletet, mert a konfigurációtól, a feladattól, a környezettől, stb. mind fügött. (Ehhez képest az, hogy az interkatív programok legtöbbje az idő legnagyobb részében nem is végez érdemi feldolgozást semelyik szálban, hanem felhasználói bevitelre vár, már csak ráadás.)

    Harmadrészt nyilvánvalóan fogalomzavarban vagy azt illetően, hogy mit jelent a "timeslice", és hogy az önmagában nem szükségszerű sajátossága a többszálú rendszereknek.

    Mindez persze teljesen független attól, hogy akár kooperatív, akár preemptív multitaszk/többszálúság is nem, hogy értelmes volt, de volt, sőt, tömegfelhasználású volt egymagos/egyprocesszoros rendszereken is. Ennek legjobb példája ugye az összes Windows, OS/2, de DOS alá is voltak multitaszkos/többszálú operációs rendszerek (pl. DESQview), amik mind kivétel nélkül egymagos/egyprocesszoros gépeken futottak. És amik egyik sem alapvetően azért volt többszálú, amit te írtál, és nem volt igaz rá, amit te írtál az idézett részben (az I/O-ról meg egyetlen feldolgozó szálról), hanem azért, hogy az alkalmazáskódot futtathassák több szálon, illetve, hogy alkalmazások tetszőleges kombinációját futtathassák egymással párhuzamosan, anélkül, hogy ezeknek valamiféle módon össze kellene drótozva és integrálva kellene lenniük egymással.

    Tehát pont az a logikai szeparáció miatt (nem pedig teljesítményokokból) amiről beszéltem, hogy értelmessé teszi a többszálú működést, illetve programírást akkor is, ha az teljesítményhozadékkal nem jár az egyetlen processzor/mag miatt, sőt, akár még összességében teljesítménycsökkenést is okoz, és amiről - nyilvánvalóan semmit meg nem értve ebből - jól közölted, hogy "nem, nem azért". De bizony, pont azért. És (részben) pont ezért léteznek többszálú programok Pythonban is, a GIL ellenére is.

    Egymagos környezetben valódi, teljes időszeletet több szálon kihasználó programot értelmes ember nem írt

    De. Lásd korábban írtak!

    Nyugodtan ülhetsz a kolléga mellé a Dunning-Kruger padra.
    Mutasd a teljes hozzászólást!
  • Nem, nem azért voltak szálak egymagos/egyprocis rendszerre.

    Ilyen környezetben tipikusan annak volt értelme, hogy max. egy szál dolgozik a teljes timeslice-t kihasználva, a többi pedig jellemzően várakozóállapotban alszik, és csak időnként ébred fel egy-egy nagyon rövid művelet erejéig. Ezek vmi külső eseményre várakoztak, I/O, driver, timer, ilyesmi, és jellemzően a prioritásukat is nagyobbra is állították a normálnál, hogy reszponzívak legyenek, ne preemptálja őket a normál "dolgozó" szál.

    Egymagos környezetben valódi, teljes időszeletet több szálon kihasználó programot értelmes ember nem írt, mert egyértelműen lassabb volt, mintha az egyes műveletek csak simán szekvenciálisan futottak volna egy szálon.

    Még az sem lehet érv, hogy már előre gondoltak vmi többmagos környezetre, ugyanis akkor
    1) illett volna intelligens módon döntenie a programnak a párhuzamos/szekvenciális végrehajtásról
    2) a fejlesztő ki sem tudja tesztelni egymagos rendszeren a párhuzamos esetet, mert több mag híján valódi konkurrens elérés nincs is. Nem véletlenül létezik Windowson is a "single proc affinity" kompatibilitási opció, amit a régi cuccokhoz sajnos viszonylag gyakran engedélyezni is kell.

    Ennek alapján egy globál lock "csak úgy" kiirtását nem is tartanám járható útnak kompatibilitás szempontjából, sokkal inkább azt, hogy a default egy GIL működési üzemmód, és a kódnak valahogy külön kell jeleznie, hogy ő tud és felkészült a GIL nélküli valódi konkurrens végrehajtásra. 
    És bár nem ismerem a Pythont, de érdekes nyelv/környezet lehet, ha egy többszálú végrehajtási mód egyszerűbb kódot eredményez. Mitől egyszerűbb mindenféle taszkokat, azok paramétereit, a hozzájuk tartozó adathalmazokat összeszervezni, más szálaknak átadogatni, hatékonyan várogatni rájuk, mint a szükséges függvényeket csak úgy szekvenciálisan meghívogatni? 

    Ezek alapján Deleted kollégának sztem teljesen igaza van, a GIL kiirtása a gyakorlatban nem fog semmiféle gyorsulást okozni már megírt kódok esetén.
    Mutasd a teljes hozzászólást!
  • Köszönöm a magyarázatod. Ez nem csak a sebességről szól tényleg.
    Rob Pike híres előadása jutott az eszembe amikor arról beszél, hogy mi a konkurens és mi a párhuzamos programozás lényege. A golang például csodálatosan mutatja, hogy a konkurens programozás nemcsak az IO szempontjából, de az olvashatóság vagy írhatóság szempontjából is egyszerűbbé tehet kódokat.
    Mutasd a teljes hozzászólást!
  • Hogy legyen valami valódi off is:

    from threading import Thread from multiprocessing import Pool from time import perf_counter COUNTER = int(10e8) def timer(func): def runner(*args, **kwargs): start = perf_counter() result = func(*args, **kwargs) stop = perf_counter() print(f">>> {stop-start:.4f}") return result return runner def worker(count): n = 0 while n<count: n += 1 @timer def threaded(): print("---threaded---") task = [] for i in range(5): task.append(Thread(target=worker, kwargs={'count':COUNTER//5})) for t in task: t.start() for t in task: t.join() @timer def multiprocess(): print("---multiprocess---") with Pool() as p: p.map(worker, [ COUNTER//5 for i in range(5) ]) @timer def sequential(): print("---sequential---") worker(COUNTER) threaded() multiprocess() sequential()


    Futtatás hagyományos python alatt:
    ---threaded---
    >>> 54.1627
    ---multiprocess---
    >>> 32.4974
    ---sequential---
    >>> 51.6511


    Ugyanez pypy3 interpretációban:
    ---threaded---
    >>> 1.4121
    ---multiprocess---
    >>> 0.9594
    ---sequential---
    >>> 1.3859


    Sajnos vannak (voltak?) néha gondok a pypy működésében, annyi emlékem maradt róla, hogy bizonyos programok nem működtek alatta, csak a hagyományos python interpreter alatt. Meg arra is, hogy pl. a regex feldolgozáson szinte semmit sem gyorsított, bár az javarészt C-ben van implementálva a CPythonban is. De azért... na... szóval ez már tényleg komoly gyorsulás, még akkor is, ha egy totál értelmetlen feladványon. :D
    Mutasd a teljes hozzászólást!
  • Bocs, veled hóttfelesleges vitatkozni. Nem azért, mert igazad van, hanem azért mert képtelen vagy belátni, ha valamit nem értesz vagy ha valamihez nem értesz.

    És látod, annak ellenére, hogy - szerinted - nincs igazam, egyetlen észérvet sem tudtál szembeállítani az általam írtakkal. Semmit nem tudtál cáfolni, semmit nem tudtál bizonyítani. Mi több, meg sem próbáltad. Ez mindent elmond arról, hogy ki nem ért mihez, és hogy mennyire tudja maga is ezt.

    Az meg sokat elmond a témához valamit is konyító olvasóknak, hogy az előző kommentem offtopic lett. ?

    Szerinted miért, mitől, ki miatt lett offtopik? Őszintén kíváncsi lennék a magyarázatodra. De vigyázz, mert beugratós kérdés!

    Ja, egyébként meg ez a kommented is offtopik lett, mivel a tartalmának (ami szerint velem nincs értelme vitatkozni, illetve, hogy az előző kommented offtopik lett) ugye semmi köze nincs a GIL-hez, se úgy a hírehez általában.
    Mutasd a teljes hozzászólást!
  • Bocs, veled hóttfelesleges vitatkozni. Nem azért, mert igazad van, hanem azért mert képtelen vagy belátni, ha valamit nem értesz vagy ha valamihez nem értesz.

    Az meg sokat elmond a témához valamit is konyító olvasóknak, hogy az előző kommentem offtopic lett. ?
    (Aki nem értené: linkeltem a python saját levlistájáról egy threadet, ami épp a GIL eltávolítás témáját boncolgatja)
    Mutasd a teljes hozzászólást!
  • Mailman 3 Python multithreading without the GIL - Python-Dev - python.org

    Egy kis társalgás tavalyról GIL megszüntetés témában. Van benne pár izgalmas dolog: pl. a single threaded alkalmazások esetleges lassulása. (Kiragadott példa!)
    Mutasd a teljes hozzászólást!
  • Épp azt írom ötödször: a jelenleg létező programok (már amelyiket szakember írt) eleve úgy vannak megírva, hogy multithreading csak I/O jellegű műveletekre

    Nem. Ez csak a tipikus Dunning-Kruger hatás megnyilvánulása. Mármint, hogy ezt mondod, hogy ti. szakember mit és miért írt, meg mit és miért nem - miközben valójában arról beszélsz, hogy te mit írtál, meg mit nem, és hogy szerinted miért volt úgy jó vagy jobb.

    Viszont ha valóban annyira szakember lennél, mint amennyire gondolod, akkor tudnád, hogy többszálú feldolgozást az emberek nem csak azért írtak és írnak (Pythonban is/sem), mert valódi párhuzamosságot, egyidejű párhuzamos végrehajtást akarnak elérni és így akarnak gyorsítani a feldolgozáson többmagos/többprocesszoros gépeken, hanem azért is, mert ezáltal jelentősen egyszerűsíthető az alkalmazás és a kód szerkezete, növelhető rugalmassága. Ami szintén előny lehet, még akkor is, ha ez esetleg érdemi teljesítménycsökkenéssel jár - ami azért viszont megint nem feltétlenül következik belőle.

    Ezért voltak szálak már akkor is akár PC-s platformon is, amikor még nem voltak többmagos, de még csak többprocesszoros gépek sem, illetve ezért volt és van máig is (pl. a fiberek formájában) kooperatív multitaszking, illetve kooperatív többszálú feldolgozás is, aminél aztán nem, hogy egyfajta globális lock kényszeríti sorozatba a különböző logikai szálakban futó feldolgozást vagy annak egyes részeit, de igazából maga a feldolgozó kód az, ami ezt a szerializációt elvégzi, és maga a végrehajtás is "fizikailag", illetve az OS szintjén végig egyetlen szálban történik. És ennek ellenére használják, máig, a fent említett okok miatt. Akár Pythonban is.

    Lényeg a lényeg: Python-ban is léteztek eddig is, a GIL ellenére is többszálú programok, amik a GIL eltűnésével automatikusan, módosítás nélkül is gyorsabbá válhatnak majd. Vagy nem, sőt, lassulhatnak is a korábban elmagyarázottak értelmében, a konkrét részletek függvényében. De ami a legfontosabb, hogy ezzel egy új lehetőség nyílik meg a párhuzamosság növelésére, fokozására processzen belül, aminek köszönhetően a Python programok az eddiginél gyorsabbak és hatékonyabbak lehetnek majd. Az, hogy milyen módosítások árán (illetve szükséges lesz -e módosítás egyáltalán ehhez) és milyen mértékben, az - mint mindig - a részletektől függ, de a lényeg a lehetőség megjelenése erre.

    Az pedig, hogy te milyen megoldásokkal és programokkal találkoztál és mivel nem, az elsősorban rólad mond el dolgokat, nem pedig arról, hogy adott dolog létezik -e, milyen sajátosságokkal bír, vagy érdemes -e használni. De ez már egy nagyon másik téma.
    Mutasd a teljes hozzászólást!
  • Épp azt írom ötödször: a jelenleg létező programok (már amelyiket szakember írt) eleve úgy vannak megírva, hogy multithreading csak I/O jellegű műveletekre, mert kb mióta van mt a pyrhonban, azóta van GIL, ennek tudatában aki sokprocesszoros feldolgozást akart, az nem szálakat, hanem processzeket használt pythonban vagy keresett egy megfelelő programnyelvet amiben nem volt ilyen kötöttség.
    Legalábbis az elmúlt kb tíz évben nem találkoztam olyan programmal ami csakazértis multithreadinget próbált volna használni cpu igényes feladatokhoz, holott a készítője tudta, hogy egy processzor egy magja fog működni vele.
    Értelme nem volt ilyet írni, mert (nem tudom, kipróbáltad-e, én igen) érzékelhetően lassúbb volt, mint egy szálon.
    Mutasd a teljes hozzászólást!
  • Elbeszélünk egymás mellett: én azt olvastam ki a cikkből, hogy a GIL eltörlése gyorsít. A megszűnéshez képest jelen időben.

    Egyrészt annak amit írsz, annak szó szerint véve eleve nincs értelme. Nem csak azért, mert a cikknek már a címe is jövő időben fogalmaz (tehát a jelen idő fogalmának használata teljes képzelgés), de azért is, mert szerintem amire gondolsz az nem az, hogy "jelen időben" gyorsul valami, hanem az, hogy a már jelenleg is létező Python kódok, programok is gyorsulhatnak majd - attól és akkor, hogy és amikor megszűnik a GIL. 

    Másrészt viszont, igen, utóbbi is igaz. A jelenleg is létező Python programok effektív futási sebessége is nőhet majd (tehát az az idő, ami összességében a végrehajtásukhoz szükséges, csökkenhet) - feltéve, hogy végeznek bármi olyan feldolgozást, ami GIL mellett csak sorban, GIL nélkül pedig valóban párhuzamosan is fut majd. Utóbbi mellett ugyanis az adott feldolgozás/program futása többmagos környezetben nyilvánvalóan előbb, rövidebb idő alatt befejeződhet majd (ami nem keverendő össze azzal, hogy a benne szereplő elemi utasítások vagy műveletek bármelyike önmagában gyorsabban kerül majd végrehajtásra, vagy hogy processzoridőben mérve összességében kevesebbre lesz szüksége.)

    Ami viszont megint nem egyenlő azzal, amin kb. a topik megnyitása óta is pörög pár félreértelmező, hogy akkor most majd minden Python program X-szer gyorsabb lesz (vagy akár csak a döntő részük gyorsabb lesz) - bármilyen értelemben is a fentiek közül. Ilyen egyrészt nem hangzott el a cikkben sem sehol, másrészt kb. a világon semmilyen olyan gyorsítótechnológia nincs (még a processzor órajelének növelése sem), ami egységesen és minden műveletet, programot gyorsít - pláne nem akkor, ha a párhuzamosság is bejön a képbe.

    Ez adott esetben is igaz - ti. lesznek olyan Python programok, amik önmagában a GIL eltűnésétől érezhetően gyorsabbá válnak, és lesznek olyanok, amik vagy nem lesznek számottevően - vagy akár mérhetően - gyorsabbak tőle. Sőt, a megvalósítás és a részletek függvényében elképzelhető még az is, hogy bizonyos programok lassabbak lesznek tőle (pl. egymással versenyző szálak cache thrashingje vagy paging pool thrashingje miatt - hogy csak a legkézenfekvőbb lokális potenciális torlódási problémákat említsem).

    És persze most majd hatékonyan lehet megírni olyan programokat többszálas szerkezetben is, amiket eddig nem is volt értelme ilyen szerkezetben megírni, hiszen a végrehajtás lényegében ugyanúgy szerializált lett volna - akkor meg minek? -, és amik ezért nem is léteztek. De ez egy, előbbiektől igazából független dolog, és ezek nélkül is lehetnek - illetve biztosan lesznek is - Python kódok, programok, amik önmagukban a GIL megszűnésétől gyorsulnak. Meg olyanok is, amik nem gyorsulnak, és valószínűleg olyanok is, amik meg lassulnak, vagy lassulhatnak bizonyos környezetekben, bizonyos erőforráskorlátok mellett.
    Mutasd a teljes hozzászólást!
  • Elbeszélünk egymás mellett: én azt olvastam ki a cikkből, hogy a GIL eltörlése gyorsít. A megszűnéshez képest jelen időben.
    Te azt írod, hogy majd fejleszthető lesz a jelenlegi úgy, hogy gyorsabb legyen. Ezt senki sem vitatta. ;)

    Nem a GIL megszüntetése a problémám, sőt... Anno úgy estem neki egy tesztprogram megírásának, hogy nem is tudtam a létezéséről, aztán meg anyáztam, hogy nem megy csak egy magon. :D
    Csak a hírben szereplő, kissé felületesnek tűnő megfogalmazást kritizáltam.
    Mutasd a teljes hozzászólást!
  • Például kb bármilyen machine learning training programnál az adatokat előkészítő workerek.
    Ezeket most a multiprocessing libraryvel lehet megoldani, sokkal lassabb indulás, bonyolultabb IPC, stb. Nyilván csak pusztán és tisztán a GIL megszüntetése nem oszt, vagy nem szoroz, de ha ezt meglépik, akkor azzal együtt egy csomó, most sokkal lassabb dolgot lehet triviálisan felgyorsítani. Nyilván a gőzgép feltalálása nem forradalmasította az ipart, el is kellett kezdeni használni.

    De eleve az alaptézised totál hibás, nem is értem.
    Ennyi erővel jöhetsz azzal is, hogy miért csináltak GPU computing libraryket Pythonhoz 10-15 évvel ezelőtt. Hiszen "semmit nem írtak pythonban GPU-ra". Közben meg manapság a GPU computinges dolgok döntő többsége Pythonban készül, és minden sokkal gyorsabb, mint 10-15 éve a GPU gyorsítók előtt.

    Az async meg épp a multiprocessinges óriási overhead miatt python "multithread" alapú, ami ugye single CPU. Na ott aztán tényleg triviális lenne gyorsítani - de igaz, a GIL megszüntetése itt sem elég, még meg kéne változtatni ezen kívül 3 fájlt a libraryben a gyorsításhoz.
    Mutasd a teljes hozzászólást!
  • Nekem mindössze olyan kétségeim vannak, hogy írt-e valaki olyan programot ami több szálon futtat cpu igényes alkalmazást.
    Tudtommal a GIL csak a CPythonban volt, jython és a .net-es verzió nem volt érintett, épp csak nem nagyon használták őket.
    Az async környezet meg hangsúlyozottan I/O-ra volt kihegyezve. (Amiről a tutorialok hallgatnak, hogy valójában az is multithread alapú)
    Mutasd a teljes hozzászólást!
  • De még ebben sincs feltétlenül igazad.

    Ha valaki jelenleg a threading modulet használja (és használhatja), akkor a GIL megszüntetésével ezek akár transzparens futhatnak több magon is, gyorsulást okozva.

    Ugyanez igaz az async dolgokra.


    Ami engem jobban "zavart" a prog.hu-s cikkben, hogy nekem nem jött át az az optimizmus az eredeti blogpostból, hogy itt a GIL megszüntetés hamarosan (vagy bármikor is) eljön.
    Volt erről már itt egy cikk. Ahogy én értelmezem az eredeti blogpostot, említik ezt a fenti fejlesztést, meg egyben hogy problémákat is okozhat. Nem mondják, hogy beépítésre kerül, se semmi.

    Én attól tartok, hogy az egészből semmi nem lesz, mert pár szpesöl kéjz program szpesöl kéjzjében előjöhetnek ilyen-olyan problémák, ezért inkább nem építik be. (Esetleg majd egy Python 4-be, aminek megint kell majd 10 év mire standard lesz)


    Azt meg, hogy milyen (nálam gyakran előjövő) use casekben lenne jó, ha nem lenne a gil, a fentebb linkelt cikk kommentjeiben már összefoglaltam. Szerintem messze ez a legnagyobb korlátja annak, hogy a Python 2022-ben egy őszintén komolyan vehető nyelv legyen (mondom ezt úgy, hogy szinte csak Pythonban dolgozok).
    Mutasd a teljes hozzászólást!
  • Igen, arról beszélek, hogy a hírben úgy szerepel, mintha a meglévő programok gyorsítására is alkalmas lenne, holott nem sok ilyen program létezik pont az ismert korlát miatt.
    Amiken meg gyorsíthat, azok minimális cpu műveletet végeznek párhuzamosan, threadekben. (Processzben megy, az más kérdés)
    Mutasd a teljes hozzászólást!
  • Szóval nem sűrűn találkoztam olyan python programmal, ami ki szeretné használni ezt a feature-t, csak a GIL  miatt mégsem.

    Ezt a mondatot nem tudom értelmezni. Azt mondod, nem találkoztál olyan programmal, ami párhuzamosan akart kódot futtatni, de a GIL miatt mégse tudott? Dehát nyilván azokat a programokat, amiknek a megírását a GIL megakadályozta, azokat nem írták meg, vagy nem Pythonban írták meg. (Vagy esetleg natív kóddal megtámogatott Pythonban.)

    Röviden összefoglalva, az, hogy jelenleg nincs párhuzamosítást használó Python kód, az nem jelenti, hogy ez a fejlesztés haszontalan lenne. A meglévő kódok egyszerűsödhetnek (ha C-ből Pythonba lehet átvinni a kód egy részét), az új kódok pedig eleve egyszerűbbnek íródhatnak, ha nem kell a GIL miatt bonyolítani az architektúrát.
    Mutasd a teljes hozzászólást!
  • Ez azért van, mert a GIL  nagyjából azóta létezik, mióta a python (CPython, hogy pontos legyek, mert jython és társai megoldották azt hiszem)
    Szóval nem sűrűn találkoztam olyan python programmal, ami ki szeretné használni ezt a feature-t, csak a GIL  miatt mégsem.
    (Összesen egy ilyet láttam, azt is én írtam, hogy kipróbáljam a valós működêsét ;) )
    Mutasd a teljes hozzászólást!
  • Tudom, a véleményed szent és (s)érthetetlen, de...
    Úgy írtad, mintha a meglévő python programok is óriásit gyorsulnának a GIL lekapcsolásával.
    De pont a GIL miatt nem nagyon íródott olyan program, ami ezt valóban kihasználná.
    Multiprocessz esetén nincs jelentősége, a multithread meg leginkább olyan feladatokra ban használatban, amik  I/O szálakat futtatnak (web szerver pl.).
    Minimális gyorsulás lehet ezeknél, de komolyabb nem nagyon.
    Mutasd a teljes hozzászólást!
  • Sacc/kb alig van olyan python program, amin ennek feloldása gyorsítana.

    És ez vajon azért van, mert a Python programok úgy általában nem akarnak párhuzamosan több számítást futtatni, vagy azért, mert a GIL miatt jelenleg kerülőutakat kénytelenek használni? Már az is tiszta haszon, ha nem kell csak azért valamit natív kódba áttolni, hogy el lehessen engedni a GIL-t és lehetővé lehessen tenni a valódi párhuzamos futást.
    Mutasd a teljes hozzászólást!
  • Már bocs, de a GIL megszüntetése miért is gyorsítja"a" python programok futását???

    Ha elolvasod alaposan a bekezdést, amiből kiragadtad ezt a pár szót, akkor megérted. Ha még mindig nem, akkor nem érted hogyan működik a GIL és/vagy a szinkronizáció valódi párhuzamos környezetben (és ennek milyen következményei vannak az effektív futási sebességre nézve), és akkor ennek kell utánaolvasnod.
    Mutasd a teljes hozzászólást!
abcd