GPGPU - Η δύναμη των GPUs στα χέρια σας

crmaris · Δεκέμβριος 20, 2009

<div align="justify"><img src="http://www.thelab.gr/gallery3/var/albums/Articles/Articles-Icons/icon_article_GPGPU.png" align="left" hspace="8" vspace="8" alt="GPGPULogo"/> Μέχρι πριν και από μερικά χρόνια, οι κάρτες γραφικών (Graphics Processors Units, GPUs) είχαν ως μόνο ρόλο (τουλάχιστον για το ευρύ κοινό) την παραγωγή και επιτάχυνση των γραφικών. Οι απαιτήσεις των παιχνιδιών για πολυπλοκότερα και ολοένα πιο «βαριά» γραφικά εξωθούσαν διαρκώς (και συνεχίζουν να εξωθούν) την τεχνολογία των GPUs στα όρια. Αυτό είχε ως αποτέλεσμα οι δυο μεγάλοι παίχτες της κατηγορίας (ATI και NVIDIA) να παρουσιάζουν ολοένα και ισχυρότερα GPUs, τα οποία διαθέτουν πολύ μεγαλύτερη υπολογιστική ισχύ από τoυς, αντίστοιχης γενιάς, κορυφαίους επεξεργαστές.

Κάποια στιγμή λοιπόν κάποιος σκέφτηκε: «Γιατί να μην εκμεταλλευτούμε όλη αυτή την ισχύ που έχουν οι GPUs και τις τεράστιες δυνατότητες παράλληλης επεξεργασίας τους και για την εκτέλεση άλλων προγραμμάτων που μέχρι πρότινος έτρεχαν σε κοινούς επεξεργαστές (Central Processing Units, CPUs), π.χ. προγραμμάτων προσομοιώσεων, επίλυσης σύνθετων μαθηματικών προβλημάτων, κ.λπ. Και το πιο σημαντικό, να προσφέρουμε το απαραίτητο λογισμικό ώστε να μπορεί ο καθένας χρήστης να γράψει κώδικα που να εκτελείται από την GPU». Και από εκεί λοιπόν ξεκίνησε η ιστορία του General Purpose Computing on Graphics Processing Units (GPGPU). Μια τεχνολογία που αν ευδοκιμήσει, θα φέρει σε πολύ δύσκολη θέση τους σημερινούς υπερ-υπολογιστές.

Η TESLA GPGPU πλατφόρμα της Nvidia

Σύντομη Ιστορία της τεχνολογίας GPGPU

Μπορεί να έχει γίνει διαθέσιμη στο ευρύ κοινό τα τελευταία χρόνια, αλλά η ιδέα της χρησιμοποίησης του υλικού παρουσίασης και επιτάχυνσης γραφικών για την εκτέλεση προγραμμάτων, που δεν έχουν να κάνουν αποκλειστικά με γραφικά, είναι πολύ παλιά. Ξεκίνησε το 1978 από το σύστημα Ikonas, μετέπειτα με την Pixel Machine (1989) και στη συνέχεια με το Pixel-Planes 5 (1992).

Ikonas

Pixel Planes

Από την επιστημονική βιβλιογραφία που υπάρχει στο συγκεκριμένο τομέα ενδιαφέρον παρουσιάζει το PixelFlow SIMD graphics computer των Eyles et al., το οποίο χρησιμοποιήθηκε από τους Kedem και Ishihara (1999) για την κρυπτανάλυση και «σπάσιμο» κρυπτογραφημένων κωδικών του λειτουργικού συστήματος UNIX. Επίσης, υλικό σχετικό με τα γραφικά χρησιμοποιήθηκε για διάφορους υπολογισμούς σε τεχνητά νευρωνικά δίκτυα (Bohn 1998).

Το σύστημα PixelFlow των Eyles et al.

Όσον αφορά πιο σύγχρονες εφαρμογές, λογισμικό όπως το Folding@home του πανεπιστημίου Stanford (USA), το οποίο αρχικά «έτρεχε» αποκλειστικά σε CPUs, μεταποιήθηκε ώστε να «τρέχει» σε GPUs με αποτέλεσμα την κατά πολύ ταχύτερη εκτέλεσή του. Σήμερα, η πανεπιστημιακή/ερευνητική κυρίως κοινότητα έχει να αποκομίσει πολλά οφέλη από τη χρησιμοποίηση GPUs για την εκτέλεση διάφορων πειραματικών προσομοιώσεων, μιας και απαλείφεται η ανάγκη χρησιμοποίησης πανάκριβων υπερ-υπολογιστών, η απόκτηση των οποίων είναι προνόμιο λίγων και μεγάλων ιδρυμάτων και σαν να μη φτάνει μόνο αυτό, η πρόσβαση σε αυτούς είναι χρονικά περιορισμένη. Βέβαια αυτό δε σημαίνει ότι και το σύνολο των απλών χρηστών-προγραμματιστών δεν έχει να κερδίσει κάτι από την τεχνολογία του GPGPU. Το αντίθετο μάλιστα, μιας θα είναι σε θέση να εκμεταλλευτεί την περίσσια δύναμη των GPUs για τους δικούς τους σκοπούς.

S3 86C911

Τελειώνοντας με την ιστορία της τεχνολογίας GPGPU, αξίζει να πούμε λίγα λόγια και για την ιστορία των GPUs ή VGAs. O πρώτος επίσημος δυσδιάστατος (2D) επιταχυντής γραφικών παρουσιάστηκε το 1991 από την S3 Graphics, με το κωδικό όνομα S3 86C911. Μάλιστα θεωρούταν τόσο πρωτοποριακός για την εποχή του, που οι δημιουργοί του τον βάπτισαν με το όνομα «Porsche 911», λόγω των επιδόσεων που υποσχόταν. Οι επιταχυντές 2D συνέχισαν την εξέλιξή τους, μέχρι που εμφανίστηκαν οι επιταχυντές αποκλειστικά τριδιάστατων (3D) γραφικών (3DFX Voodoo), οι οποίοι σήμαναν και την αρχή των τρισδιάστατων βίντεο παιχνιδιών. Λίγο αργότερα, οι κατασκευαστές κατάφεραν και ενσωμάτωσαν τους επιταχυντές 2D και 3D σε ένα ολοκληρωμένο κύκλωμα (chip) και με την έλευση του Direct3D 7, οι κάρτες γραφικών απέκτησαν τη δυνατότητα επιτάχυνσης της μεταμόρφωσης και φωτισμού των γραφικών (Transform and Lighting, T&L). Δηλαδή, στην ουσία, απάλλαξαν τα CPUs από μεγάλο βάρος και ανέλαβαν σχεδόν εξολοκλήρου την επεξεργασία και επιτάχυνση των γραφικών (πρώτη κάρτα αυτής της τεχνολογίας υπήρξε η GeForce 256). Tο T&L είναι ο απόγονος των σημερινών μονάδων pixel shader και vertex shader που χρησιμοποιούνται κατά κόρον στα σύγχρονα GPUs.

Geforce 256

Παραδείγματα Εφαρμογών GPGPU

Οι εφαρμογές που επωφελούνται τα μέγιστα από την τεχνολογία GPGPU είναι αυτές που χρησιμοποιούν πολλά νήματα (threads), ταυτόχρονα. Αυτό συμβαίνει διότι οι σύγχρονες GPUs αποτελούνται στην ουσία από πολλούς thread processors, οι οποίοι εργάζονται παράλληλα και έτσι μπορούν και «τρέχουν» χιλιάδες threads ταυτόχρονα, πράγμα αδύνατο ακόμη και για τους σύγχρονους τετραπύρηνους επεξεργαστές.

Thread processor schematic

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

<table width="559" border="2" cellspacing="2" cellpadding="2"><tr><td width="419"><div align="center">Βάσεις δεδομένων για σεισμούς</div></td><td width="118"><div align="center">66x-100x</div></td></tr><tr><td><div align="center">Προσομοίωση κεραιών κινητών τηλεφώνων</div></td><td><div align="center">45x</div></td></tr><tr><td><div align="center">Προσομοίωση νευρωνων </div></td><td><div align="center">100x</div></td></tr><tr><td><div align="center">Επεξεργασία MRI (Magnetic Resonance Imaging)</div></td><td><div align="center">245x-415x</div></td></tr><tr><td><div align="center">Προσομοίωση ατμοσφαιρικών νεφών</div></td><td><div align="center">50x</div></td></tr></table>

Προς το παρόν, η κύρια γλώσσα προγραμματισμού που χρησιμοποιείται για τον προγραμματισμό GPUs είναι η C, αλλά μελλοντικά αναμένεται να επεκταθεί η υποστήριξη και σε άλλες διαδεδομένες γλώσσες προγραμματισμού. Έτσι θα μπορεί ο καθένας να δημιουργήσει εφαρμογές που θα εκμεταλλεύονται τις μεγάλες δυνατότητες της παράλληλης επεξεργασίας χιλιάδων threads, που προσφέρουν οι σύγχρονες GPUs.

Εισαγωγή στο CTM, ATI Stream και το OpenCL

Η ATI (AMD τώρα) ξεκίνησε την υποστήριξη του GPGPU το 2006 (Νοέμβριος) με το CTM™ (Close To Metal, Κοντά στο Μέταλλο) το οποίο προσέφερε μια διεπαφή (interface) που έδινε στους προγραμματιστές τη δυνατότητα απευθείας πρόσβασης στο υλικό. Ήταν μια καλή κίνηση της ATI, η οποία όμως απευθυνόταν κυρίως σε εταιρίες ανάπτυξης λογισμικού και σε ερευνητικά ιδρύματα λόγω της πολύ χαμηλής πρόσβαση (low-level) στο υλικό που παρείχε, κάτι που συνεπαγόταν με μεγάλη δυσκολία στον προγραμματισμό (λόγω μη χρήσης γλώσσας υψηλού επιπέδου). Η γνωστή client εφαρμογή Folding@Home, τροποποιήθηκε με τη χρήση του CTM ώστε να μπορεί να τρέχει σε ATI GPUs.

Folding@Home

Στο τέλος του 2007, η ATI κυκλοφόρησε το ATI Stream SDK το οποίο αποτελούσε το πρώτο ολοκληρωμένο λογισμικό περιβάλλον ανάπτυξης εφαρμογών, για ATI GPUs. Με αυτό το SDK η ATI παρουσίασε μια καινούρια γλώσσα προγραμματισμού, την ATI Brook+, η οποία έκανε τη ζωή των προγραμματιστών ευκολότερη μιας και ήταν μια υψηλού επιπέδου γλώσσα.

ATI Stream SDK schematic

Στις αρχές του καλοκαιριού του 2008, η AMD σε συνεργασία με άλλες εταιρίες (συμπεριλαμβανόμενης και της Nvidia!) που ενδιαφέρονταν για την τεχνολογία GPGPU, κάτω από τον όμιλο Khronos (ο οποίος δημιουργήθηκε το 2000) σχημάτισαν το πρότυπο OpenCL (Open Computing Language), οι προδιαγραφές του οποίου καθορίστηκαν στο τέλος του ίδιου έτους. Το 2009, η AMD ανακοίνωσε ότι θα υιοθετήσει το πρότυπο OpenCL και θα ενσωματώσει τον αντίστοιχο μεταγλωττιστή (compliler) στο ATI Stream SDK.

Khronos group

Το OpenCL αποτελεί ένα ανοιχτό προγραμματιστικό πρότυπο για γενικού σκοπού υπολογισμούς, το οποίο είναι συμβατό με ετερογενή συστήματα. Δηλαδή μπορεί να χρησιμοποιηθεί παράλληλα τόσο σε CPUs όσο και σε GPUs. Το συγκεκριμένο πρότυπο, λόγω του ότι είναι ανοιχτό και δεν αποτελεί ένα ιδιόκτητο πρότυπο μιας συγκεκριμένης εταιρίας, είναι συμβατό με όλες τις πλατφόρμες υλικού.

Κυρίως λόγω του πρώιμου της ηλικίας του OpenCL, δεν έχουν διαφανεί καθαρά ακόμη τα πλεονεκτήματα/μειονεκτήματα του. Το κύριο χαρακτηριστικό πάντως που του δίνει σημαντικό προβάδισμα, είναι ότι πρόκειται για ένα πρότυπο που υποστηρίζεται από τους δύο μεγάλους κατασκευαστές GPUs και με την υποστήριξη αυτών, αλλά και πλήθους άλλων σημαντικών εταιριών που ανήκουν στον όμιλο Khronos, στο μέλλον σίγουρα θα επικρατήσει. Σύμφωνα πάντως με δηλώσεις αντιπροσώπων της η Nvidia, η οποία κατασκεύασε το CUDA, υποστηρίζει ότι OpenCL και το CUDA θα συναρπάξουν, τουλάχιστον για τα GPUs της ίδιας.

CUDA, η πρόταση της Nvidia

Το CUDA project ανακοινώθηκε μαζί με το G80 το Νοέμβριο του 2006 (την ίδια ακριβώς χρονική περίοδο που ανακοινώθηκε η αντίστοιχη πρόταση της τότε ATI, νυν AMD). Η πρώτη δημόσια beta έκδοση του CUDA SDK κυκλοφόρησε το Φεβρουάριο του 2007. Η έκδοση CUDA 1.1 έφερε τις διεργασίες του CUDA στους οδηγούς (drivers) της NVIDIA. Αυτό σήμαινε ότι από αυτή την έκδοση και μετά, κάθε πρόγραμμα που εκμεταλλευόταν το CUDA απαιτούσε μόνο μια κάρτα γραφικών της σειράς GeForce 8 και έκδοση οδηγών τουλάχιστον 169.xx.

Σήμερα, οι σύγχρονες εκδόσεις του CUDA (2.0 και μεταγενέστερες) επιτρέπουν την εκτέλεση κώδικα του CUDA σε κοινά CPUs. Αυτό διευκολύνει τους προγραμματιστές που δε διαθέτουν στην κατοχή τους το απαραίτητο υλικό, μιας και όπως προείπαμε το CUDA απευθύνεται αποκλειστικά και μόνο σε κάρτες γραφικών NVIDIA και δεν «τρέχει» σε άλλα GPUs (π.χ. ATI).

To Folding@Home μεταφέρθηκε φυσικά και στις NVIDIA GPUs

Τα κύρια πλεονεκτήματα της πλατφόρμας CUDA είναι τα εξής:

Η προγραμματιστική διεπαφή (interface) του CUDA βασίζεται στη γλώσσα C με μερικές επιπλέον προσθήκες, οι οποίες κάνουν την εκμάθηση του σχετικά εύκολη διαδικασία για κάποιον που έχει ασχοληθεί με την C.
Το CUDA παρέχει πρόσβαση σε 16 KB μνήμης (για κάθε επεξεργαστή), η οποία διαμοιράζεται από τα threads και μπορεί επίσης να χρησιμοποιηθεί ως μνήμη cache πολύ γρήγορης προσπέλασης.
Πολύ αποδοτική μεταφορά δεδομένων μεταξύ του συστήματος (CPU) και της μνήμης της/των GPU(s).
Δεν απαιτείται η χρήση των βιβλιοθηκών γραφικών (graphics API) για τον προγραμματισμό σε περιβάλλον CUDA.
Η διευθυνσιοδότηση της μνήμης της GPU γίνεται γραμμικά, ενώ το γράψιμο σε αυτή γίνεται αυθαίρετα.
Υποστήριξη σε επίπεδο υλικού για πράξεις ακέραιων (integer) και bit.

Οι κύριοι περιορισμοί του CUDA είναι:

Μη υποστήριξη αναδρομικών συναρτήσεων (δηλαδή μια συνάρτηση - function που καλεί τον εαυτό της).
Μέγεθος ελάχιστου unit block 32 threads.
Κλειστή αρχιτεκτονική διότι ανήκει στην NVIDIA (δηλαδή μην περιμένετε να υποστηρίξει/τρέξει σε ATI GPUs).

Όσον αφορά την πρόσβαση στη μνήμη, το CUDA υποστηρίζει το διασκορπισμό (scatter), δηλαδή την εγγραφή απεριόριστου αριθμού τιμών σε κάθε διεύθυνση της μνήμης. Αυτό το πλεονέκτημα επιτρέπει στα GPUs να εκτελούν μερικούς αλγόριθμους οι οποίοι δεν μπορούν να υλοποιηθούν αποδοτικά με προγραμματιστικούς μεθόδους GPCPUs, που βασίζονται αποκλειστικά σε βιβλιοθήκες γραφικών ρουτινών. Επιπλέον, το CUDA προσφέρει και τη δυνατότητα προγραμματισμού σε γλώσσα χαμηλού επιπέδου (assembler), για τους προγραμματιστές που θέλουν να έχουν άμεση πρόσβαση στο υλικό (δηλαδή τους real proffesionals). Σήμερα, αρκετές εφαρμογές που σχετίζονται με διάφορους τομείς εκμεταλεύονται το CUDA.

Διάφορες εφαρμογές που αναπτύχθηκαν με τη χρήση του CUDA

Ανάπτυξη εφαρμογών GPGPU – Συμπέρασμα

Σε αυτή την ενότητα θα αναφερθούμε πολύ περιληπτικά στο πώς προγραμματίζουμε, εκμεταλλευόμενοι την τεχνολογία GPGPU.

Nvidia Tesla GPU

Υποθέτουμε ότι γράφουμε ένα πρόγραμμα στο οποίο θα εκμεταλλευτούμε τη GPU (θεωρούμε ότι διαθέτουμε σύστημα με 1 CPU και 1 GPU) και χρησιμοποιώντας την τεχνολογία CUDA. Καταρχήν, μερικά κομμάτια του προγράμματος εκτελούνται στο CPU (Host) και μερικά στη GPU (Device). Τα κομμάτια του κώδικα (functions) που απαιτούν ταχύτητα και είναι κατάλληλα να εκτελεστούν από τη GPU, τα ονομάζουμε πυρήνες (Kernels).

Ένα Kernel μπορεί να εκτελεστεί ταυτόχρονα από μια συστοιχία threads. Το κάθε thread τρέχει τον ίδιο κώδικα και το καθένα από αυτά έχει ένα αναγνωριστικό (ID), το οποίο χρησιμοποιεί για τη διευθυνσιοδότηση της μνήμης που χρησιμοποιεί και για να πάρει αποφάσεις ελέγχου. Τα threads έχουν τη δυνατότητα συνεργασίας μεταξύ τους, έτσι ώστε να αποφεύγονται οι ίδιοι υπολογισμοί και να μειώνεται ο χρόνος εκτέλεσης.

CUDA parallel threads

Το κάθε kernel εκτελείται από ένα πλέγμα (grid) από thread blocks. Ένα thread block αποτελείται από έναν αριθμό threads τα οποία, όπως προαναφέρθηκε, έχουν τη δυνατότητα της μεταξύ τους συνεργασίας, μέσω του διαμερισμού των δεδομένων που υπάρχουν στην κοινή μνήμη του block και του συγχρονισμού της εκτέλεσής τους.

Threads από διαφορετικά blocks δεν μπορούν να συνεργαστούν μεταξύ τους.

CUDA Grid

Το υλικό (δηλαδή η GPU) μπορεί να προγραμματίσει σε ποιον επεξεργαστή θα εκτελεστεί το κάθε thread. Ένα kernel εκτελείται παράλληλα σε πολλούς multiprocessors.

Kernel execution

Πολύ περιληπτικά λοιπόν, όταν θέλουμε να εκτελέσουμε μερικά kernels τους προγράμματός μας στη GPU, δεσμεύουμε μνήμη στο Ηost (CPU) και στο Device (GPU), αντιγράφουμε τα προς επεξεργασία δεδομένα-μεταβλητές στο Device, εκτελούμε το kernel στο Device και όταν τελειώσει η εκτέλεση τότε αντιγράφουμε τα δεδομένα (τα αποτελέσματα δηλαδή) στη μνήμη του Host. Τέλος, απελευθερώνουμε τη μνήμη που χρησιμοποιήσαμε στο Device. Η όλη διαδικασία μπορεί να φαίνεται εύκολη αλλά δυστυχώς δεν είναι. Επίσης, ο προγραμματιστής πρέπει να σκέφτεται με τη λογική των multi-threads για να εκμεταλλευτεί ουσιαστικά την ισχύ που του παρέχει η GPU.

Η ισχύς των GPUs στο "σπάσιμο" του WPA_PSK

Η τεχνολογία GPGPU υπόσχεται να δώσει απλόχερα την ισχύ και τις δυνατότητες παράλληλης επεξεργασίες που μέχρι σήμερα κατείχαν οι υπερ-υπολογιστές, με τους εκατοντάδες επεξεργαστές, όχι μόνο σε ερευνητικά ιδρύματα και επιστήμονες αλλά και στο απλό κοινό-προγραμματιστές. Πρόκειται αν μη τι άλλο για μια πολύ ενδιαφέρουσα προοπτική και περιμένουμε να υιοθετηθούν και άλλες γλώσσες υψηλού επιπέδου, με πιο πολλές δυνατότητες από την ξεπερασμένη πια C. Ήδη η Nvidia έχει υποσχεθεί ότι θα υποστηρίξει πλήρως τη C++ και μελλοντικά τη Fortran (η οποία χρησιμοποιείται κατά κόρον από την ερευνητική κοινότητα) και τη Java. Επίσης, ήδη μεμονωμένοι χρήστες έχουν καταφέρει να βρουν τρόπους να εκμεταλλευτούν τα APIs του CUDA και σε άλλες γνωστές γλώσσες προγραμματισμού όπως η Delphi.

Athanasios2104 · Δεκέμβριος 20, 2009

Πολύ καλό review, αν και στην τελευταία σελίδα σε έχασα (ηλεκτρολόγος μηχανικός μεν, Ενεργειακός τομέας δε ).

Όσον αφορά τα games και σχετικό με το GPGPU, είναι κάτι που είχα διαβάσει πριν χρόνια σε ένα περιοδικό/site (δεν θυμάμαι), σχετικά με το AI (Artificial Intelligence) στα παιχνίδια και δη στα FPS.

Έλεγε λοιπόν ο τύπος στη συνέντευξη ότι ο κώδικας για το ΑΙ κυριολεκτικά "πετσοκόβεται" στο final (gold) product, γιατί πολύ απλά αν δεν το πετσοκόψουν οι προγραμματιστές, θα σέρνεται το σύστημα. Ναι μεν δηλαδή το botaki θα συμπεριφέρεται πολύ ρεαλιστικά και σαν "άνθρωπος-παίχτης", άλλα θα πας με 1 άντε 2 fps. Νομίζω έφερνε κι όλας σαν παράδειγμα το Unreal ή το Quake.

Και κατέληγε στην εξής σκέψη (που μου έκανε εντύπωση): "Όταν θα υπάρξει ξεχωριστό chip στο σύστημα που θα επεξεργάζεται μόνο το AI, όπως υπάρχει ήδη για τον ήχο (sound cards), τότε τα παιχνίδια θα αλλάξουν εντελώς όψη".

Δεν ξέρω αν είχε υπόψη του το GPGPU, άλλα νομίζω ότι πλέον αυτό το πράγμα (επεξεργασία ΑΙ από την GPU) είναι δυνατόν. Μένει μόνο να δούμε τις αντίστοιχες υλοποιήσεις .

Arxagelos · Δεκέμβριος 20, 2009

Πρωτοπορεί και πρωτοτυπεί η πράσινη τα τελευταία χρόνια.

Καλά πόσα threads παράλληλα είπαμε? χιλιάδες? και πόσα έχουμε τους intel? 4? άντε γειά! ΑΝΤΕ ΓΕΙΑ. Βλέπει η Intel οτι η πράσινη πάει να της φάει το ψωμί γι αυτό έχει λυσσάξει με το Larabee.

BilloukosGR · Δεκέμβριος 20, 2009

Πρωτοπορεί και πρωτοτυπεί η πράσινη τα τελευταία χρόνια.
Καλά πόσα threads παράλληλα είπαμε? χιλιάδες? και πόσα έχουμε τους intel? 4? άντε γειά! ΑΝΤΕ ΓΕΙΑ. Βλέπει η Intel οτι η πράσινη πάει να της φάει το ψωμί γι αυτό έχει λυσσάξει με το Larabee.

Άλλο stream processor και άλλο αυτό που ονομάζει η intel thread... σε καμία περίπτωση δεν μπορεί να αντικαταστήσει το ένα το άλλο... τουλάχιστον σε προγραμματιστικό επίπεδο σήμερα είναι άπιαστο όνειρο για βασικές εφαρμογές...

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

crmaris · Δεκέμβριος 20, 2009

ήδη όμως υπάρχουν ερευνητικές εφαρμογές που εκμεταλεύονται στο έπακρον τα stream processors και ρίχνουν στα αυτιά στους κοινούς επεξεργαστές. Όταν υπάρξει και full υποστήριξη IDE προγραμ. πακέτων τότε θα αλλάξουν πολλά στην προγραμματιστική κοινότητα.

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

LevelOne · Δεκέμβριος 20, 2009

ήδη όμως υπάρχουν ερευνητικές εφαρμογές που εκμεταλεύονται στο έπακρον τα stream processors και ρίχνουν στα αυτιά στους κοινούς επεξεργαστές. Όταν υπάρξει και full υποστήριξη IDE προγραμ. πακέτων τότε θα αλλάξουν πολλά στην προγραμματιστική κοινότητα.
Βασικά πρέπει να βγει (δεν πιστεύω ότι θα αργήσει) το κατάλληλο middleware που θα κρύβει την πολυπλοκότητα του hardware των GPUs και θα επιτρέπει στον κάθε προγραμματιστή να ασχολείται μόνο με την λογική του προγράμματος που γράφει και όχι και με το υλικό στο οποίο αυτό θα τρέχει.

Οπως πχ. το FASTRA απο το Πανεπιστήμιο της/του Antwerp...

Οσοι δεν το έχετε δεί, ριξτε μια ματιά...

Jaco · Δεκέμβριος 20, 2009

Ακόμα είναι σε μετάβαση η cuda και δυστυχώς πάνε να την κάνουν c++ χωρίς λόγο... θα έπρεπε να την αφήσουν c και low level, εξάλλου υπάρχουν ήδη wrappers για την c++... αυτό το oop σε τέτοια συστήματα είναι άχρηστο και πιθανόν να μην υποστηρίζεται καν από το hardware, εκτός και αν έχουν σκοπό να λανσάρουν αργότερα την cuda++ με καινούργιο hw... απλά τα πράγματα, στο επίπεδο αυτό μπορούμε να ζήσουμε χωρίς overloading, inheritance και polymorphism...

Επίσης ένα άλλο θέμα το οποίο υπάρχει, είναι η ταχύτητα μεταφοράς δεδομένων στην μνήμη... επειδή η cuda (υποθέτω και η ati αντίστοιχα) δεν υποστηρίζουν linker, ο κώδικας δεν εκτελείται εξ' ολοκλήρου στην κάρτα... αντίθετα είναι ένα executable που γίνεται linked σε x86 και απλά έχει πρόσβαση στο hardware μέσω του api... τελικά το πρόβλημα με αυτό είναι ότι όταν θέλει κάποιος να μεταφέρει μεγάλα blocks μνήμης από την ram του λειτουργικού, στην ram της κάρτας και ξανά πίσω μετά από την επεξεργασία, ο χρόνος είναι πολύ μεγάλος και τελικά πολύ μεγαλύτερος από την επεξεργασία την ίδια... επομένως, αυτό περιορίζει και το εύρος εφαρμογής των gpgpu σε διαδικασίες που απαιτούν μικρή είσοδο δεδομένων, επεξεργασία με μεγάλο expansion και χρήση μνήμης και λίγα δεδομένα σαν αποτέλεσμα στην έξοδο... Γι' αυτό και σε εφαρμογές encoding ή decoding με μεγάλο όγκο δεδομένων, δεν μπορούν να προσφέρουν, όσο μπορούν σε post-processing, όπως φίλτρα, dsp κτλ...

Τέλος ένα πράγμα το οποίο είναι πρόβλημα, είναι ότι δεν υποστηρίζεται από το hw το double precision floats (εκτός από τις νέες σειρές, αλλά τι να το κάνεις αν έχεις ήδη κάρτα πριν από την 260/70/80)... πράγμα το οποίο, ενώ δεν χρειάζεται πραγματικά στην χρήση της κάρτας για την απεικόνιση των γραφικών, για μαθηματικές πράξεις είναι πολύ σημαντικό... για παράδειγμα επειδή τώρα η cuda περιορίζεται σε 24-bit floats χρειάζονται σχεδόν 1/4 πράξεις παραπάνω απ' ότι με μια cpu... επίσης ακόμα και οι νέες κάρτες δεν είναι απόλυτα συμβατές με το IEEE-754, το οποίο υλοποιείται από τους επεξεργαστές...

Τα πράγματα γενικά είναι σε καλό δρόμο... απλά επειδή είναι κομβικό σημείο, δεν πρέπει να χαθεί ο στόχος... δεν πρέπει να σπαταλήσουν χρόνο ώστε το gpgpu να γίνει ένα sdk το οποίο θα μπορεί να γράφει κάποιος από με C# ή άλλες τέτοιες παρωδίες... το μοναδικό που θα καταφέρουν έτσι είναι μια μακαρονάδα από api, με overhead και περιττή πολυπλοκότητα...

Edit...: Βασικά η ήττα έρχεται όταν θελήσεις να κάνεις κάτι πραγματικά χρήσιμο με την cuda, το οποίο απαιτεί σε μέγιστο βαθμό την παράλληλη επεξεργασία και την ταχύτητα... έτσι την μεγάλη ήττα με το gpgpu και τους περιορισμούς, την έφαγα όταν ξεκίνησα με έναν φίλο να γράφουμε ένα Bayer filter mosaic, το οποίο θα έπαιρνε τα raw data από μια φωτογραφία (δηλαδή την ακριβή πληροφορία του sensor της dslr) και θα έβγαζε στην έξοδο την φωτογραφία... το τέλος της προσπάθειας ήρθε όταν βρεθήκαμε αντιμέτωποι με τη αργή μεταφορά των δεδομένων από την ram στην κάρτα και αντίστροφα... τεράστιος χρόνος, για τόσο μεγάλα δεδομένα... επίσης ο περιορισμός με τo double-precision, ήταν αρκετός για να μην ολοκληρωθεί ποτέ ένα project για super-pi σε cuda (τουλάχιστον με αξιοπρέπεια)...

leonbis2000 · Δεκέμβριος 20, 2009

Η αεροπορία των ΗΠΑ πάντως χρησιμοποιεί 336 κονσόλες PS3 σε parallel computing για έρευνα στην εναέρια παρακολούθηση.

chameleon · Δεκέμβριος 20, 2009

Ευχαριστώ για το άρθρο, γιατί σαν OpenGL και C++ χομπίστας προγραμματιστής, μου είναι χρήσιμο ένα γρήγορο intro στο OpenCL.

Οι παρατηρήσεις μου:

1. COMPILER: Είναι μ@λ@κια ένας προγραμματιστής να ασχολείται με τις συσκευές εκτός κι αν είναι προγραμματιστής hardware driver. Σκεφτείτε ότι ακόμα και στα 3d γραφικά δεν ασχολείσαι με το τι κάρτα έχεις (εκτός κι αν θέλεις να κάνεις κάτι πολύ εξεζητημένο). Ο προγραμματιστής πρέπει απλά να γράφει κώδικα βελτιστοποιημένο για multithreading. Το αν αυτός ο κώδικας θα τρέχει στη CPU ή στη GPU θα έπρεπε να είναι καθαρά θέμα compiler. Αντιλαμβάνομαι όμως ότι αυτό δεν είναι πάντα εφικτό.

2. Μαρκάρισμα κώδικα: Προκειμένου να γίνει εφικτό, θα έπρεπε να "μαρκαριστούν" ορισμένα block κώδικα είτε με κλήσεις σε κάποιο API (όπως π.χ. η EnterCriticalSection()/LeaveCriticalSection() ) είτε ακόμα καλύτερα με ειδικά definitions προς τον compiler (π.χ. #start_cpu_or_gpu_block_code). Το "μαρκάρισμα" (μαζί ίσως με κάποιες παραμέτρους) θα έλεγε στον compiler ότι το κομμάτι κώδικα θα πρέπει να εκτελείται είτε από CPU είτε από GPU, ανάλογα με το τι υπάρχει στο σύστημα.

3. C++: Τι εννοούνε ότι υποστηρίζουν τη C και ίσως υποστηρίξουν και τη C++; Δεν μπορούν απλά (είτε αυτοί είτε ο οποιοσδήποτε) να φτιάξουν wrapper κλάσεις;

4. Αν χρειάζεται να γραφεί κώδικας 2 φορές, μια για CPU και μια για GPU, τότε να ξέρετε ότι μόνο δυνατά προγράμματα θα χρησιμοποιήσουν τη μέθοδο. Δεν θα ξεκολλιαστεί ο χομπίστας προγραμματιστής να γράφει κώδικα 2 φορές. Για το λόγο αυτό όπως είπα, πρέπει να γράφεται μια φορά ο κώδικας και ο compiler να αναλαμβάνει τα υπόλοιπα.

Θα παρακαλούσα τον συγγραφέα ή και όποιον έχει εντρυφήσει προγραμματιστικά πάνω στο θέμα του OpenCL, να μου εξηγήσει αν αυτά που γράφω δύναται να πραγματοποιηθούν ή όχι.

Ευχαριστώ πολύ και πάλι για το intro.

crmaris · Δεκέμβριος 20, 2009

με το OpenCL δεν έχω ασχοληθεί οπότε δεν μπορώ να σε διαφωτίσω δυστυχώς. Από ότι ξέρω στο CUDA κάνεις κλήσεις σε κάποιο API για να πας σε GPU mode (το ίδιο κατά 99% γίνεται και στο OpenCL), οπότε μέσα στο δικό σου πρόγραμμα διαχωρίζεις τι θα τρέξει στο CPU και τι στο GPU.

π.χ. ένα παράδειγμα κώδικα σε Delphi που εκμεταλεύεται το CUDA.

try

SetLength(hostmem,sizeof(cufftComplex)*ALen*ABatch);

...................

rc := cufftPlan1d(plan, ALen, CUFFT_C2C, Abatch); {εδώ καλείτε η cufftPlan1d που εκμεταλεύεται το CUDA API}

//η cufftPlan1d που καλεί κατευθείαν το custom CUDA API (cufftPlan1d.dll) μέσω της stdcall

function cufftPlan1d(var plan: cufftHandle;

nx: Integer;

atype: Byte;

batch: Integer): cufftResult; stdcall ; external DLLNAME name 'cufftPlan1d';

Jaco · Δεκέμβριος 20, 2009

Edit, γιατί πόσταρα ταυτόχρονα με τον crmaris...

@Chameleon

Ότι λέω παρακάτω δεν ξέρω αν ισχύει για την opencl, γιατί δεν έχω ασχοληθεί καθόλου...

1. Αυτό που λες έχει να κάνει με το direct3d api των windows... το πρόγραμμα που κάνει calls στο direct3d περιμένει από κάποια (οποιαδήποτε) συσκευή να τα καταλάβει και να τα εκτελέσει... αυτό το αναλαμβάνουν οι drivers της κάρτας γραφικών που στην ουσία έχουν έναν wrapper για το direct3d και μετατρέπουν εσωτερικά τα calls σε αντίστοιχα τα οποία καταλαβαίνει η gpu... το βασικότερο πρόβλημα με τις gpu είναι ότι δεν έχουν κάποιο assembly το οποίο τρέχουν τοπικά, απλά ο compiler της cuda φτιάχνει ένα assembly σε χ86, το οποίο περιέχει τα calls στους drivers που θα αναλάβουν την επικοινωνία με την κάρτα (cudart.dll και cutil32.dll πχ)... δηλαδή στην τελική διαδικασία εμπλέκονται δυο compiler, ένας για την gpu και ένας για την cpu... στην περίπτωση του opencl, αν έχω καταλάβει θέλουν να τα ενοποιήσουν κατά κάποιο τρόπο, αλλά πάλι το πρόβλημα με τους ενδιάμεσους wrappers δεν θα αποφευχθεί...

2. Τουλάχιστον στην cuda υπάρχουν εντολές στον pre-processor του compiler, που του υποδεικνύουν ποια μέρη του κώδικα θα επεξεργαστεί ο x86 compiler και ποια ο compiler της cuda...

3. Κανονικά η υποστήριξη της C++, σημαίνει ότι πρέπει να υποστηρίξουν και την standard library της, όπως τα STL containers και STL algorithms της C++, όπως ορίζεται από τα standards... δεν ξέρω κατά πόσο έχει νόημα αυτό και αν μπορεί να γίνει με αυτό το hardware... άγνωστο γιατί προσπαθούν καν...

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

crmaris · Δεκέμβριος 20, 2009

για όποιον θέλει να διαβάσει περισσότερα για το CUDA επισυνάπτω ένα paper που δημοσίευσαν οι προγραμματιστές της NVIDIA που το δημιούργησαν. Αναφέρει γιατί επιλέξαν το συγκεκριμένο compiler.

cuda.doc

crmaris · Δεκέμβριος 20, 2009

σύμφωνα με το paper η C++ υποστηρίζεται αλλά ο κώδικάς της μετατρέπεται σε C από τον compiler. Κάτι λέγαν πάντως ότι θα υποστηρίζεται μελλοντικά χωρίς μετάφραση σε C και θα προγραμματίζει κανείς μέσω Visual Studio κανονικά (οπότε κάτι παρόμοιο με το NET δε βλέπω να το γλυτώνουμε).

Jaco · Δεκέμβριος 20, 2009

Δεν υποστηρίζεται η c++ ακριβώς... μάλλον το γράφουν για ευκολία κατανόησης...

Για παράδειγμα ενώ υπάρχουν types όπως τα vectors που ανήκουν ουσιαστικά στα STL containers της c++ και χρησιμοποιούνται σαν arguments για να κάνουν την μεταφορά των δεδομένων από και προς την κάρτα, ουσιαστικά τα χειρίζεται ο compiler της cuda και όχι ο x86... εσωτερικά αυτοί μπορούν να κάνουν ότι θέλουν, γιατί δεν υλοποιούν συγκεκριμένα standards που διέπουν τους ansi c compiler...

chameleon · Δεκέμβριος 20, 2009

Για αποφυγή παρεξηγήσεων, στο άρθρο περιγράφω το "πως πιστεύω ότι θα έπρεπε να είναι".

2. Τουλάχιστον στην cuda υπάρχουν εντολές στον pre-processor του compiler, που του υποδεικνύουν ποια μέρη του κώδικα θα επεξεργαστεί ο x86 compiler και ποια ο compiler της cuda...

Χαζό μου φαίνεται. Κι αν πας να τρέξεις το πρόγραμμα σε περιβάλλον δίχως GPU; FAIL!!!

Με κάποιο τρόπο θα έπρεπε τα συγκεκριμένα κομμάτια κώδικα να γίνονται compile και σε x86 και σε GPU-something binary code. Και από κει και πέρα ανάλογα αν έχεις GPU ή όχι και ανάλογα το πόσο φορτωμένη είναι εκείνη τη στιγμή, να τρέχει ο κώδικας είτε στη CPU, είτε στη GPU. Το λειτουργικό αποφασίζει. Ακριβώς όπως σε ποιο CPU θα τρέξει κάποιο thread.

3. Κανονικά η υποστήριξη της C++, σημαίνει ότι πρέπει να υποστηρίξουν και την standard library της, όπως τα STL containers και STL algorithms της C++, όπως ορίζεται από τα standards... δεν ξέρω κατά πόσο έχει νόημα αυτό και αν μπορεί να γίνει με αυτό το hardware... άγνωστο γιατί προσπαθούν καν...

Μπλιαξ.

Το αστείο είναι ότι θέλουν να το κάνουν και για Java. Εεεε... Δεν τους έχει πει κανείς ότι το binary της Java πρέπει να είναι cross-platform;

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

Κακώς δεν είναι.

Αλλά μην είσαι τόσο καταστροφολόγος.

Ένας εξαιρετικά πολύπλοκος compiler δε σημαίνει ότι παράγει bloated binary code.

crmaris · Δεκέμβριος 20, 2009

Δεν υποστηρίζεται η c++ ακριβώς... μάλλον το γράφουν για ευκολία κατανόησης...
Για παράδειγμα ενώ υπάρχουν types όπως τα vectors που ανήκουν ουσιαστικά στα STL containers της c++ και χρησιμοποιούνται σαν arguments για να κάνουν την μεταφορά των δεδομένων από και προς την κάρτα, ουσιαστικά τα χειρίζεται ο compiler της cuda και όχι ο x86... εσωτερικά αυτοί μπορούν να κάνουν ότι θέλουν, γιατί δεν υλοποιούν συγκεκριμένα standards που διέπουν τους ansi c compiler...

αυτό τότε δε λέγεται ευκολία κατανόησης αλλά παραπλάνηση ή false info

crmaris · Δεκέμβριος 20, 2009

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

Κατασκευάζεται ως ένα πολυπύρηνο σύστημα και θα ακολουθεί την αρχιτεκτονική x86, κάτι που σημαίνει ότι θα προγραμματίζεται μέσω του x86 instruction set
Ο κάθε core θα έχει αποκλειστική L1 cache και θα υπάρχει και μια global L2 cache
Θα κάνει εύκολα scale σε ένα μεγάλο αριθμό cores (φημολογείται για χιλιάδες!)
Είναι διαφορετικό σε σχέση με τις προσεγγίσεις NVIDIA/AMD όπου η GPU θεωρείται ένας ξεχωριστός συν-επεξεργαστής ο οποίος είναι προσκολημένος στο main CPU και μπορούμε να έχουμε max έναν περιορισμένο αριθμό GPUs.
Η μνήμη στα Larrabe θα είναι shared ανάμεσα σε ολους τους πυρήνες.
Θα έχει διαθέσιμο έναν ολοκληρωμένο C/C++ compiler και όπως προείπα θα είναι συμβατός με το x86 Instruction Set.
Φημολογείται ότι θα υποστηρίζει standard debuggers.
O κάθε πυρήνας θα υποστηρίζει 4-way ταυτόχρονα multithreading.

Να σημειώσω ότι τίποτα από τα παραπάνω δεν είναι σίγουρο αν δε βγει πρώτα. Πάντως υπόσχεται πολλά!

Jaco · Δεκέμβριος 20, 2009

Με κάποιο τρόπο θα έπρεπε τα συγκεκριμένα κομμάτια κώδικα να γίνονται compile και σε x86 και σε GPU-something binary code. Και από κει και πέρα ανάλογα αν έχεις GPU ή όχι και ανάλογα το πόσο φορτωμένη είναι εκείνη τη στιγμή, να τρέχει ο κώδικας είτε στη CPU, είτε στη GPU. Το λειτουργικό αποφασίζει. Ακριβώς όπως σε ποιο CPU θα τρέξει κάποιο thread.

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

Το αστείο είναι ότι θέλουν να το κάνουν και για Java. Εεεε... Δεν τους έχει πει κανείς ότι το binary της Java πρέπει να είναι cross-platform;

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

Αλλά μην είσαι τόσο καταστροφολόγος.
Ένας εξαιρετικά πολύπλοκος compiler δε σημαίνει ότι παράγει bloated binary code.

Θα δείξει... εδώ οι κλασσικοί compilers που χρησιμοποιούμε έχουν φάει χρόνια και χρόνια ανάπτυξης για να φτάσουν στην σημερινή τους μορφή...

αυτό τότε δε λέγεται ευκολία κατανόησης αλλά παραπλάνηση ή false info

Γι' αυτό δεν ξέρω... μπορεί, αλλά είναι τέτοιος ο χώρος και η εξέλιξη του, που μάλλον δεν γίνεται αλλιώς...

Επειδή δεν έχω τώρα cuda εγκατεστημένη, υπάρχει ένα καλό τεστ, το οποίο δεν το είχα δοκιμάσει... δοκίμασε λοιπόν, να δεις που γίνονται define τα containers μέσα από την lib της cuda... λογικά θα βρεις ότι τα containers που φαινομενικά ανήκουν στην c++, γίνονται define σε κάτι άλλο... αν αυτό είναι κρυμμένο στον compiler, δεν θα το δεις, οπότε για να το εξακριβώσεις μπορείς επίσης να χρησιμοποιήσεις κάποια member functions των vector containers, στον κώδικά σου, όπως πχ modifiers και μετά να κάνεις compile... επειδή δεν θα έχουν κάνει full implementation όλου του class template, κάπου θα χτυπήσει...

Edit: Βασικά, με τον τρόπο αυτό μπορείς να δεις και αν τα containers που χρησιμοποιεί η cuda, είναι built-in types στον compiler ή αν είναι abstract types που ορίζονται από βιβλιοθήκες... γμτ, τώρα πάει να με πιάσει μια φαγούρα να το δω, αλλά θα πρέπει να βγάλω την ati, να βάλω ξανά την nvidia, να περάσω drivers κλπ, κλπ... η θέληση δυνατή, αλλά η διαδικασία αποτρεπτική...

chameleon · Δεκέμβριος 20, 2009

ενδιαφέρον πάντως παρουσιάζει το επερχόμενο Larrabee για το οποίο ακούγονται πολλά καλά όπως:
Κατασκευάζεται ως ένα πολυπύρηνο σύστημα και θα ακολουθεί την αρχιτεκτονική x86, κάτι που σημαίνει ότι θα προγραμματίζεται μέσω του x86 instruction set
Ο κάθε core θα έχει αποκλειστική L1 cache και θα υπάρχει και μια global L2 cache
Θα κάνει εύκολα scale σε ένα μεγάλο αριθμό cores (φημολογείται για χιλιάδες!)
Είναι διαφορετικό σε σχέση με τις προσεγγίσεις NVIDIA/AMD όπου η GPU θεωρείται ένας ξεχωριστός συν-επεξεργαστής ο οποίος είναι προσκολημένος στο main CPU και μπορούμε να έχουμε max έναν περιορισμένο αριθμό GPUs.
Η μνήμη στα Larrabe θα είναι shared ανάμεσα σε ολους τους πυρήνες.
Θα έχει διαθέσιμο έναν ολοκληρωμένο C/C++ compiler και όπως προείπα θα είναι συμβατός με το x86 Instruction Set.
Φημολογείται ότι θα υποστηρίζει standard debuggers.
O κάθε πυρήνας θα υποστηρίζει 4-way ταυτόχρονα multithreading.
Να σημειώσω ότι τίποτα από τα παραπάνω δεν είναι σίγουρο αν δε βγει πρώτα. Πάντως υπόσχεται πολλά!

Για ένα χομπίστα προγραμματιστή ακούγονται πολύ καλά.

Αλλά και για μια εταιρία software είναι καλά καθώς δεν θα πληρώνει λεφτά για να γράφει τον κώδικά της και για CPU και για GPU.

Η όλη ιστορία θυμίζει την κωλοεποχή που οι εταιρίες παιχνιδιών έπρεπε να γράφουν κώδικα για κάθε κάρτα γραφικών. Μέχρι που η SGI έβγαλε το OpenGL. Ε! τότε ήρθε η Microsoft που τα γ@μ@ει όλα και έβγαλε το DirectX μόνο και μόνο επειδή ήθελε να το ελέγχει 100%.

Petrossortep · Δεκέμβριος 20, 2009

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

Κατασκευάζεται ως ένα πολυπύρηνο σύστημα και θα ακολουθεί την αρχιτεκτονική x86, κάτι που σημαίνει ότι θα προγραμματίζεται μέσω του x86 instruction set

Ο κάθε core θα έχει αποκλειστική L1 cache και θα υπάρχει και μια global L2 cache

Θα κάνει εύκολα scale σε ένα μεγάλο αριθμό cores (φημολογείται για χιλιάδες!)

Είναι διαφορετικό σε σχέση με τις προσεγγίσεις NVIDIA/AMD όπου η GPU θεωρείται ένας ξεχωριστός συν-επεξεργαστής ο οποίος είναι προσκολημένος στο main CPU και μπορούμε να έχουμε max έναν περιορισμένο αριθμό GPUs.

Η μνήμη στα Larrabe θα είναι shared ανάμεσα σε ολους τους πυρήνες.

Θα έχει διαθέσιμο έναν ολοκληρωμένο C/C++ compiler και όπως προείπα θα είναι συμβατός με το x86 Instruction Set.

Φημολογείται ότι θα υποστηρίζει standard debuggers.

O κάθε πυρήνας θα υποστηρίζει 4-way ταυτόχρονα multithreading.

Να σημειώσω ότι τίποτα από τα παραπάνω δεν είναι σίγουρο αν δε βγει πρώτα. Πάντως υπόσχεται πολλά!

Πρωτοπορεί και πρωτοτυπεί η πράσινη τα τελευταία χρόνια.
Καλά πόσα threads παράλληλα είπαμε? χιλιάδες? και πόσα έχουμε τους intel? 4? άντε γειά! ΑΝΤΕ ΓΕΙΑ. Βλέπει η Intel οτι η πράσινη πάει να της φάει το ψωμί γι αυτό έχει λυσσάξει με το Larabee.

Αν και έχω ελάχιστη σχέση με προγραμματισμό νομίζω ότι ο Αρχάγγελος το έχει πιάσει σωστά. Πού είναι ο Larabee για να δούμε όλα όσα προσφέρει;

Γιατί ακούμε μόνο "απειλητικές" δηλώσεις από την Ίντελ του στυλ "Θα σας σβήσω όλους" και προϊόν δεν βλέπουμε, ούτε ακούμε νέα του;

Ακούστε προσεκτικά τον CEO της Nvidia να κάνει απολύτως εύστοχα σχόλια σχετικά με τον Larabee:

"Είναι άδικο να συγκρίνουμε τον Λάραμπι με την ιστορία"

Εννοώντας τις τωρινές κάρτες, γιατί μέχρι να βγει ο Λάραμπι οι τωρινές κάρτες θα αποτελούν παρελθόν.

Σε άλλη συνέντευξή του. "Έχουμε ήδη φτιάξει τον Λάραμπι". Οι σύγχρονες GPU είναι όντως ένα είδος Λάραμπι.

"Λοιπόν x86. Ποιό είναι το νούμερο ένα όφελος της x86;Συμβατότητα κώδικα(binary combatibility).

Έτσι δεν είναι;Κανένας δεν έχει πει ότι αν δημιουργήσω μια καινούργια αρχιτεκτονική αυτή θα είναι η x86".

Και συνεχίζει

"Το ερώτημα λοιπόν είναι το εξής: Είναι ο Λάραμπι συμβατός με windows 64bit(σσ να τρέξεις word ας πούμε), είναι συμβατός με sse3-4-5-6; Η απάντηση είναι ΟΧΙ. Και τότε ποιό είναι το όφελος. Εργαλεία(tools) έχουν όλες οι CPU"

"Το θέμα είναι ότι και εμείς πιστεύουμε στο σετ x86 γιατί θέλουμε συνεργασία cpu-gpu".

Προσωπικά από τότε που άρχισα να ακούω πίπες για ray-tracing και τα συναφή άρχισα να ψιλιάζομαι ότι κάτι δεν πάει καλά με τις συγκεκριμένες ανακοινώσεις της intel. Έχω έντονες αμφιβολίες για το αν θα βγει σαν ξεχωριστή κάρτα.

Sign In

GPGPU - Η δύναμη των GPUs στα χέρια σας

Recommended Posts

crmaris

Athanasios2104

Arxagelos

BilloukosGR

crmaris

LevelOne

Jaco

leonbis2000

chameleon

crmaris

Jaco

crmaris

crmaris

Jaco

chameleon

crmaris

crmaris

Jaco

chameleon

Petrossortep

Archived

Similar Content

DeepSeek: Επαναστατική προσέγγιση στην εκπαίδευση AI με 671 δισεκατομμύρια παραμέτρους

Η RTX 5080 μπορεί να είναι πιο αργή από την RTX 4090, σύμφωνα με πληροφορίες

Asus BTF 2.0: Το μέλλον των GPUs χωρίς καλώδια ρεύματος

AMD και Nvidia πρωταγωνιστούν στη Steam Survey του Δεκεμβρίου: Οι τάσεις σε CPUs, GPUs και λογισμικό

Η Intel κάνει τη διαφορά: Από gaming GPU σε εργαλείο AI υπολογισμών

Αρχική

Blogs

Νέο Περιεχόμενο

Important Information