C or Python?

[migf1]

padding

>char* new_str(size_t sz)
{
char* result = new char[sz + sizeof size_t];
memcpy(result,&sz,sizeof size_t);
result += sizeof size_t;
*result = 0;
return result;
}
void free_str(char* str)
{
delete[] (str - sizeof size_t);
}


int main(int,char**)
{
char *str = new_str(100);
std::cin>>str;
std::cout<<str;
free_str(str);	

 

αλλα και παλι δεν εχει νοημα εφοσον ολα τα framework δουλευουν με cstr

πχ να κανεις κατι τετοιο scanf("%s",myStr) ή scanf("%s",myStr.data) δεν θα εχεις ηδεα για το μεγεθος του string αρα πλι πας σε strlen

Sorry, αλλά δεν καταλαβαίνω πως αυτός ο κώδικας αντιμετωπίζει το πρόβλημα της strlen()... και άρα και το πρόβλημα με την strcpy(), strncpy(), κλπ. Επίσης προσωπικά δεν χρησιμοποιώ ποτέ scanf για να διαβάσω strings από την κύρια είσοδο, έχω φτιάξει δική μου συνάρτηση, που είναι βελτίωση της fgets().

 

Γενικώς κανείς δεν θα έπρεπεε να χρησιμοποιεί την scanf() για το διάβασμα οποιουδήποτε τύπου δεδομένων... ήδη εδώ και χρόνια στον gcc η scanf θεωρείται depreciated και υπάρχει απλώς για λόγους συμβατότητας (όπως και η gets()). Η εύκολη & προτεινόμενη σε αρχάριους εναλλακτική είναι:

>
fgets(s, n, stdin);
sscanf(s, ..., ...);

 

Οκ βρες μου μια qsort σε c που κανει συγκρινει integers, και οταν γυρισω απο τη δουλεια θα την βαλω στο project για να δουμε και ποσο χανουν οι hl γλωσσες (οτι χανουν, χανου.. αλλα ποσο; )

 

Πατνος 1-0 LL vs HL αν καποιος χρησιμοποιουσε qsort απο την stdlib θα ετρωγε μεγαλο καροτο.

 

 

BTW τωρα που το σκεφτομαι, το προβλημα δεν ειναι στο καλεσμα της comp εφοσον αυτη θα εχει μπει στη L1 cache

Google is your friend (δεν έχω πρόχειρο κώδικα)

 

Στα γρήγορα βρήκα κάτι σαν κι αυτά:

http://alienryderflex.com/quicksort/

http://www.codeproject.com/KB/tips/optimizingquicksort.aspx

(ούτε ξέρω τι optimizations κάνουν, ούτε έχω όρεξη τώρα να κάθομαι να διαβάζω )

 

Σίγουρα πάντως στο κυνήγι της απόλυτης επίδοσης το 1ο-1ο optimization είναι να αφαιρεθούν τα casting (δηλαδή να γράψεις τον κώδικα απευθείας για τα data types σου) και να αφαιρεθούν οι έλεγχοι για την εγκυρότητα των ορισμάτων.

 

Για τα υπόλοιπα θα πρέπει να διαβάσεις το άρθρο της Wikipedia

[Timonkaipumpa]

LL vs HL... να αναφέρω ότι η FFTw είναι υλοποιημένη σε C....

 

FFTw

 

Παραθέτω από το άρθρο:

 

FFTW is known as the fastest free software implementation of the Fast Fourier transform (FFT) algorithm

[jstark]

Ρε παιδια διαβάζοντας καποιος το thread θα βγαλει το συμπερασμα πως καποιοι θεωρουν την (καθε) scripting γλωσσα εφάμιλλη (οσον αφορα την ταχυτητα) μιας native γλώσσας. Αυτό ειναι τεχνικώς αδύνατο. Οποιος δει τον κωδικα της (default) python θα καταλαβει γιατι. (Ας προσέξει για παράδειγμα πως ψαχνονται και εκτελουνται οι συναρτησεις). Αλλα implementations της python (οπως το pypy) ειναι οντως ταχυτερα του default implementation, αλλα παραμένουν 2-3 φορες βραδύτερα της C/C++. Γενικα το default implementation σε ruby/python κλπ ειναι 2 τάξεις μεγέθους βραδυτερο απο native κωδικα. Για παράδειγμα, οταν το IO της python 3 γραφτηκε εξ ολοκληρου σε python, ηταν απαράδεκτο οσον αφορά το performance, και γραφτηκε ξανα σε C. Για να μην αναφέρω τα Global locks που ταλανιζουν για χρονια.

 

Αυτα που λεω (για οσους συμφωνουν) δεν αναιρουν την αξια της python. H python ειναι μια φανταστικη γλωσσα (οχι τοσο φανταστικη οσο η LISP ), ομορφη, πρακτικη, ευκολη, κατανοητη ... Οταν αυτα που κανει ειναι "αργα" για τα γουστα μας, μας δινει τη δυνατοτητα να καλεσουμε native κωδικα. Μακάρι να προγραμματιζα σε python αντι σε C/C++. Θα ειχα σιγουρα περισσοτερα μαλλια. Μπορω με python να υποστηριξω το backend ενος site ? Ναι μπορω, μιας και το περισσοτερο χρονο το χανουμε στα IO της DB. Μπορω να φτιαξω ενα CAD/CAE προγραμμα που να σηκωνει εκατομμυρια elements απο CFD μοντελα σε 100% python; Ε μη λεμε και οτι θελουμε, προφανως οχι. Υπαρχουν απτα παραδειγματα που η python καλει native κωδικα ; Δυο παρομοια, PySide, PyQt. Μπορώ να τσεκάρω την ταχυτητα της python (και οχι μονο) σε διαφορα (περιεργα ή μή) benchmarks; Στο internet υπαρχει πληθωρα τετοιων. Τα τελευταια της pypy που "εβγαλαν" τη python ταχυτερη απο τη C σε καποια συγκεκριμενα προβληματα, προκαλεσαν ποικιλες συζητησεις και μαλωματα.

 

Αξιζει καποιος να μαθει python? 100% . Αξιζει καποιος να μαθει C? 101%. C or Python ? ΚΑΙ ΤΙΣ ΔΥΟ

 

Χαιρετω

 

Και εχω την εντυπωση πως ο κωδικας του FFTW γινεται generate απο OCAML.

[b_real]

PyPy is faster than C, again: string formatting

(μιλαμε για συγκεκριμενες περιπτωσεις...μην αρχισετε πολεμο...)

[PanosJee]

H python ειναι μια φανταστικη γλωσσα (οχι τοσο φανταστικη οσο η LISP )

(+ 1 jstark)

[παπι]

Ρε παιδια διαβάζοντας καποιος το thread θα βγαλει το συμπερασμα πως καποιοι θεωρουν την (καθε) scripting γλωσσα εφάμιλλη (οσον αφορα την ταχυτητα) μιας native γλώσσας.

 

Αυτο λογικα παει για μενα. Κειτα, αυτο που τονιζω ειναι οτι η διαφορα στο "performance" ειναι ελαχιστη και αυτη σε συγκεκριμενους τομεις. Δεν ειναι δυνατον να βαζουμε τις HL στη κατηγορια παπακι και τις LL στη κατηγορια street. Αν πραγματικα ηταν "αργες" γλωσσες (οι HLs) τοτε γιατι οι developers του blender αποφασισαν να γραψουν ενα κομματι του σε python;

 

@mig Εβαλα και αυτη την qsort συναρτηση που μου πρωτινες, και εχω να πω... (περιμενα να ειναι πολυ πιο γρηγορη αλλα δεν)

>C# sorting:     64263676ticks(6sec)
C (std)qsort:   169789712ticks(16sec)
C (other)qsort: 62233559ticks(6sec) (func result:successful)
StdSort:        75114296ticks(7sec)

 

*StdSort: της stl

[migf1]

@mig Εβαλα και αυτη την qsort συναρτηση που μου πρωτινες, και εχω να πω... (περιμενα να ειναι πολυ πιο γρηγορη αλλα δεν)

>C# sorting:     64263676ticks(6sec)
C (std)qsort:   169789712ticks(16sec)
C (other)qsort: 62233559ticks(6sec) (func result:successful)
StdSort:        75114296ticks(7sec)

 

*StdSort: της stl

Μάλλον θα θέλει κι άλλο optimization (αν μου έρθει όρεξη θα δω μήπως γράψω εγώ καμία). Μια που το έφερε η κουβέντα, η stdlib qsort εκτός από αργή είναι και implementation dependent, δλδ ο κάθε compiler την υλοποιεί διαφορετικά. Κάπου είχα διαβάσει πως ένας μάλιστα (δεν θυμάμαι ποιος) δεν την υλοποιούσε με αλγόριθμο quick-sort αλλά με shell-sort

 

ΥΓ. Σε C# αυτός εδώ: http://osix.net/modules/article/?id=695 έλεγε το 2005 πως η δική του υλοποίηση ήταν ταχύτερη από την built-in της C#. Μιας και είσαι σε... benchmarking mode, ρίξε της κι αυτηνής μια ματιά όταν ευκαιρήσεις

[παπι]

Μάλλον θα θέλει κι άλλο optimization (αν μου έρθει όρεξη θα δω μήπως γράψω εγώ καμία). Μια που το έφερε η κουβέντα, η stdlib qsort εκτός από αργή είναι και implementation dependent, δλδ ο κάθε compiler την υλοποιεί διαφορετικά. Κάπου είχα διαβάσει πως ένας μάλιστα (δεν θυμάμαι ποιος) δεν την υλοποιούσε με αλγόριθμο quick-sort αλλά με shell-sort

 

ΥΓ. Σε C# αυτός εδώ: http://osix.net/modu...article/?id=695 έλεγε το 2005 πως η δική του υλοποίηση ήταν ταχύτερη από την built-in της C#. Μιας και είσαι σε... benchmarking mode, ρίξε της κι αυτηνής μια ματιά όταν ευκαιρήσεις

 

Καλα η qsort της stdlib απλα /* */ .

 

Οχι δεν ειμαι σ εbenchmarking mode απλα τα γουσταρω κατι τετοια, να βλεπω τα ελατωματα/πλεονεκτηματα μια γλωσσα σε πρακτικο επιπεδο. Τωρα για την "γρηγοροτερη" υλοποιηση που λες... παλια ειχα βρει (στο codeproject) μια με parallel , ενα σου λεω ~2,3 πιο γρηγορη απο αυτη που εχω παραπανω (με τριπυρηνο CPU).

[PanosJee]

Ρε παιδιά ακόμα όλοι γράφετε πώς θα έχετε τον πιο γρήγορο κώδικα λες και μετράμε ποιος την έχει μακρύτερη. Ναι σε μερικές περιπτώσεις είναι το ζητούμενο αλλά σπάνια.

Σημασία έχει να γράψεις όμορφο, καθαρό κώδικα και η Python βοηθάει όσο καμία γλώσσα.

Σημασία έχει να επικεντρώνεσαι στα προβλήματα που λύνεις και όχι στο πώς να μιλάς στον υπολογιστή.

 

Ασε δε που με την Python θα κάνει μια χαρά web programming και θα μιλάς με 100άδες APIs. Αν θες web programming με C, καλή τύχη! Οπως και να έχει όλοι πρέπει να ξέρουν λίγη C!

[jstark]

Αυτο λογικα παει για μενα. Κειτα, αυτο που τονιζω ειναι οτι η διαφορα στο "performance" ειναι ελαχιστη και αυτη σε συγκεκριμενους τομεις.

 

Οχι, δεν αναφερομουν σε ατομα, απλα ηταν μια γενική "παρατήρηση" διαβάζοντας στα γρήγορα το νήμα. Γενικά συμφωνώ με την αποψή σου πως η C (πλεον) δεν ειναι και η καλυτερη γλωσσα να ξεκινησει καποιος τα του προγραμματισμου, και αποδειξη αυτου ειναι πως πολλα πανεπιστημια επιλεγουν εδω και χρονια αλλες γλωσσες. Δε συμφωνω ομως 100% και με την αποψη πως η python ειναι η καλυτερη για να μορφωθει καποιος αλγοριθμικα κλπ, γιατι εχει πολυ ετοιμο πραγμα. Εκπαιδευτικά, είμαι της αποψης πως οι scheme/cl ειναι ιδανικες.

 

Τωρα σχετικα με το νημα, νομιζω πως το ολο μπερδεμα ξεκιναει απο το τί πραγματικά εννοούμε με τον όρο "γλώσσα προγραμματισμου". Παλαιότερα, η γλωσσα προγραμματισμου πηγαινε πακετο με τις βιβλιοθηκες και τον compiler της. Οποτε, αν καποια ηταν ταχυτερη, ήταν ταχύτερη λογω φυσικα των semantics της γλωσσας, λογω του φοβερου και τρομερου compiler, λογω των καλογραμμένων βιβλιοθηκων, κλπ, που ηταν γραμμενες μονο γι αυτην. Ηταν δηλαδη ενα πακετο ταχυτητας. Στις μέρες μας, αυτο τεινει να εκλειψει στις νεες γλωσσες. Για παράδειγμα, το android τρέχει java ? Για μενα ίσως όχι. Αυτο που τρέχει ειναι μια άλλη VM (νταλβικ) και απλα καποιος γραφει με συνταξη της java. Αυτο φυσικα οι περισσοτεροι θα το θεωρησουν λαθος, και θα πουν πως ΝΑΙ το android τρεχει java. Ομοιως με τις python, ruby κλπ. Αν καλεσω τη sort, και αυτη καλεσει τη sort της ... C, ή μία γραμμένη σε C, τότε η ταχύτητα οφειλεται σε ποιον παράγοντα; Στην ευκολια της python ή στην ταχύτητα της απο κάτω γλώσσας; Δεν ξέρω. Για μένα μια γλώσσα ειναι πακετο, και τη συγκρινω με τις αλλες μονο οσον αφορα καθαρο κωδικα, οσο βεβαια μπορω. Μπορει να κανω και λαθος.

[neverlastn]

FFTw

 

Cool, σε C και assembly ΠΡΕΠΕΙ να είναι μία γραμμένη μία τέτοια βιβλιοθήκη

 

Ρε παιδιά ακόμα όλοι γράφετε πώς θα έχετε τον πιο γρήγορο κώδικα λες και μετράμε ποιος την έχει μακρύτερη. Ναι σε μερικές περιπτώσεις είναι το ζητούμενο αλλά σπάνια.

 

Αυτό είναι ΠΟΛΥ ΠΟΛΥ ΠΟΛΥ σωστό.

 

Παιδιά να σας πω ένα μυστικό...

 

ΔΕΝ ΕΧΕΤΕ ΙΔΕΑ τι είναι πιο γρήγορο...

 

Μα το θεό - ΔΕΝ ΞΕΡΕΤΕ ΤΟΝ ΧΡΙΣΤΟ ΣΑΣ!

 

Και μη το πάρετε προσωπικά... Μπορώ να σας υπογράψω ότι ΔΕΝ ΞΕΡΕΤΕ ΤΟΝ ΧΡΙΣΤΟ ΣΑΣ!

 

Να υποθέσω τότε πως πρέπει να πετάξουμε στα σκουπίδια πανεπιστήμια και τη μισή βιβλιογραφία της πληροφορικής που ασχολούνται με κάτι... αστειότητες τύπου computational complexity, algorthmic analysis και συναφείς... αηδίες! Και btw, αν χρειαστείτε ποτέ sorting, μόνο bubble-sort... ταχύτητα στο development και κάνει και τη δουλειά που θέλουμε!

 

Ο λόγος είναι ότι τα πράγματα αλλάζουν σχεδόν κάθε 2 χρόνια ή πιό σύντομα. Οι *** που διδάσκουν στο πανεπιστήμιο (πολυπλοκότητες κ.τ.λ.) είναι για παιδιά - τελείως θεωρητικές. Για να μπορείς να βγάλεις συμπεράσματα με βάση αυτές και να εκτιμήσεις σωστά θα πρέπει να ξέρεις αρκετά καλά το hardware σου και τα όριά του.

 

QuickSort και BubbleSort εχουν ΤΗΝ ΙΔΙΑ πολυπλοκότητα = σκατά

 

Η μόνη sort που είναι πιό efficient από αυτές (και η μόνη ουσιαστικά βιώσημη σήμερα) είναι η MergeSort (!!)

 

Α... και αν θέλετε ακόμα πιό γρηγόρα B+ δέντρα... δυστυχώς.

 

--- Ελπίζω να σας κέντρισα το ενδιαφέρον και να σας τσάντισα αρκετά ώστε να διαβάσετε και λίγο παρακάτω...

 

Όπως λοιπόν ξέρετε το CPU είναι γρήγορο... και άχρηστο χωρίς δεδομένα. Έχουμε λοιπόν L1 Cache, L2 Cache, RAM και τέλος τον Δίσκο...

 

Αν θέλεις να είσαι γρήγορος - ο στόχος σου είναι να μη χτυπήσεις ποτέ τον δίσκο - και αν είναι δυνατόν να μένεις όσο το δυνατόν περισσότερο στην L1

 

Αυτό σημαίνει ότι αν π.χ. μπορείς να χωρέσεις δύο arrays των 256k στην L1 και να κάνεις vector sort και να βγάλεις min/max/μέσο όρο, τέλεια! Αυτό πρέπει να κάνεις... σε 265k. Αν έχεις 100 Gb δεδομένα αυτό που πρέπει να κάνεις για να είσαι γρήγορος είναι το εξής:

 

>foreach 256k chunk of 100Gb {
 prefetch hint for the next 256k
 sort(256k) <- 
 min(256k)  <-
 max(256k)  <-
 sum(256k)  <- Αυτά τα 4 μέσα σε ένα "for" παράλληλα
}

Aggregate results (if necessary) i.e. merge από τη mergesort
μόνο για το sort και μία διαίρεση του sum με το count για να
βρούμε το μέσο.

 

Αυτός είναι ο πιό γρήγορος τρόπος να κάνουμε sort σήμερα (και ουσιαστικά τζάμπα να υπολογίσουμε και μερικά min/max/average).

 

Ακόμα κι έτσι τον περισσότερο χρόνο θα καθόμαστε να περιμένουμε από τον δίσκο η την RAM να φέρει τα δεδομένα. Γι'αυτό καλύτερα να έχουμε να τρέχουν 50 τέτοιες διεργασίες παράλληλα (όχι ότι θα μας σώσει... αλλά καλύτερα).

 

Αυτό πάνω κάτω γίνεται και σε πολύ μεγαλύτερα datasets με το mapreduce (δειτε hadoop - μπορείτε να παίξετε μαζί του σχεδόν τζάμπα με Amazon Web Services).

 

Αυτή είναι η πολυπλοκότητα σήμερα... πώς να εκμεταλευτείς τους 4 πυρήνες και το κάθε CPU να χρειάζεται να δει τα δεδομένα σου Μόνο μία φορά. Αυτά που μαθαίναμε στο πανεπιστήμιο είναι πρακτικά άχρηστα αλλά είναι πολύ καλό που τα μάθαμε γιατί μας έκαναν να ξέρουμε το πρόβλημα... και να αναζητούμε συνεχώς την καλύτερη λύση (η οποία σήμερα είναι η παραπάνω).

 

Τώρα αν έχετε ένα κομμάτι κώδικα και θέλετε να το κάνετε γρήγορο... Αφήστε την C/C++ και τις γλώσσες και πιάστε το Valgrind και δείτε που είναι το πρόβλημα. Το πιθανότερο είναι ότι ΔΕΝ είναι εκεί που φαντάζεστε. Δείτε και καταλάβετε καλά τον Amdahl's law http://en.wikipedia.org/wiki/Amdahl%27s_law . Ακόμα κι αν επιταγχύνεις τον κώδικά σου 100000 φορές μπορεί να έχεις συνολικά μόνο 1% επιτάχυνση του προγράμματός σου. Αυτός ο νόμος εξηγεί το γιατί.

 

Δείτε επίσης το parallel computation thesis.

 

http://en.wikipedia.org/wiki/Parallel_computation_thesis

 

Αυτό λέει ότι ο βαθμός στον οποίο μπορεί κάτι να γίνει παράλληλο είναι σε αναλογία (χοντρικά) με τη μνήμη που χρειάζεται το πρόγραμμα.

 

Γι'αυτό τον λόγο αν στο μέλλον θέλεις να γράφεις πολύ γρήγορα κώδικα καλά θα κάνεις να μάθεις και να καταλάβεις functional γλώσσες προγραμματισμού π.χ. Erlang γιατί οι functional γλώσσες έχουν παραδοσιακά ελάχιστο state = είναι σχεδόν trivial να τις παραλληλήσεις (όχι πάντα).

 

Αυτά για την ταχύτητα. Ελπιζω να συμφωνείτε πλέον μαζί μου ότι ΔΕΝ ΞΕΡΕΤΕ ΤΟΝ ΧΡΙΣΤΟ ΣΑΣ!

 

Ούτε εγώ ξέρω! Όταν έχω ένα κομμάτι κώδικα και ΑΝ (όπως είπε και ο φίλος - που είναι πολύ σωστός - PanosJee παραπάνω, σπάνια) το πρόβλημα είναι ότι είναι αργός τότε πρέπει να ανοίξεις τον profiler, να δεις τι φταίει, να δεις αν αξίζει να κάνεις κάτι (Amdahl's law) και μόνο τότε να δώσεις κάποιον χρόνο να το βελτιώσεις.

 

Τέλος καταλάβετε ότι η Python ή κάθε High Level Language είναι πολύ πιό γρήγορη (performance & productivity)

 

... για μεγάλα datasets και κάτω από time/budget constraints (=στην πραγματικότητα), ΓΙΑΤΙ σε αφήνουν να εστιάσεις στα πραγματικά προβλήματα (που είπαμε παραπάνω - πώς να παραλληλήσεις) από τον να κυνηγάς pointers και memory leaks.

 

Επίσης να ξέρετε ότι στη C/C++ όταν γράφεις π.χ.

 

>taks(void*a) {
 myclass * b = (myclass *)a;
 b->whatever();
 (double*)(a+2512) = 433.6;
}

 

... και όλη αυτή τη βρωμιά των casts κ.τ.λ. ο compiler σου τα παίζει και δεν μπορεί να κάνει τίποτα optimize. Ουσιαστικά αν έγραφες Java και επειδή στις λίγο πιό πολιτισμένες από την C γλώσσες δεν παίζεις με τη μνήμη κατευθείαν, ο compiler μπορεί να κάνει αρκετά καλύτερο optimization. Π.χ. μπορεί να δει μία HLL ότι από την κλάση σου δε χρησιμοποιείς 6 πεδία = 24bytes λιγότερα κάθε κλάση = στα 100M αντικείμενα 2Gb λιγότερο bandwidth/πέρασμα = μπορεί (πολύ ακραία) και 2-πλάσια ταχύτητα; Στην C δεν θα μπορούσε να δει ότι δεν χρησιμοποιείς 6 πεδία γιατί μπορεί να έχεις κάποιον ηλίθιο pointer που τα χρησιμοποιεί με κάποιον βρώμικο τρόπο.

 

Τώρα να σου πω την αλήθεια μου, κι επειδή με παρέμπεψες σε C++ για όμορφο κώδικα, προσωπικά δεν βλέπω κάποια ουσιαστική διαφορά σε ομορφιά μεταξύ

 

Αυτό δεν μ'αρέσει:

 

str_delete( s );

 

Από αυτό...

 

>int main( void )
{
 string str ("Test string");

 cout << "The size of str is " << str.size() << " bytes.\n";
 cout << "The length of str is " << str.length() << " bytes.\n";

 return 0;
}

 

 

σε αυτό...

 

>int main( void )
{
       String *s = str_new("Test string");

       printf("The size of str is %lld bytes\n", s->size );
       printf("The length of str is %lld bytes\n", s->length );

       str_delete( s );
       return 0;
}

 

Η διαφορά είναι μεταξύ σε κάποιον που μπαίνει μέσα (α) και σε κάποιον που έχει 9 δάνεια και ετοιμάζεται να πάει φυλακή (β).

 

Καμία σχέση πάντως με:

 

>>>> s="Test String"
>>> "The size of str is %d bytes\n" % len(s)

 

(που μπορεί να βγάλει και κάποια χρήματα)

 

Το να πρέπει να μαζεύεις τα σκουπίδια σου είναι απίστευτο overhead σε μεγάλα projects και η C++ με πολύ υδρώτα και smart pointers το

ψιλό-λύνει. Η C δεν μπορεί να το κάνει αυτό - τελεία και παύλα.

 

Τώρα αυτά για την ταχύτητα είναι αστειότητες, δε σου χρειαστεί πότε η ταχύτητα της C αλλά θες ταχύτητα στο development και να λύνεις γρήγορα και αποτελεσματικά τα προβλήματα που θες. Αν θες ταχύτητα τότε δες τη Cython και PyPy

 

Πέστα χρυσόστομε

 

Το μονο αντιληπτο αναμεσα σε LL και HL ειναι το startup με το δευτερο να θελει 0.1 ~ 2sec για να παρει μπρος ο interpreter

 

Ακριβώς και γι'αυτό συνήθως τα βάζουμε ώς service ώστε να μη χρειάζεται να κάνουν ούτε startup!

 

η python δεν ειναι η καλυτερη για να μορφωθει καποιος αλγοριθμικα κλπ, γιατι εχει πολυ ετοιμο πραγμα.

 

Μεγάλη αλήθεια. Μπορεί να έχεις ανθρώπους που μπορούν να κάνουν τρελά πράγματα αλλά δεν ξέρουν τίποτα με την python.

 

Πάντως για εμένα είναι πάρα πολύ μεγάλη επιτυχία το συγκεκριμένο thread - γιατί το να βάζεις δίπλα δίπλα και να συγκρίνεις C/C++ με python στην Ελλάδα και να μην έχεις φάει τρελό χαστούκι είναι ένα μεγάλο επίτευγμα. Για εμένα σημαίνει ότι πάμε πολύ καλά και τουλάχιστον μερικές 10-αδες άτομα θα αποφασίσουν να δοκιμάσουν την python και άλλες τρελές γλώσσες και θα μπορούν να επιλέξουν με βάση τη γνώση και όχι την άγνοια και τον φόβο.

 

P.S. Αν γράφετε παιχνίδια ή ρομποτικά ή high frequency trading κ.τ.λ. μάθετε C/C++.

[παπι]

Ρε παιδιά ακόμα όλοι γράφετε πώς θα έχετε τον πιο γρήγορο κώδικα λες και μετράμε ποιος την έχει μακρύτερη. Ναι σε μερικές περιπτώσεις είναι το ζητούμενο αλλά σπάνια.

 

Αγορι μου, δοκιμες κανω. Δεν εφτιαξα τιποτα. χρησιμοποιησα κατι ετοιμο σε διαφορετικες γλωσσες/πλατφορμες.

 

@neverlastn Αν δε κανω λαθος, η l1 ειναι instruction cache

 

 

 

[migf1]

Παιδιά να σας πω ένα μυστικό...

 

ΔΕΝ ΕΧΕΤΕ ΙΔΕΑ τι είναι πιο γρήγορο...

 

Μα το θεό - ΔΕΝ ΞΕΡΕΤΕ ΤΟΝ ΧΡΙΣΤΟ ΣΑΣ!

 

Και μη το πάρετε προσωπικά... Μπορώ να σας υπογράψω ότι ΔΕΝ ΞΕΡΕΤΕ ΤΟΝ ΧΡΙΣΤΟ ΣΑΣ!

 

 

Ο λόγος είναι ότι τα πράγματα αλλάζουν σχεδόν κάθε 2 χρόνια ή πιό σύντομα. Οι *** που διδάσκουν στο πανεπιστήμιο (πολυπλοκότητες κ.τ.λ.) είναι για παιδιά - τελείως θεωρητικές. Για να μπορείς να βγάλεις συμπεράσματα με βάση αυτές και να εκτιμήσεις σωστά θα πρέπει να ξέρεις αρκετά καλά το hardware σου και τα όριά του.

 

Καταρχήν το big O notation θεωρεί constant τα I/O και πάρα πολύ καλά κάνει γιατί έτσι πρέπει να κάνει! Το I/O optimization, caching, κλπ είναι άλλα fields (που επίσης είναι πολύ χρήσιμο να γνωρίζει κανείς). Και ναι μεν όντως δεν ξέρουμε τον Χριστό μας, γιατί υπεισέρχονται πολλοί αστάθμητοι παράγοντες, ξέρουμε όμως πως βελτιστοποιώντας επί μέρους τμήματα επωφελείται το σύνολο!

 

QuickSort και BubbleSort εχουν ΤΗΝ ΙΔΙΑ πολυπλοκότητα = σκατά

Ποιος τα λέει αυτά;;;;; Που τα είδες αυτά γραμμένα;;;;;;;;; Θα μας τρελάνεις τελείως φίλε never;;;;;;;;;;;;

Μη λες τέτοια πράγματα γιατί το φόρουμ το διαβάζουν και παιδιά που δεν έχουν ασχοληθεί και μπορεί και να νομίζουν ότι ξέρεις τι γράφεις

 

>
Bubble sort:
Worst case performance		O(n2)
Best case performance		O(n)
Average case performance 	O(n2)

Quick Sort:
Worst case performance		O(n2)
Best case performance		O(n log n)
Average case performance 	O(n log n)

Σου φαίνεται πολύ... ίδια η πολυπλοκότητα των 2 αλγορίθμων;

 

Η μόνη sort που είναι πιό efficient από αυτές (και η μόνη ουσιαστικά βιώσημη σήμερα) είναι η MergeSort (!!)

 

Α... και αν θέλετε ακόμα πιό γρηγόρα B+ δέντρα... δυστυχώς.

Αλήθεια τώρα, έχεις καθόλου ιδέα από πολυπλοκότητες και αλγόριθμους ή γράφεις ότι νά 'ναι έτσι απλά για να γράψεις κάτι;

 

Η μόνη sort λοιπόν που είναι η πιο efficient ΑΠΟ ΟΛΕΣ είναι αυτή που ανάλογα με την περίσταση και την τρέχουσα κατάσταση των δεδομένων που έχει να σορτάρει ΕΠΙΛΕΓΕΙ τον κατάλληλο αλγόριθμο (περίπου ότι κάνει λίγο-πολύ και η FFTw που ανάφερε ο timon).

 

Όπως με τις γλώσσες έτσι και με το σορτινγκ (και τους αλγόριθμους γενικότερα) κανένα δεν είναι πανάκεια. Για αυτό και οι πολυπλοκότητες όχι μόνο αναφέρονται σε Best, Average και Worst cases, αλλά αναλύουν λεπτομερώς πως και γιατί για την κάθε μια από αυτές τις περιπτώσεις ώστε να ξέρεις π.χ. ότι αν τα δεδομένα σου είναι ήδη σχεδόν σορταρισμένα η quick sort είναι για τα μπάζα!

 

--- Ελπίζω να σας κέντρισα το ενδιαφέρον και να σας τσάντισα αρκετά ώστε να διαβάσετε και λίγο παρακάτω...

Μπα, εγώ λέω να μην πάω παρακάτω... πάω να φτιάξω κάνα καφεδάκι και να σκουπίσω τα μαλλιά που μου έπεσαν με αυτά που διάβασα μέχρι εδώ

 

Οκ αστειεύομαι, τα διάβασα και τα παρακάτω. Το θέμα είναι πως πάνω που πας να το στρώσεις, στο καπάκι αρχίζεις πάλι κάτι άσχετα και ξανά μανά

 

π.χ.

 

Το να πρέπει να μαζεύεις τα σκουπίδια σου είναι απίστευτο overhead σε μεγάλα projects και η C++ με πολύ υδρώτα και smart pointers το

ψιλό-λύνει. Η C δεν μπορεί να το κάνει αυτό - τελεία και παύλα.

Είσαι πολύ σίγουρος ότι δεν μπορεί;

Τελεία, και, παύλα

 

Λοιπόν για να μη το κουράζουμε άλλο, και να μην παραπληροφορούμε και τον κόσμο, δεν υπάρχει κάτι που μπορεί να γίνει με οποιαδήποτε άλλη γλώσσα και να μην μπορεί να το κάνει η C (με εξαίρεση την assembly). Και κατά κανόνα το εκτελεί ταχύτερα. Sad (for some) but true (for all). Δεν την ονομάζουν Super Assembly για πλάκα!

 

Το βασικό της πρόβλημα για κάποιον που ξεκινάει είναι η "easy to learn, hard to master" φύση της και φυσικά η αντι-παραγωγικότητα της με τις στάνταρ βιβλιοθήκες (κάτι που αμβλύνεται σε πολύ μεγάλο βαθμό για όσους ξέρουν και χρησιμοποιούν δημοφιλείς άλλες βιβλιοθήκες).

 

Όσο για την Python, παρόλο που δεν τη ξέρω (πολύ πρόσφατα έβαλα Python 3 για να δω τι παίζει και έχω ήδη εντυπωσιαστεί με την παραγωγικότητα και την σφαιρικότητά της) είναι η γλώσσα που πρότεινα στον topic starter για ξεκίνημα, από την 1η κιόλας σελίδα του νήματος!

 

Το σημαντικό που πρέπει να μείνει σαν κεντρική ιδέα από το νήμα αυτό, πάντα κατά την άποψή μου, είναι πως καμία γλώσσα δεν ικανοποιεί όλες τις ανάγκες, και το ιδανικό για ένα μεσαίο-μεγάλο project είναι το να γράφεται επί μέρους σε περισσότερες της μιας γλώσσες, ανάλογα τα ατού της κάθε γλώσσας.

 

ΥΓ. Μια φιλική συμβουλή, αν βέβαια μου επιτρέπεις: μη κρίνεις εξ ιδίων τα αλλότρια

Επεξ/σία 1 Σεπτεμβρίου 2011 από migf1

[adamco]

H python ειναι μια φανταστικη γλωσσα (οχι τοσο φανταστικη οσο η LISP ), ομορφη, πρακτικη, ευκολη, κατανοητη ...

 

LISP να μάθω; Μου φαίνεται ότι η Scheme είναι πιο καλή!

[neverlastn]

Το σημαντικό που πρέπει να μείνει σαν κεντρική ιδέα από το νήμα αυτό, πάντα κατά την άποψή μου, είναι πως καμία γλώσσα δεν ικανοποιεί όλες τις ανάγκες, και το ιδανικό για ένα μεσαιό-μεγάλο project είναι το να γράφεται επί μέρους σε περισσότερες της μιας γλώσσες, ανάλογα τα ατού της κάθε γλώσσας.

 

Συμφωνώ απόλυτα!!

 

Ξέρουμε όμως πως βελτιστοποιώντας επί μέρους τμήματα επωφελείται το σύνολο!

Μπααα... ούτε στο παρελθόν αλλά ούτε και στο όλο πιό παράλληλο παρόν... απλά κάνεις exhaust τη μνήμη γενικά μιλόντας. Σε γενικές γραμμές θέλεις να κάνεις optimize το σύστημα (και όχι τις βαθμίδες) για maximum throughput/minimum latency (εξαρτάται από τις πρωτεραιότητες). Optimal υποτμήματα εξασφαλίζουν βέλτιστο σύστημα αλλά ουσιαστικά το ίδιο αποτέλεσμα θα είχες αν έκανες optimize ΜΟΝΟ τα τμήματα που βρίσκονται στο "critical path". Για όλα τα υπόλοιπα απλά χαραμίζεις τουλάχιστον τον χρόνο σου (και κινδυνεύεις όπως είπα να ξεμείνεις από buffers/μνήμη). (Amdahl's law + theory of constraints)

 

Ποιος τα λέει αυτά;;;;; Που τα είδες αυτά γραμμένα;;;;;;;;; Θα μας τρελάνεις τελείως φίλε never;;;;;;;;;;;;

Σου φαίνεται πολύ... ίδια η πολυπλοκότητα των 2 αλγορίθμων;

Μη λες τέτοια πράγματα γιατί το φόρουμ το διαβάζουν και παιδιά που δεν έχουν ασχοληθεί και μπορεί και να νομίζουν ότι ξέρεις τι γράφεις

 

Βρε migf1... το πρόβλημα είναι ότι ξέρω τι λες... και αυτό που λες έχει περάσει εδώ και τουλάχιστον 6-7 χρόνια - sorry. Είναι απόλυτα ίδια η πολ/α των δύο αλγορίθμων και όπως είπα στο προηγούμενο post Ο(bublesort)=O(quicksort)=σκατά! Δεν κάνουμε sort 1kb πλέον, νομίζω ότι το ξέρεις, έτσι δεν είναι; Επίσης νομίζω ότι το ξέρεις ότι πλέον έχεις 4 επεξεργαστές + ένα cluster στο Amazon και πρέπει να κάνεις sort συνήθως GB's έτσι δεν είναι; Τα παιδιά που δεν έχουν ασχοληθεί και διαβάζουν αυτό το post τώρα πρέπει να ξέρουν τι παίζει σήμερα και όχι στο 2001.

 

Ας το εξηγήσω μία στιγμή... Όταν έχεις να κάνεις sort 100Gb, είτε quicksort χρησιμοποιήσεις είτε bubblesort... θα πάρει αιώνες. Κοινώς μη αποδεχτό χρόνο. Καλώς; Ο λόγος δεν είναι το CPU δηλαδή και 1THz CPU να είχες και πάλι θα έπαιρνε αιώνες λόγω πολυπλοκότητας+μέγεθους dataset. Τα O(whatever) είναι άχρηστα σε μεγάλο βαθμό γιατί μιλάνε για τους πόσες επαναλήψεις θα πάρει στο CPU ενώ εμείς το ρεαλιστικό metric που θέλουμε είναι πόσο localy δουλεύει στα δεδομένα γιατί το αργό δεν είναι να επεξεργαστείς τα δεδομένα, αλλά να τα φέρεις είτε από το net, είτε από τον δίσκο. Το μόνο λοιπόν που μπορείς να κάνεις είναι mergesort. Στο "sort" χρησιμοποίησε ότι θέλεις - bubblesort, quicksort... οτιδήποτε έχει το μικρότερο O ... δεν είναι και πολύ σημαντικό. Το σημαντικό είναι να κάνεις ένα efficient "merge" το οποίο στην περίπτωση του προβλήματος της ταξινόμησης είναι ψιλό-trivial όπως και σε πολλά άλλα προβλήματα αλλά όχι πάντα. External sorting λοιπόν και mergesort πρέπει να καταλάβει κανείς αν θέλει να είναι στη σωστή κατεύθυνση για να κάνει efficient υπολογισμούς το 2011. Αυτό πιό γενικά ονομάζεται Map-Reduce. Εκεί λοιπόν παίζει η ταχύτητα του αλγορίθμου σου σήμερα και όχι στα O's. Νομίζεις ότι θα μπορούσες να συμφωνήσεις σε αυτό ή όχι;

 

Οκ αστειεύομαι, τα διάβασα και τα παρακάτω. Το θέμα είναι πως πάνω που πας να το στρώσεις, στο καπάκι αρχίζεις πάλι κάτι άσχετα και ξανά μανά

 

 

Είσαι πολύ σίγουρος ότι δεν μπορεί;

 

Ναι είμαι πάρα πολύ σίγουρος, βασικά είναι πρόβλημα της γλώσσας (συνδυασμός έλειψης destructors + ότι μπορείς να έχεις κατευθείαν πρόσβαση στη μνήμη). Αν δεν έχεις destructors που καλούνται αυτόματα στο τέλος του scope δεν μπορεί να γίνει αυτόματη απελευθέρωση μνήμης και πρέπει να βάλεις τις δικές σου συναρτησούλες για να πεις - ξέρεις μεταβλητούλα δε σε χρειάζομαι άλλο - το οποίο είναι πολύ κακό α) γιατί οι άνθρωποι πάντα θα το ξεχνάνε (memory leaks) και β) γιατί οι άνθρωποι θα το βάζουν ενώ υπάρχουν ακόμα references στην μεταβλητή (seg. faults). Αυτό το πρόβλημα δε λύνεται στην C αλλά στην C++ και under conditions (νομίζω ότι υπήρχε ένας πολύ κάφρικος, ugly και system specific way να λυθεί και στη C αλλά δε θυμάμαι πλέον).

 

Κατάλαβα που έγινε η "παρεξήγηση". Όταν έλεγα να "μαζεύεις τα σκουπίδια σου" δεν εννοούσα συγκεκριμένα garbage collection αλλά αυτοματοποιημένο memory management γενικότερα.

 

@neverlastn Αν δε κανω λαθος, η l1 ειναι instruction cache

 

Αυτό εξαρτάται σε μεγάλο βαθμό από την αρχιτεκτονική. Στη λεγόμενη Harvard architecture (χρησιμοποιείτε κυρίως σε DSP's) μπορεί να υπάρχουν δύο L1 caches η Data και η Instruction. Στα περισσότερα general purpose συστήματα οι δύο cache's είναι μία που παρέχει τόσο Instructions όσο και Data. Σε γενικές γραμμές η L1 είναι μικρή (μερικά kb) και είναι κοντά στον επεξεργαστή (πάνω στο ίδιο chip).