Windows Seven Milestones και Betas

[SSB]

Το κέρδος από την έξοδο του resource manager από τον kernel και ενσωμάτωσή του σε kernel module έδωσε αυτή την ώθηση ή ο γενικότερος επανασχεδιασμός του process scheduler ; Δεν τα κατέχω αυτά τα τεχνικά καλά ! Το κέρδος αυτό συνδιάζεται με την αρχιτεκτονική και εδώ UMD και KMD ή δεν παίζει ρόλο στην διαχείρηση των processes ή τα έχω καταλάβει λίγο κουλουβάχατα ;

Στην συγκεκριμένη περίπτωση, δεν μιλούμε για interprocess security οπότε το level των modules (kernel ή user) δεν παίζει τόσο ρόλο. Η δύο σημαντικότερες αλλαγές του kernel ήταν το αυξημένο scaling των processes σε cores με direct memory pipe, άρα η υπέρβαση του NT limit που υπήρχε από γεννέσεως NT και δεύτερον η κατανομή κάθε process στα cores ή των threads στα thread execution sockets.

Η εμπειρία από ανάλογες πρακτικές που εφαρμόστηκαν στους job schedulers των HPC servers χρησιμοποιήθηκε στο νέο process scheduler του w7 kernel. Κάθε multihreaded app "σπάνει" πλέον σε "numa nodes" ή με απλά λόγια σε σετ από αυτόνομα threads, συγκεκριμένου αριθμού και προτεραιότητας που εκτελούνται από το αντίστοιχο σετ cores. Αν και σε client mode δεν ενδιαφέρει, ωστόσο η νέα μέθοδος διαχωρισμού σε socket - core επιτρέπει στον process scheduler να κατανείμει threads ή ακόμα και solid processes όχι απλά σε cores αλλά και σε nodes, δηλαδή parallelized execution ακόμα και σε άλλο host. Θα μου πεις τι ενδιαφέρει αυτό τους clients. Ο kernel των w7 όπως ξέρεις όμως θα είναι ταυτόχρονα και kernel των server editions καθώς και των επερχόμενων HPC.

Όπως καταλαβαίνεις από τα παραπάνω, αν το υποθετικό multithreaded process έχει ήδη κατανεμηθεί προς εκτέλεση σε αυτόνομα (γιατί όχι και ετερογεννή) hosts, ένας single host manager όπως είναι ο kernel, δεν μπορεί να ελέγχει (μέσω του resource manager) το usage των resources σε όλο το μήκος του process tree ούτε βέβαια να έχει συνεχή γνώση της κατάστασης κάθε "numa node" (core collection) ώστε να κάνει affinity.
Άρα τι πρέπει να γίνει; Να φύγουν τα μέρη αυτά από τον kernel και να εκτελούνται μέσα στο ίδιο module και process space με τον job/process scheduler ώστε να επιτευχθεί συνεχής και άμεση επικοινωνία με το μικρότερο lag.

Με πολύ απλά λόγια, το νέο μοντέλο δεν στοχεύει μόνο στα w7 και τον SOHO χρήστη αλλά και τους servers με έμφαση στο SMP και multihosted scaling και φυσικά το HPC. Βέβαια το όφελος (performance), θα γίνεται άμεσα ορατό ακόμα και σε απλά dual cores όπου μέχρι σήμερα το affinity ήταν περισσότερο σε επίπεδο process παρά thread. Το νέο μοντέλο socket επιτρέπει επίσης τη χρήση του direct memory pipe (ανά core) με αποτέλεσμα πολλές ταυτόχρονες processes που συνήθως "έψαχναν" για ελεύθερο path στο mem bus, να συγχρονίζονται καλύτερα και με σαφή προτεραιότητα κατευθυνόμενα προς το μικρότερου τρέχοντος φόρτου core και memory path. Παρενέργεια του τελευταίου, είναι οι πολύ λογότεροι και μικρότεροι σε μέγεθος handlers με αποτέλεσμα την πολύ καλύτερη εκμετάλευση της RAM. Και εδώ μιλάμε για λιγότερη μνήμη σε ποσοστό που ξεπερνά το 50%.

Τέλος κάτι για το οποίο θα διαβάσουμε και θα συζητήσουμε πολλά στο μέλλον. Ολόκληρο το job/process scheduler, το resource manager, ο memory manager κλπ, έχουν πλέον 100% hardware independed χαρακτηριστικά, έστω και αν εκτελούνται σε συγκεκριμένη πλατφόρμα. Οι δυνατότητες όμως node execution destribution και recource afinity management, επιτρέπουν μέχρι και ανομοιογενή excution paths κάτι που έπεται στο μέλλον.

Να ρωτήσω και εγώ κάτι φίλε ssb αν δεν σου είναι κόπος. Οι νέες αλλαγές στο process scheduler και από ότι διαβάζω και σε πολλά άλλα σημεία του kernel δεν θα χτυπήσουν το compatibility και αν ναι σε ποιό επίπεδο; Θα υπάρξει πρόβλημα με προγράμματα;

Φίλε asm, κάτι που σίγουρα θα έχει πρόβλημα είναι εφαρμογές τύπου firewall ή άλλες που χρησιμοποιούν kernel hooks. Ευτυχώς λόγω Vista και Windows 2008, οι περισσότεροι developers είτε προσάρμοσαν τα προγράμματά τους "φεύγοντας" από το κατώτερο επίπεδο και τις πρακτικές τύπου filters, hooks, kernel drivers κλπ, είτε ...τα παράτησαν. Οπότε περιμένω πως δεν θα είναι τόσο σοβαρά τα φαινόμενα ασυμβατότητας, αν και είμαι σίγουρος πως θα υπάρξουν. Για παράδειγμα βάζω στοίχημα πως στον πρώτο χρόνο των w7, ζήτημα είναι να έχουν μείνει οι μισοί Antivirus/Antispyhare authors και ακόμα λιγότερα third party firewalls.

Όπως και να έχει, οι αλλαγές σε επίπεδο kernel ήταν σήμερα περισσότερο αναγκαίες από ποτέ. Με τα 4cores να κυριαρχούν και τα 8-16... να έρχονται, τα προηγούμενα process managers δεν θα ήταν σε θέση να ανταποκριθούν στις αυξημένες υποχρεώσεις. Και φυσικά αν μιλήσουμε για servers τότε η ανάγκη αναθεώρησης του kernel γίνεται ακόμα επιτακτικότερη. Απλά όπως είπα και παλαιότερα, θα ήταν αδύνατη η άμεση μετάβαση σε ένα νέο kernel όπως ο πολυσυζητημένος Minwin, αφού κάτι τέτοιο θα έφερνε την απόλυτη ασυμβατότητα και το γενικό χάος σε όλους, χρήστες developers και φυσικά την ίδια την Microsoft.

[Thuglife]

Πολύ ενδιαφέρων video του Russinovich πάνω στο θέμα (+ others about 7)
http://channel9.msdn.com/shows/Going...ide-Windows-7/

[asm]

Σε ευχαριστώ ssb, για τις πολλές και άκρως ενδιαφέρουσες πληροφορίες.
Τελικά οι αλλαγές στο κατώτερο επίπεδο των Windows 7 φαίνεται ότι είναι πολλές και σημαντικές έστω και αν ο ίδιος ο kernel αποτελεί συνέχεια μόνο των Vista.
Πάντως αναρωτιέμαι, εκεί στη Microsoft Research γίνεται πολύ και καλή δουλειά επάνω στους kernels, προχωρημένες αρχιτεκτονικές και άλλα που μαθαίνω. Γιατί βρε ssb δεν φτάνουν όλα αυτά σε εμάς, εννοώ στα Windows;

[SSB]

Τελικά οι αλλαγές στο κατώτερο επίπεδο των Windows 7 φαίνεται ότι είναι πολλές και σημαντικές έστω και αν ο ίδιος ο kernel αποτελεί συνέχεια μόνο των Vista.
Πάντως αναρωτιέμαι, εκεί στη Microsoft Research γίνεται πολύ και καλή δουλειά επάνω στους kernels, προχωρημένες αρχιτεκτονικές και άλλα που μαθαίνω. Γιατί βρε ssb δεν φτάνουν όλα αυτά σε εμάς, εννοώ στα Windows;

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

Όσον αφορά τον προβληματισμό σου σχετικά με το τι φτάνει στα Windows, άδικα αναρωτιέσαι. Ουσιαστικά, τα περισσότερα φτάνουν και χρησιμοποιούνται από το Windows team, αλλά όχι με την μορφή που ίσως περιμένεις. Λόγοι προφανώς marketing, επιβάλλουν την προβολή "ανόητων" πολλές φορές χαρακτηριστικών όπως themes, wizards, taskbars, skins και άλλα τέτοια, γιατί δυστυχώς ο κόσμος, ο μέσος καταναλωτής αυτά ζητά, με αυτά εντυπωσιάζεται και αυτά πληρώνει.

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

Πάντως, ότι μπορεί να χρησιμοποιηθεί από τα ερευνητικά projects, αργά ή γρήγορα χρησιμοποιείται και εφαρμόζεται και στα consumer products. Απλά δεν λαμβάνει τη δημοσιότητα που τους αρμόζει, γιατί όπως γνωρίζεις σήμερα η δημοσιότητα ελέγχεται από magazines, blogs και forums που τις περισσότερες φορές ελέγχονται και "κατοικούνται" από ανθρώπους τους οποίους ελάχιστα τους ενδιαφέρει το τεχνολογικό υπόβαθρο.

[manosdoc]

Υπερ-ευχαριστώ για τον χρόνο σου.
Κατάλαβα πως προκύπτει τώρα αυτό το κέρδος, πριν δεν ήταν φανερό. Πολύ πολύ έξυπνο μου φάνηκε, ή τουλάχιστον καινούριο εμένα. Από άποψη συντονισμού όμως των processes μήπως δεν είναι πιο επίφοβο να βγαίνει από τον καθεαυτό kernel, σαν Module που ενσωματώνει ξεχωριστά Hosts που ελέγχουν το καθένα τα resourses που χρειάζονται ; Μήπως ίσα ίσα αυτό ευνοεί τελικά την αξιοπιστία ενός συστήματος "απομονώνοντας" πιθανή προβληματική διαχείρηση πόρων κάποια στιγμή ;

Είμαι πολύ χαρούμενος που τρέχουμε πλέον universal μοντέλα κώδικα με τα VistaSP1/Windows Server 2008 και Windows 7/Server 2008 R2.

Κέρδος από την διαχείρηση των πόρων των drivers, έχουμε πληροφορίες ; Ας πούμε το νέο Dicect2D.
Σόρρυ για τις πολλές ερωτήσεις.

[SSB]

Υπερ-ευχαριστώ για τον χρόνο σου.
Κατάλαβα πως προκύπτει τώρα αυτό το κέρδος, πριν δεν ήταν φανερό. Πολύ πολύ έξυπνο μου φάνηκε, ή τουλάχιστον καινούριο εμένα. Από άποψη συντονισμού όμως των processes μήπως δεν είναι πιο επίφοβο να βγαίνει από τον καθεαυτό kernel, σαν Module που ενσωματώνει ξεχωριστά Hosts που ελέγχουν το καθένα τα resourses που χρειάζονται ; Μήπως ίσα ίσα αυτό ευνοεί τελικά την αξιοπιστία ενός συστήματος "απομονώνοντας" πιθανή προβληματική διαχείρηση πόρων κάποια στιγμή ;

Με την κυκλοφορία όλο και περισσότερων multicore συστημάτων, θα ήταν αδύνατο να χρησιμοποιηθεί το process management προηγούμενων Windows. Ουσιαστικά από Vista/2008 και μετά έχει εφαρμοστεί η νέα διαχείριση, απλά τώρα διευρύνεται ενσωματώνοντας πρακτικές host/node/sockets στο SMP, κάτι που πριν χρησιμοποιούνταν αποκλειστικά και μόνο στο HPC. Και αυτό είναι καλό, πολύ καλό ακόμα και για το απλούστερο dual core.

Μέχρι σήμερα, το kernel έβλεπε τα physical CPU ως μέρος του process sharing, της κατανομής δηλαδή jobs σε κάθε φυσικό cpu, τα δε threads είτε του συστήματος είτε των εφαρμογών, κατανέμονταν στα cores. Η κατανομή των προcesses γίνονταν με βάση το resource usage και το prioritization, αλλά των threads χρησιμοποιούσε αποκλειστικά preset priorities. Καταλαβαίνεις πως η κατανομή των threads, άρα η χρήση των cores ήταν σχεδόν στατική, δίνοντας πολύ μικρή ή καθόλου βάση στο resource usage. Επιπλέον, το thread prioritization περνούσε αποκλειστικά στο χέρι του developer, με το σύστημα να έχει ελάχιστη παρέμβαση.

Ο νέος process scheduler, αντλεί συνεχώς την τρέχουσα κατάσταση του resource usage από το resource manager, και διατηρεί μια διαρκή εικόνα του. Όταν έρθει η ώρα του process ή thread affinity, διευθετεί processes και threads σε όποιο physical CPU ή core έχει το λιγότερο φόρτο. Καταλαβαίνεις πως μιλούμε για δυναμική κατανομή, στην οποία λαμβάνονται μεν υπόψιν τα developer thread presets αν υπάρχουν, αλλά το σύστημα έχει τον τελευταίο λόγο.

Σχετικά τώρα με την ερώτησή σου σχετικά με το συντονισμό των processes. Το μεγάλο πρόβλημα δεν ήταν ποτέ ο συντονισμός αυτός, αλλά ο συντονισμός των threads. Τα threads ως αυτόνομα σχεδόν jobs, δεν έχουν τον τρόπο να "επικοινωνούν" με την controller process με αποτέλεσμα η δεύτερη να μην γνωρίζει την τρέχουσα κατάστασή τους (running, waiting, idle, finished, orphan). Ειδικά στην τελευταία περίπτωση, πολύ συχνά η control app "έχανε" τον όποιο έλεγχο των threads με αποτέλεσμα να τελειώνει ενώ τα threads παρέμεναν ενεργά αλλά "ορφανά", δημιουργώντας thread leak με όλες τις παρενέργειες όπως μη απελευθέρωσης της δεσμευμένης σε αυτά heap memory, και ακόμα χειρότερα των handles.

Ο νέος process/job scheduler κατά το affinity, αποδίδει σε κάθε distributed thread ένα execution ID που σε εσωτερικό table του συστήματος το αντιστοιχεί με την control application. Όταν τερματίσει αυτή, κανονικά ή λόγω error, έρχεται ο ίδιος ο scheduler σε συνεργασία με τον memory manager να ελέγξει αν υπάρχουν threads με το execution ID της εφαρμογής, άρα ορφανά πλέον. Σε αυτή την περίπτωση τα "σκοτώνει" και αποδίδει τα resources και τα handles πίσω στο σύστημα.

Αν και το εξήγησα με απλά λόγια, πιστεύω πως γίνεται κατανοητό πως μιλούμε για μια μορφή process - thread garbage collector σε επίπεδο συστήματος και μάλιστα scaled. Αποτέλεσμα αξιοπιστία, δυναμική χρήση resources, εξαιρετικά λιγότερα mem leaks, μηδενικές πιθανότητες orphan threads, δυναμικό thread scaling σε cores, physical CPU αλλά και hosts και δεκάδες άλλα πλεονεκτήματα. Αρκεί να πω πως από τα σημερινά καταναλωτικά λειτουργικά συστήματα, μόνο τα Windows και το FreeBSD (>v7) χρησιμοποιούν τέτοιες τακτικές process scheduling με τα w7 να επεκτείνουν ακόμα περισσότερο το μοντέλο της δυναμικής κατανομής και σε επίπεδο host distributed. Βέβαια το τελευταίο μην περιμένεις να εφαρμοστεί σε clients, όντας περισσότερο χρήσιμο σε επίπεδο servers και HPC servers.

Κέρδος από την διαχείρηση των πόρων των drivers, έχουμε πληροφορίες ; Ας πούμε το νέο Dicect2D.

Σε επίπεδο drivers, τα οφέλη είναι άμεσα συνδεδεμένα με όλα τα προηγούμενα, καθώς οι drivers και του HAL αλλά και User, όπως άλλωστε και ολόκληρο το σύστημα χρησιμοποιούν το μοντέλο διαχείρισης που περιέγραψα παραπάνω. Για το Direct2D και ειδικά το DirectWrite ένα μόνο θα σου πω φίλε manosdoc. Όπως ξανασυζητήθηκε, η κύρια αιτία του screen writes lag στα Vista, ήταν το GDI -> DirectX translator rendering που φυσικά ήταν αναγκαίο να υπάρχει ελλείψη GDI/GDI+. Στα w7, το GDI/GDI+ renderer ως fuction API εξακολουθεί να υπάρχει, αλλά αποκτά "υπόσταση", γίνεται δηλαδή ξεχωριστό layer που κάθεται επάνω από D3D ενώ ταυτόχρονα παύει να είναι translator σε D3D αλλά αποτελεί ένα εντελώς νέο 2D rendering API ικανό να τρέχει legacy GDI/GDI+ αλλά επεκτείνοντάς το σε πολλά σημεία.

Για την ακρίβεια, αντί translator χρησιμοποιείται common API με τα GDI(+) αλλά το processing γίνεται σε επίπεδο D3D, δηλαδή h/w accelerated και parallel executed (SIMD). Αν σκεφτείς πως στα Vista, ούτε το GDI, ούτε το GDI+ ήταν h/w accelerated με το δεύτερο μάλιστα να μην υπήρχε ποτέ accelerated ακόμα και στα XP, καταλαβαίνεις πως η επιτάχυνση του screen rendering και μάλιστα σε κοινές εφαρμογές θα είναι πολύ μεγαλύτερη από 100% (ακόμα και 3x σε ορισμένες περιπτώσεις). Επίσης το SIMD επιτρέπει πλέον το parallel threaded execution κοινών αλλά alltime functions όπως cursor movement, mouse cursor rendering, cleartype rendering, intermediate layer rendering, 48bit coloring, primitive antialiasing και server side rendering. Μιλούμε δηλαδή όχι απλά για GPU accelerated αλλά για GPU + system accelerated.

Ταυτόχρονα γίνεται "ευκολότερη" η εργασία που υπολείπεται στους GPU manufacturers. Μέχρι σήμερα ήταν αναγκασμένοι να παρέχουν 2d/3d - D3D accelerated drivers υλοποιόντας in-driver πολλές από τις παραπάνω functions με αποτέλεσμα οι περισσότεροι να επικεντρώνονται στο gaming performance, έχοντας στην πράξη εγκαταλείψει το desktop acceleration εδώ και μια δεκαετία. Πλέον θα είναι αρκετό να υλοποιήσουν μόνο μερικά primitives, και το 2D layer θα αναλαμβάνει τα υπόλοιπα. Αυτό θεωρητικά τουλάχιστον (καθώς εξαρτάται από την "τεμπελιά" των GPU vendors), σημαίνει μικρότερους και "ασφαλέστερους" drivers, ταχύτερο performance, αυκολότερη ανάπτυξη drivers, common acceleration APIs και ευκολότερο driver virtualization.

[manosdoc]

...Σχετικά τώρα με την ερώτησή σου σχετικά με το συντονισμό των processes...

Απλά Respect x1000. Ευχαριστώ !

[ownagE_]

Off Topic

SSB, τί έχεις σπουδάσει?

[iloxos]

Off Topic

SSB, τί έχεις σπουδάσει?

SSB = Bill Gates

@SSB ευχαριστώ και γω. αν και δεν συμμετέχω σε διαβάζω ανελλιπώς

[SSB]

SSB = Bill Gates

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

[agis29]

"Επιπλέον, το thread prioritization περνούσε αποκλειστικά στο χέρι του developer, με το σύστημα να έχει ελάχιστη παρέμβαση."

Developers των Windows ή κάποιας άλλης εφαρμογής που τρέχει στα Windows;
Λογικά εννοείς το δεύτερο.
Θες να πεις πως ακόμα και αν μια εφαρμογή δεν περιέχει καθόλου κώδικα για SMP
θα έχει καλύτερες επιδόσεις αφού τα Windows θα αναλαμβάνουν αυτό το κομμάτι;
Η προτεραιότητα στα Threads ότι και αν έχει γραφτεί στον κώδικά θα είναι θέμα πλέον των λειτουργιών που περιγράφεις;
Κάτι παρόμοιο δεν υπάρχει στα Windows server 2008;

[drhouse]

Μην ανυσηχείς και έρχοντε

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

[SSB]

"Επιπλέον, το thread prioritization περνούσε αποκλειστικά στο χέρι του developer, με το σύστημα να έχει ελάχιστη παρέμβαση."

Developers των Windows ή κάποιας άλλης εφαρμογής που τρέχει στα Windows;
Λογικά εννοείς το δεύτερο.
Θες να πεις πως ακόμα και αν μια εφαρμογή δεν περιέχει καθόλου κώδικα για SMP
θα έχει καλύτερες επιδόσεις αφού τα Windows θα αναλαμβάνουν αυτό το κομμάτι;
Η προτεραιότητα στα Threads ότι και αν έχει γραφτεί στον κώδικά θα είναι θέμα πλέον των λειτουργιών που περιγράφεις;
Κάτι παρόμοιο δεν υπάρχει στα Windows server 2008;

Ναι στο δεύτερο αναφερόμουν, στους application developers δηλαδή. Σχετικά με την ερώτησή σου, αν μια εφαρμογή δεν είναι threaded εννοείται πως δεν μπορεί το λειτουργικό να την κάνει (για την ώρα). Όμως μέχρι σήμερα το prioritization ήταν στατικό και προδηλωμένο από τον developer, κάτι που αν και διατηρείται για backward code compatibility, πλέον ο process scheduler είναι αυτός που βάση του resource usage και των queued threads καθορίζει τον επιμερισμό και το τελικό priority.

Όσον αφορά τα Windows 2008 (και τα Vista), όχι η διαχείριση των threads δεν διαφέρει παρά ελάχιστα από τα Windows 2003, όντας μόνο εν μέρει καλύτερη (στο queue handling) από τα XP.

Τέλος σχετικά με το performance, η αύξηση που παρατηρείται στα w7 όπως και το σαφώς μειωμένο resource usage, δεν αφορά μόνο SMP user applications. Όπως προανάφερα, ακόμα και το job scheduler του process manager, η διαχείριση δηλαδή monolithic uniprocessing εφαρμογών, είναι εντελώς νέο και δεν στηρίζεται στα process backexecuting priorities αλλά στο resource monitoring - usage κάθε core. Στους προηγούμενους kernel οι οποίοι διατηρούσαν το αρχικό σχήμα διαχείρισης των physical processors, το affinity καθοριζόταν σε επίπεδο physical CPU μη λάμβάνοντας παρά ελάχιστα υπόψιν το φόρτο του εκάστοτε core. Συγκεκριμένα θα έπρεπε το φορτίο να ήταν εξαιρετικά υψηλό (>50%) για να γίνει ανάθεση σε άλλο core. Στην περίπτωση που το load για παράδειγμα σε δύο cores ήταν ταυτόχρονα υψηλό, το process έτρεχε σε οποιοδήποτε. Στα w7, λαμβάνονται και άλλοι παράγοντες υπόψιν, όπως core memory usage, paging usage, zero page usage, running system services priority κλπ. Έτσι, ένα user process θα "προτιμά" να εκτελεστεί σε ένα core, το οποίο για παράδειγμα δεν τρέχει system services, ή δεν έχει μεγάλο τρέχον memory I/O.

Φυσικά η βελτίωση όσον αφορά το thread handling, θα γίνεται ιδιαίτερα φανερή σε threaded εφαρμογές αλλά αυτό δεν σημαίνει πως σε μεγάλο βαθμό δεν θα φαίνεται και σε απλές. Μην ξεχνούμε, πως κάθε kernel job, κάθε service κάθε driver και kernel module, έστω και μη threaded, είναι εκ φύσεως ξεχωριστά processes και ένας process scheduler με δυνατότητα κατανομής και ανακατανομής της εκτέλεσής τους, και συνεχούς μεταβολής του idle state βάση του resource usage, βελτιώνει κατά πολύ το performance, κάτι που σύντομα θα το διαπιστώσουν οι w7 beta testers.

Τελειώνοντας θα προσθέσω πως παρά τα όσα ακούγονται οι αλλαγές του kernel και των επιμέρους modules, είναι εξαιρετικά σημαντικές, και με την πρώτη χρονική ευκαιρία θα τις συζητήσουμε εδώ εκτενέστερα. Σίγουρα δεν είναι ένας νέος kernel, όπως και τα w7 δεν είναι ένα νέο λειτουργικό σύστημα. Αλλά στην πράξη αποτελεί τη σημαντικότερη εξέλιξη του NT Kernel από εποχής NT3.5 και ενσωματώνει τεχνικές που δουλεύονται για περισσότερο από μία δεκαετία στα MS Research labs. Τώρα το πόσο θα ικανοποιήσουν τα w7 τους χρήστες, αυτό θα φανεί στο μέλλον. Εγώ πάντοτε αναφέρομαι στα low level και όχι στο users experience. Εκείνο για να είμαι ειλικρινής, ούτε με πολυαφορά, ούτε γνωρίζω ιδιαίτερα πολλά για τα inners του

[asm]

Εξαιρετικές πληροφορίες όπως πάντοτε, φίλε ssb.
Τελικά φαίνεται πως χωρίς πολλές φανφάρες τα Windows 7 φέρνουν πολλές και σημαντικές αλλαγές στον kernel. Αυτό που αληθινά με κάνει να απορώ είναι η πολύ μικρή προβολή και δημοσιότητα τόσο σημαντικών χαρακτηριστικών. Αντί αυτών, διαβάζουμε για taskbar, explorer, aero effects και άλλα ανόητα. Ήθελα να ήξερα ποιος φταίει για αυτό η Microsoft ή όλοι αυτοί οι άσχετοι bloggers και reviewers.

Off Topic

Φίλε Σάκη ένα πουλάκι μου σφύριξε πως έχεις έρθει Θεσσαλονίκη. Αν υποψιαστώ πως είσαι αλήθεια Ελλάδα και δεν πέρασες να πιούμε ενα καφέ ρε αδελφέ, είσαι πολύ γαϊδούρι.

[drhouse]

Εξαιρετικές πληροφορίες όπως πάντοτε, φίλε ssb.
Τελικά φαίνεται πως χωρίς πολλές φανφάρες τα Windows 7 φέρνουν πολλές και σημαντικές αλλαγές στον kernel. Αυτό που αληθινά με κάνει να απορώ είναι η πολύ μικρή προβολή και δημοσιότητα τόσο σημαντικών χαρακτηριστικών. Αντί αυτών, διαβάζουμε για taskbar, explorer, aero effects και άλλα ανόητα. Ήθελα να ήξερα ποιος φταίει για αυτό η Microsoft ή όλοι αυτοί οι άσχετοι bloggers και reviewers.

Off Topic

Φίλε Σάκη ένα πουλάκι μου σφύριξε πως έχεις έρθει Θεσσαλονίκη. Αν υποψιαστώ πως είσαι αλήθεια Ελλάδα και δεν πέρασες να πιούμε ενα καφέ ρε αδελφέ, είσαι πολύ γαϊδούρι.

Όπως σήμερα ακούμε αναφορές "Xp = Vista" έτσι και τότε θα ακούμε τα ίδια.
Υπ' όψιν ότι άλλες τόσες αλλαγές έχουν γίνει και στα Vista.

Ας είναι πάντα καλά, συμφορουμήτες σαν τον SSB που μας τα υπενθυμίζουν.
Δεν έχει και κανένα DONATE για να του δώσουμε κουράγιο (τα $$$ που λέγαμε)