34
-
GABOR16 #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. -
BiroAndras #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 "[HUN]PAStheLoD")
#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.. -
dez #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.) -
GABOR16 #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. -
GABOR16 #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) -
muerte2 #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.
-
dez #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. -
dez #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. -
dez #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... -
#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. -
dez #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. -
dez #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. -
#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ó. -
dez #19 akarom mondani '..a saját SSE 1-3-unkat AMD-n!' -
dez #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ó. -
dez #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!
"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. -
dez #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. -
dez #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.) -
#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... -
dez #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ó). -
dez #10 Aha: 10% teljesítménynövekedés 2x-es áron... Jó üzlet - nekik. -
Alfa Of NS #9 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. -
Tiby #8 arty - Pedig meg kell venned ha jó , és gyors procit akarsz magadnak -
#7
nyócvanezerér' nem vennék procit, de Te tudod ;) -
#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
----------------------------------------- -
#5
13ezerért, mint a mostani 1466@2200asom ;) - ez az előbb kimaradt a kivánságból ;) -
#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 ;) -
dez #3 Akarom mondani rev. E0. -
dez #2 Nagyszerű. (Csak remélem, nem csak 4000+ és afelett lesz bevezetve a rev. D0.) -
Tiby #1 Ez igen 4000+