Intel 13th +14th Gen Core, Raptor-Lake & Z790 (2022) [LGA1700]

[kostas_anes]

23 λεπτά πριν, Herald είπε

Εκεί είναι το θέμα. Γενικά αν πας να κάνεις optimize το X cpu γιατί έχει πολλούς πυρήνες, θα επωφεληθούν όλα τα CPU που έχουν πολλούς πυρήνες, ειτε είναι της amd είτε της intel. 

Έτσι τουλάχιστον το έχω κατά νου. 

Το optimization per application basis, οπως ειναι τα patches στα παιχνιδια, δεν εχουν να κανουν με το optimization σε drivers, ειναι δυο διαφορετικα πραγματα. 

Ο driver, οταν λαβει ενα command: draw poly(123,67,2) -> apply texture(%planet%) θα το μεταφρασει σε γλωσσα μηχανης και αναλογα την αρχιτεκτονικη της GPU θα προσπαθησει να το κανει με τα καταλληλα instruction ετσι ωστε να παρει τον λιγοτερο χρονο. Αν μια αρχιτεκτονικη πχ μπορει να κανει drawing και texturing παραλληλα, ο driver θα τα παραλληλησει, ενω σε μια αλλη που μπορει να εκτελεσει μονο σειριακα αυτες τις λειτουργιες, θα φτιαξει το καταλληλο dataflow ετσι ωστε το texture unit πχ να μην μενει αχρησιμοποιητο (να τρεχει κατι αλλο), ενω τρεχει το draw polygon. 

Αυτα γενικα αφορουν διαχειρηση σε hardware επιπεδο. 

Το να γραψω optimized κωδικα για μια αρχιτεκτονικη δεν παταει πανω στον driver. Παταει πανω στο τι κωδικα γραφω και τι compiler χηρσιμοποιω. Πχ, αν θελω να κανω (3*5)+5, μπορω να το γραψω με τον πολυ απλο τροπο που θα χρησιμοποιησει x86-64 και θα τρεχει παντου ή μπορω να χρησιμοποιησω FMA (Fused Multiply Add), που εχουν ολα τα σύγχρονα CPU της τελευταιας 15ετιας+ και να τρεξει σε 1 cycle αντι για 2. 

Περαν αυτου, μπορω να γραψω κωδικα ο οποιος κανει πολυ αποτελεσματικη χρηση μνημης και επαναχρησιμοποιει σετ δεδομενων, μειωνοντας και το αποτυπομα στην μνημη και τον χρονο προσβασης, μπορω επισης να γραψω τον ιδιο κωδικα με την καθε συναρτηση πχ να αρχικοποιει εκ νεου τα δεδομενα και να υπαρχει το ιδιο σετ δεδομενων 10 φορες στην μνημη, για 10 διαφορετικες συναρτησεις. 

Θα επηρεασει ολα τα CPU; Σιγουρα, οτι αλλαγη και να κανεις θα εχει παντου μια διαφορα. Στο συγκεκριμενο παραδειγμα ομως, θα ειναι τρομερη η διαφορα σε μια αρχιτεκτονικη που εχει ασχημο Front End, ενω ισως και αμελητεο σε καποια που το Front End της ειναι πολυ δυνατο και τα penalties για memory access ειναι χαμηλα.

Παρομοια για GPU, μπορω να γραψω optimized κωδικα ειδικα για μια αρχιτεκτονικη που ευνοει καποιους συγκεκριμενους τροπους εκτελεσης και σε μια αλλη να αποδιδει χαλια γιατι δεν ειναι τοσο γρηγορη στο συγκεκριμενο κομματι.

Θα μου πεις τωρα, ρε μαν θα καθεσαι και θα γραφεις optimized κωδικα για ΚΑΘΕ arch εκει εξω; Οχι, αυτο ειναι καπως αδυνατο. Εχει διαφορα ομως το ξυνω τα απαυτα μου, το οποιο εκαναν οι devs της Bethesda, με το τηρω καποιες γενικες αρχες optimization που οφελουν ολο το hardware και απο εκει και περα οποια αρχιτεκτονικη ευνοηθει παραπανω ευνοηθηκε. 

Εδω εχουμε ξεκαθαρο παραδειγμα optimization για το datapath των AMD GPU, ενω σε CPU πλευρα δεν θα μου εκανε εντυπωση αν πηραν απλως το console code (γιατι εκει κανουν development) και το εκαναν recompile για PC, χωρις καμια διορθωση. 

*Ψευδοκωδικες και νουμερα απο τον πισινο μου, επαφη με graphics ΑPI δεν εχω, ελπιζω να αποκτησω αυτο το εξαμηνο που εχω παρει Γραφικα Υπολογιστων

Επεξ/σία 5 Σεπτεμβρίου 2023 από kostas_anes

[Herald]

1 minute ago, kostas_anes said:

Το optimization per application basis, οπως ειναι τα patches στα παιχνιδια, δεν εχουν να κανουν με το optimization σε drivers, ειναι δυο διαφορετικα πραγματα. 

Ο driver, οταν λαβει ενα command: draw poly(123,67,2) -> apply texture(%planet%) θα το μεταφρασει σε γλωσσα μηχανης και αναλογα την αρχιτεκτονικη της GPU θα αναθεσει προσπαθησει να το κανει με τα καταλληλα instruction ετσι ωστε να παρει τον λιγοτερο χρονο. Αν μια αρχιτεκτονικη πχ μπορει να κανει drawing και texturing παραλληλα, ο driver θα τα παραλληλησει, ενω σε μια αλλη που μπορει να εκτελεσει μονο σειριακα αυτες τις λειτουργιες, θα φτιαξει το καταλληλο dataflow ετσι ωστε το texture unit πχ να μην μενει αχρησιμοποιητο (να τρεχει κατι αλλο), ενω τρεχει το draw polygon. 

Αυτα γενικα αφορουν διαχειρηση σε hardware επιπεδο. 

Το να γραψω optimized κωδικα για μια αρχιτεκτονικη δεν παταει πανω στον driver. Παταει πανω στο τι κωδικα γραφω και τι compiler χηρσιμοποιω. Πχ, αν θελω να κανω (3*5)+5, μπορω να το γραψω με τον πολυ απλο τροπο που θα χρησιμοποιησει x86-64 και θα τρεχει παντου ή μπορω να χρησιμοποιησω FMA (Fused Multiply Add), που εχουν ολα τα σύγχρονα CPU της τελευταιας 15ετιας+ και να τρεξει σε 1 cycle αντι για 2. 

Περαν αυτου, μπορω να γραψω κωδικα ο οποιος κανει πολυ αποτελεσματικη χρηση μνημης και επαναχρησιμοποιει σετ δεδομενων, μειωνοντας και το αποτυπομα στην μνημη και τον χρονο προσβασης, μπορω επισης να γραψω τον ιδιο κωδικα με την καθε συναρτηση πχ να αρχικοποιει εκ νεου τα δεδομενα και να υπαρχει το ιδιο σετ δεδομενων 10 φορες στην μνημη, για 10 διαφορετικες συναρτησεις. 

Θα επηρεασει ολα τα CPU; Σιγουρα, οτι αλλαγη και να κανεις θα εχει παντου μια διαφορα. Στο συγκεκριμενο παραδειγμα ομως, θα ειναι τρομερη η διαφορα σε μια αρχιτεκτονικη που εχει ασχημο Front End, ενω ισως και αμελητεο σε καποια που το Front End της ειναι πολυ δυνατο και τα penalties για memory access ειναι χαμηλα.

Παρομοια για GPU, μπορω να γραψω optimized κωδικα ειδικα για μια αρχιτεκτονικη που ευνοει καποιους συγκεκριμενους τροπους εκτελεσης και σε μια αλλη να αποδιδει χαλια γιατι δεν ειναι τοσο γρηγορη στο συγκεκριμενο κομματι.

Θα μου πεις τωρα, ρε μαν θα καθεσαι και θα γραφεις optimized κωδικα για ΚΑΘΕ arch εκει εξω; Οχι, αυτο ειναι καπως αδυνατο. Εχει διαφορα ομως το ξυνω τα απαυτα μου, το οποιο εκαναν οι devs της Bethesda, με το τηρω καποιες γενικες αρχες optimization που οφελουν ολο το hardware και απο εκει και περα οποια αρχιτεκτονικη ευνοηθει παραπανω ευνοηθηκε. 

Εδω εχουμε ξεκαθαρο παραδειγμα optimization για το datapath των AMD GPU, ενω σε CPU πλευρα δεν θα μου εκανε εντυπωση αν πηραν απλως το console code (γιατι εκει κανουν development) και το εκαναν recompile για PC, χωρις καμια διορθωση. 

Από αυτά που γράφιες καταλαβαίνω ότι μπορείς να γράψεις κώδικα που να αξιοποιεί τα δυνατά στοιχεία μιας αρχιτεκτονικής (πχ. την Cache του 3d), αλλά όλα τα CPU με μεγάλη cache θα κερδίσουν σε επιδόσεις, είτε είναι της Intel είτε της AMD, σωστά; 

Ενώ στις GPU μπορείς να κάνεις κάτι του στυλ "If AMD fps ----> over 9 thouzandz,  if not ---> uninstall". Είμαι κοντά?

[kostas_anes]

10 λεπτά πριν, Herald είπε

Από αυτά που γράφιες καταλαβαίνω ότι μπορείς να γράψεις κώδικα που να αξιοποιεί τα δυνατά στοιχεία μιας αρχιτεκτονικής (πχ. την Cache του 3d), αλλά όλα τα CPU με μεγάλη cache θα κερδίσουν σε επιδόσεις, είτε είναι της Intel είτε της AMD, σωστά; 

Ενώ στις GPU μπορείς να κάνεις κάτι του στυλ "If AMD fps ----> over 9 thouzandz,  if not ---> uninstall". Είμαι κοντά?

1. Ισχυει και για CPU και για GPU και αυτο εκαναν για τα γραφικα και τις καρτες της AMD. Ο λογος που φανηκε στις GPU της AMD, ειναι επειδη εχουν μεγαλες διαφορες απο τις Nvidia. Αλλα ναι, αμα γραψεις κατι που ευνοει μεγαλη cache, οτι εχει μεγαλη cache θα το τρεχει καλα. 

2. Μπορεις να το κανεις παλι σε οτι θες, ειναι γενικα κοινη πρακτικη, και πολυ καλο κακοβουλο παραδειγμα παλιοτερα προγραμματα που ειχαν διαφορετικο code fork για AMD και για Intel CPU, με το fork της AMD να χρησιμοποιουν οτι πιο γενικο κωδικα υπαρχει, ενω στο intel fork να αξιοποιουν οτι instruction set μπορουσε να δωσει προβαδισμα. 

Σε μη κακοβουλο παραδειγμα, κοιτα πχ Matlab/Octave. https://www.extremetech.com/computing/308501-crippled-no-longer-matlab-2020a-runs-amd-cpus-at-full-speed

Επεξ/σία 5 Σεπτεμβρίου 2023 από kostas_anes

[Herald]

10 minutes ago, kostas_anes said:

1. Ισχυει και για CPU και για GPU και αυτο εκαναν για τα γραφικα και τις καρτες της AMD.

2. Μπορεις να το κανεις παλι σε οτι θες, ειναι γενικα κοινη πρακτικη, και πολυ καλο κακοβουλο παραδειγμα παλιοτερα προγραμματα που ειχαν διαφορετικο code fork για AMD και για Intel CPU, με το fork της AMD να χρησιμοποιουν οτι πιο γενικο κωδικα υπαρχει, ενω στο intel fork να αξιοποιουν οτι instruction set μπορουσε να δωσει προβαδισμα. 

Σε μη κακοβουλο παραδειγμα, κοιτα πχ Matlab/Octave. https://www.extremetech.com/computing/308501-crippled-no-longer-matlab-2020a-runs-amd-cpus-at-full-speed

Άρα όρεξη να έχεις και μπορείς να τα διαλύσεις και τα CPU  

I stand corrected

Επεξ/σία 5 Σεπτεμβρίου 2023 από Herald

[kostas_anes]

3 λεπτά πριν, Herald είπε

Άρα όρεξη να έχεις και μπορείς να τα διαλύσεις και τα CPU  

I stand corrected

Η αντιστοιχα να μην εχεις. Σου δινει η AMD/NVidia/Intel ενα ετοιμο library, χρησιμοποιεις αυτο και τελειωνεις. Ε μαντεψε τι θα τρεχει καλα και τι οχι 😅

To development θελει δουλεια, δεν ειναι παιξε γελασε, που λενε ολοι τελευταια "α θελω ευκολα λεφτα, παω να γινω dev". Και αυτα σας τα λεω αρκετα απο την απεξω, εχοντας ασχοληθει σε μικρο βαθμο, η ειδικοτητα μου ειναι το hardware. Αν ειχαμε καποιον dev εδω που ασχολειται, θα μπορουσε να μπει αρκετα βαθια η συζητηση στο πως αλληλεπιδρουν τα δυο και πως το κακο development μεταφραζεται σε μη σωστη αξιοποιηση του hardware

Επεξ/σία 5 Σεπτεμβρίου 2023 από kostas_anes

[Πέτρος]

47 λεπτά πριν, Herald είπε

O 13100f έχει τεράστιες διαφορές με τον 5600x πέρα απτο απλοικό 4/8 6/12...

To έχουμε δει ξανά αυτό το παράδειγμα, πραγματικά?

[Herald]

6 minutes ago, Πέτρος said:

To έχουμε δει ξανά αυτό το παράδειγμα, πραγματικά?

Aν υποθέσουμε ότι 13100 = 12100 ναί, στο spiderman remastered vhq είναι 114 vs 116 fps μεταξύ 12100 και 5600x. Ίδιες ουσιαστικά επιδόσεις δηλαδή. 

[Πέτρος]

5 λεπτά πριν, Herald είπε

Aν υποθέσουμε ότι 13100 = 12100 ναί, στο spiderman remastered vhq είναι 114 vs 116 fps μεταξύ 12100 και 5600x. Ίδιες ουσιαστικά επιδόσεις δηλαδή. 

Τα οποία δεν έχουν εξηγηθεί ποτέ επαρκώς, να σημειωθεί.

Καταλαβαίνεις ότι δεν μπορούμε να δεχόμαστε τα outliers έτσι επειδή μας αρέσουν...αλλιώς, 7900ΧΤΧ>4090 και δεν υπάρχει κανένα θέμα.

Επεξ/σία 5 Σεπτεμβρίου 2023 από Πέτρος

[this.is.elia]

42 minutes ago, kostas_anes said:

1. Ισχυει και για CPU και για GPU και αυτο εκαναν για τα γραφικα και τις καρτες της AMD. Ο λογος που φανηκε στις GPU της AMD, ειναι επειδη εχουν μεγαλες διαφορες απο τις Nvidia. Αλλα ναι, αμα γραψεις κατι που ευνοει μεγαλη cache, οτι εχει μεγαλη cache θα το τρεχει καλα. 

2. Μπορεις να το κανεις παλι σε οτι θες, ειναι γενικα κοινη πρακτικη, και πολυ καλο κακοβουλο παραδειγμα παλιοτερα προγραμματα που ειχαν διαφορετικο code fork για AMD και για Intel CPU, με το fork της AMD να χρησιμοποιουν οτι πιο γενικο κωδικα υπαρχει, ενω στο intel fork να αξιοποιουν οτι instruction set μπορουσε να δωσει προβαδισμα. 

Σε μη κακοβουλο παραδειγμα, κοιτα πχ Matlab/Octave. https://www.extremetech.com/computing/308501-crippled-no-longer-matlab-2020a-runs-amd-cpus-at-full-speed

λολ, τί γράφετε ρε σεις..; 😂😂😂😂

Νομίζεις ότι ο 'προγραμματιστής' έχει οποιαδήποτε επαφή με την 'cache', την μνήμη και βασικά με οτιδήποτε υπάρχει πάνω στη μητρική; Είμαστε στο 1982 με 6502 και Ζ80 να γράφουμε στους registers του επεξεργαστή με assembler;

Δεν υπάρχουν πλέον αυτά τα πράγματα. Ότι παιχνίδι γράφεται είναι εντελώς agnostic για τα πάντα σε σχέση με την αρχιτεκτονική. Ούτε καν για C να κάνεις κάνα peek/poke, δεν υπάρχει καμία απολύτως επαφή με το hardware. Όλα κρύβονται επιμελώς από τα windows και το kernel protection του επεξεργαστή. Με ιδιαίτερη μανία μάλιστα.

Διότι εάν οποιοσδήποτε developer σε unity/ue/visual studio/custom engine (βασικά visual studio δηλαδή) είχε transparency με το υλικό, χωρίς 500 abstraction layers από πάνω, θα έγραφε 2-3 expolits σε κάθε indie release στο steam.

Και το λινκ παραθέτεις για το matlab είναι april fools αστείο.

Επεξ/σία 5 Σεπτεμβρίου 2023 από this.is.elia

[Tambas91]

47 λεπτά πριν, Herald είπε

Πέρα απτην πλάκα τώρα, ούτα τα Intel γενικά τα πάνε καλά στο starfield. 3 CPU τα πάνε καλά, 13900k / 13700k / 13600k. Τα υπόλοιπα έχουν τραγικές διαφορές με τα προαναφερθέντα 3 που δεν τις βλέπεις σε άλλα παιχνίδια. Δεν με νοιάζει τι κάνουν τα AMD, τα Intel μεταξύ τους μόνο αν συγκρίνεις, το 21% μεταξύ 12900k και 13900k δεν είναι ιδιαίτερα συνηθισμένη διαφορά.  

έχουν κάνει περίεργα πράγματα με το συγκεκριμένο.. αυτά θα τα φτιάξουν πιστεύω αν σκεφτούμε ότι αυτό που παίζουμε είναι μια έκδοση early access θα βγούν patch και οδηγοί... το AI δε ξέρω τι θα γίνει,το game είναι tragic και όσο περισσότερο παίζεις τόσο φαίνεται να σου βγάλω βιντεάκια να κλάψεις

Spoiler

μπαίνω μέσα σε ένα δωμάτιο με ένα γραφείο που ακριβώς από πίσω του έχει ένα χρηματοκιβώτιο και ένας γιατρός κάθεται και κοιτάει το pc σκύβω διπλα του ακριβώς και ενώ με βλέπει του hackάρω το χρηματοκιβώτιο τον ψειρίζω και αυτόν και φεύγω άρχοντας

παίζεις shootια με τα npc και χωρίς λόγο βγαίνουν από τη θέση τους πάνε σε ένα τοίχο και κοιτάνε σα χαμένα

πυροβολάς μέσα στις πόλεις σα τζιχαντιστής και δίπλα σου κυκλοφορούν οι οικογένειες λες και πηγαίνουν βόλτα στο πάρκο μια ηλιόλουστη ημέρα του Μάι για picnic

 

[sjtak]

31 λεπτά πριν, this.is.elia είπε

λολ, τί γράφετε ρε σεις..; 😂😂😂😂

Νομίζεις ότι ο 'προγραμματιστής' έχει οποιαδήποτε επαφή με την 'cache', την μνήμη και βασικά με οτιδήποτε υπάρχει πάνω στη μητρική; Είμαστε στο 1982 με 6502 και Ζ80 να γράφουμε στους registers του επεξεργαστή με assembler;

Δεν υπάρχουν πλέον αυτά τα πράγματα. Ότι παιχνίδι γράφεται είναι εντελώς agnostic για τα πάντα σε σχέση με την αρχιτεκτονική. Ούτε καν για C να κάνεις κάνα peek/poke, δεν υπάρχει καμία απολύτως επαφή με το hardware. Όλα κρύβονται επιμελώς από τα windows και το kernel protection του επεξεργαστή. Με ιδιαίτερη μανία μάλιστα.

Διότι εάν οποιοσδήποτε developer σε unity/ue/visual studio/custom engine (βασικά visual studio δηλαδή) είχε transparency με το υλικό, χωρίς 500 abstraction layers από πάνω, θα έγραφε 2-3 expolits σε κάθε indie release στο steam.

Και το λινκ παραθέτεις για το matlab είναι april fools αστείο.

Αρκετά παιχνίδια που τα πηγαίνουν καλά οι x3d είναι επειδή είναι γραμμένα να έχουν υπερβολικά πολλά draw calls. Αυτό δεν μπορείς να το πεις  (un)optimization για cache; 

[BabisTs]

https://videocardz.com/newz/intels-new-core-i9-14900k-raptor-lake-refresh-cpu-shows-up-on-geekbench

 

[Tambas91]

42 λεπτά πριν, BabisTs είπε

https://videocardz.com/newz/intels-new-core-i9-14900k-raptor-lake-refresh-cpu-shows-up-on-geekbench

 

πως γίνετε σε multi ο 13900k να είναι πάνω από 14900k?

[this.is.elia]

58 minutes ago, sjtak said:

Αρκετά παιχνίδια που τα πηγαίνουν καλά οι x3d είναι επειδή είναι γραμμένα να έχουν υπερβολικά πολλά draw calls. Αυτό δεν μπορείς να το πεις  (un)optimization για cache; 

Αυτό που γράφεις είναι λίγο γενικό.

Για να γίνω λίγο περίεργος (και να διαφωνήσω ελαφρώς με τον εαυτό μου) μπορείς (θεωρητικά) να γράψεις κώδικα ο οποίος να είναι 'ευαίσθητος' στο μέγεθος της cache. Αλλά μόνο αυτό: να είναι ευαίσθητος. Όχι ντετερμινιστικά να βάζει και να βγάζει πράγματα ΜΟΝΟ από την cache. Αυτό λέγεται optimization για cache; Δεν ξέρω, είναι θέμα semantics, δεν υπάρχει yes/no απάντηση.

Για παράδειγμα, μπορώ να σκεφτώ μια (1) και μόνο εντολή που μπορεί κατά περίσταση να χρησιμοποιηθεί για να βάζεις και να βγάζεις δεδομένα πολύ γρήγορα από κάποια δομή δεδομένων (από πίνακα λ.χ) (αυτή). Αλλά μόνο υπό την προϋπόθεση ότι ο επεξεργαστής δεν θα κάνει απολύτως τίποτα άλλο εκείνη τη στιγμή. Για proof of concept, οκ, θα μπορούσε να παίξει τέτοιο σενάριο. Πρακτικά, δεν ξέρω εάν οποιοδήποτα εμπορικό SDK υποστηρίζει τέτοια πράγματα. Βασικά, είμαι βέβαιος ότι δεν τα υποστηρίζουν. Oύτε κατά διάνοια.

Και εξηγώ: Η παραπάνω εντολή είναι σαφώς κομμάτι του x86 instrusction set. Αλλά ο μόνος compiler που θα καταλάβει πώς πρέπει να την χρησιμοποιήσει επί τούτου είναι ο gcc. Μόνο. Σε κάποιες εκδόσεις του. Σε pure C++. Μόνο. Ποιο studio χρησιμοποιεί C++; Κανένα. Ίσως ο μερακλής Carmack χρησιμοποιούσε μέχρι το Quake 3 Mετά το scope των παιχνιδιών ξέφυγε τελείως, δεν άξιζε τον κόπο και τον χρόνο να ασχοληθούν οι προγραμματιστές. Δεν υπάρχει περίπτωση ένα παιχνίδι με το εύρος του Starfield (μιας και περί αυτού ο λόγος) να γραφεί σε γλώσσα προγραμματισμού και να 'στοχεύει' την χρήση cache. To development θα γίνει σε κάποιο node based εργαλείο. Ένα σπαγγέτι από γραμμές θα ενώνει nodes που αντανακλούν κάθε πράξη και αντίδραση εντός του παιχνιδιού. Και από πάνω θα έχει ένα layer από LUA ή κάτι ανάλογο για το scripting. Αν πάει καλά λόγω cache, θα είναι περισσότερο ένα 'ευτυχές δυστύχημα' παρά ηθελημένη ενέργεια. Π.χ το factorio, ένα εν γένει απλό παιχνίδι του οποίου ο ουσιαστικός κώδικα χωράει άνετα στα 100ΜΒ cache (τόσο έχουν;) που φοράνε οι 3d. To factorio είναι χρόνια στο κουρμπέτι - αλλά οι προγραμμαστιστές του δε νομίζω να ήξεραν (ή να ενδιαφερόταν) ότι θα πήγαινε σφαίρα στους 3d...

Για να προγραμματίσεις πλέον σε game studio, δεν θα σου ζητήσει κανείς hardcore γνώση σε γλώσσα τύπου C. Ούτε καν C#. Απλά να  σκαμπάζεις κάποιο εργαλείο visual studio & λίγο visual C++ μαζί με το CUDA SDK της nvidia ή opencl. Και να ξέρεις να παίζεις στα δάχτυλα το interface του dev tool που χρησιμοποιούν, συνήθως UE. Αυτό είναι το βασικό. Να ξέρεις να ενώνεις nodes. Πιθανότατα και γνώση του cuDNN πλέον, μιας και όλα πάνε προς ml και tensor flow. Δηλαδή τζίφος και η c++, όλα γυρνάνε σε python. Προγραμματιστής χωρίς python για παιχνίδια στο μέλλον = γκαζμάς.

Για να μη γράψω σεντόνι, που ήδη έγραψα, απλά αναφέρω ότι πρακτικά ΔΕΝ υπάρχει καμία απολύτως εντολή σε καμιά γλώσσα (πλεον) που να λέει explicitly στον επεξεργαστή -βάλε εκείνο στη cache μην το βάλεις στην κύρια μνήμη. Κάτι τέτοιο είναι και χαλαρά λόγος για ακαριαίο BSOD, you get my point. Δεν μπέκεις με το σίδερο στους υπολογιστές, θέλεις να είσαι πάντα σε high level και να αφήνεις τους drivers να κάνουν τη βρωμοδουλειά.

Έτσι και αλλιώς, η μνήμη του υπολογιστή δεν χωρίζεται σε cache & ram, σίγουρα όχι από την πλευρά του προγραμματιστή που γράφει τις εντολές του σε κάποιον editor. Ο προγραμματιστής δεν 'ξέρει' εκείνη την στιγμή τί είναι cache. Έχει μια ακολουθία διευθύνσεων στις οποίες μπορεί να αποθηκεύει & να τραβάει δεδομένα. Ακόμα και όταν γράφαμε assembly, το address space είναι ένα ενιαίο και αδιάσπαστο κομμάτι διευθύνσεων. Δεν υπάρχει εντολή MOVΕ X, cache. Ακόμα και στους assemblers, δεν μπορείς να βάλεις κάτι στην cache. Σε μερικούς registers, κατά περίσταση ναι. Όχι στην cache. Τους λες βάλε το Χ στην τάδε διεύθυνση της μνήμης.  Ο επεξεργαστής αποφασίζει τί μπαίνει και τι βγαίνει από κάθε διακριτό κομμάτι της μνήμης, εάν πάει στην cache, στη μνήμη, στo swap file. Και πλέον η κατάσταση έχει γίνει ακόμα πιο αφόρητη με τον thread director της ιντελ, to xbox app να ελέγχει τα tiles στους 3d, την cache κάθε πυρήνα να ελέγχεται από 50 controllers και 50 infinity fabrics και σωλήνες αποχέτευσης. Αυτό που ξέρω στα σίγουρα είναι ότι ακόμα και οι πιο hardcore compilers είναι σε autopilot πλέον. Κανείς δεν ασχολείται με την ταχύτητα και την cache, όλοι κοιτάνε πώς δεν θα σπάσουν πράγματα που ήδη δουλεύουν.

Αυτό είναι το πρώτο μου σεντόνι στο insomnia btw, ζητώ κατανόηση από τους mods 🙂

[Aten-Ra]

1 hour ago, this.is.elia said:

Ποιο studio χρησιμοποιεί C++; Κανένα. 

UE 5

https://docs.unrealengine.com/5.1/en-US/programming-with-cplusplus-in-unreal-engine/

 

To Starfield χρησιμοποίει την Creation Engine 2 που είναι γραμμένη σε Papyrus.