mboost-dp1
Python - codon
Det er almindeligt kendt at diverse JIT compiling Python implementationer som PyPy og GraalPython er langt hurtigere end standard CPython.
Men for et års tid siden dukkede der et alternativ op: codon. En Python frontend til LLVM. Interssant.
En hurtig test viste at codon er hurtigere end både PyPy og GraalPython til integer og floating point, men langsommere til string operationer.
Og så er der ikke alt Python kode codon accepterer.
Jeg måtte lave 3 rettelser i mit test script.
codon understøtter tilsyneladende ikke den gamle formatering.
lidt type sjov.
sys.version findes ikke i codon
Lidt irriterende men måske kan man leve med det for at kunne udføre integer operationer en faktor 100 gange hurtigere!
Men for et års tid siden dukkede der et alternativ op: codon. En Python frontend til LLVM. Interssant.
En hurtig test viste at codon er hurtigere end både PyPy og GraalPython til integer og floating point, men langsommere til string operationer.
Og så er der ikke alt Python kode codon accepterer.
Jeg måtte lave 3 rettelser i mit test script.
####print('%.2f million %s per second' % (xperf / 1000000, ops))
print(f'{xperf / 1000000} million {ops} per second')
codon understøtter tilsyneladende ikke den gamle formatering.
####sum = i
sum = i + 0.0
lidt type sjov.
####print(sys.version)
sys.version findes ikke i codon
Lidt irriterende men måske kan man leve med det for at kunne udføre integer operationer en faktor 100 gange hurtigere!
Ganske interessant.
Resultat på min maskine:
Hvad der er meget interessant er at codon generelt ikke har GIL.
Men Cython har den store fordel at man komme relevante afsnit af koden i pyx moduler, og gradvist optimere et eksisterende python program. Codon er vist "all or nothing" med behov for at ændre en del i koden.
Jeg er lidt skuffet over at Cython ikke klarede det bedre i ovenstående test.
def fib(n):
return n if n < 2 else fib(n - 1) + fib(n - 2)
def test():
t0 = time()
ans = fib(40)
t1 = time()
print(f'fib(40) = {ans} took {t1 - t0} seconds.')
Resultat på min maskine:
fib(40) = 102334155 took 27.467956066131592 seconds. (normal python)
fib(40) = 102334155 took 8.201532363891602 seconds. (def fib(n) Cython'ed)
fib(40) = 102334155 took 0.314555 seconds. (codon)
Hvad der er meget interessant er at codon generelt ikke har GIL.
Men Cython har den store fordel at man komme relevante afsnit af koden i pyx moduler, og gradvist optimere et eksisterende python program. Codon er vist "all or nothing" med behov for at ændre en del i koden.
Jeg er lidt skuffet over at Cython ikke klarede det bedre i ovenstående test.
I #2 kørte Cython uændret python3 kode. Den skal selvfølgelig hjælpes lidt på vej. pyx modulet ændret til:
Resultat:
cdef int _fib(int n):
return n if n < 2 else _fib(n - 1) + _fib(n - 2)
def fib(n):
return _fib(n)
Resultat:
fib(40) = 102334155 took 0.42511534690856934 seconds. (Cython med cdef fib)
#4
Ganske imponerende.
Ækvivalent kode i C:
Codon kommer ret tæt på C må man sige.
Men pågældende fibonacci beregning er jo en ret syntetisk test. Beregningen kunne klares på minimal tid hvis man gjorde det iterativt i stedet for rekursivt.
Det kunne være sjovt at finde en bare lidt mere meningsfuld benchmark og så sammenligne alle disse platforme igen. Jeg tror jeg vil lave en blog post om det og lægge koden i github.
fib(40) = 102334155 took 2.0503621101379395 seconds. (pypy 7.3.13)
Ganske imponerende.
Ækvivalent kode i C:
fib(40) = 102334155 took 0.781230 seconds. (gcc -O0)
fib(40) = 102334155 took 0.230041 seconds. (gcc -O3)
Codon kommer ret tæt på C må man sige.
Men pågældende fibonacci beregning er jo en ret syntetisk test. Beregningen kunne klares på minimal tid hvis man gjorde det iterativt i stedet for rekursivt.
Det kunne være sjovt at finde en bare lidt mere meningsfuld benchmark og så sammenligne alle disse platforme igen. Jeg tror jeg vil lave en blog post om det og lægge koden i github.
Codon vs. python forskelle: https://docs.exaloop.io/codon/general/differences
Codon's licens er BSL: https://www.reddit.com/r/Python/comments/122gssr/w...
Codon's licens er BSL: https://www.reddit.com/r/Python/comments/122gssr/w...
larsp (7) skrev:
Codon's licens er BSL: https://www.reddit.com/r/Python/comments/122gssr/w...
Den havde jeg slet ikke bidt mærke i.
BSL uden ekstra undtagelser.
Det er ikke så godt for mere seriøst brug.
#3
Det er faktisk lige ligesom Groovy @CompileStatic.
fib.groovy:
fibx.groovy:
groovy fib.groovy
fib(40) = 102334155 took 1.624 seconds.
groovy fibx.groovy
fib(40) = 102334155 took 0.343 seconds.
Det er faktisk lige ligesom Groovy @CompileStatic.
fib.groovy:
int fib(int n) {
return n < 2 ? n : fib(n - 1) + fib(n - 2)
}
t0 = System.currentTimeMillis()
ans = fib(40)
t1 = System.currentTimeMillis()
println("fib(40) = ${ans} took ${(t1 - t0) / 1000.0} seconds.")
fibx.groovy:
@groovy.transform.CompileStatic
int fib(int n) {
return n < 2 ? n : fib(n - 1) + fib(n - 2)
}
t0 = System.currentTimeMillis()
ans = fib(40)
t1 = System.currentTimeMillis()
println("fib(40) = ${ans} took ${(t1 - t0) / 1000.0} seconds.")
groovy fib.groovy
fib(40) = 102334155 took 1.624 seconds.
groovy fibx.groovy
fib(40) = 102334155 took 0.343 seconds.
arne_v (8) skrev:Det er ikke så godt for mere seriøst brug.
Nej. De nævner ikke nogen pris, kun "contact us". Er det en one-time payment? Eller skal der betales løbende så længe kunder bruger produktet udviklet med codon? Det kan blive lidt af et mareridt når softwaren ligger på fysiske apparater der kan fortsætte med at virke til "evig" tid.
#10
Det vil man jo skulle finde ud af hvis man havde behovet.
Men givet de mange gratis alternativer (Cython, PyPy, GraalPython etc.) så skal de have an attraktiv pris-politik for at kunne sælge.
Hvis jeg skulle sælge et sådant produkt ville jeg nok gå efter en "flat fee per major version valid enterprise wide" model.
Betal NNNNN dollars for retten til at bruge version X.* forevigt på alle firmaets systemer og embedded i systemer firmaet sælger til kunder.
Er kunderne tilfredse betaler de NNNNN dollars igen for version X+1.* et par år senere.
NNNNN dollars er ikke en stor udgift for et seriøst firma.
Der er ingen bøvl med licens administration.
Sælger man i tusindevis af licenser er der stadig penge i det.
Win win win.
Men jeg sælger ikke licenser og de ender sikkert med en eller anden Oracle lignende license model og nul kunder.
NB: Jeg tvivler iøvrigt på at codon egner til embedded i små dimser - codon bruger LLVM og jeg mener at LLVM bruger rigtigt meget memory.
Det vil man jo skulle finde ud af hvis man havde behovet.
Men givet de mange gratis alternativer (Cython, PyPy, GraalPython etc.) så skal de have an attraktiv pris-politik for at kunne sælge.
Hvis jeg skulle sælge et sådant produkt ville jeg nok gå efter en "flat fee per major version valid enterprise wide" model.
Betal NNNNN dollars for retten til at bruge version X.* forevigt på alle firmaets systemer og embedded i systemer firmaet sælger til kunder.
Er kunderne tilfredse betaler de NNNNN dollars igen for version X+1.* et par år senere.
NNNNN dollars er ikke en stor udgift for et seriøst firma.
Der er ingen bøvl med licens administration.
Sælger man i tusindevis af licenser er der stadig penge i det.
Win win win.
Men jeg sælger ikke licenser og de ender sikkert med en eller anden Oracle lignende license model og nul kunder.
NB: Jeg tvivler iøvrigt på at codon egner til embedded i små dimser - codon bruger LLVM og jeg mener at LLVM bruger rigtigt meget memory.
#9
Groovy er iøvrigt efter min mening et undervurderet sprog.
Typisk vil Groovy kode være lige så kort som Python kode.
Der er naturligvis for og imod begge.
Grunde til at vælge Python:
* masser af folk med python erfaring
* lavt memory forbrug
* solidt kendskab til hvad der er i PyPi
* behov for avanceret data analytics evt. ML
Grunde til at vælge Groovy:
* hurtigere out of the box uden brug af alternative implementationer
* mere almindeligt {} sprog fremfor indent sprog
* solidt kendskab til hvad der er i Maven repo
* behov for integration med diverse Java/Kotlin/Scala kode
Jeg ville finde det naturligt hvos Python var 10 gange så meget brugt som Groovy, men Python er 100 gange så meget brugt som Groovy.
Groovy er ikke på radar skærmen hos ret mange.
Groovy er iøvrigt efter min mening et undervurderet sprog.
Typisk vil Groovy kode være lige så kort som Python kode.
Der er naturligvis for og imod begge.
Grunde til at vælge Python:
* masser af folk med python erfaring
* lavt memory forbrug
* solidt kendskab til hvad der er i PyPi
* behov for avanceret data analytics evt. ML
Grunde til at vælge Groovy:
* hurtigere out of the box uden brug af alternative implementationer
* mere almindeligt {} sprog fremfor indent sprog
* solidt kendskab til hvad der er i Maven repo
* behov for integration med diverse Java/Kotlin/Scala kode
Jeg ville finde det naturligt hvos Python var 10 gange så meget brugt som Groovy, men Python er 100 gange så meget brugt som Groovy.
Groovy er ikke på radar skærmen hos ret mange.
Cython har ligesom codon et problem med strenge.
En C int og en Python int er ens så længe Python ikke skal opgradere til en "big integer", men en C char[] og en Python string er ikke nær så kompatible.
Jeg testede - både Cython og Codon scorer tårnhøjt i integer og floating point, men lavt i strenge.
https://www.vajhoej.dk/arne/articles/perf.html
En C int og en Python int er ens så længe Python ikke skal opgradere til en "big integer", men en C char[] og en Python string er ikke nær så kompatible.
Jeg testede - både Cython og Codon scorer tårnhøjt i integer og floating point, men lavt i strenge.
https://www.vajhoej.dk/arne/articles/perf.html
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund