Az AMD jövőre ígéri az SSE3 technológiát
Jelentkezz be a hozzászóláshoz.
#34
Azért nem mindenkinek van szüksége rá.
Egy átlag user aki anyit tud, hogy hogykell bekapcsolni a gépet, kicsit netezik, Wördözik, majd kikapcs.
Egy átlag user aki anyit tud, hogy hogykell bekapcsolni a gépet, kicsit netezik, Wördözik, majd kikapcs.
ilyen feltételek mellett nem éri meg... ez az egész nem tetszik.. ..-ohh.. már látom a fényt az alagút végén!.. -te h*lye.. az csak a vonat!...
#33
Aki szerint FDD már nem kell, az próbáljon meg egy RAID vezérlõt installálni nélküle. És mivel manapság mr szinte minden alaplapra integrálva van, és a vinyók is meglehetõsen olcsók, nemsokára normális lesz az otthoni gépekben is RAID.
![[HUN]PAStheLoD](https://media.sg.hu/forum/avatars/10334754621140968716.jpg)
#32
ez érthetõ is , mert amíg egy norton ghostnál alapként a floppy-t ajánlja fel ill. a win xp is 6floppys recovery setet akar csinálni az emberek szeretik ha van elfekvõben egy fdd .. nekem is van vagy 3 , de be sincs rakva a gépbe .. azaz most nem látom mer sötét van , de biosból tuti tiltotam hogy még annyi felesleges erõforrást se használjon..
hátö .. az előző aláírásom sokkal jobb volt :]
#31
A PCI-X nem olyan nagyon gyors, ráadásul a sávszélességen osztoznak slotok. És még sima párhuzamos busz, ami nehezíti, drágítja az alaplap tervezését. 64 bites mód esetén jó hosszú kártyák kellenek, ami szintén drágít.
(Szerintem a 64KB-onkénti lapozás már nincs, vagy nem tudom, mire gondolsz.)
(Szerintem a 64KB-onkénti lapozás már nincs, vagy nem tudom, mire gondolsz.)
#30
Vagyis az emberek ragaszkodnak hozzá (többek között én is), ezért nem egyszerû feladat a piacról történõ eltüntetése.
ilyen feltételek mellett nem éri meg... ez az egész nem tetszik.. ..-ohh.. már látom a fényt az alagút végén!.. -te h*lye.. az csak a vonat!...
#29
Az FDD-t kb vagy 5 éve króbálják már kihozni a piacról (fõleg amerikában)
Ezt úgy próbálják, hogy a szábítógépgyártók többsége nem tesz bele alapból Floppymeghajtót, de a felhasználók (megintcsak többsége) igényét tartja rá, hogy belegyen építve (vagyis tesz, tetet bele, a gyártóval)
Ezt úgy próbálják, hogy a szábítógépgyártók többsége nem tesz bele alapból Floppymeghajtót, de a felhasználók (megintcsak többsége) igényét tartja rá, hogy belegyen építve (vagyis tesz, tetet bele, a gyártóval)
ilyen feltételek mellett nem éri meg... ez az egész nem tetszik.. ..-ohh.. már látom a fényt az alagút végén!.. -te h*lye.. az csak a vonat!...
#28
Húú gyerekek, ne vitázzatok már! Hogy mi mögött mi rejlik azt úgy is csak a gyártó tudja. Van neki x-emberbõl álló részlege, ahol piaci, fejlesztési, stb stratégiákat dolgoznak ki, és bizony nem 1-2 hónapra, hanem évekre elõre. Lehet hogy egy számunkra jlentéktelen lépésük egy majd 2évvel késõbbi jelentõsebb dologgal van összefüggésben.
Na mind1. Addig amíg az átlah júzerek 70%-a csak v fõleg játékokra használja a gépét és ott jól futnak a dolgok sseakárhyány nélkül is, addig õt rohadtul nem érdekli, hogy mit hogy menynivel gyorsabban kódol, v enkódol.
A maradék 30% meg nem hülye és azt veszi ami neki a legjobban megfelel.
A PCI-E jó dolog, de nem értem, hogy mért nem a már régen meglévõ és jóval gyorsabb PCI-x et vezettük be a home szegmensbe is. Egyébként meg a pc-s világ alapjait is le kéne cserélni. pl. 64Kb-on ként i memlapozás, PCI, FDD, IDE, stbstbstb.
Na mind1. Addig amíg az átlah júzerek 70%-a csak v fõleg játékokra használja a gépét és ott jól futnak a dolgok sseakárhyány nélkül is, addig õt rohadtul nem érdekli, hogy mit hogy menynivel gyorsabban kódol, v enkódol.
A maradék 30% meg nem hülye és azt veszi ami neki a legjobban megfelel.
A PCI-E jó dolog, de nem értem, hogy mért nem a már régen meglévõ és jóval gyorsabb PCI-x et vezettük be a home szegmensbe is. Egyébként meg a pc-s világ alapjait is le kéne cserélni. pl. 64Kb-on ként i memlapozás, PCI, FDD, IDE, stbstbstb.
#27
Egyébként jönnek az olyan (olcsó) TV-kártyák is, amiken már van HW enkódolás is. Most dobott a piacra hozzá a Conexant egy olcsó chipet.
#26
Pontosabban már a mostani generáció is támogat egy sor dolgot (mpeg1-2, wma (, talán más is) dekólolás, NV-nél mpeg2 enkodolás is), mpeg2 dekólolás-támogatás már az elõzõ generációban is volt, és a DxVA-s kodekek már használták is.
#25
"az ok, hogy lesz hozzá támogatás, de ilyen igényei csak egy nagyon szûk rétegnek vannak."
Most. De ez változik. Jön a HD videózás. Annál még a dekódolás is eléggé megfogja a mai leggyorsabb PC-ket is. És az újabb videokártyák mindegyike támogatni fogja legalábbis a dekódolást (mpeg1-2, wmv, és több más is), de talán az enkódolás is alap lesz. És nem tudhatjuk, hogy nem válik még hétköznapibbá az utóbbi is.
"azt fenntartom, hogy a PCI-E a CPU piacon tökéletesen irreleváns."
Ez csak akkor igaz - legalábbis, hogy "tökéletesen", ha az elsõ mondatod igaz. De hamarosan nem lesz az...
Most. De ez változik. Jön a HD videózás. Annál még a dekódolás is eléggé megfogja a mai leggyorsabb PC-ket is. És az újabb videokártyák mindegyike támogatni fogja legalábbis a dekódolást (mpeg1-2, wmv, és több más is), de talán az enkódolás is alap lesz. És nem tudhatjuk, hogy nem válik még hétköznapibbá az utóbbi is.
"azt fenntartom, hogy a PCI-E a CPU piacon tökéletesen irreleváns."
Ez csak akkor igaz - legalábbis, hogy "tökéletesen", ha az elsõ mondatod igaz. De hamarosan nem lesz az...
#24
az ok, hogy lesz hozzá támogatás, de ilyen igényei csak egy nagyon szûk rétegnek vannak. azt fenntartom, hogy a PCI-E a CPU piacon tökéletesen irreleváns.
When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?
#23
Pedig ez a tendencia. Sõt, a video-enkódolásban, és fõleg dekódolásban már ma is gyakorlat használni. Lásd "DxVA" GPU-s videodekódolás API támogatás a DirectX-ben. Jön az enkódolás támogatás is. Ami még kísérleti fázikban van, az a hangfeldolgozás.
#22
Hmm, kösz az infót. (A PCI-E-vel kapcsolatos kijelentést fenntartod?)
#21
"Én nem ködösítek. A felhasználót nem az érdekli, hogy melyik CPU a gyorsabb, hanem hogy a feladat gyorsabban legyen elvégezve. Ha a GPU-n gyorsabb, akkor azt kell használni."
A GPU nem általános célú CPU. Jelenleg kevés helyen, és kísérleti jelleggel próbálják alkalmazni. mondjuk divx kódolásra lehet, de ne számíts rá, hogy ez általánossá válik.
A GPU nem általános célú CPU. Jelenleg kevés helyen, és kísérleti jelleggel próbálják alkalmazni. mondjuk divx kódolásra lehet, de ne számíts rá, hogy ez általánossá válik.
When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?
#20
"Igen furcsa, hogy az XviD enkódolás AMD-n gyorsabb (más dolgokhoz hasonlóan, kivéve a SYSMark megintcsak furcsa eredményeit), az DivX-né hirtelen az élre tör az intel. Nem mondtam, hogy itt biztos SSE3 vs. "semmi" ügyrõl lenne szó, annyit mondtam, gyanús a dolog. Mivel nem lenne ennyivel gyorsabb az SSE3 az SSE2-nél."
Ez nem az SSE1-2-3-mal való játszadozás eredménye, a divX kódolást hozzú pipe-al rendelkezõ CPUkra optimalizálták, így jóval kevésbé számít az egyes utasítások hosszabb végrehajtási ideje, illetve a nagyobb memóriakésleltetés, így az intel CPUk a magasabb órajelükbõl tudnak elõnyt kovácsolni. Hogy ez miért nincs így az Xvid-nél? az a kódoló nincs annyira optimalizálva, mert nincs mögötte egy több programozót alkalmazó cég. És hogy a divx network miért optilaizált hosszú pipe-ú(jellemzõen intel) processzorokra? azért mert az ügyfeleik erre tartottak igényt. Hafel akarja venni a versenyt a nyílt kódú versenytársaival(pl. xvid) akkor olyan szolgáltatásokat kell nyújtania, amiket a többiek nem. mivel az ügyfeleik nagyrésze a vállalati szegmensbõl kerül ki(akik _döntõ_ többségben intel-alapú rendszereket használnak), a hozzú pipe optimalizáció, (ami nem egy egyszerû feladat) egy olyan szolgáltatás, amit a többiek nem nyújtanak. És itt nem AMD diszkriminációról, hanem intel optimalizációról van szó. nem mindegy.
"Hát, nem biztos, hogy a felhasználóknak is ez a véleménye... Mivel ez az õ érdekeik ellen is való."
a felhasználók 99.5%a szarik bele, azt sem tudja, mi az a fordító.
Ez nem az SSE1-2-3-mal való játszadozás eredménye, a divX kódolást hozzú pipe-al rendelkezõ CPUkra optimalizálták, így jóval kevésbé számít az egyes utasítások hosszabb végrehajtási ideje, illetve a nagyobb memóriakésleltetés, így az intel CPUk a magasabb órajelükbõl tudnak elõnyt kovácsolni. Hogy ez miért nincs így az Xvid-nél? az a kódoló nincs annyira optimalizálva, mert nincs mögötte egy több programozót alkalmazó cég. És hogy a divx network miért optilaizált hosszú pipe-ú(jellemzõen intel) processzorokra? azért mert az ügyfeleik erre tartottak igényt. Hafel akarja venni a versenyt a nyílt kódú versenytársaival(pl. xvid) akkor olyan szolgáltatásokat kell nyújtania, amiket a többiek nem. mivel az ügyfeleik nagyrésze a vállalati szegmensbõl kerül ki(akik _döntõ_ többségben intel-alapú rendszereket használnak), a hozzú pipe optimalizáció, (ami nem egy egyszerû feladat) egy olyan szolgáltatás, amit a többiek nem nyújtanak. És itt nem AMD diszkriminációról, hanem intel optimalizációról van szó. nem mindegy.
"Hát, nem biztos, hogy a felhasználóknak is ez a véleménye... Mivel ez az õ érdekeik ellen is való."
a felhasználók 99.5%a szarik bele, azt sem tudja, mi az a fordító.
When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?
#19
akarom mondani '..a saját SSE 1-3-unkat AMD-n!'
#18
'Mi adjuk a kompilert, és naná, hogy nem használjuk a saját SSE 1-3-unk AMD-n történõ futtatását - miközben kereszt-licensz szerzõdés keretében kapta -, mert az nemkünk nem elõnyös!' - Hát, nem biztos, hogy a felhasználóknak is ez a véleménye... Mivel ez az õ érdekeik ellen is való.
#17
"Ide csak az intel-közeli szoftverek tartoznak, kereskedelmiek nem."
Nézd csak meg ezt az oldalt:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2261&p=12
Igen furcsa, hogy az XviD enkódolás AMD-n gyorsabb (más dolgokhoz hasonlóan, kivéve a SYSMark megintcsak furcsa eredményeit), az DivX-né hirtelen az élre tör az intel. Nem mondtam, hogy itt biztos SSE3 vs. "semmi" ügyrõl lenne szó, annyit mondtam, gyanús a dolog. Mivel nem lenne ennyivel gyorsabb az SSE3 az SSE2-nél.
"Azt mondtam. Tanulj meg olvasni."
Tényleg, bocs! <#nyes>
"Már csak azért sem, mert itt a CPUk teljesítményérõl van szó, és nem a GPUkról. Ne ködösíts."
Én nem ködösítek. A felhasználót nem az érdekli, hogy melyik CPU a gyorsabb, hanem hogy a feladat gyorsabban legyen elvégezve. Ha a GPU-n gyorsabb, akkor azt kell használni.
Nézd csak meg ezt az oldalt:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2261&p=12
Igen furcsa, hogy az XviD enkódolás AMD-n gyorsabb (más dolgokhoz hasonlóan, kivéve a SYSMark megintcsak furcsa eredményeit), az DivX-né hirtelen az élre tör az intel. Nem mondtam, hogy itt biztos SSE3 vs. "semmi" ügyrõl lenne szó, annyit mondtam, gyanús a dolog. Mivel nem lenne ennyivel gyorsabb az SSE3 az SSE2-nél.
"Azt mondtam. Tanulj meg olvasni."
Tényleg, bocs! <#nyes>
"Már csak azért sem, mert itt a CPUk teljesítményérõl van szó, és nem a GPUkról. Ne ködösíts."
Én nem ködösítek. A felhasználót nem az érdekli, hogy melyik CPU a gyorsabb, hanem hogy a feladat gyorsabban legyen elvégezve. Ha a GPU-n gyorsabb, akkor azt kell használni.
#16
persze, kikerülhetõ, kevés hackeléssel.
És ez az intelre nem vet árnyékot, teljesen természetes, hogy piaci verseny esetén minden cég a saját termékeit szerené elõnybe helyezni, ez nem szemétség, vagy ilyesmi, ez teljesen normális. Annak, hogy a 64bites compiler nem alkalmaz ilyen eszközöket valószínûleg az AMD-Intel keresztlicensz szerzõdés az oka.
És ez az intelre nem vet árnyékot, teljesen természetes, hogy piaci verseny esetén minden cég a saját termékeit szerené elõnybe helyezni, ez nem szemétség, vagy ilyesmi, ez teljesen normális. Annak, hogy a 64bites compiler nem alkalmaz ilyen eszközöket valószínûleg az AMD-Intel keresztlicensz szerzõdés az oka.
When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?
#15
Ha az inteles SIMD utasítások AMD-n való nem-használata az intel kompilere miatt van, hát az is az intelre vet árnyékot. De én úgy tudom, a máshogy is meg lehet oldani a vizsgálatot, tehát egy szoftvercég nem mutogathat erre.
#14
"Tisztában vagyok ezzel, de egyes esetek nagyon gyanúsak... (Amikor pl. az SSE3-at használják, de az SSE2-t azért sem, stb.)"
ilyen nincs.
"Pedig úgy tûnik, megtörténik... Egyes szoftverek "indokolatlanul" lassabbak AMD-n. (Miközben másik hasonló program gyorsabb rajta...) Azaz olyan, mintha intelen használnák pl. az SSE3-at, AMD-n meg semmit."
Ide csak az intel-közeli szoftverek tartoznak, kereskedelmiek nem.
"Õõõ, nem azt akartad írni, hogy a CPUid-t (típus) nézte, és nem a CPU flageket (MMX, SSE, stb.)?"
Azt mondtam. Tanulj meg olvasni.
"
Már hogy ne lenne??? Egy megfelelõ GPU hatékonyabb ilyesmire, mint a CPU, a párhuzamosított feldolgozás miatt. (Az mpeg2 - és talán más - dekódolást már "régóta" támogatták a GPU-k, és az NV új GPU-i már az enkodolás is támogatják.)
A PCI-E meg úgy jön ide, hogy sokkal nagyobb a visszirányú (grafkártya->rendszer) sávszélessége, mint az AGP-nek. (Az SD még talán belefér az AGP-be, de a HD már nem nagyon. Most hadd ne számolgassak.)"
Már csak azért sem, mert itt a CPUk teljesítményérõl van szó, és nem a GPUkról. Ne ködösíts.
ilyen nincs.
"Pedig úgy tûnik, megtörténik... Egyes szoftverek "indokolatlanul" lassabbak AMD-n. (Miközben másik hasonló program gyorsabb rajta...) Azaz olyan, mintha intelen használnák pl. az SSE3-at, AMD-n meg semmit."
Ide csak az intel-közeli szoftverek tartoznak, kereskedelmiek nem.
"Õõõ, nem azt akartad írni, hogy a CPUid-t (típus) nézte, és nem a CPU flageket (MMX, SSE, stb.)?"
Azt mondtam. Tanulj meg olvasni.
"
Már hogy ne lenne??? Egy megfelelõ GPU hatékonyabb ilyesmire, mint a CPU, a párhuzamosított feldolgozás miatt. (Az mpeg2 - és talán más - dekódolást már "régóta" támogatták a GPU-k, és az NV új GPU-i már az enkodolás is támogatják.)
A PCI-E meg úgy jön ide, hogy sokkal nagyobb a visszirányú (grafkártya->rendszer) sávszélessége, mint az AGP-nek. (Az SD még talán belefér az AGP-be, de a HD már nem nagyon. Most hadd ne számolgassak.)"
Már csak azért sem, mert itt a CPUk teljesítményérõl van szó, és nem a GPUkról. Ne ködösíts.
When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?
#13
Nincs idõm nagyobb vitába szállni, de azért válaszolnék.
"1: Nem fizetnek senkinek, hogy használják, a SIMD utasítások elterjedése minden platformon általános tendencia."
Tisztában vagyok ezzel, de egyes esetek nagyon gyanúsak... (Amikor pl. az SSE3-at használják, de az SSE2-t azért sem, stb.)
"ennek így nincs sok értelme"
Pedig úgy tûnik, megtörténik... Egyes szoftverek "indokolatlanul" lassabbak AMD-n. (Miközben másik hasonló program gyorsabb rajta...) Azaz olyan, mintha intelen használnák pl. az SSE3-at, AMD-n meg semmit.
"ha arra gondolsz, hogy a régebbi intel compilerek nem a CPU flagjei alapján választották ki a végrehajtandó kódot, hanem a CPUid alapján, és AMD CPU esetén az FPU optimalizált kódot futtatják."
Õõõ, nem azt akartad írni, hogy a CPUid-t (típus) nézte, és nem a CPU flageket (MMX, SSE, stb.)?
"Amúgy ez teljesen megváltozik, a 64bites intel compiler már a CPU flagjei alapján válsztanak kódot."
Hát még jó...
"Ez akkora faszság, hogy már egy cikkbe kívánkozik, értelmes fórumozó ilyet nem ír le. a PCI-E-nek semmi köze a processzor SIMD bõvítéseihez..."
Már hogy ne lenne??? Egy megfelelõ GPU hatékonyabb ilyesmire, mint a CPU, a párhuzamosított feldolgozás miatt. (Az mpeg2 - és talán más - dekódolást már "régóta" támogatták a GPU-k, és az NV új GPU-i már az enkodolás is támogatják.)
A PCI-E meg úgy jön ide, hogy sokkal nagyobb a visszirányú (grafkártya->rendszer) sávszélessége, mint az AGP-nek. (Az SD még talán belefér az AGP-be, de a HD már nem nagyon. Most hadd ne számolgassak.)
"1: Nem fizetnek senkinek, hogy használják, a SIMD utasítások elterjedése minden platformon általános tendencia."
Tisztában vagyok ezzel, de egyes esetek nagyon gyanúsak... (Amikor pl. az SSE3-at használják, de az SSE2-t azért sem, stb.)
"ennek így nincs sok értelme"
Pedig úgy tûnik, megtörténik... Egyes szoftverek "indokolatlanul" lassabbak AMD-n. (Miközben másik hasonló program gyorsabb rajta...) Azaz olyan, mintha intelen használnák pl. az SSE3-at, AMD-n meg semmit.
"ha arra gondolsz, hogy a régebbi intel compilerek nem a CPU flagjei alapján választották ki a végrehajtandó kódot, hanem a CPUid alapján, és AMD CPU esetén az FPU optimalizált kódot futtatják."
Õõõ, nem azt akartad írni, hogy a CPUid-t (típus) nézte, és nem a CPU flageket (MMX, SSE, stb.)?
"Amúgy ez teljesen megváltozik, a 64bites intel compiler már a CPU flagjei alapján válsztanak kódot."
Hát még jó...
"Ez akkora faszság, hogy már egy cikkbe kívánkozik, értelmes fórumozó ilyet nem ír le. a PCI-E-nek semmi köze a processzor SIMD bõvítéseihez..."
Már hogy ne lenne??? Egy megfelelõ GPU hatékonyabb ilyesmire, mint a CPU, a párhuzamosított feldolgozás miatt. (Az mpeg2 - és talán más - dekódolást már "régóta" támogatták a GPU-k, és az NV új GPU-i már az enkodolás is támogatják.)
A PCI-E meg úgy jön ide, hogy sokkal nagyobb a visszirányú (grafkártya->rendszer) sávszélessége, mint az AGP-nek. (Az SD még talán belefér az AGP-be, de a HD már nem nagyon. Most hadd ne számolgassak.)
#12
kedves barátom téged sem az intel alkalmaz CPU architektnek úgy látom:
1: Nem fizetnek senkinek, hogy használják, a SIMD utasítások elterjedése minden platformon általános tendencia.
"Sõt, egyes esetekben nem is támogatják az eggyel kisebb cuccot, mert az már van az AMD-ben is"
ennek így nincs sok értelme, ha arra gondolsz, hogy a régebbi intel compilerek nem a CPU flagjei alapján választották ki a végrehajtandó kódot, hanem a CPUid alapján, és AMD CPU esetén az FPU optimalizált kódot futtatják. Amúgy ez teljesen megváltozik, a 64bites intel compiler már a CPU flagjei alapján válsztanak kódot.
"Na majd megváltozik ez, ha jobban elterjed a PCI-E (mert ott már visszafelé és megfelelõ a sávszél, így a konvertálás nagy része a GPU-kra bízható)."
Ez akkora faszság, hogy már egy cikkbe kívánkozik, értelmes fórumozó ilyet nem ír le. a PCI-E-nek semmi köze a processzor SIMD bõvítéseihez...
1: Nem fizetnek senkinek, hogy használják, a SIMD utasítások elterjedése minden platformon általános tendencia.
"Sõt, egyes esetekben nem is támogatják az eggyel kisebb cuccot, mert az már van az AMD-ben is"
ennek így nincs sok értelme, ha arra gondolsz, hogy a régebbi intel compilerek nem a CPU flagjei alapján választották ki a végrehajtandó kódot, hanem a CPUid alapján, és AMD CPU esetén az FPU optimalizált kódot futtatják. Amúgy ez teljesen megváltozik, a 64bites intel compiler már a CPU flagjei alapján válsztanak kódot.
"Na majd megváltozik ez, ha jobban elterjed a PCI-E (mert ott már visszafelé és megfelelõ a sávszél, így a konvertálás nagy része a GPU-kra bízható)."
Ez akkora faszság, hogy már egy cikkbe kívánkozik, értelmes fórumozó ilyet nem ír le. a PCI-E-nek semmi köze a processzor SIMD bõvítéseihez...
When using Linux - there\'re no walls, so we don\'t need any Gates or Windows, do we?
#11
Szerintem is. (Amit úgy használnak ki, hogy fizetnek 1-2 cégnek, hogy ezt használják - minimális, de tesztekben jól mutató gyorsulást produkálva. Sõt, egyes esetekben nem is támogatják az eggyel kisebb cuccot, mert az már van az AMD-ben is.)
Na majd megváltozik ez, ha jobban elterjed a PCI-E (mert ott már visszafelé és megfelelõ a sávszél, így a konvertálás nagy része a GPU-kra bízható).
Na majd megváltozik ez, ha jobban elterjed a PCI-E (mert ott már visszafelé és megfelelõ a sávszél, így a konvertálás nagy része a GPU-kra bízható).
#10
Aha: 10% teljesítménynövekedés 2x-es áron... Jó üzlet - nekik.
Neha ugy tunik, hogy ez az SSE csak azert kell az Intelnek, hogy igy jusson olcson elonyhoz az AMD-vel szemben. Kihasznalja, hogy o vezeti a piacot.
#8
arty - Pedig meg kell venned ha jó , és gyors procit akarsz magadnak
#7
nyócvanezerér' nem vennék procit, de Te tudod 😉
Forza.
#6
És akkor felébredsz ... 😊
Én pedig megelégszek egy S939-es 3800+ -ossal - jövõ februárban. Plusz 1 GB 500 MHz-es TwinX RAM
-----------------------------------------
.:i2k:. = IMYke2000 - @ - 2004® - Elsõ számú honlap
.:i2k:. = IMYke2000 - @ - 2004® - Második számú honlap
-----------------------------------------
Én pedig megelégszek egy S939-es 3800+ -ossal - jövõ februárban. Plusz 1 GB 500 MHz-es TwinX RAM
-----------------------------------------
.:i2k:. = IMYke2000 - @ - 2004® - Elsõ számú honlap
.:i2k:. = IMYke2000 - @ - 2004® - Második számú honlap
-----------------------------------------
Szigorúan magánvélemény | Can’t spell “STEAL” without EA? | Gamer's Hell: DLC, Early-A, Pre-Order, Seasons, Episodes, Regions, Loot Box, Microtransactions, MS Store, Epic Store.
#5
13ezerért, mint a mostani 1466@2200asom 😉 - ez az elõbb kimaradt a kivánságból 😉
Forza.
#4
aztamindenit, mennyi alkalmazás létezik SSE3 támogatással, ahol az intel elõnye behozhatatlan lett emiatt ... 😉
(hamár a win64 megnemjelenését felróják az amdnek, akkor ez is sztem belefér ide 😉 )
én egy E0-s 1.8as a64et szeretnék, szorzólokk nélkül, 2.8ghz-en 😉
(hamár a win64 megnemjelenését felróják az amdnek, akkor ez is sztem belefér ide 😉 )
én egy E0-s 1.8as a64et szeretnék, szorzólokk nélkül, 2.8ghz-en 😉
Forza.
#3
Akarom mondani rev. E0.
#2
Nagyszerû. (Csak remélem, nem csak 4000+ és afelett lesz bevezetve a rev. D0.)
#1
Ez igen 4000+