PDA

Επιστροφή στο Forum : Συμπίεση δίσκων



waste
23-05-08, 07:21
καθώς το πιο αργό εξάρτημα των υπολογιστών μας είναι εδώ και καιρό ο σκληρός δίσκος είπα να δοκιμάσω να ανταλλάξω λίγη επεξεργαστική ισχύ με λίγη ταχύτητα... δοκίμασα να συμπίεσω δυο folders. του firefox και του thunderbird καθως και τα αντιστοιχα αρχεια τους που βρισκονται στο profie folder και νομίζω πως είδα βελτίωση στην ταχύτητα που φορτώνουν τα δύο προγράμματα.

πιο παλιά λέγαμε πως η συμπίεση δίσκων είναι μια άχρηστη λειτουργία που τρώει επεξεργαστική ισχύ, αλλά σήμερα που η επεξεργαστική ισχύ δεν είναι πρόβλημα, μήπως μπορούμε να κερδίσουμε λίγη ταχύτητα???

Θάνος
23-05-08, 08:12
Δεν το έχω δοκιμάσει ποτέ ως τώρα, ούτε πήγαινε στο μυαλό μου σε κάτι τέτοιο.
Είμαι περίεργος να διαβάσω την συνέχεια του θέματος. :hmm:

razorblade1100
23-05-08, 11:47
εγω ειχα δοκιμασει κατι τετοιο σε εναν pentium 4 καποτε και σερνοταν πολυ, συνεχεια στο 100% η χρηση cpu. :p

ZAGNA
23-05-08, 11:53
H συμπίεση δίσκων δεν κρίνεται απαραίτητη πλέον στις μέρες μας διότι ο αποθηκευτικός χώρος έχει πολύ χαμηλότερη τιμή από κάποιες άλλες εποχές. Τώρα ένας δίσκος 500 gb κοστίζει περί τα 90ευρώ.
Παλιά που δεν υπήρχαν τόσο μεγάλες χωρητικότητες πολλοί συμπίεζαν τους δίσκους τους για εξοικονόμηση χώρου με το κόστος της υπολογιστικής δύναμης, αφού για να λειτουργήσει το οτιδήποτε μετά χρειαζόταν να αποσυμπιεστεί πρώτα.
Από πάντα θεωρούσα άσκοπη ενέργεια αυτό τον τρόπο . Προσωπική μου άποψη πάντα.

Tiven
23-05-08, 11:53
καθώς το πιο αργό εξάρτημα των υπολογιστών μας είναι εδώ και καιρό ο σκληρός δίσκος είπα να δοκιμάσω να ανταλλάξω λίγη επεξεργαστική ισχύ με λίγη ταχύτητα... δοκίμασα να συμπίεσω δυο folders. του firefox και του thunderbird καθως και τα αντιστοιχα αρχεια τους που βρισκονται στο profie folder και νομίζω πως είδα βελτίωση στην ταχύτητα που φορτώνουν τα δύο προγράμματα.

πιο παλιά λέγαμε πως η συμπίεση δίσκων είναι μια άχρηστη λειτουργία που τρώει επεξεργαστική ισχύ, αλλά σήμερα που η επεξεργαστική ισχύ δεν είναι πρόβλημα, μήπως μπορούμε να κερδίσουμε λίγη ταχύτητα???

Archive έκανες ή Compress Content ?

manosdoc
23-05-08, 11:54
καθώς το πιο αργό εξάρτημα των υπολογιστών μας είναι εδώ και καιρό ο σκληρός δίσκος είπα να δοκιμάσω να ανταλλάξω λίγη επεξεργαστική ισχύ με λίγη ταχύτητα... δοκίμασα να συμπίεσω δυο folders. του firefox και του thunderbird καθως και τα αντιστοιχα αρχεια τους που βρισκονται στο profie folder και νομίζω πως είδα βελτίωση στην ταχύτητα που φορτώνουν τα δύο προγράμματα.

πιο παλιά λέγαμε πως η συμπίεση δίσκων είναι μια άχρηστη λειτουργία που τρώει επεξεργαστική ισχύ, αλλά σήμερα που η επεξεργαστική ισχύ δεν είναι πρόβλημα, μήπως μπορούμε να κερδίσουμε λίγη ταχύτητα???

Κάνε χρήση του Superfetch αντί αυτών.

waste
23-05-08, 12:27
η ιδεα της συμπιεσης (compress) δεν ειναι να μειωσεις τον χωρο αλλα να κανεις τον μεγαλο μεν, αργος δε σκληρο , να διαβασει λιγοτερα δεδομενα.

και ναι δεν μιλουσα για P4, αλλά για τους τετραπυρηνους που εχουμε και καθονται....

το superfetch δεν ειναι των (s)Vista? ειπαμε να κανουμε τον υπολογιστη μας λιγο πιο γρηγορο, όχι ποιο αργό.. λολ

tedd
23-05-08, 12:45
H συμπίεση δίσκων δεν κρίνεται απαραίτητη πλέον στις μέρες μας διότι ο αποθηκευτικός χώρος έχει πολύ χαμηλότερη τιμή από κάποιες άλλες εποχές. Τώρα ένας δίσκος 500 gb κοστίζει περί τα 90ευρώ.
Παλιά που δεν υπήρχαν τόσο μεγάλες χωρητικότητες πολλοί συμπίεζαν τους δίσκους τους για εξοικονόμηση χώρου με το κόστος της υπολογιστικής δύναμης, αφού για να λειτουργήσει το οτιδήποτε μετά χρειαζόταν να αποσυμπιεστεί πρώτα.
Από πάντα θεωρούσα άσκοπη ενέργεια αυτό τον τρόπο . Προσωπική μου άποψη πάντα.

Παρομοίως
+1

waste
23-05-08, 12:50
παιδια επιμένω η συμπίεση γίνεται για να περιορισεις την αργή ταχύτητα του σκληρού κι όχι για να κερδίσεις χώρο. Οπότε το επιχείρημα ότι ο χώρος είναι φθηνός είναι άσχετο

παράδειγμα...

εστω πως για να ανοιξει το firefox χρειαζεσαι 4 δευτερόλπετα, 15% χρήση του επεξεργαστή και διάβασμα 50ΜΒ από τον σκληρό.
η ιδέα είναι πως με το compression θα χρειαστεί μόλις 25ΜΒ από τον σκληρό 35% χρήση του επεξεργαστή και 3 δευτερόλεπτα...

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

Jazzer
23-05-08, 13:04
Πολύ καλή ιδέα η δημιουργία αυτού του θέματος. :oneup:
Θα έχει ενδιαφέρον να κάνει κάποιος ένα τεστ, στο οποίο να φαίνονται οι όποιες διαφορές στην ταχύτητα του δίσκου με συμπίεση και χωρίς.

mevan
23-05-08, 15:27
το superfetch δεν ειναι των (s)Vista? ειπαμε να κανουμε τον υπολογιστη μας λιγο πιο γρηγορο, όχι ποιο αργό.. λολ

Θα μου επιτρέψεις να διαφωνήσω με το παραπάνω...Έχεις δοκιμάσει VistaSP1 με το superfetch ανοιχτό και οι εφαρμογές δούλευαν αργότερα απο ότι με αυτό κλειστο; Η μήπως -σου είπαν-άκουσες-νομίζεις;




εστω πως για να ανοιξει το firefox χρειαζεσαι 4 δευτερόλπετα, 15% χρήση του επεξεργαστή και διάβασμα 50ΜΒ από τον σκληρό.
η ιδέα είναι πως με το compression θα χρειαστεί μόλις 25ΜΒ από τον σκληρό 35% χρήση του επεξεργαστή και 3 δευτερόλεπτα...

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

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

Άν προλάβω θα δοκιμάσω να κάνω καμιά δοκιμή...

SSB
23-05-08, 15:27
Η συμπίεση των αρχείων δεν συνιστάται για βελτίωση του χρόνου φορτώματος, αλλά σχεδόν αποκλειστικά για μείωση του όγκου σε περιπτώσεις ανεπάρκειας ελεύθερου χώρου στο δίσκο.

Βέβαια η απόψη του φίλου waste, δεν στερείται λογικής, απλά οι σύγχρονοι δίσκοι και controllers έχουν πια τόση μεγάλη ταχύτητα μεταγωγής, που η ανάγνωση ακόμα και ενός executable image των 30ΜΒ δεν παίρνει περισσότερο από 1-2sec. Ακόμα και αν αυτό το υποθετικό αρχείο συμπιεζόταν κατά 50%, η διαφορά του χρόνου ανάγνωσης θα ήταν μεν αντίστοιχη (50%) αλλά τα 2sec να γίνουν 1 δεν είναι και καμιά ιδιαίτερη διαφορά ειδικά όταν αυτό έχει κόστος.

Μετά την ανάγνωση του συμπιεσμένου αρχείου, θα πρέπει να ακολουθήσει η αποσυμπίεση, κάτι που απαιτεί επεξεργαστική ισχύ, ανάλογη του ποσοστού της συμπίεσης και του είδους του αρχείου. Μπορεί σήμερα με τους quad η επεξεργαστική ισχύς να μην φαίνεται ιδιαίτερη απάιτηση, αλλά είναι. Μάλιστα σε αρχεία μεγάλου μεγέθους όπως το υποθετικό παράδειγμα των 30MB η αποσυμπίεση, αναλόγως του φόρτου του CPU, μπορεί να υπερβεί κατά πολύ το όποιο όφελος στο χρόνο φορτώματος. Μπορεί οι αλγόριθμοι συμπίεσης να είναι γρήγοροι στα benchtests αλλά σε αυτά χρησιμοποιούνται κυρίως αρχεία text, image ή sound με πολλά επαναλαμβανόμενα μοτίβα, καθώς και πολλά τεράστια σε μέγεθος null fragments κάτι που συνεισφέρει στην "ονομαστική" αύξηση των επιδόσεων.

Όμως ένα binary executable (exe, dll κλπ) σε αντίθεση με τα προηγούμενα, έχει στο μεγαλύτερό του τμήμα ασαφή δομή κάτι που επιβαρύνει την αποσυμπίεση. Εκτός μάλιστα από τη δομή, τμήματα του αρχείου (exe header, relocation tables, resources κλπ) δεν μπορούν να συμπιεστούν ως έχουν αλλά πρέπει να επαναδημιουργηθούν και να επαναδιευθετηθούν με τέτοιο τρόπο ώστε να είναι δυνατή η εκτέλεση του συμπιεσμένου, αλλά και η ανάκληση από το OS απαραίτητων πληροφοριών για το αρχείο. Φυσικά κάτι τέτοιο προσθέτει στο συνολικό χρόνο και την απαιτούμενη επεξεργαστική ισχύ.

Δυστυχώς, υπάρχει και χειρότερο. H αποσυμπίεση δεν έχει ως κόστος μόνο την επεξεργαστική ισχύ και το χρόνο που απαιτείται. Αυτό το οποίο από μόνο του καθιστά ανώφελη την realtime αποσυμπίεση αρχείων είναι οι απαιτήσεις σε μνήμη. Μετά την ανάγνωση ενός αρχείου στη μνήμη, το module της αποσυμπίεσης κάνει allocate στη physical memory των Windows τόσο χώρο όσο απαιτείται για το uncompressed image, συν επιπλέον pages για τα reconstruction tables, τα recover indexes κλπ.

Με το που φορτώνεται δηλαδή το υποθετικό αρχείο των 30MB, το decompression lib διαβάζει πρώτα τα reconstruction tables του image, διαπιστώνει ότι απαιτούνται για το uncompressed image π.χ. 60MB, κάνει allocate στη μνήμη αυτού του χώρου συν σχεδόν άλλο τόσο για temp storing των rellocation tables. Μιλάμε για συνολική allocated physical mem περίπου 150MB χωρίς να υπολογίσουμε το virtual stack, τα buffers και τις υπόλοιπες απαιτήσεις του decompression lib.

Όλα αυτά, συν την αύξηση των page swaps λόγω απαιτήσεων για free pages κατά το decompression, κάνουν την realtime αποσυμπίεση μάλλον "αντιοικονομική". Ας μην ξεχνάμε, ότι αναφέρομαι στην συμπίεση - αποσυμπίεση συγκεκριμένων μόνο αρχείων και όχι των runtime libs (application dll, C runtime, system runtime) κάτι που αυξάνει εκθετικά όλες τις παραπάνω απαιτήσεις.

Τέλος αξίζει να συμπληρώσω ότι σε αντίθεση με τα ασυμπίεστα αρχεία, των οποίων οι διαδοχικές αναγνώσεις γίνονται απευθείας από την disk cache του συστήματος χωρίς απαιτήσεις άλλης επεξεργασίας, τα compressed πρέπει σε κάθε ανάγνωσή τους να αποσυμπιέζονται ξανά και ξανά καθώς το decompressed image δεν γίνεται cached αλλά διαγράφεται μετά κάθε χρήση.

Άρα τελικά προς τι το όφελος, πέραν του μικρότερου χώρου στο δίσκο;

waste
23-05-08, 18:56
@mevan δεν μιλάμε για του superfetch εδώ ούτε για το εάν τα s(vista) είναι αποδοτικό λειτουργικό, οποτε δεν πέφτω στην παγίδα να αρχισω flame war σε thread που ανοιξα μονος μου lol lol :whistle:

τώρα όσον αφορά στη συμπίεση
δοκίμασα στον τετραπύρηνο μου με και χωρίς συμπίεση να ανοιξω το open office μετά απο reboot . ο χρόνος ήταν 9 και 7,5 δευτ αντίστοιχα (χωρίς και με συμπίεση). μικρό το κέρδος σίγουρα αλλά γιατί όχι?

θα δοκιμάσω μερικά ακομη για πλάκα αργότερα.

SSB ο χρόνος που απαιτείται να διαβάσει το openoffice απο το σκληρό δεν είναι αμεληταίος. Για παράδειγμα ενώ το ΟΟ κανει 9δευτ να ανοιξει σε μηχανημα που μολις εχει γινει επανεκκίνηση, κάνει μόλις 2,5 όταν είναι cached στη μνήμη, πράγμα που δείχνει ποσο σημαντικά αργός είναι ο σκληρός δίσκος σε σχέση με τον υπόλοιπο υπολογιστή.

KIT-XDestroyerGR
23-05-08, 20:05
Μην κανετε κνν αστειο γιατι μετα δεν θα μπαινει στα windows

SSB
23-05-08, 20:23
SSB ο χρόνος που απαιτείται να διαβάσει το openoffice απο το σκληρό δεν είναι αμεληταίος. Για παράδειγμα ενώ το ΟΟ κανει 9δευτ να ανοιξει σε μηχανημα που μολις εχει γινει επανεκκίνηση, κάνει μόλις 2,5 όταν είναι cached στη μνήμη, πράγμα που δείχνει ποσο σημαντικά αργός είναι ο σκληρός δίσκος σε σχέση με τον υπόλοιπο υπολογιστή.

Σίγουρα το πιο αργό device είναι ο δίσκος, αλλά σκέψου ότι σε περίπτωση συμπίεσης ενός αρχείου που υπό κανονικές συνθήκες φορτώνει σε 9sec, θα φορτώνει στην καλύτερη περίπτωση σε 5-6 και η αποσυμπίεσή του μαζί με το overhead θα "κοστίζει" άλλο τόσο χωρίς να λάβουμε υπόψιν την τεράστια ποσότητα μνήμης που απαιτείται για 50% compression factor.

Θα σου δώσω ένα απλό πρακτικό παράδειγμα που μπορείς να επαναλάβεις μόνος σου.

Office 2007, και συγκεκριμένα Word 2007 σε σύστημα Vista64 - Intel X48/QX9650, 4GB, Seagate Barracuda 7200.11 1TB / SATA2 (ICH9). Για τη δοκιμή, απενεργοποιήθηκαν τα Superfetch, DriveReady, Readyboost.

Uncompressed:
Χρόνος load - execute (1st run): 4sec
Χρόνος load - execute (cached): <1sec

Compressed: (Office 2007 folder, common files folder, όλα τα αρχεία και στα 2 folders)
Χρόνος load - execute (1st run): 6sec
Χρόνος load - execute (cached): >4sec

Second Run with Superfetch:
Χρόνος load - execute (1st run): 1.5sec
Χρόνος load - execute (cached): <1sec

Όπως μπορείς να διαπιστώσεις και μόνος σου, θυσιάζοντας την πολύτιμη physical mem για το Superfetch αντί του folder compression κερδίζεις σε performance. Και μην νομίζεις ότι υποστηρίζω το Superfetch. Σε άλλο topic έχω ήδη αναλύσει τους (πολλούς) ενδοιασμούς μου σχετικά με την ρεαλιστική του "αξία"...

Τέλος ας μην ξεχνάμε ότι το realtime decompression συμπιεσμένων executables, είναι κάτι που από εποχής DOS χρησιμοποιήθηκε κύρια προς αποφυγή reverse engineering ή στο παρελθός για μείωση μεγέθους. Παρόλη την μέχρι και σήμερα μεγάλη διάδοσή του, οι περισσότεροι developers εγκατέλειψαν τη χρήση του για τους λόγους ακριβώς που προανάφερα.

Ανάλογη υπήρξε η χρήση του και στο hardware, συγκεκριμένα στους σκληρούς δίσκους. Οι παλαιότεροι σίγουρα θυμούνται κάποιους από τους πρώτους εικοσάρηδες δίσκους (1983-84) που στην κυριολεξία ήταν δεκάρηδες αλλά με ενσωματωμένο στο firmware RLE compression/decompression.

Σίγουρα στα Windows, η υλοποίηση του realtime folder compression είναι αρκετά πιο ολοκληρωμένη από τα γνωστά thirdparty apps, αλλά είναι ταυτόχρονα μνημοβόρα και όχι ιδιαίτερα αποτελεσματική, κυρίως λόγω των αλγόριθμων που χρησιμοποιούνται (RLE & LZ) αλλά και λόγω του ότι η αποσυμπίεση δεν πραγματοποιείται στο κατώτερο file system layer όπου θα μπορούσε να αποφευχθεί μέρος τουλάχιστον του decompression overhead.

waste
24-05-08, 01:43
Πολύ καλό το παράδειγμά σου SSB, να σημειώσω πως οι 20αρηδες που λές ήταν 20ΜΒ κι όχι 20GB, είχα έναν τετοιο το 87... λολ

σε δευτερο τεστ που εκανα με το firefox (συμπιεσμενα και το folder του και το αντίστοιχο προφιλ) η διαφορά ταχύτητας ήταν αμεληταία

δεν είχα ποτέ εκτίμηση στο folder compression και στις εποχές του 386 ήταν ένας καλός τρόπος να κάνεις τον υπολογιστή σου σημαντικά αργότερο, αλλά πίστευα πως αφού σήμερα οι ταχύτητες της μνήμης και του επεξεργαστή έχουν ξεφύγει τόσο πιο μπροστά από τις αντιστοιχες του σκληρού, ίσως η συμπίεση να ξαναείχε νόημα...

στην πραγματικότητα έκανα μια άσκηση επι χάρτου γιαυτό και ζήτησα να την διερευνήσουμε.

SSB
24-05-08, 02:50
Πολύ καλό το παράδειγμά σου SSB, να σημειώσω πως οι 20αρηδες που λές ήταν 20ΜΒ κι όχι 20GB, είχα έναν τετοιο το 87... λολ

Χα χα, σωστά Megabytes, που να τα βρούμε τότε τα Giga; :lol:

Μια και το έφερε η κουβέντα, τι δίσκοι ήταν αλήθεια και εκείνοι με το RLE compression. Συγκριτικά με τους προηγούμενους, του κοινούς δεκάρηδες (MB), οι εικοσάρηδες ήταν για τα σκουπίδια. Από τη μία το RLE από την άλλη τα αδοκίμαστα ακόμα plates "υψηλής" πυκνότητας, καταλήγαμε να παλεύουμε καθημερινά με bad tracks.

Ωραίες εποχές πάντως...

waste
24-05-08, 12:40
εαν δεν με απατά η μνήμη μου ήταν Seagate και μάλιστα δεν ήταν και σφραγισμένοι για να αερίζονται... η πλάκα είναι ότι μου άλλαξαν ολόκληρο υπολογιστή λόγω ενός χαλασμένου μεγαφωνακίου (από αυτά που έκαναν μπιπ μπιπ) και ο δευτερος που μου έδωσαν είχε πραγματικό 20άρη κι όχι γιαλαντζί... είχα πάρει τρελή χαρά τότε. αλλάζα και τα 16χρώματα που έβγαζε η EGA κάρτα γραφικών μου...

Τότε η συμπίεση με τα πραγματικά Megabyte ήταν η μέρα με τη νύχτα. Αλλά και πάλι εάν δεν είχες καθόλου σκληρό πριν και δουλευες με δισκέτες 5 1/4, ακόμα και ο γιαλαντζί σκληρός γρήγορος σου φαινόταν. Εδω ήταν γρήγορες οι δισκέτες 1,2ΜΒ από τις απλές 360αρες...

ΥΓ παντως ο δικος μου πραγματικος 20αρης ακομα δουλευει μαζι με τον 286 μου στα 8Mhz και τα θρυλικά 640ΚΒ RAM του Bill Gates

SSB
24-05-08, 17:07
παντως ο δικος μου πραγματικος 20αρης ακομα δουλευει μαζι με τον 286 μου στα 8Mhz και τα θρυλικά 640ΚΒ RAM του Bill Gates

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

ZackNV
24-05-08, 17:15
Το θέμα είναι η αξιοπιστία. Άμα κάποια στιγμή κλατάρει το σύστημα (windows είναι οπότε είναι αρκετά πιθανόν), τι θα τα κάνεις τα συμπιεσμένα δισκάκια; Αν θες να συμπιέσεις κάτι, το συμπιέζεις με κάποιον archiver (zip, rar, 7zip, ace, κτλ.) ώστε ό,τι και να γίνει, τα δεδομένα σου είναι προσβάσιμα κι από αλλού.

SSB
24-05-08, 18:14
Το θέμα είναι η αξιοπιστία. Άμα κάποια στιγμή κλατάρει το σύστημα (windows είναι οπότε είναι αρκετά πιθανόν), τι θα τα κάνεις τα συμπιεσμένα δισκάκια; Αν θες να συμπιέσεις κάτι, το συμπιέζεις με κάποιον archiver (zip, rar, 7zip, ace, κτλ.) ώστε ό,τι και να γίνει, τα δεδομένα σου είναι προσβάσιμα κι από αλλού.

Τα compressed folders των Windows δεν διαφέρουν από ένα archive σαν αυτά που ανάφερες, οπότε ακόμα και σε περίπτωση reinstalltion του συστήματος μπορούν να μεταφερθούν και να διαβαστούν μια χαρά.

waste
26-05-08, 21:13
ασε που δεν θελεις να συμπιεσεις δεδομενα αλλα τα αρχεια των προγραμματων που τα ξαναβρίσκεις ευκολα...

οπως αναφερω συνεχως το ολο ερωτημα σε αυτο το thread εχει να κανει με την ταχυτητα και οχι με την οποια αυξηση της χωρητικοτητας...

@ ADSLgr.com All rights reserved.