KDE Framework 6.16.0 ja python

[ilkant]

Huomasin, että KDE Framework 6.16.0 päivityksessä on tullut python-esimerkkejä erinäisistä asioita.

Koodia: [Valitse]

Merkittävä kohokohta KCoreAddonsissa ja KGuiAddonsissa on parannettu Python-tuki. Python-esimerkkejä on lisätty tärkeimmille apuohjelmille, kuten päivämäärän validointi ja kuvakkeiden hallinta.

Tarkoittaako tämä, että tietokoneenkäyttäjä voi rakennella itse lisiä KDE:hen? Vai käyttääkö KDE noita koodinpätkiä tulkattuna (python on tulkattu kieli)?

Tarkoittaakohan tällainen sitä, että pikkuhiljaa KDE siirtyy C++:sta Pythoniin? 

Kaksi esimerkkiä:

kaboutdata ja kformat.

[SuperOscar]

Tarkoittaakohan tällainen sitä, että pikkuhiljaa KDE siirtyy C++:sta Pythoniin? 

Ei tietenkään Pythonilla on ennenkin voinut rakentaa ainakin sovelmia. Tarkemmin en tiedä, mikä nyt on muuttunut. Samalla tavallahan Gnome käyttää JavaScriptiä apuna käyttöliittymien rakentamisessa.

Toisaalta tietysti kääntävän ja tulkkaavan kielen ero ei ole enää aikoihin ollut niin absoluuttinen kuin joskus Basic-aikoina.

[kamara]

Toisaalta tietysti kääntävän ja tulkkaavan kielen ero ei ole enää aikoihin ollut niin absoluuttinen kuin joskus Basic-aikoina.

Kyllä se nopeuskerroin taitaa olla 3x-5x edelleen, mutta koneet ovat nopeutuneet lähes exponentiaalisesti, niin nykykoneille on yhä vähemmän nopeuskriittisiä tehtäviä.

[SuperOscar]

Kyllä se nopeuskerroin taitaa olla 3x-5x edelleen,

Riippuu hyvin paljon tehtävästä. Kokeilin juuri keskiarvon tekstitiedostosta laskevaa ohjelmaa C:llä ja Pythonilla, kun dataa on pari megaa: eri oli luokkaa 2× – ja puhutaan sekunnin murto-osista. Siitäkin erosta suurin osa kuluu Pythonin käynnistämiseen.

[kamara]

Kyllä se nopeuskerroin taitaa olla 3x-5x edelleen,

Riippuu hyvin paljon tehtävästä. Kokeilin juuri keskiarvon tekstitiedostosta laskevaa ohjelmaa C:llä ja Pythonilla, kun dataa on pari megaa: eri oli luokkaa 2× – ja puhutaan sekunnin murto-osista. Siitäkin erosta suurin osa kuluu Pythonin käynnistämiseen.

Jompi kumpi meistä ei osaa optimoida (todennäköisesti minä). Minä ilmeisesti koodaan sen verran paskasti, että kun käännän python-ohjelmani C/C++:lle, niin ohjelmani nopeutuvat usein 5x. Tosin kyseistä optimointia en tee kovin usein, mutta jos on kysessä gigatavu-luokkaa olevan aineiston käsittely, niin saatan aluksi tehdä sen pythonilla, ja kun olen sen saanut tehdyksi, niin väännän siitä C/C++-version. Yleensä ratkaisu on nopeutunut monikertaisena python-ratkaisuun nähden.

Esimerkiksi käänsin tämän C/C++:lle ...
https://github.com/vancha/Binary-stl-to-ascii-stl

... ja ainakin omalla koneellani tuli merkittävä ero käskyillä:

Koodia: [Valitse]

time python3 Reader.py binary_example.stl py-example.stl
real 0m15,615s
user 0m7,652s
sys 0m0,585s

ja C/C++:lla...

Koodia: [Valitse]

time ./Reader binary_example.stl c++example.stl
Binary file

real 0m2,388s
user 0m2,114s
sys 0m0,154s

Edit - Käänteisessä testausjärjestyksessä ei ole niin suuri ero, mutta kuitenkin merkittävä myös siinä:

Koodia: [Valitse]

time ./Reader binary_example.stl c++example.stl
Binary file


real 0m2,433s
user 0m2,161s
sys 0m0,157s


Koodia: [Valitse]

time python3 ./Reader.py binary_example.stl py-example.stl
real 0m8,544s
user 0m7,545s
sys 0m0,560s


[SuperOscar]

Jompi kumpi meistä ei osaa optimoida (todennäköisesti minä).

Ei välttämättä. Kyse on tosiaan hyvin paljon tehtävästä. Koska Pythoninkin kirjastofunktiot on kirjoitettu kääntävällä kielellä, paljon riippuu siitä, paljonko aikaa vietetään niissä ja paljonko tulkkaavassa koodissa.

Kokeilin vielä samaa keskiarvon laskevaa pätkää Rustilla, ja se oli yllättäen selvästi kolmikosta hitain! Siinä taas varmasti kyse on optimoinnista ja juuri tehtävän kannalta oikeiden funktioiden käytöstä.