C or Python?

[otommod]

Μιας και άλλαξε λίγο το θέμα της συζήτησης θα ήθελα να προσθέσω κάτι.

http://www.youtube.com/watch?v=k6U-i4gXkLM&feature=BFa&list=SP4C4720A6F225E074

Νομίζω βοηθάει να μάθεις γενικά για τον προγραματισμό, και χρησιμοποιεί σαν παράδειγμα την Python. Αυτό είναι το πρώτο, και συνολικά είναι 24.

Tώρα άρχισα να τα βλέπω και εγώ.

Υ.Γ Πώς βάζουμε βίντεο;

[neverlastn]

Κι αυτό είναι πολύ καλό και το'χει γράψει ένας Έλληνας: "Learn Python in Ten Minutes" by Stavros Korokithakis

 

http://leanpub.com/learn-python

 

Το tutorial είναι και δωρεάν στο blog του: http://www.korokithakis.net/tutorials/python/

 

Υ.Γ Πώς βάζουμε βίντεο;

 

Το κουμπάκι "Εισαγωγή media" - τελευταίο στην λίστα

 

http://www.youtube.com/watch?v=k6U-i4gXkLM

[migf1]

...

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

 

Βρε 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. Νομίζεις ότι θα μπορούσες να συμφωνήσεις σε αυτό ή όχι;

Σαφώς και όχι! Κι ο λόγος είναι πως μου τα γυρίζεις κατά το δοκούν!

 

Για παράδειγμα, μου μιλάς για Αmazon clusters και παράλληλη επεξεργασία εκατοντάδων Gb κι εγώ σε ρωτάω το εξής απλό: Εν έτη 2011 υπάρχει ή δεν υπάρχει σε τεράστια και ολοένα αυξανόμενη άνθηση (με εκατομμύρια εκατομμυρίων σε επενδύσεις και κέρδη) embedded programming? Υπάρχει! Τι πρέπει τώρα να κάνω εγώ, να αποκλείσω όλους τους υπόλοιπους τομείς της πληροφορικής, να ισχυρίζομαι πως το μέλλον είναι το embedded programming και να αρχίζω να επιχειρηματολογώ για γενικά θέματα, έχοντας όμως ως σημείο αναφοράς το embedded programming και να απαξιώνω όλους τους υπόλοιπους τομείς χαρακτηρίζοντάς τους άμεσα ή έμμεσα ως είτε πεθαμένους είτε ανύπαρκτους είτε αμελητέους? (btw, ξέρεις πόσα "μέλλοντα" έχω δει να μην γίνονται καν "παρόντα" στα περίπου 25 τελευταία χρόνια που ασχολούμαι με το... άθλημα, ουουουουουουουουου! )

 

Σου έγραψα και στο προηγούμενο ποστ "μη κρίνεις εξ ιδίων τα αλλότρια". Σε προηγούμενα πόστς (αυτού του νήματος νομίζω) σου είχαμε ξαναπεί πάλι κάτι παρόμοιο κι εγώ κι ο Erevis (εξαρτάται από το τι δουλειά θες να κάνεις, εξαρτάται αν οι στόχοι σου περιορίζονται στην εγχώρια αγορά ή και στη διεθνή, κλπ). Προφανώς ότι σου το είπαμε δεν σημαίνει πως πρέπει να το αποδεχτείς, επειδή όμως τα φόρουμ τα διαβάζει πάρα πολύς κόσμος που μεταξύ άλλων ψάχνει να ενημερωθεί προκειμένου να αποφασίσει, προσωπικά το θεωρώ σημαντικό να είμαστε όσο μπορούμε πιο προσεκτικοί σε αυτά που προτείνουμε.

 

Έστω λοιπόν πως ότι είχες να κάνεις με τα υποσυστήματα το έχεις κάνει κι έχεις στη μνήμη π.χ. 2Gb δεδομένων έτοιμα προς επεξεργασία (είτε είναι sorting, είτε είναι parsing, είτε είναι searching, είτε είναι λεξικογραφική ανάλυση, είτε είναι μαθηματικοί υπολογισμοί, είτε βάλε οτιδήποτε άλλο θέλεις εδώ, απλό ή πολύπλοκο). Ας μείνουμε στο sorting όμως αφού για αυτό μιλάμε τώρα, λες λοιπόν σε αυτούς που διαβάζουν το φόρουμ ότι είναι αμελητέο με το ποιον αλγόριθμο (και ποια data structures προσθέτω εγώ) θα τα ταξινομήσουν. Το ότι π.χ. με τον έναν αλγόριθμο θα ταξινομηθούν σε 10 λεπτά και με τον άλλον σε 35 για σένα είναι το ίδιο πράγμα! Ή το ότι ο αλγόριθμος που τα ταξινομεί σε 10 λεπτά αν τα φορτωμένα δεδομένα βρίσκονται σε κάποια Α ή Β κατάσταση ο ίδιος αλγόριθμος αντί για 10 λεπτά θα κάνει 35 είναι και πάλι αμελητέο.

 

Σορρυ, αλλά τέτοιους είδους λογικές & πρακτικές προσωπικά όχι μόνο δεν τις ασπάζομαι αλλά τις κυνηγάω κιόλας, δια ροπάλου μάλιστα!

 

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

 

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

Πάλι μου τα γυρίζεις! Το σίγουρο είναι ένα πάντως, πως αν ξέρεις και κάνεις μονάχος σου διαχείριση μνήμης, το πρόγραμμά σου θα είναι κατά κανόνα πιο efficient από οποιοδήποτε general automated management library.

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

[neverlastn]

Το σίγουρο είναι ένα πάντως, πως αν ξέρεις και κάνεις μονάχος σου διαχείριση μνήμης, το πρόγραμμά σου θα είναι κατά κανόνα πιο efficient από οποιοδήποτε general automated management library.

 

Ναι, αλλά δεν έχεις το χρόνο να το κάνεις αυτό manually, ειδικά όσο αυξάνονται οι χιλιάδες γραμμές κώδικα που διαχειρίζεσαι γιατί η πολυπλοκότητα του προβλήματος αυξάνει εκθετικά.

 

Ή το ότι ο αλγόριθμος που τα ταξινομεί σε 10 λεπτά αν τα φορτωμένα δεδομένα βρίσκονται σε κάποια Α ή Β κατάσταση ο ίδιος αλγόριθμος αντί για 10 λεπτά θα κάνει 35 είναι και πάλι αμελητέο. Σορρυ, αλλά τέτοιους είδους λογικές & πρακτικές προσωπικά όχι μόνο δεν τις ασπάζομαι αλλά τις κυνηγάω κιόλας, δια ροπάλου μάλιστα!

 

Ναι. 10 και 35 λεπτά είναι το ίδιο. Πάρα πάρα πάρα πολλά για κάθε πρακτική χρήση!! Κι εγώ μαζί σου είμαι... τις πρακτικές που λές τις κυνηγάω δια ροπάλου - μόνο που αυτή τη φορά η κακή πρακτική είναι αυτή που προτείνεις. Κάθεσαι και προσπαθείς να μάθεις στα παιδάκια πώς να σώζουν 10 κύκλους ρολογιού σε ένα CPU που έχει "καρφωθεί" στα 2.2GHz και δεν τους μαθαίνεις πώς να γράφουν για την πραγματικότητα, τα 4,8 και 16 cores και τα web services. Ακαδημαϊκά καλά κάνεις. Πρακτικά αυτή η νοοτροπία μπορεί να καταστρέψει μία γενιά Ελλήνων προγραμματιστών που μέσα από το σχολείο και τις συμβουλές σου θα τρώει βδομάδες να κάνει τα 35 λεπτά 10 (και να γράψει ένα paper) ενώ ο Αμερικάνος θα κάνει το ίδιο πράγμα σε 2 δευτερόλεπτα.

 

Επίσης για άλλη μία φορά disclaimer ΜΕΓΑΛΟ για όποιον πάει να πειράξει οτιδήποτε performance orriented:

 

Καταλάβετε τον Amdahl's law

 

Αν είσαι Ινδός και γράφεις σκατά κώδικα, μετά το πρώτο draft θα κάνεις profiling και θα δείς:

 

>Function A 70%
Function B 20%
Function C  5%
Rest       ...

 

Σε αυτή τη περίπτωση είσαι μία χαρά!! Μπορείς να κάνεις αυτό που λέει ο migf1. Πέσε με τα μούτρα στην Function A και κάν'την 100 φορές πιό γρήγορη.

 

Αν όμως είσαι Έλληνας ή Ρώσος και εξ'ορισμού γράφεις "σφιχτό" κώδικα... τότε μετά το profiling θα δείς:

 

>Function A 17%
Function B 14%
Function C  9%
Rest       ...

 

Σε αυτή τη περίπτωση αυτό που λέει ο migf1 δεν θα σου δώσει τίποτα και γενικότερα είναι ελάχιστα που μπορείς να κάνεις για να βελτιώσεις το performance αυτού του προγράμματος. Ο λόγος είναι... Amdahl's law!! Αν βελτιώσεις 100000% την συνάρτηση A με πολύ κόπο μόχθο και υδρώτα ξοδεύοντας βδομάδες το μόνο που θα πετύχεις είναι 17% βελτίωση στο πρόγραμμά σου... και μόλις το κάνεις αυτό και περάσεις στη Β πας για άλλο 14%. Αυτό ούτε Bonus θα σου δώσει ούτε το βραβείο Nobel. Μάλλον θα σου δώσει όμως ένα [κουτί] για να μαζέψεις τα πράγματα και να πας σε άλλη εταιρεία/εργαστήριο, whatever!

 

Το μόνο λοιπόν που μπορείς να κάνεις στη περίπτωση β) που λέω παραπάνω είναι είτε κάποιο πολύ δυνατό στρατηγικό refactoring all-over the place είτε να δεις πώς μπορείς να παραλληλήσεις τον αλγόριθμο για να εκμεταλλεύεται όλα τα CPUs είτε να κάνεις "outsource" τον αλγόριθμο σε κάποιο web-service έτσι ώστε να εκμεταλεύεσαι το γεγονός ότι πολλοί χρήστες μπορεί να τον έχουν εφραμόσει στο ίδιο dataset και συνεπώς μπορεί να είναι σε κάποια cache.

 

embedded programming

 

Ναι/όχι! Embedded programming είναι πάρα πολύ μικρή αγορά. Mobile programming ναι - αλλά και πάλι αυτή τη στιγμή τα κινητά είναι σχετικά thin clients και πάντα χτυπάνε κάποιο server. Παρόλα αυτά λόγω ζωής μπαταρίας και ότι η κατανάλωση πάει με το τετράγωνο της τάσης δεν μπορούν να ανεβάσουν τη συχνότητα και εκεί - το μόνο που μπορούν να κάνουν είναι να πάνε σε πολλαπλούς επεξεργαστές (για άλλη μιά φορά). Επίσης εκεί το data locality είναι ακόμα πιό σημαντικό μιας και οι caches είναι ακόμα μικρότερες και οι δίαυλοι λιγότερο αποδοτικοί.

 

Υ.Γ. Data locality = Αν ένας αλγόριθμος χτυπάει σε ένα array με τη σειρά τα a[0], a[1], a[51], a[1045], a[3], a[12], a[15004] = ΠΟΛΥ ΚΑΚΟ, αν ένας αλγόριθμος χτυπάει a[0], a[1], a[1], a[2], a[3], a[4] ... a[1000], a[1001], a[1000], a[1001] = ΠΑΡΑ ΠΟΛΥ ΚΑΛΟ! (Ακόμα κι αν η πολ/τα του 2ου αλγορίθμου είναι χειρότερη θα έχει πολύ λιγότερα cache line misses και μπορεί να είναι σημαντικά πιό γρήγορος). Και πάλι ο profiler έχει την τελευταία λέξη.

 

OK guys, για να το αμβλύνω λιγάκι γιατί καταντάει βαρετό.

 

Ναι, υπάρχει η πολυπλοκότητα και ναι μετράει, και ναί, το quicksort είναι κατά μέσο όρο πιό γρήγορο και ναί, αν τα δεδομένα σου έχουν συγκεκριμένα στατιστικά χαρακτηριστικά μπορείς να το εκμεταλευτείς για να επιλέξεις τον κατάλληλο αλγόριθμο που θα είναι ο πιό γρήγορος.

 

Παρόλα αυτά, σε αυτά τα προβλήματα θα συνιστούσα να μπείτε αφότου έχετε βάλει όλες τις caches σας ώστε να μην κάνετε διπλό δουλειά, αφότου έχετε εξετάσει αν είναι trivialy παραλληλισμο, αφότου έχετε δει από τον Amdhal's law ότι μπορείτε να το βελτιώσετε σημαντικά και αφότου έχετε επιβεβαιώσει με τους managers/supervisors σας ότι το να γίνει X% πιό γρήγορο κάνει justify τον μισθό σας για τον χρόνο που θα σας πάρει.

 

Οι ακαδημαϊκοι σας ετοιμάζουν για να γράφετε λειτουργικά συστήματα και άλλα ενδιαφέροντα και sexy πράγματα. Δυστυχώς όμως η πραγματικότητα είναι ότι οι περισσότεροι από εσάς αυτό που θα γράφετε είναι application code και η λύση στο ότι κάτι είναι αργό συνήθως θα είναι "ok-θα αγοράσουμε την enterprise licence" ή "ok-κάνε upgrade στην καινούρια έκδοση της βιβλιοθήκης που είναι 1.8x πιό γρήγορη". Σε κάποιες περιπτώσεις η λύση στο ότι το πρόγραμμα είναι αργό θα είναι "μην ανησυχείς - θα τους δώσουμε 2 μήνες iTunes δωρεάν συνδρομή - θα το αγοράσουν ούτως ή άλλως".

 

Τώρα για python, java, C/C++ όλες οι γλώσσες ειναι χρήσιμες και είναι καλό να ξέρεις πολλές ώστε να χρησιμοποιείς τη πιό κατάλληλη κάθε στιγμή. Κατά κανόνα κάθε νεότερη γλώσσα είναι ΠΙΟ ΕΥΚΟΛΗ από τις προηγούμενες αλλιώς δεν θα γινόταν αποδεχτή. Παρόλα αυτά γύρω από κάθε νεότερη γλώσσα υπάρχει ο ΦΟΒΟΣ του αγνώστου. Προσπαθείστε να ξεπεράσετε αυτόν τον φόβο. Η Python είναι πιό εύκολη από τη C++ και η C++ πιό εύκολη από assembly (χμμ... ίσως )

 

Δοκιμάστε καινούρια πράγματα!

 

Φιλιά πολλά,

neverlastn

[migf1]

Ναι, αλλά δεν έχεις το χρόνο να το κάνεις αυτό manually, ειδικά όσο αυξάνονται οι χιλιάδες γραμμές κώδικα που διαχειρίζεσαι γιατί η πολυπλοκότητα του προβλήματος αυξάνει εκθετικά.

Όταν δεν έχεις χρόνο, πας στην καλύτερη εναλλακτική που μπορείς για τον χρόνο που διαθέτεις. Το πρόβλημα είναι πως για να μπορείς να επιλέξεις εναλλακτικές πρέπει να τις ξέρεις αυτές κάθε αυτές, καθώς και τα εργαλεία που πρέπει να χρησιμοποιήσεις ή που να τα βρεις. Λογικές τύπου για ταξινόμηση χρησιμοποιώ αδιακρίτως quick-sort, για αναζήτηση χρησιμοποιώ αδιακρίτως binary-search, είναι λογικές τύπου "πονάει χέρι, κόψει κεφάλι"... και believe it or not υπάρχουν ΑΠΕΙΡΟΙ τομείς στην πληροφορική που τέτοιες λογικές προγραμματισμού θεωρούνται (και είναι) επαγγελματικά απαράδεκτες!

 

Ναι. 10 και 35 λεπτά είναι το ίδιο. Πάρα πάρα πάρα πολλά για κάθε πρακτική χρήση!! Κι εγώ μαζί σου είμαι... τις πρακτικές που λές τις κυνηγάω δια ροπάλου - μόνο που αυτή τη φορά η κακή πρακτική είναι αυτή που προτείνεις. Κάθεσαι και προσπαθείς να μάθεις στα παιδάκια πώς να σώζουν 10 κύκλους ρολογιού σε ένα CPU που έχει "καρφωθεί" στα 2.2GHz και δεν τους μαθαίνεις πώς να γράφουν για την πραγματικότητα, τα 4,8 και 16 cores και τα web services. Ακαδημαϊκά καλά κάνεις. Πρακτικά αυτή η νοοτροπία μπορεί να καταστρέψει μία γενιά Ελλήνων προγραμματιστών που μέσα από το σχολείο και τις συμβουλές σου θα τρώει βδομάδες να κάνει τα 35 λεπτά 10 (και να γράψει ένα paper) ενώ ο Αμερικάνος θα κάνει το ίδιο πράγμα σε 2 δευτερόλεπτα.

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

 

Επίσης για άλλη μία φορά disclaimer ΜΕΓΑΛΟ για όποιον πάει να πειράξει οτιδήποτε performance orriented:

 

Καταλάβετε τον Amdahl's law

 

Αν είσαι Ινδός και γράφεις σκατά κώδικα, μετά το πρώτο draft θα κάνεις profiling και θα δείς:

 

>Function A 70%
Function B 20%
Function C  5%
Rest       ...

...

Αν όμως είσαι Έλληνας ή Ρώσος και εξ'ορισμού γράφεις "σφιχτό" κώδικα... τότε μετά το profiling θα δείς:

 

>Function A 17%
Function B 14%
Function C  9%
Rest       

 

Σε αυτή τη περίπτωση αυτό που λέει ο migf1 δεν θα σου δώσει τίποτα και γενικότερα είναι ελάχιστα που μπορείς να κάνεις για να βελτιώσεις το performance αυτού του προγράμματος. Ο λόγος είναι... Amdahl's law!! Αν βελτιώσεις 100000% την συνάρτηση A με πολύ κόπο μόχθο και υδρώτα ξοδεύοντας βδομάδες το μόνο που θα πετύχεις είναι 17% βελτίωση στο πρόγραμμά σου... και μόλις το κάνεις αυτό και περάσεις στη Β πας για άλλο 14%. Αυτό ούτε Bonus θα σου δώσει ούτε το βραβείο Nobel. Μάλλον θα σου δώσει όμως ένα "κουτί" για να μαζέψεις τα πράγματα και να πας σε άλλη εταιρεία/εργαστήριο, whatever!

 

Το μόνο λοιπόν που μπορείς να κάνεις στη περίπτωση β) που λέω παραπάνω είναι είτε κάποιο πολύ δυνατό στρατηγικό refactoring all-over the place είτε να δεις πώς μπορείς να παραλληλήσεις τον αλγόριθμο για να εκμεταλλεύεται όλα τα CPUs είτε να κάνεις "outsource" τον αλγόριθμο σε κάποιο web-service έτσι ώστε να εκμεταλεύεσαι το γεγονός ότι πολλοί χρήστες μπορεί να τον έχουν εφραμόσει στο ίδιο dataset και συνεπώς μπορεί να είναι σε κάποια cache.

Όταν γράφεις χρησιμοποιώντας αδιακρίτως γενικούς μπούσουλες ο κώδικάς σου είναι έτσι κι αλλιώς σκατά. Και το καταλαβαίνεις στο πετσί σου the hard way αμέσως μόλις βγει στην αγορά το ανταγωνιστικό προς το δικό σου σου προϊόν, που κάνει τουλάχιστον ότι κάνει και το δικό σου, αλλά το κάνει σε 10 λεπτά αντί για 35 που κάνει το δικό σου. Θα έχεις επωφεληθεί εμπορικά σε short-run το διάστημα που μεσολαβεί μεταξύ του δικού σου launch-day και εκείνου, αλλά η mid και long run δυναμική του δικού σου προϊόντος αρχίζει να μετράει αρνητικά από την 1η κιόλας launch-day του ανταγωνιστικού προϊόντος (του οποίου η δυναμική προφανώς μετράει θετικά μέχρι να βγει 3ο ανταγωνιστικό προϊόν που θα κάνει τη δουλειά σε 5 λεπτά ή μέχρι να διορθώσεις εσύ το δικό σου).

 

Τις αποφάσεις για το αν το νωρίτερο launch-day αντισταθμίζει το product-deficiency ή αν συμφέρει καλύτερα να έχεις εξαρχής πιο efficient προϊόν με κόστος το αργότερο launch-day αλλά κέρδος την αποφυγή του revisiting cost μετά το launch-day του ανταγωνιστή (ή έστω την όσο το δυνατόν μεγαλύτερη επιμήκυνση του διαστήματος που θα μεσολαβήσει μέχρι να εμφανιστεί καλύτερο ανταγωνιστικό προϊόν), καλείσαι να τις πάρεις πριν ξεκινήσεις ή κατά τη διάρκεια του εκάστοτε project.

 

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

 

Όπως καταλαβαίνεις είναι άλλο πράγμα τις αποφάσεις και τα ρίσκα να τα παίρνεις συνειδητά & διαφορετικά ανά περίπτωση και άλλο πράγμα να χρησιμοποιείς αδιακρίτως γενικούς μπούσουλες σε όλα σου τα προϊόντα και ότι βρέξει ας κατεβάσει.

 

Ναι/όχι! Embedded programming είναι πάρα πολύ μικρή αγορά. Mobile programming ναι - αλλά και πάλι αυτή τη στιγμή τα κινητά...

http://en.wikipedia.org/wiki/Embedded_system#Variety_of_embedded_systems

 

OK guys, για να το αμβλύνω λιγάκι γιατί καταντάει βαρετό.

 

Ναι, υπάρχει η πολυπλοκότητα και ναι μετράει, και ναί, το quicksort είναι κατά μέσο όρο πιό γρήγορο και ναί, αν τα δεδομένα σου έχουν συγκεκριμένα στατιστικά χαρακτηριστικά μπορείς να το εκμεταλευτείς για να επιλέξεις τον κατάλληλο αλγόριθμο που θα είναι ο πιό γρήγορος.

 

Παρόλα αυτά, σε αυτά τα προβλήματα θα συνιστούσα να μπείτε αφότου έχετε βάλει όλες τις caches σας ώστε να μην κάνετε διπλό δουλειά, αφότου έχετε εξετάσει αν είναι trivialy παραλληλισμο, αφότου έχετε δει από τον Amdhal's law ότι μπορείτε να το βελτιώσετε σημαντικά και αφότου έχετε επιβεβαιώσει με τους managers/supervisors σας ότι το να γίνει X% πιό γρήγορο κάνει justify τον μισθό σας για τον χρόνο που θα σας πάρει.

 

Τώρα για python, java, C/C++ όλες οι γλώσσες ειναι χρήσιμες και είναι καλό να ξέρεις πολλές ώστε να χρησιμοποιείς τη πιό κατάλληλη κάθε στιγμή. Κατά κανόνα κάθε νεότερη γλώσσα είναι ΠΙΟ ΕΥΚΟΛΗ από τις προηγούμενες αλλιώς δεν θα γινόταν αποδεχτή. Παρόλα αυτά γύρω από κάθε νεότερη γλώσσα υπάρχει ο ΦΟΒΟΣ του αγνώστου. Προσπαθείστε να ξεπεράσετε αυτόν τον φόβο. Η Python είναι πιό εύκολη από τη C++ και η C++ πιό εύκολη από assembly (χμμ... ίσως )

 

Δοκιμάστε καινούρια πράγματα!

 

Φιλιά πολλά,

neverlastn

Επιτέλους, συμφωνούμε !!!!!

[neverlastn]

http://en.wikipedia.org/wiki/Embedded_system#Variety_of_embedded_systems

 

Gumstix, Mini-ITX = Embedded = καλύτερα απόφυγέ το

 

Android,iOS,Windows Mobile = Mobile = Αυτή η αγορά ανοίγει πολύ και είναι πολύ πιό εύκολη από την Embedded

 

Τώρα όταν στο Mini-ITX έτρεχα SuSE εγώ το έλεγα... μάλλον desktop

[migf1]

Το link το έβαλα επειδή έγραψες πως το embedded programming είναι πολύ μικρή αγορά. Και περισσότερο το έβαλα για να το δουν όσοι ψάχνουν να βρουν τι είναι αυτό το πράγμα και σε πόσους τομείς επεκτείνεται.

 

Στον μικρόκοσμο της Ελλάδας είναι πολύ μικρό (ανύπαρκτο είναι βασικά) σε διεθνή κλίμακα όμως είναι πολύ μεγάλο. Και ναι, ακόμα κι αυτό οδεύει με αργά βήματα κατά επιμέρους τομείς προς το web και τα hosted services, αλλά είναι τόσο μεγάλο το εύρος του που δεν υπάρχει περίπτωση να μπουν στο μουσείο any-time soon οι ανάγκες για dedicated εφαρμογές του.

 

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

 

Τα πάντα ρει

[neverlastn]

Το μόνο κακό όταν δούλευα σε embedded ήταν ότι φαινόταν πιό cool απ'ότι ήταν από μακρυά. Στο τέλος απλά ξόδευες απίστευτο χρόνο λόγο των περιορισμένων δυνατοτήτων debugging και του σχετικά περιορισμένου documentation (στα embedded μήν ξεχάσετε να διαβάσετε και να καταλάβετε το errata - θα σας σώσει χρόνο)

 

Anyway.

 

Αυτό που σκέφτηκα ότι θα βοηθήσει μιας και υπάρχει όλο αυτό το ενδιαφέρον στο thread, είναι να κάνω ΔΩΡΕΑΝ ένα insomnia exclusive εισαγωγικό webinar (45 λεπτά) στην python, scrappy, mongodb και cloud computing (AWS).

 

Αν σας ενδιαφέρει να παρακολουθήσετε (θα μπορούσαμε να το κάνουμε τη Κυριακή) please συμπληρώστε το παρακάτω survey για να ξέρω τι σας ενδιαφέρει...

 

http://www.surveymonkey.com/s/5QKCWD3

 

Αν δεν ενδιαφέρει αρκετούς (π.χ. λιγότερες από 15 συμμετοχές) το webinar δε θα γίνει (sorry)!

 

Υ.Γ. Αν το webinar γίνει θα το γράψουμε σε video ώστε να μπορείτε να το δείτε και μετά αλλά ο μόνος τρόπος να ρωτήσετε ότι δεν καταλαβαίνετε είναι να είστε εκεί live.

Υ.Γ.2 Ο εξοπλισμός που χρειάζεται για τη συμμετοχή είναι browsser με Java (και προαιρετικά μικρόφωνο)

Υ.Γ.3 Δεν είμαι expert στην Python, ούτε δάσκαλος ούτε τίποτα certified. Παρόλα αυτά πιστεύω ότι θα είναι ενδιαφέρον, χρήσιμο και fun!

[adamco]

Ρε παιδιά τι είναι αυτά που γράφετε;

Αν θέλουμε να κερδίσουμε κάποια χρήματα από προγραμματισμό πρέπει να κάνουμε προγράμματα σαν αυτό: http://www.multisoft.com.gr/apdoikodo.htm

Θα κοστίζει κανένα 200ευρω αν το αγοράσεις και για να το φτιάξεις χρειάζονται καλές γνώσεις λογιστικής και όχι γνώσεις πολυπλοκότητας των αλγορίθμων. Αυτά που λέτε εσείς είναι για projects της NASA, IBM, Digital κλπ. και όχι για παιδάκια που θέλουν να ασχοληθούν με τον προγραμματισμό.

 

Για προγράμματα εμπορικού τύπου όπως το παραπάνω η C/C++ είναι ιδανική για τους καλούς προγραμματιστές όπως ο Smirnov και o migf1. Η Rapid-Q για όσους θέλουν να γίνει η ίδια δουλειά αλλά με λιγότερη δυσκολία.

[Directx]

Για προγράμματα εμπορικού τύπου όπως το παραπάνω η C/C++[..]

Όπως το βλέπω από τις εικόνες παίζει να είναι γραμμένο σε Delphi (PASCAL) το οποίο και θεωρώ πιο πιθανό (η δεύτερη περίπτωση είναι σε C++ Builder αλλά συνήθως τέτοια soft τα γράφανε σε Delphi) - γενικά πάει 50/50 μεταξύ των δυο αυτών πακέτων (C++ Builder ή Delphi) αλλά συγκλίνω προς Delphi.

[παπι]

Ρε παιδιά τι είναι αυτά που γράφετε;

Hello! Εισαι σε Ελληνικο φορουμ! Αν διαβασεις ολα τα παρομοια νηματα θα δεις τις ιδιες υπερβολες.

 

@dx Δεν ξερω σε τι το εχει γραψει, παντο 100% δεν εχει φορτωσει το comctl

 

 

 

[Directx]

[..]@dx Δεν ξερω σε τι το εχει γραψει, παντο 100% δεν εχει φορτωσει το comctl

Σωστά (μιλάμε για ComCtl 6+) ή έχει κλείσει τα themes ...

[neverlastn]

Για όσους ένοιωσαν κάτι γαργαλιστικό και μία γερή δόση αλήθειας σε αυτά που έλεγα σε προηγούμενες απαντήσεις περί O() κ.τ.λ. βρήκα ένα καταπληκτικό βιβλίο που μιλάει μεταξύ των άλλων και για το ποιό είναι το πιο γρήγορο sort το 2009+ (κεφάλαιο 8). "The Art of Concurrency" λοιπόν... http://shop.oreilly.com/product/9780596521547.do

 

Επίσης ρίξτε μία ματιά στην ανάλυση του τυπά στο τέλος σε αυτό το post: http://www.mysqlperformanceblog.com/2007/08/18/how-fast-can-you-sort-data-with-mysql/ Όπως θα δείτε, ακόμα και π.χ. στη MySQL merge-sort με σωστά μεγέθη buffers είναι πιό γρήγορο από pure quicksort.

 

Cheers!

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

[provato]

Πλεονεκτήματα C

Μαθαίνοντας C, στο μέλλον θα μπορέσεις να μάθεις πιο εύκολα άλλες γλώσσες προγραμματισμού,όπως C++.Επίσης είναι πολύ δυνατή γλώσσα για καλά προγράμματα.

 

Μειονεκτήματα C

θα σου πάρει πολύ καιρό για να την μάθεις καλά.

 

 

Πλεονεκτήματα Python

Πολύ εύκολη πρός τη μάθηση,επίσης πολύ δυνατή γλώσσα.

 

Mειονεκτήματα Python

Πολύ λίγοι υπολογιστές έχουν εγκατεστημμένο το Python, οπότε θα είναι δύσκολο να διαδοθούν τα προγράμματα.

[insomniaK]

Eclipse με pydev ή έχετε κάτι καλύτερο να προτείνετε;

 

Και ποιο τουτόριαλ;