kostas_anes

Eπιβεβαιωνω παρομοια εμπειρια με τον 5800Χ. Ο 3D απο την αλλη δεν κανει κιχ, ευτυχως. Ειναι αναλογα τι τσιπακι θα σου κατσει.

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

Μήπως εδώ εννοείς "παραπάνω"; Ξανακοίταξα τα νούμερα 2-3 φορές και εκτός από το idle (με polling) του 5800Χ, το HWInfo δίνει παραπάνω είτε την χρονική περίοδο που κάνει polling είτε όχι. Γενικά όταν παρουσιάζεις τα αποτελέσματα μιας έρευνας δεν είσαι εσύ που σχολιάζεις τα αποτελέσματα σου, εσύ περιγράφεις αυτά που βρήκες και οι υπόλοιποι αξιολογούν τα ευρήματα αυτά. Το "σημαντικές διαφορές", είναι ένας γρήγορος τρόπος να περιγράψει κανείς αυτό που βλέπει στα νούμερα όποιος έχει μάτια: Διαφορές, είτε προς τα πάνω, είτε προς τα κάτω, οι οποίες καθιστούν την μέτρηση μη έγκυρη και χωρίς αντιστοιχία στα πραγματικά φαινόμενα. Επίσης η "ομολογία" που αναφέρεις παρακάτω είναι απλώς μία εμπεριστατωμένη υπόθεση. Δεν μπορώ να ξέρω ότι οφείλεται όντως σε αυτό που αναφέρω αν δεν δω αναλυτικά τον σχεδιασμό της AMD και της Ιντελ στα τσιπάκια τους. Ο λόγος που πιθανότατα είναι σωστή όμως, είναι το γεγονός ότι α) όντως ισχύουν αυτά που λέω για το πως μετράει η κάθε εταιρεία (σύμφωνα με τα datasheet των VRM Controller και δεδομένα του author του HWInfo) και β) θα ήταν πολύ λογικό αυτή η διαφορά στους τρόπους μέτρησης να δημιουργεί το πρόβλημα και από εμπειρία μου με πάσης φύσεως ηλεκτρονικά, το απλό και λογικό συμπέρασμα είναι συνήθως το σωστό. Εσύ από την άλλη πως καταλήγεις στο ότι δεν ισχύει αυτό; Αν έχεις κάποια στοιχεία που πάνε αντίθετα σε αυτά που ανέφερα, δώσε πηγή γιατί είναι αρκετά ενδιαφέρον να δούμε την πραγματική αιτία. Κοινό trend και παραδοχή που μπορείς να κάνεις για όλα τα μικρά τσιπάκια που έχουν κυκλοφορήσει από αρχής χρόνου Όσο μεγαλώνεις αρχίζει και δημιουργείται πολύ θέμα inefficiency.

Ευχαριστώ τον @PC_Science_Lefkada για το tag, με το που είδα τίτλο θέματος και φώτο κατάλαβα αμέσως το πρόβλημα μιας και το έχω συναντήσει σε δύο από τα review μου που έχω κάνει σε Colorful κάρτες (1050Ti και 1650), οι οποίες έχουν ίδια φιλοσοφία με Zotac, PNY κτλ: Τα απολύτως απαραίτητα για την ορθή λειτουργικότητα, για μείωση κόστους, χωρίς όμως να παίζουν με την αξιοπιστία του προϊόντος. Για παραπάνω πληροφορίες, το κομμάτι καταναλώσεων της 1050Ti και της 1650.

Εχω να δω τετοιο thread necromancy καιρο να ξες 😂 Καλη απορια παντως

Για πες πιο συγκεκριμενα, ιδια καρτα εχω και σκεφτομουν να το παρω μπας και ειναι playable σε 1440p με DLSS.

Εεεχ... Βασικα οχι γιατι λογω σχολης το ειχα ζησει το θεμα. Το ιδιο και το octave/anaconda, μεχρι να βγει ryzen optimized codepath και να μην τρεχει το generic. Πχ οριστε το thread που ειχα χρησιμοποιησει προσπαθωντας να φτιαξω το θεμα. https://reddit.com/r/matlab/s/OOSCNKRtko Γενικα στα αλλα συμφωνω στα μισα. Ναι κανενας δεν ελεγχει τι θα μπει στην cache κτλ, δεν νομιζω να ανεφερα πουθενα κατι τετοιο. Αυτο που λεω ειναι οτι μπορεις να γραψεις κωδικα που μπορει να τρεχει optimized σε ενα CPU και σε αλλο οχι και τοσο. Συμφωνα με εμπειριες μου σε C/C++ ειναι πολυ εφικτο. Ποσο μαλλον δε αν χρησιμοποιεις και πειραγμενο/optimized compiler το οποιο δεν μου φαινεται απιθανο, αλλα οχι και ιδιαιτερα συχνο φαινομενο. Οπως ειπε και ο Ατεν, υπαρχουν engines που βασιζονται σε C++. Για scripting επειδη εχω κανει αρκετο closed alpha/beta test για μερικους indie τιτλους ξερω οτι LUA παει κατα κορων. Το εντελως agnostic και οτι το φωτισει ο θεος ειναι λαθος προσεγγιση για εμενα και ειναι αυτη που γινεται κυριως, γι'αυτό και παιρνουμε τα σκουπιδια που παίρνουμε. Ως ασχετος στο game development μεν, αλλα σχετικος με coding, αρνούμαι να δεχτω οτι δεν μπορει να γινει καποια βελτιστοποιηση σε γενικο επιπεδο.

Η αντιστοιχα να μην εχεις. Σου δινει η AMD/NVidia/Intel ενα ετοιμο library, χρησιμοποιεις αυτο και τελειωνεις. Ε μαντεψε τι θα τρεχει καλα και τι οχι 😅 To development θελει δουλεια, δεν ειναι παιξε γελασε, που λενε ολοι τελευταια "α θελω ευκολα λεφτα, παω να γινω dev". Και αυτα σας τα λεω αρκετα απο την απεξω, εχοντας ασχοληθει σε μικρο βαθμο, η ειδικοτητα μου ειναι το hardware. Αν ειχαμε καποιον dev εδω που ασχολειται, θα μπορουσε να μπει αρκετα βαθια η συζητηση στο πως αλληλεπιδρουν τα δυο και πως το κακο development μεταφραζεται σε μη σωστη αξιοποιηση του hardware

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

Το 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 δεν εχω, ελπιζω να αποκτησω αυτο το εξαμηνο που εχω παρει Γραφικα Υπολογιστων

Τεχνικα μιλωντας και τα CPU εχουν drivers, απλως ειναι ενσωματωμενα στον kernel του καθε λειτουργικου. Ενας driver αυτο που κανει ειναι να φτιαχνει το λεγομενο HAL (Hardware Abstraction Layer). Τα OS προσφερουν αρκετα υψηλο επιπεδο abstraction, με τον kernel να κανει τον χρονοπρογραμματισμο αλλα και αντιστοιχα το optimization των διεργασιων σε γλωσσα μηχανης. Οι GPU's απο την αλλη επειδη τρεχουν πανω απο το CPU, επικοινωνουνε μεσω API με αυτο (βλεπε OpenCL/GL, DirectX, Vulkan, CUDA etc). Ο driver αυτο που κανει ειναι ακριβως την ιδια δουλεια με τον kernel του λειτουργικου: Παιρνει τα high abstraction API's και τα φερνει σε γλωσσα μηχανης με τα καταλληλα optimization και χρονοπρογραμματισμους. Οι GPU βεβαια ειναι λιγο πιο πολυπλοκες στο ISA τους και λογω πολυ μεγαλου παραλληλισμου, υπαρχουν πολλες βελτιωσεις που μπορουν να γινουν στο optimization καθε διεργασιας. Γι αυτο και βγαινουν συχνα driver updates, σε αντιθεση με τα CPU που λιγο πολυ αντιμετωπιζουν ολες τις διεργασιες με πολυ συγκεκριμενους τροπους.

Με 45W PPT στο ΒΙΟS

Γενικά να ενημερώσω ότι δεν κάνουν. Κυρίως γιατί έχουν και regulator εσωτερικά του CPU. Της AMD αντίστοιχα έχουν αρκετά πιο αργό response time (τάξης ns) και εκεί βλέπεις αισθητά spikes. Δες αυτό το έχω 2 εβδομαδούλες και το έχω αγαπήσει ιδιαιτέρως. Επίσης είναι επώνυμο, UNI-T μεν, αλλά από no name κινεζιά προτιμώ την ονοματισμένη που ξέρω τι παίρνω.

To ότι έχουν 2 σελίδες που σου εξηγούν με πολύ όμορφο τρόπο ότι δεν χρησιμοποιείς σωστά τον όρο efficiency, αλλά αντί να πεις "σόρρυ παίδες είπα μαλακία" είτε γιατί όντως δεν το ήξερες, είτε γιατί μυαλό είναι και κολλάει καμιά φορά, κάθεσαι και το παίζεις βαρύς, ειρωνευόμενος, να ξες αγγίζει επίπεδα μπάρμπα-ξερόλα στον επαρχιακό καφενέ που κάθε "σοφία" που ξεστομίζει με περίσσεια μαγκιά, βροντάει και τις χάντρες από το κομπολόι. Άντε πες και κάνα "εσείς οι νέοι δεν τα ξέρετε σωστά, ακούστε εδώ που μιλάει η εμπειρία", να κλείσει το πακέτο. Ε μερικοί θέλετε να τα ακούσετε, δεν υπάρχει άλλη εξήγηση!

To οποίο εντελώς τυχαία συμφωνεί και με τα νούμερα μου στον 11500 (9.6W)