Περί python bytecode

[defacer]

Γενικά μιλώντας δεν υπάρχει γλώσσα που να τρέχει σαν interpreter κατευθείαν από source και να χρησιμοποιείται για πρακτικούς σκοπούς, απλά γιατί είναι τόσο αργό που δεν έχει νόημα. Οπότε "όλα" τα implementations έχουν ένα πρώτο compilation σε bytecode και συνήθως μετά από αυτό ακολουθεί jit compiler σε δεύτερο στάδιο (πχ PyPy, οτιδήποτε τρέχει σε jre η .net).

 

Υπάρχουν βεβαίως και πολλά implementations όπου έχουμε πρώτα compilation σε bytecode και μετά interpretation του bytecode από ένα vm (πχ CPython, Ruby, PHP) -- αυτό γενικά μπορεί να είναι αποδεκτό από άποψης ταχύτητας για συγκεκριμένα είδη εφαρμογών, αλλά είναι σίγουρα πιο αργό από εκτέλεση native machine code (όντως, όχι 100 φορές πιο αργό γενικά αλλά εκεί που μετράει η ταχύτητα και το 3 ή 5 ή 50 ενίοτε φορές δεν είναι αποδεκτό).

 

Τελείως ενδεικτικά, και με προειδοποίηση πως πρέπει κανείς να ξέρει πως να μεταφράσει αυτά που διαβάζει για να μη βγάλει λάθος συμπεράσματα, νούμερα πχ εδώ: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=yarv&lang2=java

[akisamdgr]

Δηλαδη το bytecode που γινεται interpretation απο vm cpython ποσο πιο αργο ειναι απο το bytecode που γινεται compilation απο jit PyPy ;;;

Ποσο πιο αργο ειναι το jit PyPy απο μια εφαρμογη compiler.....ενα exe file......υπαρχει διαφορα στην ταχυτητα και αναμεσα στα exe.....αν ειναι exe της visual basic η της c++ η της delphi η ακομη και της python με py2exe PyInstaller ;;;;;

 

Και φυσικα ποσο αργο ειναι το κλασικο inerpretation π.χ απο εναν interpreter οπως η gw basic basica κλπ ;;;;;;

[defacer]

Δηλαδη το bytecode που γινεται interpretation απο vm cpython ποσο πιο αργο ειναι απο το bytecode που γινεται compilation απο jit PyPy ;;;

 

Δεν έχω ασχοληθεί αλλά ακούγονται γενικά κάτι νούμερα του στυλ και 5 φορές πιο αργό. Αλλά η επιλογή CPython vs PyPy έχει μέσα πολλά θέματα να λάβει υπόψη πέραν της ταχύτητας.

 

Ποσο πιο αργο ειναι το jit PyPy απο μια εφαρμογη compiler.....ενα exe file......υπαρχει διαφορα στην ταχυτητα και αναμεσα στα exe.....αν ειναι exe της visual basic η της c++ η της delphi η ακομη και της python με py2exe PyInstaller ;;;;;

 

Δεν έχω ιδέα. Το PyPy τελείως θεωρητικά θα μπορούσε κατά τόπους να είναι και πιο γρήγορο από C++, είναι η κλασική συζήτηση aot vs jit που έχει γίνει παλιότερα και εδώ.

 

Και φυσικα ποσο αργο ειναι το κλασικο inerpretation π.χ απο εναν interpreter οπως η gw basic basica κλπ ;;;;;;

Απύθμενα πιο αργό αλλά τι νόημα έχει; Κανείς δεν πρόκειται να το εξετάσει αυτό

[pmav99]

@akisamdgr

Δεν υπάρχει one size fits all.

 

Το warm-up cost ενός jit compiler δεν είναι μικρό. Αν αρχίσεις να μετράς χρόνους θα δεις ότι για ένα process που θα τρέξει για πολύ λίγη ώρα, το pypy μπορεί και να είναι πιο αργό από cpython. Το jit εκ φύσεως είναι φτιαγμένο για να βελτιστοποιεί loops. Αν έχεις ένα straight execution path, το jit δεν μπορεί να σε βοηθήσει. Μόνο overhead θα προσθέσει.

 

Για short running processes, ακόμα και το start-up time παίζει ρόλο. Συνέκρινε πχ

time python3 -c 'pass'
time python2 -c 'pass'
time pypy -c 'pass'

Αν έχεις πάλι ένα loop με πολλά iterations, θα δεις ότι το pypy είναι τάξεις μεγέθους γρηγορότερο.

[akisamdgr]

Πως γινεται το παλιο κλασικο interpretation;;;;;.........παιρνει εντολη εντολη το προγραμμα το ελεγχει λεξικα συνατακτικα

κλπ....το διερμηνευει σε assembly....μετα το διερμηνευει σε γλωσσα μηχανης...το βαζει στη μνημη και το εκτελει;;;

για compiler source object assembler linker loader κλπ υπαρχουν αναλυσεις και σχηματα αλλα για απλο interpretion

ενα ξερο source------machine code......ποια ειναι τα βηματα ενος προγραμματος file.bas απο τον interpreter της gw basic

ναι δεν εχει αξια...κανεις δεν ασχολειται με παλιους interpreter αλλα......το εχω απορια ;;;;

[παπι]

Δεν το διερμηνεύει σε asm. Όλες οι εντολές είναι bindαρισμενες σε low level γλώσσα.

[akisamdgr]

Γενικά μιλώντας δεν υπάρχει γλώσσα που να τρέχει σαν interpreter κατευθείαν από source και να χρησιμοποιείται για πρακτικούς σκοπούς, απλά γιατί είναι τόσο αργό που δεν έχει νόημα. Οπότε "όλα" τα implementations έχουν ένα πρώτο compilation σε bytecode και συνήθως μετά από αυτό ακολουθεί jit compiler σε δεύτερο στάδιο (πχ PyPy, οτιδήποτε τρέχει σε jre η .net).

 

Υπάρχουν βεβαίως και πολλά implementations όπου έχουμε πρώτα compilation σε bytecode και μετά interpretation του bytecode από ένα vm (πχ CPython, Ruby, PHP) -- αυτό γενικά μπορεί να είναι αποδεκτό από άποψης ταχύτητας για συγκεκριμένα είδη εφαρμογών, αλλά είναι σίγουρα πιο αργό από εκτέλεση native machine code (όντως, όχι 100 φορές πιο αργό γενικά αλλά εκεί που μετράει η ταχύτητα και το 3 ή 5 ή 50 ενίοτε φορές δεν είναι αποδεκτό).

 

Τελείως ενδεικτικά, και με προειδοποίηση πως πρέπει κανείς να ξέρει πως να μεταφράσει αυτά που διαβάζει για να μη βγάλει λάθος συμπεράσματα, νούμερα πχ εδώ: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=yarv&lang2=java

Σε αναζητησεις στο internet η java φαινεται στην vm να εμπεριεχει και jit compiler και interpreter........με μπερδεψε λιγο.......εχουμε source--compiler to bytecode-----vm με interpreter για εκτελεση και αν θελουμε pypy jit compiler (python)...........και την java source---compiler to bytecode------vm με jit compiler και interpreter για γρηγοροτερη εκτελεση..............υπαρχει jit compiler και jit interpreter στην vm της java....................ξεμπερδεψε το μου λιγο.......καπου δεν το επιασα καλα....................

[defacer]

Σε αναζητησεις στο internet η java φαινεται στην vm να εμπεριεχει και jit compiler και interpreter........με μπερδεψε λιγο.......εχουμε source--compiler to bytecode-----vm με interpreter για εκτελεση και αν θελουμε pypy jit compiler (python)...........και την java source---compiler to bytecode------vm με jit compiler και interpreter για γρηγοροτερη εκτελεση..............υπαρχει jit compiler και jit interpreter στην vm της java....................ξεμπερδεψε το μου λιγο.......καπου δεν το επιασα καλα....................

 

Κάλλιο αργά παρά ποτέ...

 

Λοιπόν, γενικά πρέπει να ξεχωρίσεις στο μυαλό σου το specification μιας γλώσσας/πλατφόρμας από το implementation. Το πρώτο καθορίζει το πώς θα λειτουργούν τα πράγματα και είναι το ευαγγέλιο της υπόθεσης, το δεύτερο αποτελεί τον πραγματικό τρόπο λειτουργίας. Αυτός μπορεί να διαφέρει από τη θεωρητική περιγραφή του πρώτου, αρκεί βέβαια η όποια διαφορά να μην είναι ορατή εκτός του συστήματος.

 

Ένα κλασικό παράδειγμα είναι διάφορα πράγματα που κάνουν οι optimizing compilers, π.χ. για τη συζήτηση αν γράψεις Χ = Y + Y δεν είναι απαραίτητο ότι θα γίνει πρόσθεση, επειδή αυτό που έγραψες είναι ισοδύναμο του X = 2 * Υ και η πράξη 2 * μπορεί να γίνει πάρα πολύ γρήγορα με ένα απλό αριστερό bit shift σε εξειδικευμένο τμήμα της cpu που υπάρχει για να κάνει ακριβώς αυτό.

 

Οπότε τώρα όσον αφορά τη Java, ή ακριβέστερα το specification του JVM: σου λένε ότι ο κώδικάς σου (.java) θα γίνει compile σε bytecode (.class) και αυτό με τη σειρά του interpret από το JVM. Στην πράξη όμως το JVM περιλαμβάνει και JIT compiler σε native machine code, που μπορεί να λειτουργήσει σε επίπεδο method. Εαν και όταν το JVM αποφασίσει (ένα μέρος του είναι εκεί για να κάνει ακριβώς αυτή τη δουλειά) πως η τάδε method αξίζει να γίνει JIT, θα τη δώσει στον compiler (χωρίς φυσικά να τον περιμένει) και όταν αυτός τελειώσει, από κει και πέρα η εκτέλεσή της δε θα γίνεται βάσει του αρχικού bytecode αλλά με το native που έχει παραχθεί. Αυτό δεν είναι καν απαραίτητο να έχει δύο μόνο καταστάσεις: μπορεί θεωρητικά ένα VM να αποφασίσει μαζεύοντας περισσότερα δεδομένα κατά την εκτέλεση του προγράμματος να ξανακάνει JIT compile ξοδεύοντας περισσότερο χρόνο ή στοχεύοντας συγκεκριμένα σημεία του κώδικα για optimization επειδή θεωρεί πως αξίζει τον κόπο σε μάκρος χρόνου. Ο χρόνος που θα χρειαστεί μέχρι να "κατασταλάξει" το JVM τελικά λέγεται warm-up time και σε κάποιες περιπτώσεις είναι τόσο σημαντικός που ο ίδιος ο κώδικας που γράφουμε λαβαίνει το φαινόμενο υπόψη του.

 

Εκεί που γίνεται πραγματικά το έλα να δεις μ' αυτά τα πράγματα είναι στη Javascript, η οποία δεν έχει στο specification ούτε bytecode ούτε τίποτα επομένως θα μπορούσε να γίνεται και κατευθείαν interpreted από source (και όντως έτσι γινόταν τον καιρό εκείνο στην Ιερουσαλήμ). Επειδή για προφανείς λόγους το performance της Javascript engine του εκάστοτε browser είναι πλέον ίσως το σημαντικότερο feature του, το τι multi level JIT compilation και optimization γίνεται εκεί είναι πραγματικά επιστήμη από μόνο του. Ορίστε μερικά random links που βρήκα με ελάχιστο googling τα οποία θα σε βάλουν στο κλίμα (σόρι, έχω διαβάσει στο παρελθόν πολύ καλύτερα αλλά δε μπορώ να τα βρω αυτή τη στιγμή):

 

https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-time-jit-compilers/

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JIT_Optimization_Strategies

http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-optimizing-compiler

https://github.com/Microsoft/ChakraCore/wiki/Architecture-Overview

[Ilias95]

Ανασταίνω λίγο το thread, αλλά έχω μια σχετική απορία.

Γιατί το VM της εκάστοτε γλώσσας (έστω JVM της Java) δεν κάνει πάντα AOT compilation τον κώδικα ενδιάμεσης μορφής μία φορά ώστε να παράγεται native code και να μην υπάρχει το όλο overhead του να τρέχει το bytecode μέσω της VM κάθε φορά;

Τι κερδίζουμε δηλαδή με τον τρόπο που γίνεται τώρα η διαδικασία (JIT/interpretation);

[defacer]

Το VM να κάνει AOT; Εκεί που πατάς να ξεκινήσει το πρόγραμμα δηλαδή να περιμένεις πρώτα να κάνει compile ολόκληρο, ακόμα και τα μέρη του που δε θα χρησιμοποιηθούν καθόλου;

 

Και για ποιό λόγο κιόλας να κάνει κάτι τέτοιο;

[Ilias95]

Εννοούσα να γίνει εκ των προτέρων αυτό, όχι τι στιγμή που θες να εκτελέσεις το πρόγραμμα. Το πρόβλημα δηλαδή είναι το μέγεθος του εκτελέσιμου που θα προκύψει;

[defacer]

Αν γίνει εκ των προτέρων τότε δεν το κάνει το JVM αλλά ο javac. Και το πρώτο και μεγαλύτερο πρόβλημα που αποκτάς είναι ότι χάνεις αμέσως το WORA, που είναι... το σλόγκαν της γλώσσας. 

[Ilias95]

Αν γίνει εκ των προτέρων τότε δεν το κάνει το JVM αλλά ο javac. Και το πρώτο και μεγαλύτερο πρόβλημα που αποκτάς είναι ότι χάνεις αμέσως το WORA, που είναι... το σλόγκαν της γλώσσας. 

Μπορείς να με βοηθήσεις να καταλάβω το bigger picture εδώ;

 

Δηλαδή μια αρχιτεκτονική σαν αυτή δεν έχει νόημα;

source code -> compiler -> bytecode -> VM translator (AOT) -> machine code

 

Με το όφελος ότι είναι ευκολότερο να γράφεις τον VM translator μόνο για κάθε διαφορετική αρχιτεκτονική επεξεργαστή, απ' ότι έναν compiler που μεταφράζει από source code σε machine code κατευθείαν.

 

Από το άρθρο της wikipedia που παρέθεσες:

 

This means a programmer can develop code on a PC and can expect it to run on Java enabled cell phones, as well as on routers and mainframes equipped with Java, without any adjustments. This is intended to save software developers the effort of writing a different version of their software for each platform or operating system they intend to deploy on.

 

Αν αντί για ένα VM που τρέχει καθ' όλη τη διάρκεια του προγράμματος, έχεις έναν VM translator που μεταφράζει το bytecode σε native code μία φορά και μετά απλά τρέχει αυτό το executable, πάλι δεν ισχύει το παραπάνω που παρέθεσα για τους developers;

 

Στην 1η περίπτωση η προϋπόθεση είναι να έχεις το VM εγκατεστημένο. Στην 2η περίπτωση η προϋπόθεση είναι να έχεις τον VM translator εγκατεστημένο ΚΑΙ να τον εκτελείς μία φορά για να μεταφράζει κάθε πρόγραμμα. Αυτή η μετάφραση όμως θα μπορούσε να γίνεται "αυτόματα" με την εγκατάσταση κάθε προγράμματος (για να μην βάζεις τον χρήστη να το κάνει μόνος του).

 

Χάνω κάτι μεγάλο από την εικόνα ή δεν έχει νόημα αυτό που λέω;

[defacer]

Αυτό που λες γίνεται (φυσικά, σχεδόν τα πάντα τεχνικά είναι πραγματοποιήσιμα). Αλλά γιατί να το κάνει κανείς δεδομένων των υπέρ/κατά;

 

Αν έχεις ήδη ένα VM τότε γιατί να ασχολείσαι με AOT compiler και ιστορίες για αγρίους; Δηλαδή ΟΚ, ασχολούνται γενικά (π.χ. υπάρχει AOT compilation για .ΝΕΤ και υποθέτω και για Java θα υπάρχει) αλλά μόνο σαν bonus feature που υποθέτω είναι για να χρησιμοποιηθεί από τους ελάχιστους που το χρειάζονται, αλλά για ποιό λόγο να μπεις στον κόπο να το κάνεις βασικό mode λειτουργίας; Έξτρα πολυπλοκότητα, πρέπει να αναπτύξεις compiler backend για κάθε πλατφόρμα που θες να υποστηρίξεις, κλπ κλπ. It's just not worth it.

[Ilias95]

Αυτό που λες γίνεται (φυσικά, σχεδόν τα πάντα τεχνικά είναι πραγματοποιήσιμα). Αλλά γιατί να το κάνει κανείς δεδομένων των υπέρ/κατά;

Αυτό ακριβώς είναι που ρωτάω! Ποια είναι τα υπέρ και τα κατά, έστω χοντρικά.

 

Αν έχεις ήδη ένα VM τότε γιατί να ασχολείσαι με AOT compiler και ιστορίες για αγρίους; Δηλαδή ΟΚ, ασχολούνται γενικά (π.χ. υπάρχει AOT compilation για .ΝΕΤ και υποθέτω και για Java θα υπάρχει) αλλά μόνο σαν bonus feature που υποθέτω είναι για να χρησιμοποιηθεί από τους ελάχιστους που το χρειάζονται, αλλά για ποιό λόγο να μπεις στον κόπο να το κάνεις βασικό mode λειτουργίας; Έξτρα πολυπλοκότητα, πρέπει να αναπτύξεις compiler backend για κάθε πλατφόρμα που θες να υποστηρίξεις, κλπ κλπ. It's just not worth it.

 

Πριν φτιαχτεί το πρώτο VM όμως, τα έβαλαν κάτω και αποφάσισαν ότι για κάποιο λόγο είναι καλύτερο να φτιάξεις VM παρά AOT compiler για το bytecode του "πρώτου" compiler. Ποιος είναι αυτός ο λόγος/λόγοι είναι αυτό που ρωτάω.

 

Με το έξτρα πολυπλοκότητα δεν καταλαβαίνω τι ακριβώς εννοείς. Όσο του ότι πρέπει να αναπτύξεις compiler για κάθε πλατφόρμα που θες να υποστηρίξεις, το ίδιο ακριβώς δεν ισχύει και στη περίπτωση της VM; Για κάθε πλατφόρμα που θες να υποστηρίξεις δεν πρέπει να υλοποιήσεις και την VM γι' αυτήν;

 

Ευχαριστώ πολύ για τον χρόνο σου!