Itt miért van annyi infós, aki szerint a python nem jó semmire csak data science-re vagy ML-re? (Többi lent)

@17:30

Azt demonstációnak írtam a másik kérdezőnek és feladtam neki házi feladatnak, hogy fejtse meg mi az oka, hogy a c++ a lassabb. Bár megoldást nem írt, hogy próbálkozik vele azt sem.

Ha nem ilyen demonstrációnak írtam volna akkor faragtam volna le futási időt kódszinten is.

12

Te megnézted -O3 optimalizációval? Az a tippem, hogy nem

5/13:

"nem mondanám reprezentatívnak mert 1000-et messze nem éri el a szavazatok száma. "

Mondd, Te hol tanultál statisztikát?

Csak mert egy minta nem az ezres számtól lesz reprezentatív, hanem attól, hogy az a bizonyos ezer mint részhalmaz, reprezentálja-e a halmaz egészét.

Ha egy társadalom átlagjövedelmére vagy kiváncsi, de te ezer hajléktalant szondázol, akkor a mintád nem lesz reprezentatív és "úgy" fogsz járni az eredményeddel.

"Te megnézted -O3 optimalizációval? Az a tippem, hogy nem"

Nem talált. Elhiszem ha kisebb fajta csodának néz ki, hogy megtáltosodott a kód egy -O3-tól.

A pontosítás érdekében a másik kérdés : https://www.gyakorikerdesek.hu/szamitastechnika__programozas..

A kérdező egy videólinket írt 9-es hozzászólás (febr. 6. 12:43) ahol bizonygatja hogy a c++ milyen gyors a python-hoz képest.

Erre én ellenpéldát csináltam : 15-ös hozzászólás (febr. 6. 15:29)

Itt házinak feladtam : 30-as hozzászólás (febr. 7. 12:51) Miután 24-es (febr. 6. 17:27) hozzászólásban kételkedett a kérdező, hogy bármikor előfordulhat, hogy a python a gyorsabb.

Akkor lássuk a másik kérdezőnek írt házija megoldását:

Jelentős overhead-et adott hozzá a c++ vector<bool> sajátossága, mivel ez memóriaméretre optimalizált. Ha minden vector<bool> -t lecserélek vector<char> - á, akkor egyből felgyorsul a kód. A vector<bool> "belső szerkezetileg" nem úgy működik mint egy vector template általában, nem úgy mint tömböknél megszoktuk, hanem ott ténylegesen egy bitet foglal egy eleme, így memióracímképzése sem lehetséges, fordítási hibát okozna. A "színfalak mögött" bitmaszkolással nyerhetők ki és módosíthatóak az egyes bitek, melyek műveletigénye plusz overhead amilyen kódot kigenerál hozzá a g++ , bár ezt kioptimalizálja a -O3 kapcsoló. Így viszont nincs is olyan erős futási idő különbség, ha vector<char> - t használok -O3 kapcsolóval és a nélkül.

Az eredeti kód szerint az eredeti fordítással, már az gyorsít ha if (is_prime[i] && (long long)i * i < n) a két logikai kifejezést megcserélem. Továbbá a szemet szúrja, hogy a négyzetgyökénél tovább fut a külső for ciklus, ha nem akarunk négyzetgyököt vonni, legalább ezt tegyük meg : for (int i = 2; (long long)i * i < n; i++) és máshol nem kell ellenőrizni hogy i * i < n igaz vagy hamis. Ezen felül pedig a 2 feletti p prímek esetében amikor p prím a szitáló elem a belső for ciklusnál i-nek a duplája célszerűbb lépésköznek, hiszen, ha i a lépésköz minden második iterációban páros lesz j ami tök felesleges, hiszen 2-nél azok már kiestek.

A python kód pedig azért tud gyors lenni, mert olyan tömbműveletet kihasználtam ami natív kód, naivan ott nincs beágyazott ciklus csak egy for ciklus. Valójában a beágyazott ciklus az natív kódba fut le. A külső ciklus pedig eleve a szitaméret négyzetgyökéig fog menni, így az overhead négyzetgökös függvény szerint nő az interpretáltság miatt. Így pedig ahhoz hasonló sebességet kapunk mintha natívan lenne az egész.

@09:15

Köszönjük a szőrszálhasogatást, feltehetően a lényeg így is átjött. A több ok közül az egyik szerint azért nem reprezentatív mert a szavazatok száma messze kevesebb mint az egy reprezentatív felméréstől elvárt.

15

Először is a házis megjegyzéseidet ignorálom, mert kicsit lekicsinylőként jön át...

Nem ismerem a numpy-t de megtippeltem volna, hogy belül nem python intepreteren működik.

Szóval C++ kódot hasonlítasz optimalizált natív kódhoz (ami vagy C++, vagy C, vagy Assembly vagy ki tudja), tehát a példád kapásból rossz (és ráadásul még te is azt mondod, hogy natívhoz közeli sebességet kapunk -> C++-hoz viszonyítod).

C++-hoz is biztos találsz matematikai műveletekre optimalizált könyvtárat. De eleve, szerintem egy magára valamit adó programozó tudja, hogy a vektor nem gyors, nem véletlenül van sok könvtárban megfelelője

Az -O3 nem csodákat csinál, de fontos, mivel a fordító opzimalizálás nélkül aligha fogsz production kódot kapni.

Szerintem maradjunk annyiban, hogy pythonban könnyebb kódolni és C++-ban lehet gyorsabban, ha az ember tudja, hogy mit csinál. És ezért van túlhype-olva a python. Ugyanis túl van, mert mind a kettő egy eszköz, aminek adott előnye/hátránya van, és eszerint kéne eldönteni, hogy adott feladatra mit használunk

"Először is a házis megjegyzéseidet ignorálom, mert kicsit lekicsinylőként jön át..."

Pedig nem annak szántam.

"Szóval C++ kódot hasonlítasz optimalizált natív kódhoz"[...] "és ráadásul még te is azt mondod, hogy natívhoz közeli sebességet kapunk -> C++-hoz viszonyítod"

Megírtam még milyen optimalizációk lehetnek, a c++ -ből lefordított kód g++ -al az natív kód, így ez nem igaz. Natívhoz hasonló sebességet kapunk az említett pyton kóddal az arra vonatkozik.

"C++-hoz is biztos találsz matematikai műveletekre optimalizált könyvtárat." Például a c-ben is létező math.h-t, de ott van a gmplib. Az utóbbi viszont nagyon nagy számokkal és úgynevezett tetszőleges pontossággal tud számolni. Így annál gyorsabb mint ami triviális, de ha nincs szükség olyan nagy számokra és olyan nagy pontosságra akkor lassabb mint a math.h.

"De eleve, szerintem egy magára valamit adó programozó tudja, hogy a vektor nem gyors, nem véletlenül van sok könvtárban megfelelője"

Ez nem igaz. Sok esetben pont ugyan olyan gyors mint egy tömb, sőt gyakorlatilag ha úgy használod mint ahogy bemutattam csak char-al akkor sebességben semmiben nem fog különbözni attól mintha tömböt használtam volna. Persze a vector esetében kivételt lehet mondani, például ez bool-ra pont igaz, de -O3 -al már mindjárt nem mondanám hogy lassabb. Ugyanez lenne sebesség szempontjábó, ha egy char tömböt memóriatakarékosság miatt (ha csak különálló bitek kezelésére van szükségem) bitmaszkolással bitekénti és vagy , negációval használnám az egyes bitjeit, cserébe nehezebben átlátható lenne a kód.

Annak egyéb más okai vannak, hogy miért van több fajta egyéb megfelelője a vectornak.

"Szerintem maradjunk annyiban, hogy pythonban könnyebb kódolni és C++-ban lehet gyorsabban, ha az ember tudja, hogy mit csinál."

Pont hogy python-ban lehet gyorsabban kódolni.

"Megírtam még milyen optimalizációk lehetnek, a c++ -ből lefordított kód g++ -al az natív kód, így ez nem igaz. Natívhoz hasonló sebességet kapunk az említett pyton kóddal az arra vonatkozik."

Igen, én is ezt próbáltam írni. C++ -> natív kód, python adott példa kód -> natívhoz közeli sebesség -> python nem olyan gyors, mint amilyen a C++ lehet

A vektor akkor lesz nagyon lassú, ha elemeket ad hozzá valaki, mert ekkor folyton újra le kell foglalni a memória területet, esetleg még át is kell másolni minden elemet az új helyre. Ez ellen lehet tenni persze

""Szerintem maradjunk annyiban, hogy pythonban könnyebb kódolni és C++-ban lehet gyorsabban, ha az ember tudja, hogy mit csinál."

Pont hogy python-ban lehet gyorsabban kódolni."

Igen, elírtam. Az akart lenni, hogy gyorsabb kódot lehet C++-ban írni

"A vektor akkor lesz nagyon lassú, ha elemeket ad hozzá valaki, mert ekkor folyton újra le kell foglalni a memória területet, esetleg még át is kell másolni minden elemet az új helyre. Ez ellen lehet tenni persze"

Nem mintha, nem lenne nagyon lassú ha tömbbel csinálod meg ugyanezt, ott viszont te magad implenetálod. Új tömb lefoglalása, a régiből az elemek átmásolása plusz az új elem, a régi tömb megszüntetése.

A vector esetében nem fog minden egyes új elem hozzáadásánál újrafoglalódni az egész. A capacity metódusával lekérhető, hogy mennyi elemnek van fenntartott hely aktuálisan, ami gyakran több mint a size. Van metódusa amivel tudod befolyásolni a kapacitását. Ha viszont úgy implenetálod a tömb bővítését ahogy említettem akkor garantáltan minden új elemnél az egyész új tömb újrafoglalása stb. lesz. Ez ellen is lehet tenni persze, de nem feltétlen kell újra feltalálni a meleg vizet.

A kompatibilitás miatt meg van hagyva a klasszikus c-s tömb is, van c++ -os tömb is. Ha az adatok jellege olyan hogy kevés tömbelemre van szükség, de nagyon nagy különbség is lehet két tömbindex között, erre jó választás a map és még lehetne sorolni.