Πως σετάρουμε το high nibble ενός byte;

[migf1]

Ελα απο αριστερα προς τα δεξια. Βαλε σε παρενθεσεις το σιφτιν αλλιως θα κανεις σιφτ στο αποτελεσμα

 

Αύριο, γιατί τώρα ξέχασα κι αυτά που ήξερα (εννοώ πως δεν λειτουργώ, κοντέυω να κλείσω 14άωρο με coding)

 

EDIT: Thanks papi, nai re sy... asxhmo sklawma, alla me to last post soy ok

[parsifal]

Πάμε να το δούμε με τους αριθμούς της main() σου για να γίνει πιο κατανοητή η ένστασή μου.

 

Φτιάχνεις Byte με όνομα byte, με τον αριθμό 4 ή 0100₂ στο low nibble. Άρα, το byte θα έχει τα εξής bits:

>
00000100

 

Βάζεις τον αριθμό 10 ή 1010₂ στο high nibble. Το byte γίνεται ως εξής:

>
10100100

 

Αν αργότερα θελήσεις να βάλεις τον αριθμό π.χ. 1 ή 0001₂ στο high nibble απλά με ένα bitwise OR και μόνον, θα πάρεις αυτό:

>
10110100

 

ενώ εσύ θα περίμενες αυτό:

>
00010100

 

Αυτό εννοούσα με το «θα σε δαγκώσουν οι παλιοί άσσοι στα πισινά»...

[migf1]

Ναι φίλε parsifal, σωστός ήσουν εξαρχής. Εγώ είμαι που τα 'χω παίξει

 

 

 

Κι όλα αυτά για να χωρέσω ένα τραπουλόχαρτο σε ένα byte (suit + face).

 

 

[parsifal]

Ο αρχικός κώδικάς σου που αργούσε; Στο allocation της βοηθητικής μεταβλητής; Και κάτι δε μου καθότανε καλά όταν τον πρωτοδιάβασα. I mean: «Γιατί να κουνάει ο άνθρωπος το low nibble από τη θέση του, αφού με το high nibble θέλει να δουλέψει»;

 

Όταν μπορείς να δουλέψεις με μάσκες και bitwise arithmetic, να ξέρεις ότι συχνά μπορείς να αποφύγεις εντελώς το swapping mentality.

[migf1]

Yeap, το γνωρίζω... αλλά είναι από εκείνες τις ημέρες που μετά από κανά 10ωρο σερί coding αρχίζει και βγαίνει ζουμί το μυαλό από τη μύτη και τα αυτιά

 

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

 

Για παράδειγμα, αν καταφέρω να συμπυκνώσω τα δεδομένα μιας παρτίδας σε καμιά 10αριά bytes (που κάπου εκεί θα πάει, όπως το βλέπω), ακόμα κι ένα ιστορικό ας πούμε 1.000.000 καταγεγραμμένων παρτίδων θα είναι της τάξης των μόλις 10 Mb. Λέγοντας δεδομένα εννοούμε τα φύλλα που απαρτίζουν την παρτίδα, τη θέση που κάθεσαι στο τραπέζι, το αν κέρδισες-έχασες-πήγες πάσο και με τι φύλλο, τη σειρά που έπεσαν τα φύλλα, κλπ).

 

Για το παράδειγμα του νήματος, ακόμα κι αν κράταγα το κάθε φύλλο σε 2 bytes (π.χ σε ένα char το face και σε ένα άλλο το suit) αντί για 1 που θα το κάνω με τα nibbles, αμέσως-αμέσως κόbω τον όγκο της βάσης σχεδόν στο μισό. Πληρώνω όμως το overhead της (απο)κωδκοποίησης των nibbles.

 

Οπότε επειδή η "αποσυμπύκνωση" όπως και να το κάνουμε κοστίζει, προσπαθώ να μειώσω όσο το δυνατον περισσότερο το όποιο overhead.

[imitheos]

Αν υπάρχουν αδέσποτοι «άσσοι» στο high nibble από προηγούμενη χρήση, θα τον δαγκώσουν στα πισινά.

 

Φυσικά έχεις δίκιο. Η πλάκα είναι ότι το σκέφτηκα 10 λεπτά αφότου ξάπλωσα και βαρέθηκα να σηκώνομαι, να κάνω login, κτλ και είπα θα το γράψω το πρωί

[Retromaniac]

Yeap, το γνωρίζω... αλλά είναι από εκείνες τις ημέρες που μετά από κανά 10ωρο σερί coding αρχίζει και βγαίνει ζουμί το μυαλό από τη μύτη και τα αυτιά

 

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

 

Για παράδειγμα, αν καταφέρω να συμπυκνώσω τα δεδομένα μιας παρτίδας σε καμιά 10αριά bytes (που κάπου εκεί θα πάει, όπως το βλέπω), ακόμα κι ένα ιστορικό ας πούμε 1.000.000 καταγεγραμμένων παρτίδων θα είναι της τάξης των μόλις 10 Mb. Λέγοντας δεδομένα εννοούμε τα φύλλα που απαρτίζουν την παρτίδα, τη θέση που κάθεσαι στο τραπέζι, το αν κέρδισες-έχασες-πήγες πάσο και με τι φύλλο, τη σειρά που έπεσαν τα φύλλα, κλπ).

 

Για το παράδειγμα του νήματος, ακόμα κι αν κράταγα το κάθε φύλλο σε 2 bytes (π.χ σε ένα char το face και σε ένα άλλο το suit) αντί για 1 που θα το κάνω με τα nibbles, αμέσως-αμέσως κόbω τον όγκο της βάσης σχεδόν στο μισό. Πληρώνω όμως το overhead της (απο)κωδκοποίησης των nibbles.

 

Οπότε επειδή η "αποσυμπύκνωση" όπως και να το κάνουμε κοστίζει, προσπαθώ να μειώσω όσο το δυνατον περισσότερο το όποιο overhead.

 

Και όταν θα θες να κάνεις αναζήτηση στην βάση με συγκεκριμένα κριτήρια να δω πόσες ώρες θα θέλει.

[migf1]

Και όταν θα θες να κάνεις αναζήτηση στην βάση με συγκεκριμένα κριτήρια να δω πόσες ώρες θα θέλει.

 

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

 

Αν έχεις κάποια καλύτερη ιδέα, πολύ ευχαρίστως να την συζητήσουμε.

[Retromaniac]

Προτεινω να αφησεις την δουλεια αυτη στην βαση δεδομενων. Τι ακριβως σε ενοχλει αντι για 10mb να πιανει 100mb και να μην το φορτωνεις στην μνημη;

Εξαλλου την βάση τι ακριβως την χρειαζεσαι; Ετσι που τα αποθηκευεις μπορεις να τα σωσεις ανετα και στο file system

[defacer]

@migf1:

 

Νομίζω ότι αυτό που πληρώνεις είναι development time το οποίο δεν ξέρω πραγματικά αν σου φέρνει κάποιο ώφελος. Έχει κανένα νόημα να αποθηκεύσεις 1Μ παρτίδες σε 10MB? Αυτή τη στιγμή που το πρόγραμμα δεν υπάρχει ακόμα (δηλαδή δεν έχει καλά καλά 1 χρήστη, αλλά ας πούμε ότι είναι ένας) αν η κάθε παρτίδα παίρνει 1 λεπτό για να τελειώσει και αν το user base σου παίζει ασταμάτητα 24/7, για να συμπληρωθούν 1Μ παρτίδες θα χρειαστούν λίγο παραπάνω από 2 χρόνια. Ακόμα και αν κατασπαταλούσες το χώρο ξοδεύοντας 1Κ bytes ανά παρτίδα, νομίζω πως δε θα σε έδερνε κανείς αν του έλεγες "για τα δεδομένα που (ρεαλιστικά) θα σου πάρει μερικές δεκαετίες να συγκεντρώσεις θα χρειαστείς 1GB χώρο". Βασικά μέχρι να τα συγκεντρώσει τα USB sticks θα τα μετράμε σε petabytes.

 

Το βασικό μου point λοιπόν είναι πως πιστεύω ότι καλύτερα θα ήταν να φτιάξεις ένα abstraction πάνω από το storage και να ασχοληθείς περισσότερο με το ζουμί της εφαρμογής σου. Αν και όταν υπάρξει λόγος να παιδευτείς με μεταφορές-μετακομίσεις bytes, το abstraction layer θα σου επιτρέψει να το κάνεις χωρίς να επηρρεαστεί το υπόλοιπο πρόγραμμά σου (και επίσης θα φανεί πολύ χρήσιμο και σε μια σειρά από άλλα ενδεχόμενα).

 

Update: Μόλις είδα τα περι loading in memory. Ακόμα και για εκεί, η υπερ-απλόχερη εκτίμηση καταλήγει σε 1 GΒ οπότε πρακτικό πρόβλημα δεν υπάρχει. Βεβαίως η συζήτηση αλλάζει αρκετά γιατί αν ενδιαφέρεσαι να έχεις την ίδια αναπαράσταση τόσο για efficient storage όσο και για efficient queries θα χρειαστεί κάτι πολύ πιο εξελιγμένο από "a bunch of bytes".

[migf1]

@retromaniac:

Είναι σίγουρο πως ο τρόπος που προτείνεις θα είναι ταχύτερος; Προσωπικά διατηρώ αμφιβολίες.

 

@defacer:

Το ιστορικό δεν θα δημιουργείται αποκλειστικά δυναμικά, αλλά θα μπορεί να γίνει και import μαζικά (π.χ. από έτοιμα csv αρχεία).

[Retromaniac]

Ναι είμαι σίγουρος.

Αλοίμονο αν ανακαλύπτουμε συνέχεια τον τροχό από την αρχή.

Εσύ θες να φτιάξεις στην ουσία μια δικιά σου μηχανή βάσης δεδομένων και να την τρέχεις για δεδομένα στην μνήμη!

Γιατί να μην βάλεις την βάση δεδομένων σε έναν ssd; Έχουν απίστευτο random read που χρειάζεσαι για την βάση δεδομένων και έτσι δεν θα χρειαστεί να κάνεις τίποτε. Χρόνια research & development έχουν γίνει για τις βάσεις. Γιατί να το ξανακάνεις εσύ;

 

 

Όσο για αυτό που ρώτησες, η δικιά μου απάντηση

#define JoinNibbles(hi, lo) ((hi << 4) | lo)

#define HiNibble(byte) (byte >> 4)

#define LoNibble(byte) (byte & 0xf)

#define SetHiNibble(byte, hiNibble) (byte = (byte & 0x0f) | (hi << 4))

#define SetLoNibble(byte, loNibble) (byte = (byte & 0xf0) | (lo & 0xf))

[migf1]

Ναι είμαι σίγουρος.

Αλοίμονο αν ανακαλύπτουμε συνέχεια τον τροχό από την αρχή.

Εσύ θες να φτιάξεις στην ουσία μια δικιά σου μηχανή βάσης δεδομένων και να την τρέχεις για δεδομένα στην μνήμη!

Γιατί να μην βάλεις την βάση δεδομένων σε έναν ssd; Έχουν απίστευτο random read που χρειάζεσαι για την βάση δεδομένων και έτσι δεν θα χρειαστεί να κάνεις τίποτε. Χρόνια research & development έχουν γίνει για τις βάσεις. Γιατί να το ξανακάνεις εσύ;

 

Δεν είναι κάτι δύσκολο για αυτό που θέλω, γιατί είναι πολύ συγκεκριμένα τα φίλτρα που χρειάζομαι. Θα το κάνω όμως both ways, χρησιμοποιώντας π.χ. και το sqlite api σε uncompressed data (το οποίο όμως μπορεί να με πάρει και παραπάνω development time έως ότου το... μάθω ). Και θα προσπαθήσω να κάνω συγκρίσεις (btw, το data storage device που θα χρησιμοποιηθεί πρέπει να θεωρηθεί ... random, δεν μπορώ δηλαδή να βασιστώ πως θα το τρέχουν από κάποιο συγκεκριμένο device).

 

Όσο για αυτό που ρώτησες, η δικιά μου απάντηση

#define JoinNibbles(hi, lo) ((hi << 4) | lo)

#define HiNibble(byte) (byte >> 4)

#define LoNibble(byte) (byte & 0xf)

#define SetHiNibble(byte, hiNibble) (byte = (byte & 0x0f) | (hi << 4))

#define SetLoNibble(byte, loNibble) (byte = (byte & 0xf0) | (lo & 0xf))

 

Που είναι και η πιο πλήρης

(όντως είχαμε ξεχάσει να καθαρίζουμε πρώτα το low nibble στην set_low_nibble())

[defacer]

Εγώ στο παρελθόν επειδή δεν ήθελα να εισαγάγω κάποια SQL (όπως SQLite) μέσα στην C++ σε ένα λογισμικό που έγραφα, έκτασα και έγραψα μια δικιά μου βάση δεδομένων τύπου flat file που πραγματικά ήταν και είναι ότι πιο γρήγορο και επιπλέον δεν είχε κάποια από τα μειονεκτήματα των relational αλλά και πολλά άλλα θετικά στοιχεία που δεν έχει νόημα να αναφέρουμε.

Το σημαντικό είναι ότι γλυτωσα μέγεθος και ταχύτητα!

 

Φαντάζομαι πως θα είμαι ο μόνος που θα πει δημοσίως αυτό που φαντάζομαι ότι πολλοί σκέφτονται αλλά το κρατάνε για τον εαυτό τους:

 

I call bullshit. Υπάρχει κάπου ο κώδικας ή κάποιο binary από όπου μπορούμε να συγκρίνουμε features και ταχύτητα? Γιατί διαφορετικά και γω έχω γράψει έναν αλγόριθμο κρυπτογράφησης που τρέχει 50 φορές γρηγορότερα από τον AES και δε σπάει με τίποτα.

 

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

 

Κλείνοντας, έτσι για το χαβαλέ:

 

http://en.wikipedia....t_file_database

 

Strictly, a flat file database should consist of nothing but data and, if records vary in length, delimiters. More broadly, the term refers to any database which exists in a single file in the form of rows and columns, with no relationships or links between records and fields except the table structure.

 

Flat file database λοιπόν είναι και το CSV. Αν τα δεδομένα σου ήταν τέτοια που δε χρειάζεσαι κάτι καλύτερο, τότε γιατί έκατσες και έγραψες κάτι καινούριο από τη στιγμή που ένα τετριμμένο CSV σε καλύπτει; Αν πάλι χρειαζόταν κάτι καλύτερο, τι ήταν ας πούμε αυτό και πώς περίπου το υλοποίησες;

 

Ρητορικές ερωτήσεις obv.

 

@migf1: Και τι διαφορά κάνει το αν θα υπάρχει και import ή όχι;

[migf1]

...

@migf1: Και τι διαφορά κάνει το αν θα υπάρχει και import ή όχι;

 

Το διευκρίνησα σχετικά με εκείνο που έγραψες πως θα πάρει 2 χρόνια να καταγραφεί το ιστορικό from scratch.

 

@Di0D3:

 

Ευχαριστώ για την ενθάρρυνση. Θεωρητικά έχει όντως τη δυναμική να είναι τουλάχιστον συγκρίσιμο σε ταχύτητα με μια υλοποίηση έτοιμης db, και σίγουρα θα είναι πολύ μικρότερο σε όγκο (βέβαια πάντα μπορούν να αποηθκευτούν και στην έτοιμη db συμπυκνωμένα τα data )

 

Στην πράξη όμως δεν μπορούμε να ξέρουμε. Η αλήθεια είναι πως αν επρόκειτο για κάτι πολύ σύνθετο σχετικά με τις αναζητήσεις, η 1η μου σκέψη θα ήταν και μένα μια έτοιμη db. Αλλά με τα μέχρι τώρα δεδομένα δεν δείχνει να χρειάζεται. Θα δείξει υποθέτω.