- Samsung Galaxy S25 - végre van kicsi!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Milyen okostelefont vegyek?
- Mobil flották
- India felől közelít egy 7550 mAh-s Redmi
- iPhone topik
- Android alkalmazások - szoftver kibeszélő topik
- Profi EKG-s óra lett a Watch Fitből
- Honor 400 Pro - gép a képben
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
Aktív témák
-
perla
csendes tag
1. Register renaming es attoltes nem ugyanaz, de ezt mar mondtam. Masreszt az, hogy ket utasitas mehet egyszerre, az nem jelenti azt, hogy pl. a masodik nem lassit, hiszen az elso mehetne egyutt a harmadikkal is, ha nem lenne ott a masodik. Amugy minden utasitas, ami atmegy a pipe-on bir lassitani, ha lehetne helyette ott a kovetkezo.
Ha a peldam nem tetszik, nyugodtan irjal masikat, megnezhetjuk.
2. Ha ez hivatalos allaspont, akkor rakd be az url-t, ahol olvashato.
3. Cafolni nem cafoltad, csak irtad, hogy nem igaz. Ez ugye nem cafolat, hiszen nincs indoklas. En peldat is irtam, ahol latszik, hogy 7 helyett 3 utasitassal meg lehet ugyanazt oldani.
4. Ez megint kodosites. Arrol volt szo, hogy ha keves regisztered van, es kifogysz beloluk, akkor kenytelen vagy memoriaba irni az adatot. Erre irtad te, hogy memoria operandusu muvelet regiszteresre helyettesitodik. Aha, csak lesz mellette egy memoria eleres, szal igy mindenkepp lassabb, mintha regiszterekben meg lehetne oldani.
5. Akkor ebben megegyeztunk?
6. ? Akkor mit ertesz nem jobb alatt? Minthogy sebessegrol van szo, nekem csakis az jut eszembe, hogy nem gyorsabb. De mar mondtam, hivatkozd le. Akkor nem kene itt levegobe beszelni, es az idot tolteni (amibol neked olyan keves van).
7. Akkor ebben is megegyeztunk?
'Figyelj vegyél kicsit vissza újoncstílusodból!'
'Mondod ezt az együgyüség magabiztosságával.'
Es te mondod, hogy hagyjuk a szemelyeskedest. Amugy mit jelent nalad az, hogy ujoncstilus? Ez az, aki nem hiszi el a sok hulyeseget, hanem ellentmond? Ez az egyugyuseg is sima fikazas, erv nelkul, teny, hogy nem hivatkoztad le egyiket sem. Beszolasverseny nem itt van.
'Valóban nincs sok időm, ugyanis dolgozom, értelmes emberekkel, értelmes célokért és még sok pénzt is kapok érte.
Szerinted vitatkozzam inkább veled, eredménytelenül???
A június végén megyek az USA-ba és találkozom többek közt John Crawforddal(gyerünk nézd csak meg a Google-ba kicsoda az ürge), majd megemlítem neki a gondolataid.'
? Nem maradt mas, mint elovenni, hogy kinek az apukaja erosebb?? Kepzeld, en is ertelmes emberekkel, ertelmes celokert dolgozom, es sok penzt kapok erte (es nalam ez azt jelenti, hogy sebessegre optimalizalok intel/amd/mips/ppc procikon, szal a temahoz eleg sok kozom van). Nem kell velem vitatkozni feltetlenul, eleg ha beismered, ha tevedsz ;). Es az ellentmondas nem vita. A vitaban erveket is mond az ember. Amugy Inteles csokaval nem annyira jo mostanaban dicsekedni, minthogy architekturaban elegge bukasra allnak. A marketingesekkel dicsekedhetsz, az jol megy naluk. Szal uzenem a csavonak, hogy jo lenne belehuzni, mert az emberek allnak at az amd platformra, szal nagyotmondasbol eleg, kene dolgozni is. -
perla
csendes tag
Persze, mindenki abban hisz amiben akar. De teveszmeid neked vannak. Eleg sokminden osszegyult mar az elozo hozzaszolasomban, amit te mondtal es hulyeseg. Csak sorolom:
1. Attoltesek nem lassitanak semmit
2. Intel&AMD ellenjavalja az assemblyt
3. 3/4 operandusu utasitassal nem lehet gyorsabb kodot irni, mint 2 operandusuval
4. Memoria operandusu muvelet regiszteresre helyettesitodik
5. Tobb regiszterrel se lehet gyorsabb kodot irni, mint kevesebbel
6. Ugyanaz a proci tobb cache-sel lassabb, mint kevesebbel.
7. Risc compilert nehezebb irni, mint cisc/vliw compilert.
Ezek a te teveszmeid. Nem kijavitani nincs idod, max utananezni vagy lusta, hogy hol tevedsz. Nyilvan nem tudtad egyebkent ezeket lehivatkozni, hiszen ezek hamis allitasok, csak nehez beismerni, hogy tevedtel. Sokkal egyszerubb azt mondani, hogy 'nincs idom'. -
perla
csendes tag
''Az áttöltések nem lassítanak semmit''
Te irtad. Megegyszer mondom, probald ki.
''Írj te, hogy hol gyorsít ez?''
Ok. Pl:
attoltes nelkuli kod:
mov eax,1
mov ebx,1
add ebx,eax
attoltessel kod:
mov eax,1
mov ebx,1
mov ecx,ebx
add ebx,eax
Lemerheted, lassit az attoltes. Johet a te peldad.
''A későbbi szükségletekre ott a renaming, az átöltés párhuzamosan megy.''
? A renamingnek szerintem semmi koze a keves regiszter problemahoz. Szerinted mi koze van hozza?
''Felejtsd már el ezt a kézi optimalizálást. Mind az intel, mind az Amd ellenjavalja az assembly-t. Egy 386-os vagy egy P2-es esetén használhatsz, de 2004-ben már csak magadat fogod szívatni.''
Ezt nem tudom, honnan veszed, hogy ellenjavaljak, hivatkozd le. Azt tudom, hogy en szinte minden nap irok assembly kodot, C-ben in-line assembly, foleg sse2 gyorsitas miatt, de sajnos ahhoz kell sima x86 assembly is ugye. SSE2 nelkul nyilvan nem irnek, mezei x86-ban nagyon sok munkaval tudok csak kicsivel gyorsabb kodot irni (ha erre a gondoltal, akkor az igy van), az nem eri meg, de sse2 az tokre megeri.
''Nyílvánvaló, hogy nem a 3/4 operandus gyorsít.''
Latom ezt nem veszi be az agyad. Ujra mondom, probald ki. Pl. a*b+b*c+c*a 2 operandusu muvelettel 7 utasitas, 3 operandusuval 5. Emiatt gyorsit.
''Belül egy sima memória operandusú művelet is regiszteresre helyetessítődik.''
Na, ha fogalmam sincs rola, akkor fejtsd ki. Hogy tudja vajon a proci a memoria operandusu utasitast regiszteressel helyettesiteni. Ha a forras a memoria operandusu: hulyeseg, ha az adat a memoriaban van, akkor nem lehet regiszterben. Ha az eredmeny: vajon ilyenkor beirja az adatot egy regiszterbe, egy masikba meg egy cimet, hogy hova is kellett volna irni, hiszen kulonben nem tudna, hogy hogy milyen mem hivatkozasnal kell elovenni. Es ezt igy folytatja, mig el nem fogynak a regiszterek. Es utana? Ez is hulyeseg. Cachbe irodik nyilvanvaloan, az pont erre van kitalalva. Na meselj, hogy van ez szerinted?
''Én nem ezt írtam. Én nem írtam egy szót se a memóriába írásról.
Nem olvasol figyelmesen vagy nem érted?''
Probalsz kodositeni. Arrol volt szo, hogy tobb regiszterrel gyorsabb kodot lehet irni, szerinted meg nem. De igen, mert sokszor elofordul, hogy keves regiszterbe sok adat nem fer be, valamit ki kell irni membe. Ezert lehet tobb regiszterrel gyorsabb kodot irni. Lehet, hogy te nem szoltal memoriaba irasrol, csak sajnos mas valasztasa a forditonak sincs, minthogy kiirja az adatot membe.
''1. Több processzoros környezetben a kozisztencia problémák léphetnek fel és egy túlméretezett cache visszafoghatja a rendszert.
2. Gyártási problémák - túlontúl nagy cache -> rosszabb kihozatal, alacsonyabb órajel''
Ja, ezert is raknak egyre tobb cachet a procikra. Ez full kamu. Az egesz hozzaszolasodra ez jellemzo egyebkent. De hivatkozd le. Melyik gyartonal van olyan, hogy azt mondjak, itt egy specko proci direkt kisebb cache-sel, hogy gyorsabb legyen. Nincs ilyen.
''Tudod mi az az MMX/SSE/SSE2?''
Abszolut. Tobb eve sse2-ben programozok. Az intel marketing eventeken szokott a kodjaimra hivatkozni. Mondjuk ez nem tudom, hogy jott a temaba, de mind1.
''Micsoda???
Látod a mikro kódot? Látod a futásközbeni átrendezést?
Felejtsd már el az x86-os opcode-okat, totál más zajlik a háttérben.''
Ezt nem kell ennyire misztifikalni. Egyreszt ha nagyon muszaj, akkor a mikrokodot is elo lehet banyaszni, de nem szoktam. Szepen le lehet merni a sebesseget enelkul is, tokre kimerheto, hogy az adott kodban egy ilyen memoriaba mentes es visszaolvasas mennyit lassit.
''Ezen már mosolyogni sem tudok.
Te vagy 14 éves vagy vagy menthetetlen.
Szerintem itt zárjuk le.''
? Ha jol ertem, nincs erved, inkabb fikazol. Ird be a google keresobe : ''risc vc cisc compiler'', es lasd az eredmenyt. Risc compilert egyszerubb irni. Egyforma az utasitasok hossza. Ugyanarra a feladatra nincs tobb megoldas, mint a ciscnel, nem kell gondolkozni, hogy melyiket valassza a compiler. Egyszerubb a cimzes. stb. -
perla
csendes tag
''Egy olyan processzor ami sok proci környezetre terveztek nem lassabb, mint amit ugyanabból egy procis környezetre terveztek, sőt mindegyike gyorsabb.''
Nincs benne, hogy riscrol lenne szo, hanem az, hogy mindegyik. Nezzel mas benchmarkot is, pl. quake. Masreszt meg olyat nezz, ahol hasonlok a cache meretek. Ajanlom a p4ee-t.
Ha programoztal volna assemblyben, tudnad, hogy x86 felulirja az egyik operandust, es ha kesobb szukseged van ra, akkor extra utasitassal kell elmenteni (rosszabb esetben memoriaba). Attoltes lassit, probald ki. Ha nagyon kotni akarod az ebet a karohoz, mutass peldat, amikor nem lassit, szivesen lemerem.
Nem keverek semmit, te nem olvasod el amit irtam. Nem volt szo a miertrol, csak arrol, hogy gyorsit.
''Belül egy sima memória operandusú művelet is regiszteresre helyetessítődik.''
Ez hulyeseg. Akarod tovabb ragozni, vagy maradjunk ennyiben?
Masreszt a register renaming nem helyettesiti a tobb regisztert. X db regiszterben nem tudsz X+1 adatot tartani, errol szol az egesz. Ki kell irni membe (ami szerinted regiszterbe irasra helyettesitodik??? Vicces). Membe iras (level 1 cachebe is) lassu.
''cache, minel tobb van, annal jobb''
Ez sincs így csak a mesében.
Ez megint hulyeseg. Mutass 2 processzort, amik csak a cache mereteben ternek el egymastol, es amiben a kisebb cache van, az gyorsabb. Nagyon kivancsi vagyok.
''Azt hiszem folyamatosan kevered az összetett műveleket a több operandusossággal.''
Nem, csak te hiszed, hogy ezeket szet kell valasztani. Annyirol volt szo, hogy szetkapja az ember a legfaszabb x86 processzorat, a riscszeru magot megtartja, rak bele tobb regisztert es nehany uj utasitast (3-4 operandusut), es gyorsabb lesz a proci. Igen, van, ahol az osszetett muvelet miatt, van ahol azert, mert nem irja felul az operandust, van ahol azert, mert nem kell kiirni membe. Tok mind1, gyorsabb lesz.
Kerdezd meg az ismeroseidtol, hogy riscre vay x86-ra konnyebb compilert irni. Nyilvan riscre. Mellesleg x86-ra kezzel mindig gyorsabb kodot irok, mint az intel compiler.
''Nem visszakozok.
20-30% kizárt.
max 5%-ra gondoltam ''
Tegyel egy probat. Irjal egy akarmilyen c proggyt, forditsd le, aztan nezd meg a kodot amit kaptal. Latni fogod, hogy tele van olyan reszletekkel, amikor adat kiirodik membe, aztan visszaolvasodik. Ugye mondanom sem kell, hogy membe irni (level 1 cachebe is) jopar orajel. Szal 5% az 100 orajelenkent kevesebb, mint 1 ilyen. Szerintem tobbet fogsz talalni.
''Ez ilyen visszafele bizonyítás?''
Mit nem ertesz? Szivesen elmagyarazom.
''Na mindegy, nem akarok semmi bántót írni.''
Ne is, erveket irjal. Megjegyzem a stilusod eleg lenezo ebben a hozzaszolasban, pedig eleg sok hulyeseget irtal. Erdekes eddig meg ha nem is ertettunk egyet, de nem volt ilyen. -
kisfurko
senior tag
Teljesen egyetértek veled, szerintem sem lehet nagyobb teljesítményűt kihozni egy másik architektúrával.
DE!
Nagyon nem mindegy, hogy szegény programozónak mennyit kell szenvednie (mert nincs olyan programnyelv, ami a vektoros számításokat normálisan használná pl.)! Egyébként nem értem, hogy a C-t (vagy C++-t) miért nem egészítették ki megfelelő adattípusokkal... Persze szóljatok, ha van már ilyen...:)
''Lehet izmozni, de szignifákns különbséget nem fogsz tudni elérni RISC-kel sem, viszont annál több munka van vele + sok extra tranzisztor.''
Ez az, ami szerintem nem igaz. A P4 kifejlesztése szerintem sokkal több pénzt emésztett fel, mint egy ugyanolyan teljesítményű, de kevésbé gány processzor. Pont a szopások leküzdése miatt. Gondolom te is megnézted azt a videót, amit DCsabaS linkelt be a korábbi vitánk során, és ott elmesélte az inteles fickó, hogy bizony a P6 architektúrában volt egy olyan bibi, hogy néha bizonyos utasítások még több száz (vagy több, nem emlékszem) ciklus után sem akarták elhagyni az instruction pool-t.
Nekem csak ez a problémám. De ezt már kibeszéltük egyszer. :) -
kisfurko
senior tag
''A regiszter kezelés illetve a flagek a RISC procikban is jelen van, ezt register átnevezéssel jól lehet kezelni a RISC procikban is így csinálják, ez nem gond, könnyen orvosolható probléma.''
Ez igaz, de nem mindegy, hogy 8 regiszterre kell trükközni, vagy minimum 32-re. Meg az sem mindegy, hogy kétoperandusú vagy több. Mert kétoperandusúhoz több regiszter kell.
A flagekről meg csak annyit, hogy sokszor tök feleslegesek (mert részszámítás), nyugodtan lehetne szabályozni, hogy mikor kell. Egyébként nem RISC/CISC összehasonlítást kell csinálni (hiszen manapság nincs igazi CISC), én is, mint perla x86 vs. jobb.
''A gyakorlatban azonban ugyanakkora a függőség egy P4/K8-nál, mint egy USP/Power-nél.''
Ezt azért nehezen hiszem, nem véletlen, hogy a K8-ba is duplaannyi regisztert raktak.
Mikor is vitáztunk ezen régebben? :) -
perla
csendes tag
Tenyleg nem lassabb? Xeon MP? Vagy akar Xeon? Ezek mind lassabbak, mint a megfelelo p4-ek. A Xeon MP meg orajelben is.
Nem tudom ertelmezni amit irtal, hogy ugyanolyan gyorsak. PPC-t nem tudom, de szerintem mind dual procira van tervezve, A64 meg multiprocira, szal nincs beloluk single-re tervezett, nem?
Ja, 3 operandusos utasitasok gyorsitjak a kodot. Latszik, hogy sose programoztal assemblyben. Tok fontos, hogy nem irodik felul egy operandus, nem kell ujra betolteni, vagy masik regiszterbe menteni, ez kezzelfoghato gyorsulast jelent. Hogy a 4 operandusu utasitasokrol mar ne is beszeljek. Pl. nem tudom hallottal-e mar arrol, hogy egy ilyen jellegu muvelet: d=a*b+c az ppc-ben 1 utasitassal vegrehajthato, es ugyanugy 1 orajel mint barmi mas. Probalj egy a*b+b*c+c*a kifejezest kiszamitani 2 es 3-4 operandusu muveletekkel, es latni fogod, hogy melyik a gyorsabb.
1. Szukseg van tobb regiszterre, megint azt tudom mondani, hogy latszik, hogy nem programoztal assemblyben. De tekintsd pl. ugy, hogy a regiszterek a 0. szintu cache, minel tobb van, annal jobb. Kulonben ennel nyilvanvalobb dolgot, hogy az x86 architecturaban keves a regiszter, nem is lehet talalni. Te ezt komolyan cafolni probalod???? Ja, taskvaltasnal trade-off van, ezert van optimalis meret, nem kell ezer regiszter. Eleg mondjuk 32.
2. Ez igaz, ilyenkor a l1 cache-be toltest lassitja.
3. Latod, hogy tudtam. 3 operandusu muvelettel es tobb regiszterrel. Illetve igazabol 'felesleges' utasitasokat sporoltam meg ezekkel. Egyebkent nyilvan nem az IPC fog vissza, az csak meri a proci egy jellemzojet, nem meghatarozza.
4. Azzal valoban nem, az olyan amilyen. Mondjuk azt azert el lehet erni, hogy ugyanannyi ido alatt tobb adatt toltodjon fel a cachekbe. Masreszt van ez a data stream cucc a ppc-kben, hogy ha folytatolagos cimrol kezdesz olvasni a memoriaban, akkor elkezdi neked a proci elore behozni a cachebe.
Nemnem. A peldam jo, egy csomo tranyot kidobtam, amikor csak a magot tartottam meg, par regiszter meg par utasitas siman kitelik belole. Es forditot csak x86-ra meg itaniumra nehez irni, riscre sokkal egyszerubb, ez is egy elonye, csak eddig errol nem volt szo, mert nem a hardverhez kapcsolodik.
Amugy eddig azt magyaraztad, hogy risckel kozelebe se jutok az x86-nak, mostmar visszakoztal, hogy szignifikans kulonbseget nem tudok osszehozni. Egyreszt ez a nem szignifikans kulonbseg szerintem akar 20-30% is lehet (ki lehet probalni G5-on csak 4-6-8 regiszter hasznalataval mennyivel lassabb kodot lehet irni, es amikor rajossz, hogy hoppa, ki kell irni a memoriaba az adatot, mert nincs tobb regiszter, akkor kiderul, hogy mennyit lassit), masreszt mivel kidobtam a procibol egy nagy reszt, valszeg magasabb orajelet is el lehetne erni, harmadreszt ez 0 uj otletet tartalmazo megoldas, szal ha meg 1-2 evet belefektet az ember a tervezesbe, nyilvan egyeb gyoritasokat is kitalal, es nem csak egy siman lemasolt procit krealna. -
perla
csendes tag
Persze, a tobbiek is okosak. De mondjuk azok mas celu processzorok, szal nem gondolnam, hogy az osszehasonlitas valamennyire is erdekes. Szal egy olyan procit, ami csak single proc uzemmodban mukodik, nem erdemes egy olyanhoz hasonlitani, ami 64 procis kornyezetben is mukodik.
Fejtsd ki legyszi, hogy milyen elvi oka van, hogy egy risc proci gyorsabb legyen, mint egy p4. Kulonosen, mert hiszen tudjuk, hogy belul riscszeru magja van, szal igy mar lehetne rogton olyan procit csinalni, ami ugyanilyen gyors, es risc, ha ennek a magjat vesszuk (igaz, az nem x86 kompatibilis). Megszorjuk meg par 3 operandusu utasitassal ill. sok regiszterrel, es maris gyorsabb (es meg az utasitasok mikroutasitasra bontasat is megsporoltuk -> rovidebb pipeline, vagyis egy pipeline stall koltsege kisebb -> meg gyorsabb). Tessek, ez egy recept a gyorsabb risc procihoz. -
perla
csendes tag
Bocs, felreertettel. ''Helyesen 'nem x86''' alatt azt ertettem, hogy amikor eddig arra hivatkoztam, hogy a risc mennyivel jobb, stb., az azt jelentette, hogy a 'nem x86' mennyivel jobb.
Nem hiszem, sokkal jobb lenne. Eddig egyetlen jo erv nem volt a mellett, hogy az x86 miert lenne az abszolut sebessegkiraly irany (nem is az). Persze, az Intel meg az AMD mernokei fasza csavok, es mara nagyon kiraly procikat hoztak ossze. (Nagyon sok penzert, amin sokkal gyorsabb nem x86-os procit lehetett volna fejleszteni). Igen, a kompatibilitas a legnagyobb ertek, ezert is mehet a sebesseg rovasara.
Igen, Itanium teljesen mas megkozelites. Miert csinaltak igy, es miert nem x86 az is? Mert megprobaltak valami gyorsat csinalni, es ugy gondoltak (ahogy en is, de te nem), hogy azt nem x86 alapon lehet megcsinalni. -
perla
csendes tag
Ez a ketto osszefugg. Az x86 processzorok (a kompatibilitas miatt) ossze-vissza allitgatjak a flageket, es emiatt szopatjak a pipelinet (illetve a branch predictiont). De errol mar volt szo korabban. De nezd meg pl., hany orajel kell a flag allito utasitasokhoz (pl. shift, rotate).
Hulyeseg, hogy mindig riscet mondunk (mondok), amugy helyesen 'nem x86'. Hogy ne legyen felreertes, mar mondtam ugyan, szal nem arrol van szo, hogy a mostani x86 procik szarok, eppen ellenkezoleg, de sokkal faszabbak lennenek, ha nem x86-ok lennenek. Meg az itanic is jo pelda erre, az Intel szerint is szopat az x86 architectura, az itanium nem is arra van optimalizalva. -
kisfurko
senior tag
Azért annyit elismerhetnél már perla-nak, hogy sokkal egyszerűbb lenne a pipeline-t megcsinálni, ha nem kéne mindenféle függőségekkel szívni, hogy most ez az utasításrész melyik valódi regisztert, mikor érinti, vagy összeharácsolni az EFLAGS állapotát egy-egy utasítás után.
Tudom, hogy a mostani RISC-szerű procikban is van register renaming, de egy háromoperandusú utasításkészlet jóval kevesebb függőséget okoz. Igaz ez nem RISC/CISC kérdése. -
perla
csendes tag
1. Nyilvan arrol van szo, hogy egy hasonlo teljesitmenyu risc proci kevesebb tranzisztorbol all, mint egy cisc vagy vliw stb.
USP-IV - ez 2 USP-III corebol all, az USP-III-ban a logic 11 millio tranzisztor
PA-8800 - ez ugye ket PA-8700-as corebol epul fel +cache, a core-ok 25 millio tranzisztorbol allnak
Tobbirol nem talaltam egyertelmu adatot, ha te talalsz, legyszi ird ide.
2. Nem tudom itt mire gondolsz. Szerintem nagyreszt az hatarozza meg, hogy sikerult-e egy chip, amikor a tranzisztorokat kialakitjak. Logikus modon a nagyobb meretbol nagyobb hibaszazalek adodik, raadasul egy szeletre kisebb szamu chip fer. Ezekbol az kovetkezik, hogy kisebb chipet ugyanolyan technologiaval olcsobb gyartani.
Ja, az x86 processzorok hasonloak, mint a riscek, van egy risc magjuk, meg a hulye korites. Pont a hulye korites az, amit ki kellene dobni. Amugy nem is ertem, hogy ezen miert vitatkozunk. Jozan paraszti esszel: az x86 architecture korlatozas, kereteket, szabalyokat szab. Vajon egy korlatozas nelkul vagy azzal egyutt lehet a gyorsabb procit epiteni? Nyilvan a korlatozas nelkul. Na errol van szo. Az SMT-nek meg CMP-nek nincs koze az x86 vagy nem x86 kerdeshez. -
perla
csendes tag
1. Egy risc proci kisebb (most a cacheket hagyjuk). Mitol lenne nagyobb?
2. Ha minden egyforma (technologia, csikszelesseg stb.), akkor ugyanazert a penzert a kisebb lapkameretubol tobbet lehet gyartani.
Persze, csak nem a felso kategorias processzorokon van a haszon. Nyilvan nem akkor kaszal a ceg, amikor meg a fejlesztesi koltseget termeli vissza.
Pl. egy mostani Celeron proci arat szerinted mi hatarozza meg? Szerintem foleg az eloallitasi koltseg es a piac. Fejlesztes mar nem nagyon jatszik.
Mar volt szo rola, de nem ugyanazok a gondok. Pl. egy risc procinal nincsenek olyan nagy gondok, mint az x86 pipeline szopato flagallitasai. Szerintem ha riscet fejlesztettek volna, akkor mar most 4-5 gigahertznel tartananak, es teljesitmenyben meg legalabb 2x-nel. Az intel nem ezert nem csinalt riscet, hanem mert azt nem tudta volna eladni, az x86-ot meg igen. -
perla
csendes tag
Vajon az Itanium es egy risc proci fejlesztesi koltsegei hogy viszonyulnak egymashoz szerinted? Nyilvan a risc olcsobb. Masreszt egy kisebb lapkameretu proci hosszutavon is olcsobba bir valni a nagyobb kihozatal stb. miatt. Es igaz ugyan, hogy az eladott kb. 18 db Itanium procinal a fejlesztesi koltseg dominal, de egy piacvezeto procinal mar sokkal jelentosebb az eloallitasi koltseg (mint az Itaniumnal, nyilvan a fejlesztesi koltseg sokaig meghatarozo az arban).
Amugy mit ertesz 'a risc' alatt? Szerintem csak siman risc van, es termeszetesen nem ugyanazok a gondok vele, mint az x86-nal. -
DcsabaS
senior tag
''1. De közelében sem volt a 3000-nek, nemhogy 95-ben, még később sem.''
Lehet, ezt akkor egy ujsagcikkben olvastam, es sokfele adat keringett a pontos felepitesrol. Az mindenesetre biztos, hogy nagyon sok procit hasznaltak, nem x86 osokat, es megsem teljesitett jobban a 90 MHz-es Pentiumnal. Magatol ertetodoen a szoftver miatt. A peldat eppen arra hoztam, hogy a Deep Blue sakkprogramja nyilvan nem volt kelloen optimalizalva az adott hardverre.
''3. Kihasználta. Pont erre épített, egy több, mint 40 éves algortimust használt cél hw-re.''
Akkor legyunk pontosak. Ha ez igaz, akkor ''egy több, mint 40 éves algortimus''-ra optimalizaltak, es nem a Deep Blue hardverere, amire kellett volna.
Hogy most mennyire hasznalja ki, az is vitathato, ugyanis a PC-s Fritz aktualis verzioja most is versenyben van vele.
Az altalad megadott linkbol erdemes felfigyelni arra, hogy az IBM a Deep Blue tortenetet ugyesen a Kaszparov elleni (96-os) meccsel inditja, igy nem kell irnia arrol, hogy korabban alulmaradt egy 90 MHz-es Pentium-mal szemben. -
DcsabaS
senior tag
''1. A Deep Blue processzor számát illetően erősen el van tájolva a kollega.''
Meglehet, ellentmondo adatok voltak. Mindenestre a legelso, fejlesztes alatt allo Deep Blue volt, amelyet tulajdonkeppen reklamozni akartak, ezert sakkoztattak.
''2. 1995-ben volt Fritz-Deep Blue, amely azonban messze nem ugyanaz volt, mint a Kaszparovval mérkőző 97-es(a kettő között jelentős számításbeli különbség volt).''
Ki beszelt az ember elleni merkozesrol?!? Vagy hogy a Deep Blue-t kesobb hova fejlesztettek?
''3. A két program elve teljesen más, ezért volt köztük különbség és nem az optimalizálás a különbség. ''
A 2 program nyilvan teljesen mas volt, de a lenyeg: a Deep Blue-ra irt program aligha hasznalta ki a Deep Blue hatalmas parhuzamos szamitasi kapacitasat, noha az a sakknal elvben jol kihasznalhato. Erre irtam azt, hogy nem optimalizaltak a sakkozo programjukat, csak irtak egy sakkozo programot a szuperkomputerukre, es azzal szinte elintezettnek tekintettek a dolgot. Ahogyan ez tudomanyos korokben szokas is.
''4. A Deep Blue nem klasszikus szuperszámítógép. Speciális sakkprocesszorok voltak benne, amelyeket Power processzorok vezéreltek(minden RS/6000-es node-ok 16 sakkproci kapcsolódott).''
Aligha voltak benne specialis ''sakkprocesszorok'', ugyanis eredetileg idojarasi es gazdasagi folyamatok elemzesehez konstrualtak. -
Den
veterán
-
L3zl13
nagyúr
Ha az OS teljesen azonos keretet képes biztosítani, akkor a progikat nem is kell portolni... Akkor meg tökmindegy, hogy van-e source a kezemben vagy sem.
Ja és ha csak egy a-t kell átírni b-re mert ugyan nem fur 1:1-be a progi a másik platform alatt, akkor azt megteszi a fejlesztő is hidd el, vagy eleve úgy írja meg a progit, hogy mindkettőre telepíteni lehessen.
[Szerkesztve]
Aktív témák
Hirdetés
- Csere-Beszámítás! Intel Core I9 14900KS 24Mag-32Szál processzor!
- i5-8400 Processor, 6 mag, Max Turbo 4.00 GHz, ajándék hűtővel-elkelt TheCrafter22, értékelésre vár
- Csere-Beszámítás! Ryzen 9 9950X3D Processzor! 16Mag-32Szál!
- Csere-Beszámítás! AMD Ryzen 8700G Processzor!
- Core i7 9700 processzor - 6 hó garival
- BESZÁMÍTÁS! Asus M5A99FX PRO R2.0 990FX chipset alaplap garanciával hibátlan működéssel
- Azonnali készpénzes Microsoft XBOX Series S és Series X felvásárlás személyesen/csomagküldéssel
- 119 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!) (ELKELT)
- Huawei P20 Lite 64GB, Kártyafüggetlen, 1 Év Garanciával
- Samsung Galaxy A54 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest