Új hozzászólás Aktív témák
-
hakos1987
őstag
Egy kis help!
A phenom 9500-am még tlb hibás verzió... anno olvastam vmi leírást, ahol át kellett írni vmit, így lehet kikapcsolni a hibát, de állítólag nagyon belassul... inkább gyorsabb legyen, úgyis kevés az esélye, hogy előfordul.... hol tudom meglesni, hogy most a TLB hiba lehetősége ki van iktatva, illetve hogy tudom újra aktiválni hogy inkább gyorsabb legyen?
köszi előre is a segítséget, fontos lenne nekem!
-
#531
Andre1234
aktív tag
butcher eu
#530
Andre1234
aktív tag
válasz
butcher eu
#530
üzenetére
olvass át a Nagy Everest topicba mert az everest okozott már meglepetést.
nem tudom melyik verziókkal szabad próbálkozni.olvass utána -
#530
butcher eu
senior tag
butcher eu
senior tag
nem tudja valaki hogy ezt a konfigot ami nekem van miért nem ismeri fel az everest 2007 ultimate
negyed annyi pontot nem csinál mint az előző 2 magos 4400+ -os procival -
#529
butcher eu
senior tag
butcher eu
senior tag
még egy kérdés.
nem tudom hol kell a ht szorzót emelni,
és így nem nagyon tudom húzni a procit csak 270 mhz-el
meg a memória szorzót sem találom -
#528
butcher eu
senior tag
butcher eu
senior tag
amúgy memória beállítási gondom volt
vissza vettem mindent az eredetire, és nekiálltam kisérlatazni.
kivettem az egyik ramot, a betnlévőnek beállítottam az ideális késleltetést 4-4-4-12, felemeltem 1,9 ről 2 v-ra, és így ment.
a Vista így sem ment fel de az xp-t nagynehezen fel tudtam rakni
xp alól meg rámegy a viszta 64, azt kész. -
#527
butcher eu
senior tag
butcher eu
senior tag
még lapot cseréltem de nem jobbra csak sli-t crossfire-re
ASUS M2NSLI DELUX--->ASUS M2R32-MVP
MINDEN MÁS MARADT -
#526
Max6
tag
butcher eu
#518
Max6
tag
válasz
butcher eu
#518
üzenetére
Én is jártam ugyan igy, nálam memória gond okozta. Pontosabban mindkét memória hibátlan volt külön-külön. Volt olyan , hogy a két modullal a memtest 2.5 órán át futott hibátlanul aztán próbáltam telepíteni és hiba
Aztán az egyik modult vissza vittem kicserélték és azóta (kb 2hónap) nem jelentkezett a probléma -
#525
fLeSs
nagyúr
butcher eu
#518
fLeSs
nagyúr
válasz
butcher eu
#518
üzenetére
Ha nem a vinyó/DVD/kábel a gond, akkor a RAM.
Nem feltétlenül rossz! Lehet, hogy csak rosszul vannak beállítva az időzítések. -
#524
dKes
tag
butcher eu
#521
dKes
tag
válasz
butcher eu
#521
üzenetére
Egyéb komponensek nem változtak a gépben? Csak a pontosság kedvéért ...
-
#523
dKes
tag
butcher eu
#518
dKes
tag
válasz
butcher eu
#518
üzenetére
Szia!
CD/DVD PATA kábel csere - lehetőleg újra. Többször (több géppel is) belefutottam ugyanilyen problémába - mindig ez lett a megoldás. Esetleg még a vinyó kábelezését is érdemes megnézni/cserélni.
Üdv : dKes
-
#522
Takhanto
őstag
butcher eu
#521
Takhanto
őstag
válasz
butcher eu
#521
üzenetére
Az eredmény csak prociváltás miatt lett jobb vagy az egész konfigot cseréltél le?
-
#521
butcher eu
senior tag
Takhanto
#520
butcher eu
senior tag
-
#519
Takhanto
őstag
butcher eu
#518
Takhanto
őstag
válasz
butcher eu
#518
üzenetére
Ugyanaz a file-nál írt ki? Vinyód nem kattog vagy valami? Próbáld meg másik wincsivel.
-
#518
butcher eu
senior tag
butcher eu
senior tag
Halihó
Lenne egy nagy gondom. Az alábbi konfigom van, twgnap raktam össze úgy, hogy még rajta volt az előző XP.
Azzal működött, de úgy gondoltam, hogy az új konfighoz, új rendszert teszek fel.
Próbáltem 2 fajta xp-t és 2 vistát. Mindegyikkel ugyan az a problémám, a telepítési fájlok másolása közben hiba lépett fel, vagy indítsam újra a telepítést, vagy hagyjam ki azt a fájlt. -
#517
fLeSs
nagyúr
butcher eu
#515
fLeSs
nagyúr
válasz
butcher eu
#515
üzenetére
Nem oldja meg, mivel ez a procitól és a chipsettől függ.
-
#516
cudar07
senior tag
butcher eu
#514
cudar07
senior tag
válasz
butcher eu
#514
üzenetére
ezt ÉN is tudtam
de nem hiszem hogy a felére esik a teljesítmény!!!
-
#515
butcher eu
senior tag
butcher eu
senior tag
ha valaki ezt tudja mondja már meg.
-
#513
cudar07
senior tag
TomBoy1986
#51
cudar07
senior tag
válasz
TomBoy1986
#51
üzenetére
sziasztok
mekkora a különbség AM2 meg AM2+ lap között
ugyan azzal a PHENOM procival!!! ??? -
#512
#95904256
törölt tag
butcher eu
#511
#95904256
törölt tag
válasz
butcher eu
#511
üzenetére
A gyárilag hozzá adott hűtő minden bizonnyal elbír vele.
Bár általános hogy az ember lecserélni egy halkabb típusra...
-
#511
butcher eu
senior tag
butcher eu
senior tag
én nem tudom milyen az x64 hűtője mert nekem nem a gyári van fenn, hanem egy tunuing. csak azt nem tudom érdemes e a phenom-ot a gyárival működtetni, vagy tegyem rá a cooler master hyper coolert?
-
#510
#95904256
törölt tag
butcher eu
#509
#95904256
törölt tag
válasz
butcher eu
#509
üzenetére
Olyasmit hallottam hogy ugyanolyan hűtő jár a Pehnom-hoz mint az X2-eshez.
-
#509
butcher eu
senior tag
butcher eu
senior tag
sehol nem találok képet a phenom gyári hűtőjéről valaki nem tudna nekem ebben segíteni?
Ma jön meg az új procim, és nem tudom hogy a gyárival használjam vagy a cooler master hyper-rel.Please help mi
-
radírfej
senior tag
-
P.H.
senior tag
Még csak ismerkedési fázisban vagyok ezzel, de úgy tűnik, néha tényleg "egyidőben több utasítás-köteget hajt végre":
A futtatás bemeneti egységei legfeljebb 3 (3x41 bit) utasítást tartalmazó blokkok (bundle), amelyet egy 5 bites sablon (template) egészít ki 16 byte-ra, ez egyrészt leírja, hogy az egyes utasítások milyen típusúak (~milyen típusú execution unit-ra kerüljenek), illetve hogy hol van bennük stop. Mivel több, egymás után következő bundle határoz meg egy futtatási egységet (instruction group), amelyet egy stop vagy ugrás zár le, és amin belül a fő vezető elv, hogy nem függhetnek az utasításainak bemeneti regiszter-paraméterei más utasításainak kimeneti register-értékeitől (memórián keresztüli adatátadás - pl. read-after-write - megengedett), és megfelelő sorrendi előírások vannak.
(A memóriafüggőségeket egy, a klasszikus store-forwading-hoz hasonló mechanizmus kezeli, tehát a " Párhuzamos végrehajtás, a függőségeket koordináló egységgel" is megvan.)És ezen instruction group-okra:
"The net effect of the dependency restrictions stated above is that a processor may execute all (or any subset) of the instructions within a legal instruction group concurrently or serially with the end result being identical."
"The ordering rules and the dependency restrictions allow the processor to dynamically re-order instructions, execute instructions with non-unit latency, or even concurrently execute instructions on opposing sides of a stop or taken branch, provided that correct sequencing is enforced and the appearance of sequential execution is presented to the programmer."
-
-
Abu85
HÁZIGAZDA
Hát a 45nm-es Shanghai lesz a K10 kiterjesztése. Főleg a prefetch és a cacheszervezés kerül optimalizálásra (erre szükség is van). Szerintem egy jó ideig a K10 lesz foltozgatva, kb. 4 év múlva esetleges egy teljesen új technika, ennyire előre nem pletyiz még a Fud sem
Amúgy Bulldozer néven fut a köv. project. OoO logikájú szuperskaláris proci lesz, magas IPC-vel és a Barcelonánál hosszabb csővezetékkel. Ebben debütál majd az SSE5 is.
A következő generációs asztali platform pedig a Falcon lesz, egy chipbe integrált Bulldozer CPU maggal, GPU maggal, közös gyorstár, integrált közös memóriavezérlő, integrált PCI-Express 2.0 vezérlő.Szerverben a Sandtiger fog versenyezni, erről kb. semmit nem tudni.
Ennyi szivárgot ki...
-
Frigo
őstag
- Not VLIW, still OoO superscalar architecture
- Deeper pipeline than Barcelona/Shanghai
- New x86 instructions targeted at HPC and "media processing"
- increased computational density
- increased flow control capability
- extend SIMD capability targeted specifically at media data types - Hyper Transport 3 will be supported
- The chip will feature 4 HT3 links
- DDR3 support - G3MX Memory Technology
- PCIe 2.0 - IOMMU (Hardware Accelerated I/O Virtualization) -
#95904256
törölt tag
Művelettípus, konkrétan. Ha csak memóriaműveletet tud, akkor dedikált. Ha mondjuk közben tud integer utasításokat is, akkor általános... Vay legalábbis általánosabb... De az általad írtak szerint a Transmeta is dedikáltakat használt. Kezdek kételkedni, hogy általános volt-e egyáltalán... Hiába, üdítő dolog ez a szenilizmus
Az általános VE-ket alkalmazni elég tarnzisztorpazarló megoldás. Hiszen az adott VE-nek mindig csak egy kis része kap(hat) munkát. Szerintem ritka, így túl sok gyakorlati jelentősége sem lehet.
Egyébként azt hittem hogy a dedikált / általános megjelölést a VE utasításkötegen belüli pozícióhoz rendelésére értetted. Ez sokkal érdekesebb megközelítés, lenne.
-
fLeSs
nagyúr
Ezzel az erővel a MAJC 5200-n kívül minden prociban dedikált VE-k vannak (FPU, ALU, LSU, BPU), vagy csak nem értem mire gondolsz. A MAJC-ban voltak ha jól emléxem általánosan használható VE-k, amikkel minden műveletet végre lehetett hajtani (a tévedés jogát fenntartom).
szerk: utánanéztem, a MAJC 5200-ban voltak FU-k, azaz functional unitok.
-
Rive
veterán
válasz
#95904256
#489
üzenetére
Mire vonatkoztatod hogy általános vagy dedikált egy VE?
Művelettípus, konkrétan. Ha csak memóriaműveletet tud, akkor dedikált. Ha mondjuk közben tud integer utasításokat is, akkor általános... Vay legalábbis általánosabb... De az általad írtak szerint a Transmeta is dedikáltakat használt. Kezdek kételkedni, hogy általános volt-e egyáltalán... Hiába, üdítő dolog ez a szenilizmus
A szigorú in-order végrehajtás miatt elég gyakori, hogy egy utasításköteg - a Transmeta szóhasználata szerint valószínű ez lesz a 'molecule' - egyes részeit - atomjait - nem lehet értelmes utasítással feltölteni. Ez elég megszokott dolog, ebből semmire se lehet következtetni.
-
#95904256
törölt tag
Ha a Transmeta VE-k általánosak voltak, annak örülök: akkor nem felejtettem még el mindent
Hm... Mire vonatkoztatod hogy általános vagy dedikált egy VE?
A Crusoe processzorokban volt 1 FPU, 2 ALU, 1 LSU és 1 BU. A 64/128 bites molekula (utasításszó) legfeljebb 4 atomból állt. The Technology Behind
Crusoe™ Processors doksiban szerepel egy "molekula minta", amiben csak az egyik ALU kap utasítást. Ebből mire lehet következtetni? -
Rive
veterán
Tipikusan L/S, integer, klf. FP... Gyak. azok, amik ma egy normális proccban VE-ként szerepelnek. Csak nem a soros utasításszálról válogatták le nekik a dolgoznivalót, hanem az összes egyszerre, párhuzamosan kapta az áldást. Konkrét proccot már nem tudok mondani, rég volt, hogy kentem-vágtam az efféléket. A Wiki talán segíthet.
Ha a Transmeta VE-k általánosak voltak, annak örülök: akkor nem felejtettem még el mindent
Ui.: közben elővakartam én. A Trace-család került nálam komolyabban képbe anno:
"Multiflow’s first computers were called the Trace 7/200 and Trace 14/200. The 7/ in the computer model number signified that the processor could initiate seven operations each cycle, using a 256-bit long instruction composed of 7 32-bit operations and a 32-bit utility field. The 7 operations were 4 integer/memory, 2 floating, and a branch. The 14/ models had twice as many of each instruction, and thus 512-bit long instruction words.
...
Multiflow also announced a 28/ model at the outset, and eventually these were built and sold to a few customers. The 28/ had 1024-bit instruction words."Azért egy 128 byte hosszúságú utasítás már nem semmi
-
#95904256
törölt tag
Szuperskalár: a gyakorlatban olyan futószalagelvű procc, amiben több VE dolgozik párhuzamosan egy utasításszálon.
Tudom hogy a szuperskalár processzorok gyakrolatilag pipeline-osak is, de szerintem nem attól lesz szuperskalár mert van benne futószalag.
VLIW: futószalagon csorgó, dedikált VE-ket meghajtó egybefűzött utasításcsomagok.
Muszáj hogy dedikált VE-k legyenek?
szerk.: Legalábbis annyi darab VE-nek kell lenni amennyit vezérel az utasításszó. Valóban egyszerűbbnek tűnik ha dedikáltak.
EPIC: tuningolt VLIW.
Egy tőről fakadnak. Igazából az EPIC mint ötletet a VLIW-ből származtatják. Valószínűleg az EPIC egy fajtája lehet VLIW-nek. Sajnos pontos, szabatos meghatározást nem találtam arra hogy mit is takarnak.
szerk.: Látom, közben kiemelted a lényeges részt a szuperskalár-nál.
-
Rive
veterán
válasz
#95904256
#482
üzenetére
Szuperskalár: a gyakorlatban olyan futószalagelvű procc, amiben több VE dolgozik párhuzamosan egy utasításszálon.
VLIW: futószalagon csorgó, tipikusan dedikált VE-ket meghajtó egybefűzött utasításcsomagok.
EPIC: tuningolt VLIW.
A fordító szerepének hangsúlyozása azért félrevezető, mert a 'sima' VLIW is fordítófüggő.
-
#95904256
törölt tag
Kiindulópontnak megteszi a Wikipedia doksi: Superscalar
Ha jól sejtem, akkor szupersaklár/VLIW/EPIC dolgok az alábbiakat jelentik:
Superscalar: Párhuzamos végrehajtás, a függőségeket koordináló egységgel.
VLIW: Olyan utasításszó, amely egyszerre vezérel több különálló műveletvégzőt.
EPIC: Párhuzamos feldolgozást támogató technika, amelynél (részben?) a fordítóra bízzák a párhuzamosan végrehajtandó utasítások koordinálását.
-
Rive
veterán
Sztem az EPIC az éppenséggel VLIW+szuperskalár.
Iiiiik
Mondjuk inkáb úgy, hogy az IA64-EPIC egy speciális VLIW-inplementáció
A szuperskalár-dolgot VLIW-esetre elég nehéz értelmezni Ui.: a VLIW-szuperskalár talán valami olyasmi lenne, ami egyidőben több utasítás-köteget hajt végre
-
fLeSs
nagyúr
Legyen félig ez, félig az.
VLIW, mert utasítás-kötegeket hajt végre.
Szuperskalár, mert egyszerre több utasítást hajt végre, igaz az ütemezést a fordító végzi.Ha bebizonyítod, hogy nem utasításkötegeket hajt végre, tehát nem VLIW, és azt, hogy órajelenként egy utasítást hajt végre, tehát skalár, akkor leborulok előtted.
szerk: ha már itt tartunk van benne egy kis OoO is.
Ott a kispekulált load vagy minek nevezik magyarul, ami a load-okat előre végrehajtja. -
-
fLeSs
nagyúr
-
Abu85
HÁZIGAZDA
Kis leírás:
Utasítás szinten párhuzamos architektúra elvek: A teljesítmény drasztikus növelését az utasítások végrehajtásának a gyorsításával lehet elérni. Ennek az egyik legkézenfekvőbb módja, hogy egyszerre több utasítást hajtunk végre. Az efféle párhuzamosítást a végrehajtó egységek többszörözésével oldják meg, legnagyobb problémája a függőség-kezelés és az ütemezés. Függőség esetén a párhuzamosan végrehajtott utasítások keresztezik egymás útját, például előfordulhat, hogy ugyanazt az erőforrást szeretnék használni. Ezeket a problémákat még a kialakulásuk előtt meg kell előzni.
Szuperskaláris: Elég bonyolult hardver gondoskodik az utasítások párhuzamos végrehajtásáról. A függőségek kezelését is maga a hardver végzi. Modern processzor esetén komoly probléma lehet, hogy a tranzisztorok nagy részét nem a végrehajtó egységekre, hanem a párhuzamosítást felismerő hardverre használják fel.
VLIW (Very Long Intruction Word): Nagyon hosszú utasítás szó. A párhuzamosítás ütemezését és a függőség-kezelését áthelyezi a fordítóprogramra (rendszerprogramozókra), ezzel jelentősen egyszerűsítve a hardver felépítését. Megfelelően megírt fordító esetén a hardver már teljesen párhuzamosított kódot dolgozhat fel. A furcsa elnevezés onnan ered, hogy a hardver egy nagyon hosszú utasítás szót kap, amiben a kötegjelzők segítségével állapítja meg, hogy mely utasítások hajthatók végre párhuzamosan.
EPIC (Explicitly Parallel Instruction Computer): Nagymértékben párhuzamos utasítású számítógép. Nagyon hasonló a VLIW elvhez. A különbség elsősorban abban rejlik, hogy azt az utasítást is végrehajtja, amire feltételezhetően nincs szükség. Ez akkor jön jól amikor a program elágazáshoz ér, a legtöbb processzor ilyenkor valamilyen elv alapján megpróbálja megbecsüli, hogy mi lesz a "helyes irány". Az EPIC elvű processzor utólag deríti ki melyik ág volt a jó, és a feleslegesen végrehajtott utasítások ezután törlésre kerülnek. A rendszer az optimalizálást a programozóra hárítja, illetve csak optimalizált utasítás sorozatot hajt végre.
Megjegyzés: A magyarázatok nem kőbe vésett szabályok, inkább amolyan tervezési filozófiák, ennek köszönhetően bármelyik rendszer eltérhet a leírt elvektől.
Az Itanium-ról nem szoktam véleményt alkotni, maga az elv nagyon tetszik, csak hát irtózatos pénz van benne ami nem térült vissza, ráadásul a piaca is szűkül így ha valami csoda nem történik, rövid időn belül vége az Itanium-nak.
Egy alapjában RISC elvű porcit nem érdemes CISC->RISC procikkal összehasonlítani. Ne feledd, hogy a Power RISC architektúrájának nincs szüksége bonyolult dekódoló hardverre. A Load/Store utasítások is egyszerűbbek. Nem kell az utasítás szavakat feldarabolni, majd ezeket out-of order sorba rendezni. Ezek az x86-nál rendkívül pazarló hardvert csinálnak. Szinte a chip negyede a dekódoló hardverre megy el, amikor lehetne regiszterekre, és gyorstárakra, vagy végrehajtó egységekre is költeni a tranzisztorokat.
A Power 6-tal keveset foglalkoztam.
-
-
energiamenedzsmentnél az alulfeszezés mellett az extra fesz lehetősége is adott legyen
Ezt könnyen meglehet csinálni, biosban beállítod a VID-nél magasabb feszt, EIST+C1E-t bekapcsolod. RMclock-ban csinálsz egy profilt, amiben pl. 6x333-n megy 1.16V-al.
Ha játszani akarsz, átváltasz "No managment" profilra, és máris az eredeti órajelen megy, a VID-nél magasabb feszen. -
radírfej
senior tag
jó, most meg az a része jön, hogy az E4500 3 gigán még 275-ös FSB-vel is erősebb mint a pédában szereplő két másik proci. így aki teljesítményre hajt annak ez a szempont kerül előtérbe (mégha 1%-ban is használja ki)
aki meg a lehető legoptimálisabb teljesítmény-fogyasztás kombinációkban gondolkodik (és nem akar két 8800GT-t kihajtani közepes felbontásban), annak jó választás az X2. mégjobb a BE széria.
tehát amire utalsz, az egyfajta szélsőség, hogy 7/24 ben megy a gép, csak ritkán (1%) kell kraft, stb. de igaz, ebben az esetben én is az AMD mellett döntenék. (így is amellett döntöttem, de ez más kérdés
-
fLeSs
nagyúr
Egyszer már leírtam neked, hogy throttlingolással sokkal jobban vissza lehet venni az órajelet, idleben nem 6x333 lesz. Én ha úgy állítom be, akkor 3150-ről 1280 MHz-re veszi vissza a proci órajelét az RM, ez a throttling. A feszt tényleg nem lehet 1,16V alá állítani.
"megjegyzés: 275 FSB-vel sokat csökken a számítási teljesítmény a 333-hoz képest"
miben? Everestben? másban nem fogod megérezni.
-
dokar
addikt
válasz
radírfej
#458
üzenetére
egy sima x2 tuninggal ugyanúgy megkapja azt a pici "FSB" pluszt, ami miatt meg alacsony szorzóval is nagyobb órajel marad, ergó nem biztos, hogy kisebb feszültséggel eldöcög.
nézzünk egy BE-2400-at:
alap: 11.5x200=2300
tuning ilde: 4x290=1160 (1V elég)
tuning load: 11.5x290=3335 (ide kell már valszeg 1.4V - 1.5V)akkor most az E4500-am:
alap: 11x200=2200
tuning ilde: 6x333=1998 (1.1V, ennél kevesebbet nem lehet)
tuning load: 9x333=2997 (~1.3V alapfesz, ennél többet nem lehet)
tuning ilde: 6x275=1650 (1.1V, ennél kevesebbet nem lehet)
tuning load: 11x275=3025 (~1.3V alapfesz, ennél többet nem lehet)
megjegyzés: 275 FSB-vel sokat csökken a számítási teljesítmény a 333-hoz képest
végül az 5000+ BE:
alap: 13x200=2600
tuning ilde: 4x200=800 (kevesebb mint 1V bőven elég)
tuning load: 17x200=3400 (ide kell már valszeg 1.4V - 1.5V)melyik a szimpatikus, figyelembe véve, hogy 99% idle és 1% full load?
-
#460
dokar
addikt
VaniliásRönk
#456
dokar
addikt
válasz
VaniliásRönk
#456
üzenetére
nem csak a magasabb idle órajel miatt gázos a kóró, hanem azért is, hogy energiamenedzsment mellett nem lehet túlfeszes órajelet elérni.
jó lenne, ha technológiailag az intel felnőne az amd-hez a következőkben:
-FSB-t váltsa le (talán majd Nehalem)
-min 6x szorzó legyen inkább 4x
-energiamenedzsmentnél az alulfeszezés mellett az extra fesz lehetősége is adott legyen
-független magórajel (K8-nál még nincs, de K10-nél igen) -
radírfej
senior tag
gyárilag valóban a via c3 volt az utolsó, de CM vagy AC (pl freezer64) hűtők nagyobb hőcsöves bordái képesek venti nélkül is elbánni egy jól belőtt rendszerrel.
különben a vájtfülűeknek a 200rpm is hangos.
vaniliásRönk: igen, csak egy sima x2 tuninggal ugyanúgy megkapja azt a pici "FSB" pluszt, ami miatt meg alacsony szorzóval is nagyobb órajel marad, ergó nem biztos, hogy kisebb feszültséggel eldöcög.
mod. off
-
#456
VaniliásRönk
nagyúr
radírfej
#455
VaniliásRönk
nagyúr
válasz
radírfej
#455
üzenetére
A felfele szabadszorzótól eltekintve minden K8 képes erre, nem BE prociknál annyi a megkötés, hogy a chipset fogyasztását nem tudod megspórolni, ami mondjuk egy jófajta nVidiánál lehet max. +10-15W, de még ez is kevés a CPU többletfogyasztásához, ami ennek többszöröse lehet, ha nem tudod alulfeszelni, levenni a szorzót.
-
radírfej
senior tag
azért tegyük hozzá, hogy a BE procikkal tudod ezt eljátszani csak, egy sima x2 ugyanúgy viselkedik, mint az említett E4500.
de persze igaz, ami igaz, a kettő ritkán találkozik. mármint a jelentősebb tuning, ill a minimális fogyasztás (és az ezel járó minimális hőtermelés és zajszint) igénye. ebben az 5000+ BE proci az általad említett trükközéssel lehet alternatíva.
mod: fLeSs: nem csak a villanyszámla itt a tét, hanem mondjuk egy 0-át pörgő venti is kijöhet ebből a felállásból.
-
dokar
addikt
na ha már ilyen sokan kérdezik, akkor bemásolom ide is:
Én 99%-ban töltögetek (idle állapot) és csak 1%-ban van teljes terhelésen a proci.
Az E4500-at alapfesszel 3GHz-ig tudom húzni FSB emeléssel. Max szorzó: 11x.
A processzor teljesítmény menedzsmentje béna,mert min szorzó 6x, míg AMD-nél 4x.
Max szorzó 5000+ BE esetében bármi lehet (szorzó független). Ebből következik, hogy az FSB-t nem muszáj húznom, ami alacsonyabb idle órajelet von magával, ami kisebb fogyasztás, kevesebb hőtermelést, halkabb ventiműködést eredményez. Ha az E4500 proci órajelét 11x274-el állítom elő, akkor ugyan alacsonyabb az idle órajel, mint 9x333 esetén, de a full load teljesítmény is csökkeni fog (elavult AGTL+ buszrendszer).
Továbbá hiába használok rmclock-ot teljesítmény menedzsmentre, mert csak alapfeszes tuningot lehet. Hiába állítok be BIOS-ban magasabb feszt, az rmclock csak az alapértemezett VID-ig engedi beállítani. AMD proci esetén tehát idle állapotban kisebb az órajel, de továbbá a max órajel is több, mert adhatok +feszt az cpu-nak full load esetén, míg az Intel-nél csak az alapfesz lehet. Ha nem az rmclock-ot használom E4500-nál, hanem a gyári C1E és EIST-et, akkor ha pl 1.5V-ot állítok be BIOS-ban, akkor az full load és idle állapotban is ugyanennyi marad.mod: -> off
kieg: na lehet támadni.
előre mondom, hogy nem vagyok fan. -
fLeSs
nagyúr
Sztem az EPIC az éppenséggel VLIW+szuperskalár.
Az Itanium teljesítménye meg most olyan amilyen (annyira azért nem rossz), meglátjuk mire lesz képes IMC-vel meg 80 MB L3 cache-sel.
(mondjuk 32 nm-en, ahol a tranzisztorszám nem lesz probléma). Ahova az itaniumot pozícionálja az Intel, ott nem gond a chip mérete és ára.Megtod nekem mondani, hogy pl. a Sun vagy az IBM a Rock és a Power6 után merre haladnak tovább? A Sun berak a procijába majd 64 magot, magonként 8 szállal?
Ezt milyen programmal fogod tudni kihasználni? Illetve gondolod képesek lesznek áthidalni az ebből adódó problémákat? Az IBM meg OoO-ról (P5) most átnyergelt in-orderre (P6), később mit eszelnek ki? Visszatérnek az OoO-ra? Vagy mondjuk 4magosra fejlesztik a P6-os designt, plusz felnyomják az órajelet 6 GHz-re? Lesz vagy 300 watt a fogyasztása, de nem gond. Az IA-64-nek a memória elérése és mérete döntő fontosságú, mert az utasítások és az operandusok egy része is átlagosan kétszer nagyobb, mint egy x86-os/RISC (maradjunk a Powernél) procinál (átlag 2,5-3 vagy 4 byte vs 128/3 bit, azaz 5,3 byte). Van egy nagy rakat végrehajtó egység, ha elég gyors a memória, akkor tudod őket etetni, csak ezen múlik. Ha véletlenül belebotlanak egy olyan korlátba, hogy már a végrehajtó egységek a szűk keresztmetszet, akkor a jelenlegihez bepakolnak még párat és kész, az Itanium magmérete (most a cache-t ne vedd figyelembe) nagyon kicsi az összes többi megvalósításhoz képest, szóval simán belefér.
-
ddekany
veterán
Ha az explicit párhuzamosságot nem "tűnteti el" a programozó számra a compiler (vagy intepeter, JIT, akármi), akkor meg is ette az egészet a fene. Szóval akkor mos mi is lett ezzel? Eddig nem voltak képesek jó compiler-eket írni hozzá, vagy a végén kiderült, hogy más paradigmájú programozói nyelveket kéne hozzá használni?
-
Abu85
HÁZIGAZDA
A IA-64 az EPIC elvű rendszer. Technikailag tényleg non-plusz ultra, csak a szoftveripar most kezd barátkozni explicit párhuzamos rendszerekre való fejlesztéssel. Jelenleg az az elsődleges cél, hogy a programod a lehető leggyorsabban kiad, a lehető legjobb állapotban. Az EPIC elvű rendszerek tipikusan elméletben működnek, a lenyűgöző képességek a gyakorlatban többnyire hajtépést eredményeznek.
A szuperskaláris procik mellett jelenleg talán a VLIW rúghat még labdába, de az EPIC semmiképp. -
#446
radírfej
senior tag
VaniliásRönk
#445
radírfej
senior tag
válasz
VaniliásRönk
#445
üzenetére
phienj egy picit, nem kell kardozni ott, ahol nincs harc.
miközben az igazságot védted az AMD oldalán, elfáradtál. biztos ezért tüzelsz ész nélkül jobbra, balra.
-
#444
stevve
veterán
shabbarulez
#441
válasz
shabbarulez
#441
üzenetére
Jah, persze a mostaninál jobb... annál legyen is!
Nézted a képeket? egy szétbuherált lapos van rajtuk. Szerintem az is sokat elárul majd, hogy melyik gyártók és mikor veszik át. Remélem jó lesz, jó áron. 
-
#443
fLeSs
nagyúr
VaniliásRönk
#442
fLeSs
nagyúr
válasz
VaniliásRönk
#442
üzenetére
Sztem az is jó lenne, ha tiszteletben tartanád amit gondol/ír, és nem parancsolgatnál neki sem másnak.
-
#442
VaniliásRönk
nagyúr
shabbarulez
#441
VaniliásRönk
nagyúr
válasz
shabbarulez
#441
üzenetére
A jelenlegi Centrinohoz hasonlítják, mi máshoz kéne? Gondolod kapnak következő generációs ES példányokat Inteltől hogy azzal vethessék össze?
Egyébként is, ha már igérgetésnél tartunk, mobil platformon az Intelnek sem kell szégyenkeznie, fűt-fát ígért az X3100-ba is, aztán mi lett a vége?
Különben meg jó volna ha nem állandóan az AMD-s topikokban nyomnád az Intel PR-t, inteles topikokban biztos nagyobb sikert aratnál.
-
#441
shabbarulez
őstag
stevve
#436
shabbarulez
őstag
A K10 megjelenéséig is azt állították róla hogy jól sikerült és a kóró akár nyugdíjba is vonulhat mellette, de a megjelenés után a száraz tények hamar kijózanította közvéleményt. Ezek utána Pumánál óvatosabban kezelném az AMD hasonló kijelentéseit. Megint ugyanazt játszák mint K10-nél, régi generációs modellekhez hasonlítják egy még jővőben megjelenő platformjuk terjesítmény és jééé ahhoz képest jobb. Hát persze hogy jobb gáz is lenne ha még azt se tudná überelni, de nem ahhoz képest kell jobbnak lennie ami addigra már talán nem is lesz a piacon, hanem az Intel jővőbeli, időben ugyanakkor piacon lévő fejlesztéseivel kell versenyben maradni. Ez kicsit olyan mint amikor a Ford 2008-ban kijelenti hogy az 1988-as Opel Kadettnél jobb autót alkotott. Elég szomorú lenne ha még ezt a lécet sem tudnák átugroni, de nekik az 2008-as Opel Astrát kell megverniük. Ugyanígy a Puma fő riválisa az Intel Montevina platformja lesz, ahhoz kell mérni a teljesítményét is. Ott pedig sok fejlesztés lesz, korábbi hírek szerint 3x nagyobb grafikus teljesítmény a korábbi modellhez képest, integrált HD-DVD, Blu-Ray hardwares lejátszás támogatás VC-1 és H.264 kódolsához is. Épp ezért pl. a cikkben említett HD-DVD lejátszásbeli különbség addigra már nagy valószínűséggel sehol nem lesz.
-
ftc
nagyúr
válasz
Takhanto
#438
üzenetére
Hyper-Threading az egy virtuális 2. magot mutat az OS felé...P4-nl került bevezetésre...
HT AMD CPU ezzel a buszrendszerrel kommunikáll...ez teszi lehetővé szervereknél a 8+ magokat teljesitmény csökkeés nélkül...
A virtualizácio...hardveresen segiti 1-2 program müködését...pl Linux latt Wint emulálsz...nem fog behallni a gép
-
#439
stevve
veterán
VaniliásRönk
#437
válasz
VaniliásRönk
#437
üzenetére
Én is ezt sejtem mögötte, meg azt, hogy lehet, hogy kicsit elcsúsztak a hibajavítással is...
-
Ismét csúszást jelentett be az AMD:
[link]"Have we given up on the CPU performance crown? Absolutely not," he emphasized. "Hey look, we know exactly what the issues are with the quad-core, we know how to fix them, and we're hell-bent on getting those fixes into the market as soon as possible."
viszont egy jó hír, bár nem ide tartozik:
A Puma jól sikerült...
[link] -
ftc
nagyúr
-
fLeSs
nagyúr
MMX: Intel, 8x8-2x32 bit integer operandusok, csak vertikális műveletek, x87-es stack-regisztereket (MM0-MM7) használ, tehát egyszerre a kettő (x87 és MMX) nem müxik
3DNow!: AMD, csak 2x32 bit Integer/FP operandust támogat ("emulálva" 64-128bit), vertikális és horizontális műveletek egyaránt, viszont még mindig x87-es regisztereken
SSE: Intel, 8x16-4x32 bit Int+FP operandusok, külön 128 bites regiszterek (tehát FP utasításoknak többé nem az x87-eseken kell dolgozni), de még mindig csak vertikális műveletek
szerk: a lényeg, hogy az SSE nem a 3DNow!-ra épül, hacsak nem az FP utasításokat annak vesszük, de a fejlesztési irányt meghatározta, hogy az MMX-ből kimaradtak az FP operátorok, szal ez lehetett az elsődleges célja az SSE-nek, az új regiszterkészleten felül.
1ébként az egész egy nagy gagyi az Altivechez képest.
IA-64: lehet, hogy el fog bukni, de jelenleg ebben az architektúrában van a legnagyobb kiaknázatlan potenciál, a cache latency csökkenésével és méretének növekedésével (illetve a memória alrendszer fejlődésével) együtt gyorsul az architektúra. A CISC és a RISC rendszerek ugyanarra az analógiára épülnek kb. 2000 óta, azóta csak az újabb SIMD utasításkészletek megjelenése és a TLP (szálak párhuzamosítása) tette lehetővé a teljesítmény növelését (ugye egyre több mag egy lapkán). Az OoO, spekulatív végrehajtás, stb.-n felül nincs semmi újdonság már régóta.
-
#427
gV
őstag
VaniliásRönk
#426
gV
őstag
válasz
VaniliásRönk
#426
üzenetére
-
#425
gV
őstag
VaniliásRönk
#424
gV
őstag
válasz
VaniliásRönk
#424
üzenetére
nem csak én pl nem jelentettem ki h ez v az megbukott
mivel nem nagyon van benne tapasztalatom, de te biztos az Itanium eladásaival kelsz és fekszel
egyébként is kérdeztem és nem mondtam
-
#423
gV
őstag
VaniliásRönk
#422
gV
őstag
válasz
VaniliásRönk
#422
üzenetére
jól gondolom h te nem pártatlanul szemléled a dolgokat?
-
#422
VaniliásRönk
nagyúr
gV
#421
VaniliásRönk
nagyúr
-
Állj!
Sehol nem mondtam, hogy az AMD nem vett egy Intel-t és nem azzal kezdte, de az SSE, mert itt csak arról volt szó! és nem másról!!!! volt témában.Előbb olvassátok végig a hsz-eket. Nem a történelemről beszéltünk, azt mindenki tudja, hogyan kezdték! Ezzel már ne gyertek, légyszi.
Épp azt próbáltam én is leírni, hogy az SSE minden volt, csak nem lopás, de az Intel-fanboy-ok szerint az AMD mindent lopott, miközben az Intel nagy lemaradásában szintén lemásolta a 64 bitet.
Nem tudom, hol olvastátok, hogy én azt írtam, hogy mi volt a "CPU történelem hajnalán"...
gv:
arra próbáltam reagálni, amikor azt írtad, hogy örüljenek az AMD-sek, hogy ingyen megkapták az SSE-t, semmi másra. Erre írtam, hogy az Intel viszont a 64 bitet másolta le.Hogy miért épül az SSE a 3DNow!-ra? Mert ezek nagyban nem különböznek, de inkompatibilisek és mivel a 3DNow! volt előbb és aztán jött az SSE, nem értem, miért ne lehetne? Épp a szerződéseik engedik, hogy ez megtörténjen. MMX - 3DNow! - SSE...
Az IA64 pedig egy picit később jött ki és (azt hiszem, itt jön be a történelem) lemásolta az AMD megoldását saját 64 bites megoldásaikhoz, mert főként időben voltak lemaradva.
És az, kedves gv, hogy már totál hülyének nézel, nem biztos, hogy a fórum keretei közé tartozik!
"igy van, miköze az SSE-nek a 3dnowhoz(?) ezt kérdezem tőle."
Éppen te jöttél ezzel:
"amugy tök jó h az Intel fejlesztésével (SSE) jönnek állandóan az amd-sek örüljenek h "hála" a két cég közötti szerződésnek megkapják ingyen"Szóval így jön ide. Az Intel szintén ingyen kapta a 3DNow!-t, amire az SSE épül.
De most már akkor esetleg le is lehet szállni rólam és a magas lóról, ok?
Köszi
No offense -
ftc
nagyúr
Ha jol emlékszem akkor Ti oylanokrol beszéltek ami a keresztlicenc megállapodás altt cserélődnek...
MMX volt alapja mindennek...de AMD részéről 3DNow és fejlettebb válltozatai eléggé jók voltak.Emlékeim nem csalnak pontosabban tudtak számolni
Csak ugye, ha beakartak törni a piacra akkor SSE-*re kelett átállni...
De egy példa MMX +70 utasitás az lett SSE...amely utasitások al ebegőpontos számitásra vannak kihegyezve
-
gV
őstag
Hol irtam h lopott az AMD
, az F1ben sem lopás volt, a Ferrari alkalmazott önhatalmulag adta oda a Mekisnek az általa legalisan hozzáférhető ferraris adatokat.Az x64 bizony azért lett "csak" kiegészítés, mert ha totál inkompatibilis, nem fut be.
Akkor belátod h mivel kevesen használnak 64bites op rendszert keves használják ezt az AMD-s fejlesztést és h nem függ töle az x86?
Ja, az SSE sem volt levédve, egy válasz volt a 3DNow!-ra, amit aztán az AMD is implementált.
akkor miért kellett erről szerződést kötni?
Az Intel erre alapozva hozta létre az SSE-t, de inkompatibilis utasításokkal.
Mutatnál vmit ami bizonyitja h a 3dnow alapjaira épül az SSE?
-
Chaser
legenda
Ha tudnád a 2 cég történetét, akkor rájönnél hogy nem vakítás ez. Anno az AMD szépen lekopizott sok mindent az inteltől, pontosabban kicsit módosított a dolgokon, és így nem lett jogi gebasz. Az intel pedig lenyúlta a 64 bites történetet. Ha megfigyeled a 2 architektúra mára már eléggé különböző, vajon mért?
-
Nem az Intel kapta, de azt is kitette az AMD, szóval így jön ide. Ne vakíts már, hogy az AMD lopott az Inteltől, a mindentudútól... mint az F1-es sztori idén. Az x64 bizony azért lett "csak" kiegészítés, mert ha totál inkompatibilis, nem fut be.
Ja, az SSE sem volt levédve, egy válasz volt a 3DNow!-ra, amit aztán az AMD is implementált. Ennyi. Az Intel erre alapozva hozta létre az SSE-t, de inkompatibilis utasításokkal.
-
gV
őstag
a HT biztosan nem az Intel kapta meg szal h jön ide
És ha az x64-et senki nem használja szerinted, akkor miért örültek annyira a programozók és egy sor cég, hogy maradt a 32bit felé kompatibilitás?
én 32biten maradtam annak semmi köze az x64-hez az csak egy kiegészités (nézd meg az Everestben)
ezt honnan veszed?
-
Ennél azért jóval többet. pl a HT-t is kiadta a kezéből. Ne gondoldd, hogy az Intelnek nincs szüksége senki fejlesztéseire. Ez leányálom.
És ha az x64-et senki nem használja szerinted, akkor miért örültek annyira a programozók és egy sor cég, hogy maradt a 32bit felé kompatibilitás? Le kellene szokni arról, hogy csak az asztalik szegmensét és azon belül is csak az egyik fél álláspontját nézzük.(#405) gV : ezt honnan veszed?
-
-
#402
gV
őstag
VaniliásRönk
#395
gV
őstag
válasz
VaniliásRönk
#395
üzenetére
Ilyen alapon az Intelnek csődbe kellett volna mennie a 2000-től 2006-ig terjedő időszakban, legalább kétszer...
nem mivel maximum a az asztali szegmensbe nyujtott gyengébb teljesítményt minden másban ezen ídőszakban is jól álltak (lsd Pentium M, Itanium1-2)
Ja bocs mégsem, az Intel a D805-öt leszámítva nem volt olcsó.
érdekes, nekem nem D805-öm volt (hanem Northwood) mégsem mentem csődbe
-
igaz, H.264, de a codec, amit használ enkódolásra, az X264. Aztán újraolvasva kicsit zöldség, amit írtam, mert nyilván egy gyorsabb CPU hamarabb végez vele, csak arra akartam kitérni, hogy az AMD is optimális megoldás lehet ezekre. Na de mindegy, néha csacskaságokat is kell írni
![;]](//cdn.rios.hu/dl/s/v1.gif)
gv: azért az Intel is kapott jó pár szabványleírást, implementálást, amit az AMD fejlesztett ki.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Wise (ex-TransferWise)
- A lemondást javasolja az Intel vezetőjének Donald Trump
- Háztartási gépek
- Parkside szerszám kibeszélő
- WLAN, WiFi, vezeték nélküli hálózat
- Nők, nőügyek (18+)
- CURVE - "All your cards in one." Minden bankkártyád egyben.
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Revolut
- bambano: Bambanő háza tája
- További aktív témák...
- AKCIÓ! Microsoft Surface 5 13,5 notebook - i5 1235U 8GB RAM 256GB SSD Intel Iris Xe IGP 27% áfa
- Huawei P20 Lite 64GB, Kártyafüggetlen, 1 Év Garanciával
- HP ZBook Studio 8 WorkStation i7-11850H 16GB 256GB Nvidia Quadro T1200 15.6" FHD IPS 1 év garancia
- Konzol felvásárlás!! Nintendo Switch
- 512 GB-os PCIe 4.0-as M2 SSD-k garanciával
Állásajánlatok
Cég: FOTC
Város: Budapest