Vyznam dual core

Citace:

---

Původně odeslal Eagle

Instrukce mě nestojí dvojnásobek.

---

to nemozes tvrdit; vyrobne mozno ano, predajnou cenou nie. Kazda novinka ma isty "priplatok" jednak za vyssiu vyrobnu cenu, ale aj za dalsi vyvoj. Ak si si v dobe uvedenia porovnal ceny p3 a p4 s sse2 a ich vykon, tak urcite sa p4 spociatku neoplatil, celkovo ale dosiahol vyssi vykon. Ale ceny sa casom menia, preto myslim ze fakt nema zmysel rozoberat cenu, ale skor pouzitie.

Citace:

---

Při stejném výkonu cenový rozdíl JE dvojnásobný. Otestuj si to a porovnej v ceníku.

---

DC je lacnejsi o 60%!!!! viz:
http://www.czechcomputer.cz/product.jsp?artno=30676
a
http://www.czechcomputer.cz/product.jsp?artno=38987

Myslim ze o cenach sa nema vyznam bavit, pretoze sa menia - od predajcu k predajcovi, a z casu na cas. O rok budu tvoje argumenty o cenovych rozdieloch neplatne.

Citace:

---

Kvůli tomu mě ale nemusí nabízet jen DC variantu s tím, jak je to skvělé. Pokud mi nenabídne adekvátní volbu za pro mě přijatelnou cenu, prostě půjdu jinam.

---

to ze tebe dany procak pre tvoje programy nevyhovuje, neznamena ze je na h, pretoze mnoho inych ludi pren ma vyuzitie. A stale si myslim ze DC je lepsie ako nejake sse8. Single threaded vykon uz velmi zvysovat nejde, tak aspon vdaka za to druhe jadro.

Citace:

---

Podle mě to, co bude mít lepší price/performance. Další instrukce nepřinesou skoro žádný užitek navíc, ale taky nestojí skoro nic navíc (max. pár transistorů, což se ve stovkách milionů ztratí). DC mít přínos může, ale taky stojí o 100 % víc.

---

DC je lacnejsie o 60%. Dalej sa odmietam bavit o cenach.

Citace:

---

Optimalizace pro dvě jádra je to samé jako pro čtyři, osm, tisíc.

---

nemyslim, moho veci rozdelis na niekolko asymetrickych threadov, hoci ten hlavny vypocetny ostane nezmeneny, vsetko okolo (grafika, prekreslovanie okna, animacie atd.) mozes dat do druheho threadu a tak ziskat trocha vykonu navyse.

Citace:

---

SIMD mají dle mě v mnoha případech značný přínos a optimalizace na ně je snazší než pro DC. Navíc je dostanu prakticky zdarma, což se o DC říct nedá. Dívej se na to asi takhle - kdybych měl na výběr mezi dvěma procesory, jedním s SSE2 a druhým bez nich, přičemž ten s SSE2 by byl dražší, tak bych taky porovnával cenu, zda se mi to vyplatí. Kdyby ne, tak bych koupil ten bez SSE2.

---

ber to tak, ze ak by si dnes zacal vyrabat p3 na najmodernejsom vyrobnom procese, tak dosiahnes mozno aj 2ghz frekvencie - na kanc. pracu a beznym uzivatelom by to v pohode stacilo. A urcite by to bolo lacnejsie ako c2d, p4 atd., pretoze by netrebalo platit navyse ziaden vyvoj. Ale uz to raz tak byva, ze vyrobcovia pouzivaju rozne strategie a robia napr. to ze starsie procesory prestavaju vyrabat atd. Kazdopadne stale si mozes kupit transmentu.

Citace:

---

Alpha má tuším 256 záznamů. A to už pěknou řádku let. Velké okno by mohlo pomoct spekulaci. Přirozeně by to chtělo i spoustu dalších změn. Takovýmto inovativním návrhům jsem přikloněn víc než přidávání jader, což dlouhodobě stejně nikam nepovede.

---

lenze alpha je RISC a trocha ina architektura, takze tam sa vacsie reorder buffery a window mozu oplatit viac. Myslim, ze ak by to malo mat podstatny prinos, tak u c2d su omnoho vacsie reorder buffery.

Citace:

---

Sdílená cache má výhody pro multithreading, ale pro multitasking je špatná. A ono sdílení taky nemusí být tak jednoduché. Navíc mám pocit, že Intel do Core 2 Duo nakonec nedal ono přímé spojení L1D cache.

---

nezabudaj, ze beznemu uzivatelovi na pozadi bezi winamp, dc, nejaky antivir (ktory kazde 3 hodiny stahuje novu databazu a kontroluje ram) a kopec dalsich aplikacii (icq, rozne netlimitery, oc utilitky atd.). Nevravim ze nejak vyrazne zatazuju jadro, povedme dokopy 10%. Vsade kde sa robia v recenziach testy, tak na pozadi nic nebezi, podobne v hrach je vypnuty zvuk. U DC mas vyhodu v tom, ze tieto ostatne veci bezia na druhom jadre a 100% vykonu jedneho jadra ma pre seba tvoja hlavna aplikacia. U hier druhe jadro vyuzije napr. multithreaded driver od grafiky, alebo si na nom bude robit vypocty driver integrovanej "sw" zvukovky.
Skratka oproti novym instrukciam ma DC vyhodu v okamzitej pouzitelnosti.

Pokud nehodláš pochopit, že cenová politika Intelu je mi úplně u pr****, protože to samé mi AMD nabídne podstatně levněji (D945 na 3.4 GHz je jako A64 3500+ za 2700 Kč), pak nemá smysl se s tebou nadále bavit, protože jsi nepochopil smysl této diskuze.

Za druhé jádro bych někomu poděkoval pouze tehdy, když by to bylo zadarmo. Co kdybychom to udělali tak, že já si vyberu SC, ty mi pak zaplatíš to druhé jádro, koupím DC a poděkuju ti? Férová nabídka, ne?

ad zbytek - Přijde mi, že máš lehce zkreslené představy o přidělování jádra v OS a o programování. Doporučuju zkusit ASM, z toho pochopíš, jak se věci mají. BTW, Core 2 Duo je samozřejmě RISC procesor (jako všechny dneska).

Citace:

---

Původně odeslal Eagle

Pokud nehodláš pochopit, že cenová politika Intelu je mi úplně u pr****, protože to samé mi AMD nabídne podstatně levněji (D945 na 3.4 GHz je jako A64 3500+ za 2700 Kč), pak nemá smysl se s tebou nadále bavit, protože jsi nepochopil smysl této diskuze.

---

zmysel tejto diskusie je ze DC nie je na h

kym nevyslo c2d, tak boli ceny AMD o dost vyssie - skratka ceny sa menia, preto sa odmietam bavit o cenach

Citace:

---

Původně odeslal Eagle

Za druhé jádro bych někomu poděkoval pouze tehdy, když by to bylo zadarmo. Co kdybychom to udělali tak, že já si vyberu SC, ty mi pak zaplatíš to druhé jádro, koupím DC a poděkuju ti? Férová nabídka, ne?

---

staci ze si pockas tak rok a cenovy rozdiel bude zanedbatelny
Potom padnu vsetky tvoje argumenty o cene a ze dc je na h atd. Neagrumentoval by som tym, co sa bude menit.

Citace:

---

Původně odeslal Eagle

ad zbytek - Přijde mi, že máš lehce zkreslené představy o přidělování jádra v OS a o programování. Doporučuju zkusit ASM, z toho pochopíš, jak se věci mají. BTW, Core 2 Duo je samozřejmě RISC procesor (jako všechny dneska).

---

nie som si celkom isty ci su vobec dnes nejake RISC procesory (mozno nejake sparc?), skor to je nieco medzi risc a cisc. Mozno blizsie k RISC, ale rozhodne nie cisty risc.

V com sa ti zda ze mam skreslene predstavy o pridelovani jadra v OS a o programovani? V com mi ma pomoct assembler pri pochopeni pridelovania jadra nejakym schledulerom?

Sam vis, ze to tak neni. Interne sice jedou na RISC, ale pro SW se tvari jako CISC, prevod CISC instrukci na RISC provadi dekodery instrukci. Nebo snad instrukce typu MMX, SSE a pod jsou RISC? Asi ne, co :) Cisty RISC jsou ruzne embeded CPU typu MIPS, pokud se nepletu, ale mozna ze uz i ty maji neco navic.

Ad ceny: nemuzes porovnavat novou vlajkovou lod intelu proti staremu modelu AMDcka, to se pak nediv, ze to vychazi 2x draz. Nove CPU, zvlaste od intelu a zvlaste pokud jsou dobre, byly vzdycky drahe. Ze to je DC na tom nic nemeni. Ja se tesim, az zacne intel prodavat neco jako core solo, tedy core 2 duo s jednim vadnym jadrem. Je ale dost mozne, ze to bude cenove skoro stejne jako DC, tak to ostatne je u core duo/solo.

Ted neco k budoucnosti. Podle me jedina cesta, jak zvysit vykon CPU, je cesta, jakou se vydal cell, resp. intel s jeho 80-ti jadrovou novinkou. Procaky budoucnosti budou mit podle me nekolik zakladnich charakteristik: budou vysoce paralelni, budou mit velmi vykonne SIMD jednotky/jadra a jejich logika bude podobna, jakou ma cell nebo transmeta, tedy vpodstate zadna. Tim nevznikne omezeni pro budoucnost, jako je nyni u x86, procesory budou plne programovatelne. Dopadne to tedy opdobne jako tomu bylo ve vyvoji telekomunikaci/siti, kdyz se od komplikovaneho prepinani okruhu preslo na jednoduzsi prepinani packetu a sit jako takova neumi vpodstate nic, vse se dela pomoci SW.

Citace:

---

Původně odeslal Eagle

ad zbytek - Přijde mi, že máš lehce zkreslené představy o přidělování jádra v OS a o programování. Doporučuju zkusit ASM, z toho pochopíš, jak se věci mají. BTW, Core 2 Duo je samozřejmě RISC procesor (jako všechny dneska).

---

Citace:

---

Původně odeslal Petrik

Sam vis, ze to tak neni. Interne sice jedou na RISC, ale pro SW se tvari jako CISC, prevod CISC instrukci na RISC provadi dekodery instrukci. Nebo snad instrukce typu MMX, SSE a pod jsou RISC? Asi ne, co :) Cisty RISC jsou ruzne embeded CPU typu MIPS, pokud se nepletu, ale mozna ze uz i ty maji neco navic.

---

su to post-risc procesory, maju tolko vela pridanych zmien, ze uz ich davno nemozno povazovat za cisto riscovske procesory. RISC a CISC su velmi stare koncepty. Uz pentium bol post risc (a to teda dost velmi vzdialeny cistemu risc), nie to este dnesne core2. Pokial viem, dnes uz nejaky risc alebo cisc procesor tazko vobec niekde najdes. Aj tie embedded budu istym variantom post-risc, aj ked verim ze blizsie k risc.

No ja chapu problemy s malou optimalizaci na dual a vice core procesory. Kdyz si odmyslime, ze programator je v jadru "liny" tvor, tak proti porad stoji cena.
Proc by se mel programator ucit ladit "rucne" multi core program, kdyz je to mnohem slozitejsi a malokdo mu to zaplati. Souhlasim s tim, ze se nejdrive musi mnohem zlepsit v podpore vyvojove nastroje a co nejvic ulehcit praci.

Odhadnul bych, ze vyvoj takove optimalizovane aplikace bude cca stat minimalne 2x tolik a testovani 4x tolik. A ted rekni zakaznikum, ze budou mit vykon o nejakych 20-70% vetsi, bude to stat minimalne 4x tolik a bude v tom vic chyb, protoze se blbe hledaji? Napr. dnes prodavane hry za 1000,- budou rychlejsi, ale budou stat 4000,-? Kdo to koupi?

Citace:

---

Původně odeslal THX

na jednej strane tvrdis, ze programatorom pracu navyse nikto nezaplati a ze nebudu optimalizovat atd. Teda potom asi vsetci pisu este vo visual basicu, pretoze je to najjednoduchsie a preco by stracali akykolvek cas ucenim sa nejakeho ineho jazyka (napr. C) v ktorom ide urobit to iste, len sa to pise zlozitejsie, a ze to ide rychlejsie - ved to je predsa problem hw.

---

Spatne porovnavas C a Visual Basic. Musis porovnavat puvodni Basic. A pak psat, ze v Cecku se pise hur. No ja ti nevim, ale me podstatne lip. A chtel bych videt napr. interpretovany Linux :-)

Jen tak na okraj, uz delsi dobu se daji psat multi-threadove aplikace i ve Visual Basicu, vsechno je uz zalezitost .NET Frameworku.

Musim potvrdit, ze se mi v nem taktez pise mnohem hur nez treba v C#, ale to sem uz spis nepatri.

A naco je to dobre? Ked to niekto spravi v tom VB.NET, tak to na tom dvojjadrovom C2D pojde pomalsie ako rovnaky program v C na Celerone 266.

No ja netvrdil, ze to bude nejak rychle :D Jen jsem branil vsemi (vcetne me) nenavideny VB ;D

Citace:

---

Původně odeslal Rainbow

A naco je to dobre? Ked to niekto spravi v tom VB.NET, tak to na tom dvojjadrovom C2D pojde pomalsie ako rovnaky program v C na Celerone 266.

---

OT: to by som netvrdil, sice ano, urcite najdes taky specificky program, ale celkovo je .net dost rychly, navyse som niekde cital/pocul ze by sa mohli objavit procesory ktore by ciastocne podporovali .net mikrokod (nieco take chcel spravit aj sun s javou) a potom by ta rychlost mala byt omnoho lepsia

Citace:

---

Původně odeslal THX

OT: to by som netvrdil, sice ano, urcite najdes taky specificky program, ale celkovo je .net dost rychly, navyse som niekde cital/pocul ze by sa mohli objavit procesory ktore by ciastocne podporovali .net mikrokod (nieco take chcel spravit aj sun s javou) a potom by ta rychlost mala byt omnoho lepsia

---

Zrovnavat .NET a C co sa rychlosti tyce sa naozaj neda. Mal som moznost to porovnavat a mozem povedat, že ak nejaku aplikaciu napisete v C, tak obvykle je x krat rychlejsia ako v pripade že by ste ju napisali v .NET. Ale zase na druhej strane kto pozna .NET aj C, tak vie že porovnavat tieto dve prostredia je dost od veci...každé je určene do ineho segmentu.

Citace:

---

Původně odeslal Rainbow

A naco je to dobre? Ked to niekto spravi v tom VB.NET, tak to na tom dvojjadrovom C2D pojde pomalsie ako rovnaky program v C na Celerone 266.

---

A pro to mas nejake podklady, nebo jsi to jen tak placnul? Vsechny benchmarky, ktere jsem videl, byly totiz zalozeny na mereni vykonu nejakych kratkych algoritmu. Jinymi slovy- prilis zjednodusujici. A v techto pripadechsi vedl .NET vesmes velmi dobre (dlouhodobe plati, ze prekladace virtualni stroje atd. od MS patri , na rozdil od vetsiny ostatnich produktu teto firmy, ke svetove spicce... staci srovnat o kolik je gcc v kvalite generovaneho kodu za Visual C). Pokud mas skutecne nejake konkretni vysledky tak by me hodne zajimaly. Co jsem nasel ja:

http://www.osnews.com/story.php/5602...File-IO/page3/

Vykon C# vyssi nez gcc c. Proc ne, kdyz jde jen o vypocetni algoritmus a objekty se temer nepouzivaji?

http://www.tommti-systems.de/go.html...enchmarks.html

Velmi zajimavy test. Meren je i maximalni memory footprint aplikace.

http://www.shudo.net/jit/perf/

Cast SciMark 2. Asi nejvice vypovidajici vec. C# 240 bodu, gcc 266 bodu (11% lepsi vysledek nez C#), Visual C 329 bodu (37% lepsi vysledek nez C#). To vse navic s poznamkou "C version is advantageous compared with Java and C# versions because Java and C# versions use a "synchronized" version of the random number generator, which makes the Monte Carlo Test much slower." Linpack taktez dava zajimave vysledky.

http://www.ddj.com/dept/cpp/184401976

Dalsi sada mikrobenchmarku. Vysledky zacinaji na druhe strane.

... a desitky dalsich podobnych...

Jaky je zaver? No at si ho kazdy udela sam :-) Ja si ten svuj utvoril na zaklade mych vlastnich testu (pac je znamo, ze existujou tri druhy lzi- male, velke a benchmarky a take neverim statistikam, ktere jsem si nezfalsoval sam ;-) ) a pokusu, kde mi vyslo, ze C# ztraci za C++ zhruba o 30%. Pri urcovani platformy projektu to beru v uvahu a zamicham do toho zkraceni doby vyvoje v C# oproti C++ a cenu programatoro hodiny. Vetsinou mi to vyjde ve prospech C# maximalne s cca 5% aplikace (kriticka cast) napsanymi v C.

Citace:

---

Původně odeslal miho

A pro to mas nejake podklady, nebo jsi to jen tak placnul? Vsechny benchmarky, ktere jsem videl, byly totiz zalozeny na mereni vykonu nejakych kratkych algoritmu. Jinymi slovy- prilis zjednodusujici. A v techto pripadechsi vedl .NET vesmes velmi dobre (dlouhodobe plati, ze prekladace virtualni stroje atd. od MS patri , na rozdil od vetsiny ostatnich produktu teto firmy, ke svetove spicce... staci srovnat o kolik je gcc v kvalite generovaneho kodu za Visual C). Pokud mas skutecne nejake konkretni vysledky tak by me hodne zajimaly. Co jsem nasel ja:

http://www.osnews.com/story.php/5602...File-IO/page3/

Vykon C# vyssi nez gcc c. Proc ne, kdyz jde jen o vypocetni algoritmus a objekty se temer nepouzivaji?

http://www.tommti-systems.de/go.html...enchmarks.html

Velmi zajimavy test. Meren je i maximalni memory footprint aplikace.

http://www.shudo.net/jit/perf/

Cast SciMark 2. Asi nejvice vypovidajici vec. C# 240 bodu, gcc 266 bodu (11% lepsi vysledek nez C#), Visual C 329 bodu (37% lepsi vysledek nez C#). To vse navic s poznamkou "C version is advantageous compared with Java and C# versions because Java and C# versions use a "synchronized" version of the random number generator, which makes the Monte Carlo Test much slower." Linpack taktez dava zajimave vysledky.

http://www.ddj.com/dept/cpp/184401976

Dalsi sada mikrobenchmarku. Vysledky zacinaji na druhe strane.

... a desitky dalsich podobnych...

Jaky je zaver? No at si ho kazdy udela sam :-) Ja si ten svuj utvoril na zaklade mych vlastnich testu (pac je znamo, ze existujou tri druhy lzi- male, velke a benchmarky a take neverim statistikam, ktere jsem si nezfalsoval sam ;-) ) a pokusu, kde mi vyslo, ze C# ztraci za C++ zhruba o 30%. Pri urcovani platformy projektu to beru v uvahu a zamicham do toho zkraceni doby vyvoje v C# oproti C++ a cenu programatoro hodiny. Vetsinou mi to vyjde ve prospech C# maximalne s cca 5% aplikace (kriticka cast) napsanymi v C.

---

Tie benchmarky o realnom nasadeni .NET nehovoria NIC. Vzdy ked sa robi aj velmi jednoducha aplikacia...pouzivaju sa objekty z .NET a tie su o vela pomalsie ako triedy napisane v C s podobnou funkciou.

Proc citujes muj sahodlouhy prispevek jen abys dolu napsal jednu vetu, ktera byla v mem prispevku navic zminena? :-)

Moje testy byly zalozeny na realnych aplikacich, ktere jsem potreboval vytvorit takze vypovidaly o realnem nasazeni vsechno ;-)

Vytvoreni a ruseni objektu ma v .NET vyssi rezii. To je pravda. Ovsem algoritmus, kde se to projevi (tzn. kde se vytvari tak mnoho objektu, ze rezie jejich vytvareni prekroci "spotrebu" zbytku algoritmu) je s nejvetsi pravdepodobnosti proste spatne navrzen. V .NET (a jave) je pak treba pouzit napr. object pool nebo jinou techniku aby se nadmernemu vytvareni objektu zabranilo. Jsou tam jeste dalsi zadrhele jako napr. zpracovani vyjimek, ktere je v .net citelne pomalejsi. Tohle vsechno se ale vejde do tech 30%, ktere jsem zminil vyse.

... ale mam pocit, ze jsme tady uz docela OT.

Citace:

---

Proc citujes muj sahodlouhy prispevek jen abys dolu napsal jednu vetu, ktera byla v mem prispevku navic zminena?

---

To uz tak nejak ze zvyku ked idem na niekoho reagovat tak hned kliknem quote, proste blby zvyk.

Kde v prispevku si napisal to co ja?? Praveze si pekne zhrnul jak je .NET len o malo pomalsi (coz neni tak) viz. posledny tvoj odstavec.

Citace:

---

Vytvoreni a ruseni objektu ma v .NET vyssi rezii. To je pravda. Ovsem algoritmus, kde se to projevi (tzn. kde se vytvari tak mnoho objektu, ze rezie jejich vytvareni prekroci "spotrebu" zbytku algoritmu) je s nejvetsi pravdepodobnosti proste spatne navrzen. V .NET (a jave) je pak treba pouzit napr. object pool nebo jinou techniku aby se nadmernemu vytvareni objektu zabranilo. Jsou tam jeste dalsi zadrhele jako napr. zpracovani vyjimek, ktere je v .net citelne pomalejsi. Tohle vsechno se ale vejde do tech 30%, ktere jsem zminil vyse.

---

Ano rezia je pomalsia ale hlavny dovod proc aplikacie napisane pod .NET su ovela pomalsie neni len kvoli tejto rezii (ta je naopak zanedbatelná). Pomalost NETu je spusobena hlavne principami programovania.

Napríklad string :
Azda všetky bežne client aplikacie vo velkom používajú stringy. Ako iste vies, v .NET su stringy relativne velke objekty ktorych vytvorenie tvori dosť náročných funkcii. Takisto sú tam funkcie ktoré často ani programator v aplikacii nevyužije (len zaberaju sys. prostr.). V C je string obycajny datovy typ (napr. pole charov) ktorý nezaberá ani z daleka toľko sys. prostr. ako jeho ekvivalent v NET (proste v pameti zabera len tolko kolko je treba, jeden znak sa da uložiť do 1 bajtu takže string zaberá minimum). Je sice o niečo pracnejšie pracovat stymto stringom, programator si musí vela vecí písať sám ale to je daň za výkon a efektivitu.

Tým som chcel len povedať kde je ten hlavný dovod, preco je .NET pomalsi. Uviedol som ako príklad sice len string ale ked sa pozres na triedy ktoré .NET obsahuje tak hned vieš prečo je NET pomalší.

A nemusia to byt len zakladne triedy typu string, int, staci sa pozriet aj na GUI triedy, na WIndows.Forms. V porovnani napriklad s MFC ktore použijem v C++ nemaju WindowsForms šancu čo sa týče rychlost

EDIT:

Citace:

---

dlouhodobe plati, ze prekladace virtualni stroje atd. od MS patri , na rozdil od vetsiny ostatnich produktu teto firmy, ke svetove spicce... staci srovnat o kolik je gcc v kvalite generovaneho kodu za Visual C

---

Jo a compilator obsiahnuty v MS produktoch je made by Intel a nie MS.

Citace:

---

Původně odeslal pYr0

Napríklad string :

---

Blby priklad:
http://www.ddj.com/showArticle.jhtml...chlegel&pgno=8

Citace:

---

Původně odeslal pYr0

v .NET su stringy relativne velke objekty ktorych vytvorenie tvori dosť náročných funkcii.

---

Neni pravda. String je velmi jednoduchy immutable objekt, ktery ma v datove casti krome samotneho retezce navic pouze delku a pocet odkazu.

Citace:

---

Původně odeslal pYr0

Takisto sú tam funkcie ktoré často ani programator v aplikacii nevyužije (len zaberaju sys. prostr.).

---

Predne- v OOP rikame metody. Kdyz prilinkujes stdlib.h tak si tim nabalis take stovky funkci, ktere nikdy nepouzijes.

Citace:

---

Původně odeslal pYr0

jeden znak sa da uložiť do 1 bajtu takže string zaberá minimum).

---

Tohle si v dnesni dobe mysli uz jen malokdo a kazdy, kdo si to mysli, se drive nebo pozdeji dostane do znacnych problemu a/nebo pise jen male programky pro vlastni potrebu.

Citace:

---

Původně odeslal pYr0

int

---

int v .NET neni objektem, chova se stejne jako v C.

Citace:

---

Původně odeslal pYr0

staci sa pozriet aj na GUI triedy, na WIndows.Forms.

---

Pravda, GUI je pomalejsi. Rozsil ale neni nijak velky a navic to neni kriticka cast aplikace takze to je irelevantni.

Citace:

---

Původně odeslal pYr0

Vzdy ked sa robi aj velmi jednoducha aplikacia...pouzivaju sa objekty z .NET a tie su o vela pomalsie ako triedy napisane v C s podobnou funkciou.

---

Scimark je pomerne velka aplikace. A vysledky viz vyse. Moje aplikace, na kterych jsem testoval, taktez k uplne prtavym nepatrily. Tezko ale urcit nejakou metriku podle ktere se urcuje "velkost aplikace" :-)

Citace:

---

Blby priklad:
http://www.ddj.com/showArticle.jhtml...legel& pgno=8

---

Na tych strankach pisu:

"String concatenation is performed here, but the memory allocation is done outside the benchmarking loop. That's why I called it "fixed" or "preallocated." "
Neni tam zahrnutá pre nás velmi dôležitá alokácia obektu, takze ten test neni moc objektivný.

Citace:

---

Neni pravda. String je velmi jednoduchy immutable objekt, ktery ma v datove casti krome samotneho retezce navic pouze delku a pocet odkazu.

---

S tymi funkciami čo poskytuje nemôže byť velmi jednoduchy maly objekt. Tomu neverim. A aj keby bol mensi nez si myslim, tak co z toho ked stale neni taky maly jak zakladny string v C? Nic nemeni na tom co som napisal

Citace:

---

Predne- v OOP rikame metody. Kdyz prilinkujes stdlib.h tak si tim nabalis take stovky funkci, ktere nikdy nepouzijes.

---

Nepotrpím si na terminologii. Jo ty funkce a triedy si nabalim do exe to je fakt, ale sys. prostriedky zeru az ked jednu z nich vyvolam alebo vytvorim triedu. Ak nie tak je len o par kB alebo mozno stoviek kB vecší exe což dneska nejak nevadí. To v .NET sa to robí tak že sa aplikacia načíta se vším všudy a hele hned kukam do taskmanageru, že tie čísla reprezentujuce volnu pamet nejako klesaju.

Citace:

---

Tohle si v dnesni dobe mysli uz jen malokdo a kazdy, kdo si to mysli, se drive nebo pozdeji dostane do znacnych problemu a/nebo pise jen male programky pro vlastni potrebu.

---

Ano a kolko si mysliš že ten char v pameti zabere? Kolko ma typ dané, tolko si aj alokuje. Jedina vynimka je co sem niekde čital že niektoré kompilatory alokuju datovemu typu bool 4 bajty....ale co je na tom pravdy to nevim.

Citace:

---

int v .NET neni objektem, chova se stejne jako v C.

---

Ano a co je potom System.Int32 ?

Citace:

---

Pravda, GUI je pomalejsi. Rozsil ale neni nijak velky a navic to neni kriticka cast aplikace takze to je irelevantni.

---

Este kedysi davno som si robil pod .NET, aplikaciu ktorú som nazval ImageViewer, bol to velmi jednoduchy prehladavac obrazkov ktory obsahoval filebrowser, okno pre nahlad obrazkov a hlavne okno pre zobrazovanie fotky fullscreen. Nestacil som sa diviť aké strašné veci to robilo, obrazky som nacitaval do objektu Image (myslim že tak sa volal) a fakt velmi dlho trvalo nacitanie foto 1280x1024 v jpg. Dalsi sok bol ked som to nechal zobrazovat v nahladovom okne. Cela aplikacia si pri tomto procese alokovala asi 80 mb z RAM....tak som musel do toho cyklu este pridať aj garbage colector aby to tie pozostale Image objekty uvolnilo....to bolo samozrejme dalšie spomalenie nacitania obrazkov a fotiek. Asi tolko ku gui .NET Frameworku a jeho "rychlých" objektoch.

Citace:

---

Scimark je pomerne velka aplikace. A vysledky viz vyse. Moje aplikace, na kterych jsem testoval, taktez k uplne prtavym nepatrily. Tezko ale urcit nejakou metriku podle ktere se urcuje "velkost aplikace"

---

Inak neco treba povedat aj ktym testom. Nemyslim si že by boli objektivne lebo pokial viem tak .NET ma rozne optimalizačné techniky, že nejaky usek kodu zkompiluje este pred začatím toho useku, a tym padom sa nenamera spravny vysledok. A myslim že nielen to obsahuje NET, urcite tam sú aj dalšie veci ktore môžu oklamať tak jednoduchy benchmark ako si ty uviedol. Aj v tych jednoduchych cykloch to môže v realu vyzerať inak. Ale to už je tak skor moja spekulacia a silne OT mali by sme to asi nechať :-)

neodbocili ste "kapanek" od temy?

Kamos vymenil pekny single core A64 co behal na 2700+ MHz za A64 dual-core, ktery da maximalne 2550MHz a vsechno co doma ma mu beha pomaleji a ted lituje vyhozenych penez.

Su ale aj opacne pripady ako napr. ja. Stary Wincko dal 2340, teraz beham na 2550... A myslim, ze zdaleka niesom sam

Citace:

---

Původně odeslal tomase

Su ale aj opacne pripady ako napr. ja. Stary Wincko dal 2340, teraz beham na 2550... A myslim, ze zdaleka niesom sam

---

Statisticky vzato musí jít dual-core přetaktovat hůř, protože potřebuješ úspěšnost přetaktu u obou jader.

Matematicky zapsáno: Mějme pravděpodobnost a < 1, že jádro půjde přetaktovat na danou frekvenci (libovolně zvolenou). Pak aby šel přetaktovat celý procesor, musí jít přetaktovat obě jádra současně, a tedy musí platit:

a * a < a

Citace:

---

Původně odeslal Eagle

Statisticky vzato musí jít dual-core přetaktovat hůř, protože potřebuješ úspěšnost přetaktu u obou jader.

Matematicky zapsáno: Mějme pravděpodobnost a < 1, že jádro půjde přetaktovat na danou frekvenci (libovolně zvolenou). Pak aby šel přetaktovat celý procesor, musí jít přetaktovat obě jádra současně, a tedy musí platit:

a * a < a

---

Tyto vztahy by platily pouze v pripade, ze a1 (jde pretaktovat jadro 1) a a2 (jde pretaktovat jadro 2) jsou jevy nezavisle coz zde urcite neplati (jeden kus kremiku z casti podobne kvality, potazmo stejna serie atd.). P(a1 a soucasne a2) je samozrejme mensi nez P(a1) ale kvuli zavislosti techto jevu je vetsi nez P(a1)*P(a2).

Citace:

---

Původně odeslal pYr0

...

---

Odbihame tady opravdu od tematu. Ja mam sve argumenty podporeny benchmarky zverejnenymi na webu a vlastnimi merenimi. Ty tady stale davas nejake teoreticke argumenty (s kterymi BTW nesohlasim) proc by mel byt .net pomalejsi. Budto to podpor necim konkretnim nebo to nema zadnou vypovidaci hodnotu.

Rozdil mezi hodnotovymi typy (int, char...) a referencnimi (Object a jeho potomci) patri k naprostym zakladum .NET. Pokud je nechapes tak je diskuze zbytecna. int je aliasem System.Int32. To nemeni nic na tom, ze promenne tohoto typu nejsou objekty a vznikaji tudiz na zasobniku a ne na halde. Hodnotove typy maji vzdy ekvivalentni objektovy obal, do ktereho se daji zabalit v pripade, kdy je nutne aby se hodnotovy typ choval jako referencni (napr. kolekce.add(1)). Rika se tomu boxing a deje se to jen v situacich, kdy je to nutne.

ad velikost char- Dnes je v zasade vzdy dvojbajtovy (v jave, .NET, ...). V C je jednobajtovy z historickych duvodu. V seriozne minenych programech musis ale pouzit stejne dvojbajtovy wchar. Duvod- do jednoho bajtu se unicode znak strasne blbe cpe.

//edit: abych nezakladal dalsi OT prispevek- pomoci UTF8 neargumentujte, samotny char musi byt dvojbajtovy pac nikdy nevis, co ti prijde. Vnitrni reprezentace retezcu v jave, .net a C++ wchar a ve vetsine dalsich jazyku je taktez dvojbajtova protoze je s tim mnohem snazsi a rychlejsi prace. Zjistete si fakta nez neco napisete.

Ked robis v UTF-8, tak ziadne dvojbajtove znaky nepotrebujes.
A uz dost OT.

Ted mi dosla jedna vec: tento problem je jiz totiz vyresen, jelikoz PPU Aegia ve hrach funguje a tento problem tam zrejmne nenastava, nebo je nejak elegantne osetren :) Navic, prenost dat z PPU pres PCI-E x16 do CPU je radove pomalejsi a ma radove vetsi latence, nez prenost dat z jednoho jadra DC do druheho, takze v pripadne DC to bude mnohem bezproblemovehjsi.
Jeste jedno upresneni ke GRAW: defautlne jede cela fyzika na havoku, PPU se pouziva pouze pokud je k dispozici na specialni efekty jako jsou vybuchy a pod. Jelikoz GRAW by mel umet vyuzit DC,a to pry dost vyrazne, predpokladam, ze prave havok bezi oddelne.

Citace:

---

Původně odeslal Eagle

Dnes vyšel zajímavý článek na The Inquirer. Někdo z redakce hovořil s vývojáři her o možnosti využití quad-core:



Zvýraznil jsem nejdůležitější část. To docela mění zde nastolený směr diskuze - zjevně nebude problém zatížit jedno jádro výpočtem fyziky a kolizí, potíž bude v tom, že chceme-li, aby tato fyzika probíhala realtime (tj. aby například jedno auto neprojelo celé druhým a až pak byla zjištěna kolize), musí být fyzika spočítána hodně rychle, protože se jedná o sekvenční záležitost. A je zřejmě jasné, že když data musíme překopírovat z jednoho CPU do druhého, může DC dokonce i zpomalovat výpočet.

Možná by to šlo vyřešit tak, že jedno jádro bude počítat kolize a fyziku pro jeden frame dopředu, zatímco další jádra aktuální frame. To ale bude docela potíž z hlediska synchronizace a taky tam bude určité zpoždění reakcí na uživatelům vstup (čili zdaleka to nebude optimální).

---

Nevím, zda mi někdo argumentoval tady nebo na Živě, ale mrknul jsem teď na IncrediBuild, který by měl zrychlovat kompilování na Visual C++. Fakt mě to pobavilo, je to za peníze a licenční politika je opravdu velice "příznivá". Za jednu licenci chtějí 329 dolarů a za podporu každého dalšího jádra pak dalších 149 dolarů!!! To jste si ze mě dělali legraci, že?

Standardní edice Visual Studia 2005 je za 299 dolarů.

Citace:

---

Původně odeslal Petrik

Ted mi dosla jedna vec: tento problem je jiz totiz vyresen, jelikoz PPU Aegia ve hrach funguje a tento problem tam zrejmne nenastava, nebo je nejak elegantne osetren :) Navic, prenost dat z PPU pres PCI-E x16 do CPU je radove pomalejsi a ma radove vetsi latence, nez prenost dat z jednoho jadra DC do druheho, takze v pripadne DC to bude mnohem bezproblemovehjsi.
Jeste jedno upresneni ke GRAW: defautlne jede cela fyzika na havoku, PPU se pouziva pouze pokud je k dispozici na specialni efekty jako jsou vybuchy a pod. Jelikoz GRAW by mel umet vyuzit DC,a to pry dost vyrazne, predpokladam, ze prave havok bezi oddelne.

---

To nebude nikdy fungovat! Kdyz se nestihaji kopirovat data mezi jadry na jednom CPU, co pak nejaka karta v PCI-E nebo GPU. Jsem si jist, ze miliony, ktere investuji do vyvoje Ageia, nVidia a Ati prijdou vnivec.
Aneb co bys cekal od cloveka, ktery nikdy nenaprogramoval vicevlaknovy program a ceka na to az to za nej udela kompilator :-)

to myslis ironicky, ze? hehe :D

UPDATE: Zda se ze Eaglovy teorie o MT SW se borti, protoze pokud si dobre pamatuju, tvrdil, ze napr. takova fyzika se paralelizovat neda, ze? No tak asi protoze to "nejde" Aegia umoznuje neco jako SLI pro jejich PPU karty, tedy provoz se dvema kartam zaroven pro dvojnasobny vykon: http://www.zive.cz/h/Uzivatel/AR.asp?ARI=131532
A jeslize to jde pro dve karty, navic na relativne pomale PCI-E, nevim proc by neslo pro herni fyziku vyuzit klidne dvou a vice jader v novych QC CPU :)

Citace:

---

Původně odeslal richie08

To nebude nikdy fungovat! Kdyz se nestihaji kopirovat data mezi jadry na jednom CPU, co pak nejaka karta v PCI-E nebo GPU. Jsem si jist, ze miliony, ktere investuji do vyvoje Ageia, nVidia a Ati prijdou vnivec.
Aneb co bys cekal od cloveka, ktery nikdy nenaprogramoval vicevlaknovy program a ceka na to az to za nej udela kompilator :-)

---

2Petrik: Zaprvé to nebyla moje teorie a za druhé bys nám tedy mohl osvětlit, jak si to jako představuješ, že budeš vykreslovat objekt, u kterého ještě nevíš, jak se bude pohybovat. Do toho!

1)No ale rozhodne jsi neco v tom smyslu tvdil, nechce se mi to uz hledat.

2)Eagle, ja nejsem programator, ani jsem netvrdil, ze vim, jak to udelat. Ja jsem odpovedel na tvoji teorii, ze to pravdepodobne nejde, nebo ze to bude spatny a pod. Realne to funguje a to dokonce s vyrazne pomaleji propojenou kartou nez je propojeni jednoho jadra k druhemu. Navic, dokonce i samotna fyzika jde paralelizovat, v coz jsem ani moc nedoufal.
Ty proste misto abys uznal, ze jsi se mylil, radeji napadas me. Prosim, napadej si, ja skutecne nevim, jak to udelat, ale presto trvam na tom, ze to funguje a dokonce velmi dobre. Ja totiz, abych se prizal, hernim enginum moc nerozumim, jen tusim, jak asi muzou fungovat. Docela logicka je tvoje kontrukce, ze nejdrive se musi vypocitat pohyb vsech objektu (resp. jejich poloha) a az pak se muzou zacit vykreslovat. Finta je v tom, ze kdyz ten pohyb nepocita CPU nebo to jedno konkretni jadro, ma cas delat neco jineho. Napr. muze dopocitavat vykreslovani minuleho framu nebo tak neco. Kazdopadne Aegia PPU je dukazem, ze i velmi narocna fyzika, bezne nezvladnutelna, jde realizovat pomoci vice jader, v tomto pripade jednim CPU a druhym specialnim na PCI-E karte. Jasne, ze PPU je na fyziku mnohonasobne vykonejsi nez bezny jadro CPU, ale tady jde o princip, ze. A jestli ze to jde s fyzikou, na ktere zavisi vse ostatni, proc by to neslo se zvukem, AI a dalsima komponentama herniho enginu. Takze bych to shrnul, principialne vice jader nebo specializovanych procesoru ve hrach vyuzit rozhodne jde, zalezi jen na programatorech. A umim si predstavit, ze za par let budou hry bezne umet vyuzit klidne ty 4 jadra, o kterych tu take byla rec. K tomu klidne nejakou grafiku ci PPU jako akcelerator nejenom grafiky a zbyva se jen tesit na to, jak to bude slapat a vypadat. s tvojim pristupem, totiz ze CPU ma byt jeden a basta, bychom se toho nedockali ani za 10 let.

Citace:

---

Původně odeslal Eagle

2Petrik: Zaprvé to nebyla moje teorie a za druhé bys nám tedy mohl osvětlit, jak si to jako představuješ, že budeš vykreslovat objekt, u kterého ještě nevíš, jak se bude pohybovat. Do toho!

---

Citace:

---

Původně odeslal Petrik

Realne to funguje a to dokonce s vyrazne pomaleji propojenou kartou nez je propojeni jednoho jadra k druhemu.

---

To, že to někde ošulíš, neznamená, že to funguje. To už bys mohl konečně pochopit! Udělat paralelizaci snížením výstupní kvality není umění.

Citace:

---

Původně odeslal Petrik

Ty proste misto abys uznal, ze jsi se mylil, radeji napadas me.

---

Domnívám se, že diskuze spíš vyzněla v můj prospěch. Takže jaképak mýlení se.

Citace:

---

Původně odeslal Petrik

Docela logicka je tvoje kontrukce...

---

Takže jsme u toho. Konstrukce je logická, to sám uznáš. Fakt si myslíš, že programátor může tohle logické pořadí změnit? Ono z toho tak nějak vychází, že jediný způsob, jak to provést, je počítat fyziku pro jiný snímek, než který je vykreslován. Výsledek? Zpoždění reakcí uživatelova vstupu o jeden snímek. To mi jako moc dobrý příklad paralelizace nepřijde.

Citace:

---

Původně odeslal Petrik

s tvojim pristupem, totiz ze CPU ma byt jeden a basta, bychom se toho nedockali ani za 10 let.

---

To mi připomíná teorii komunismu. Obětuju svůj zájem ve prospěch společnosti. Díky, ale o takovou nabídku nemám zájem, a proto chci to, co mi teď a tady přinese nejvíc. Jestli Intel chce tlačit víc jader, tak ať se postará o to, aby na to software byl patřičně optimalizován, a to tak, že mě to nebude stát ani padesátník. Přirozeně odmítám "optimalizace" vedoucí ke snížení výstupní kvality.

1) Myslis ze to Aegia nekde osulila? muzes mi prosim rict kde? A rovnou to napis nekam do nejakyho velkyho fora, at lidi ty jejich drahy PPU vyhazej, ze to je akorat vosuleny :D:D:D

2)tvuj nazor...

3)aha, takze kdyz to vsechno pocita jeden CPU, tedy nejdriv spocita fyziku, pak vse ostatni, tak tam neni zpozdeni, jo? zajimava teorie :)) u vice jader to je naopak s mensim zpozdenim, protoze se s pocitanim fyziky neceka na dokonceni vseho ostatniho, jako normalne. Proste fyzikalni engine chrli jeden snimek za druhym a ostatni jadra k tomu jen dopocitavaji vse ostatni. Nebo se mylim? vysvetli mi tedy prosim, jaktoze u jednoho jadra zpozdeni neni a u vice ano :)

4) :D to me pobavilo...proc by se mel intel starat, aby te to nestalo ani o padesatnik navic? ocividne vubec nechapes, jak funguje soucasna ekonomika :))

Citace:

---

Původně odeslal Eagle

To, že to někde ošulíš, neznamená, že to funguje. To už bys mohl konečně pochopit! Udělat paralelizaci snížením výstupní kvality není umění.


Domnívám se, že diskuze spíš vyzněla v můj prospěch. Takže jaképak mýlení se.


Takže jsme u toho. Konstrukce je logická, to sám uznáš. Fakt si myslíš, že programátor může tohle logické pořadí změnit? Ono z toho tak nějak vychází, že jediný způsob, jak to provést, je počítat fyziku pro jiný snímek, než který je vykreslován. Výsledek? Zpoždění reakcí uživatelova vstupu o jeden snímek. To mi jako moc dobrý příklad paralelizace nepřijde.


To mi připomíná teorii komunismu. Obětuju svůj zájem ve prospěch společnosti. Díky, ale o takovou nabídku nemám zájem, a proto chci to, co mi teď a tady přinese nejvíc. Jestli Intel chce tlačit víc jader, tak ať se postará o to, aby na to software byl patřičně optimalizován, a to tak, že mě to nebude stát ani padesátník. Přirozeně odmítám "optimalizace" vedoucí ke snížení výstupní kvality.

---

Citace:

---

Původně odeslal Petrik

1) Myslis ze to Aegia nekde osulila? muzes mi prosim rict kde?

---

Domnívám se, že už jsme to tady rozebrali a to i ty sám jsi to uznal.

Citace:

---

Původně odeslal Petrik

2)tvuj nazor...

---

Vzhledem k tomu, jakou jsi dostal karmu, je to vcelku jasné.

Citace:

---

Původně odeslal Petrik

u vice jader to je naopak s mensim zpozdenim, protoze se s pocitanim fyziky neceka na dokonceni vseho ostatniho, jako normalne. Proste fyzikalni engine chrli jeden snimek za druhym a ostatni jadra k tomu jen dopocitavaji vse ostatni.

---

Zapomínáš na jeden podstatný detail. Uživatel reaguje podle toho, co vidí na obrazovce. Tedy když mu budeš něco kreslit a mezi tím už počítat dopředu, tak když on zareaguje, bude reagovat na něco jiného, než co uvidí na obrazovce. Čím víc budeš počítat dopředu, tím větší problém.

Citace:

---

Původně odeslal Petrik

ocividne vubec nechapes, jak funguje soucasna ekonomika :))

---

Sice mám titul Bc. z Vysoké školy ekonomické, momentálně tam studuju v navazujícím magisterském studiu a mám za sebou Státní zkoušku z podnikového hospodářství, Státní zkoušku z ekonomie a Státní zkoušku z vedlejší specializace Finanční manažer, ale jinak v klidu.

Citace:

---

Původně odeslal Eagle

Domnívám se, že už jsme to tady rozebrali a to i ty sám jsi to uznal.


Vzhledem k tomu, jakou jsi dostal karmu, je to vcelku jasné.


Zapomínáš na jeden podstatný detail. Uživatel reaguje podle toho, co vidí na obrazovce. Tedy když mu budeš něco kreslit a mezi tím už počítat dopředu, tak když on zareaguje, bude reagovat na něco jiného, než co uvidí na obrazovce. Čím víc budeš počítat dopředu, tím větší problém.


Sice mám titul Bc. z Vysoké školy ekonomické, momentálně tam studuju v navazujícím magisterském studiu a mám za sebou Státní zkoušku z podnikového hospodářství, Státní zkoušku z ekonomie a Státní zkoušku z vedlejší specializace Finanční manažer, ale jinak v klidu.

---

a) Jenze to ceho se bojis se vlastne deje vzdy, protoze zatimco se grafika stara o vykreslovani (vlastne jiz stareho) snimku, tak vlastni engine hry zpracovava a pripravuje data pro novy. Zpozdeni je pritomno vzdy, jenom to clovek neni schopen pri dostatecnem FPS rozpoznat.

b) Pokud se maji pocitat 3 paralelizovatelne veci (coz engine, fyzika, AI nepochybne jsou) tak jejich sekvencni vykonavani na jenom CPU bude vzdy pomalejsi. Tudiz na vicejadrovem stroji si muzeme dovoli vyssi refres nebo slozitejsi/rozsahlajsi vypocty.

c) To, ze je to v praxi realizovatelne ukazuji Ageia, nVidia a Ati kdyz prichazi s vypocty mimo CPU. Tady na foru se muze kdokoli stavet treba na hlavu, ale lide, kteri tomu opravdu rozumi do toho investuji obrovske sumy. Jinak vzhledem k tvemu vzdelani (tim se leccos vysvetluje) si myslim, ze mas pravdu ty a ti vyvojari do toho vubec nevidi a riti se do zarucene zahuby :-)

d) Jinak si myslim, ze tady nikdo nema dostatecne znalosti dane problematiky tak, aby se nektere veci resily do detailu. Proto jak je to doopravdy se synchronyzaci vlaken a jejich dopadem na zpozdeni nema cenu resit, natoz je brat jako argument.

Hm sledujem to tu uz dost dlho, pochopil som dost. Dnes staci single core, dualcore je hudba buducnosti, pripadne dneska, ked hras hru ale musis mat dva disk (dve R0 polia z 150GB raptorov..) aby si mohol robit dve veci naraz. Ale zaujimalo by ma jedno. NEMOZE JEDEN Z USEROV napr C2D pretaktovaneho spravit test, nejakej hry, ktora ma patch na vyuzitie dualcore procesora, porovnat to s neopatchovanou hrou pri single core procaku? Najprv pretakt procaka a potom napr. default frekvencie, ze aky tam bude rozdiel, nevravim, ze tie patche su nejak extra optimalizovane, ale nazorna ukazka vyvedie vela userov z omylu, ci nie? :)

ukaz mi nejakou hru ktera takovy patch ma a ja to zkusim - o zadny takovy nevim.
co se tyce dvojjadra tak subjektivne vidim velke rozdily pri pouzivani vice narocnych aplikaci vzhledem k tomu co mam ted a Dothanovi 1,86 co jsem mel pred tim. Proste D2C mi prijde mnohem rychlejsi pri vice spustenych narocnych aplikacich ale o tom je tu cely forum kde lide pisou to same...
Mozna ze podle vasi teorie dualcore neni potreba (no asi neni) ale v praxi je to vazne znat.

BTW: co takhle ALAN WAKE Intel video? 4jadrovy cpu pocita v teto hre fyziku zvlast a zvladne tak to kvuli cemu si jiny ted kupuji PhysX karty -nebo mi budete tvrdit ze to co tam ukazuji je podvod?

Citace:

---

Původně odeslal Poofy

ukaz mi nejakou hru ktera takovy patch ma a ja to zkusim - o zadny takovy nevim.

---

Napr. http://forumz.tomshardware.com/games...pict94969.html

Citace:

---

Původně odeslal misokgb

Napr. http://forumz.tomshardware.com/games...pict94969.html

---

Tady jsou ale hry ktere DC uz podporuji ne? ale abych tomohl overit potrebuju nejakou hru ktera vysla pro singlecore a vysel patch pro podporu DC. I kdyz nevim teda jestli takovy benchmark bude o necem vypovidat - teoreticky by to melo byt ve prospech DC.

Ono to nebude tak jednoduchy, protoze ten QC byl pretocen myslim na 3.5GHz, takze tezko rict, zda to ty 4 jadra opravdu potrebuje, nebo zda to potrebuje jedno o vysoke frekvenci. Vytizeni vsech jader ale pry bylo podobne, takze snad je to opravdu vyuziva.

Citace:

---

Původně odeslal Poofy

BTW: co takhle ALAN WAKE Intel video? 4jadrovy cpu pocita v teto hre fyziku zvlast a zvladne tak to kvuli cemu si jiny ted kupuji PhysX karty -nebo mi budete tvrdit ze to co tam ukazuji je podvod?

---

Q4 vysel pro SC a pozdeji byl uvolnen patch pro DC. Otazka je, jak moc to ten patch poresi, protoze nepredpokladam ze by kvuli tomu prepsali cely engine, coz je asi docela nutne, aby to vyuzilo cely potencial DC.

Citace:

---

Původně odeslal Poofy

Tady jsou ale hry ktere DC uz podporuji ne? ale abych tomohl overit potrebuju nejakou hru ktera vysla pro singlecore a vysel patch pro podporu DC. I kdyz nevim teda jestli takovy benchmark bude o necem vypovidat - teoreticky by to melo byt ve prospech DC.

---

Poofy a nestaci ked hru pustis rovno ako DC a nasledne pri dalsom teste odtestujes s nastavenou affinitou pre jedno jadro?

jj po vikendu to otestuju oboji -Q4 s a bez patche a taky pustit to jen na jednom core.

To už jsem přece otestoval v článku na Živě. Zrychlení je tam značné, jenže jaksi pouze v nízkém rozlišení. Když je limitem grafická karta, je to téměř k ničemu. A v reálných herních nasazeních bývá limitem právě grafická karta. Možná do budoucna, až se zintenzivní výpočty... ale to bude asi ještě nějakou dobu trvat.

Citace:

---

Původně odeslal Eagle

To už jsem přece otestoval v článku na Živě. Zrychlení je tam značné, jenže jaksi pouze v nízkém rozlišení. Když je limitem grafická karta, je to téměř k ničemu. A v reálných herních nasazeních bývá limitem právě grafická karta. Možná do budoucna, až se zintenzivní výpočty... ale to bude asi ještě nějakou dobu trvat.

---

aha tak ten clanek jsem necetl... urcite se na nej podivam a az bude trocha casu vyzkousim to protoze bych to rad videl na vlastni oci (ne protoze bych ti neveril -ciste ze stourave zvedavosti :) )

http://www.svethardware.cz/art_doc-8...5003D1530.html Vyborne napsany clanek.

jen kratka citace:
Poměrně zřejmým důsledkem nové architektury, a vůbec přístupem k dalšímu zvyšování výkonu, je obtížnější návrh a vývoj software pro achitekturu s desítkami až stovkami jader. Do teď vývojáři nemuseli příliš hledět na architekturu a spoléhalo se spíše na trend výrazného růstu výkonu jednojádrových procesorů. Využij to, co máš právě k dispozici a časem to bude, třeba i samo od sebe, běhat mnohem rychleji. Tento trend je ale u konce. Jistotu máme s ohledem na příští roky pouze v tom, že díky růstu integrace zaručeně budeme schopni zpracovat více vláken a aplikací současně – růst výkonu se tedy jistě nezastaví, ale za vyšším výkonem půjdeme jinou cestou...

Citace:

---

Původně odeslal Petrik

Vyborne napsany clanek....

---

:rolleyes: petrik <> Petricek :rolleyes:

Ne diky, ale tohle jsem ja vazne nenapsal :mweheh:

Citace:

---

Původně odeslal SajmoN

:rolleyes: petrik <> Petricek :rolleyes:

---

Citace:

---

Původně odeslal SajmoN

:rolleyes: petrik <> Petricek :rolleyes:

---

Hodnotis informacie v clanku na zaklade toho KTO ich napisal? (Co dokonca v tomto pripade ani nie je pravda)

ty snad nie? to ze by to pisal on sa mi nezdalo prave realne, ale zarazila ma tam ta zhoda .. cely tento thread je ako debata dedkov v krcme pri pive o atomovej fyzike .. ale sak sa vyzivajte

EDIT> nejde o zaujatost, ide o filtrovanie .. ide o informaciu objektivnu a o informaciu subjektivnu .. ide o to, o com je cely tento uplne zbytocny onanisticky thread :P

No predstav si, ze nie. Aj ked mi Eagle v poslednej dobe nie je moc sympaticky, povazujem jeho clanky za prinos. To ze si ty zaujaty voci niekoho osobe, si ries sam so sebou.

Citace:

---

Původně odeslal Petrik

http://www.svethardware.cz/art_doc-8...5003D1530.html tohle si, Eagle, velice pozorne precti. Vyborne napsany clanek

---

Ty máš opravdu velký problém. Tak znovu, abych ti přiblížil stav věcí. Mně je úplně ukradený, co vyvíjí nějaký Intel. Pokud mi nenabídne produkt, který zvýší výkon v mnou používaných aplikacích, tak jeho nabídky nevyužiju a on nedostane moje peníze. Třeba ho to pak přinutí se zamyslet, zda by se neměl víc snažit nebo vyměnit některé ze svých zaměstnanců za takové, kteří budou lepší.

Článek samotný nehodnotím moc pozitivně, neboť v něm není nikde zmíněno, co tato věc přinese mně a mnou používaným aplikacím. Že má Intel velký problém s frekvencí, a tak se snaží všechny obalamutit počtem jader, je mi lhostejné. Na rozdíl od autora článku nezastávám názor, že programátor bude muset změnit přístup. Vím něco o psychologii a je mi jasné, že každý člověk se chová tak, jak je to pro něj nejlepší Čili programátor se chová tak, aby 1) měl co nejméně práce 2) vydělával co nejvíc peněz. Jelikož zákazník (vcelku logicky) většinou není ochoten platit za vývoj programu dvojnásobek jen kvůli pár procentům výkonu navíc, nedostane programátor z prodeje optimalizovaného programu žádné dodatečné prostředky, a proto je jeho cílem splácat každý program co nejrychleji, a tedy s co nejnižšími náklady. Můj názor na celou věc je takový, že když si to Intel zavařil, tak ať se postará o optimalizaci software - ať třeba najme programátory, nechá je udělat nějaký špičkový kompilátor a ten následně ať dává lidem zdarma.

Citace:

---

Původně odeslal Eagle

Ty máš opravdu velký problém...

---

je uzasny, jak od jednoho dodavatele chces maximum a chces, aby si svoje penize zaslouzil a od druhyho ti stacej sprominutim 'sracky' ... a pritom od toho druhyho nakupujes mnohem vic...

Citace:

---

Původně odeslal Fox!MURDER

je uzasny, jak od jednoho dodavatele chces maximum a chces, aby si svoje penize zaslouzil a od druhyho ti stacej sprominutim 'sracky' ... a pritom od toho druhyho nakupujes mnohem vic...

---

Tím druhým myslíš AMD ? Pokud ano, tak tě zklamu, protože i od něj si nic nekoupím, pokud to nebude mít odpovídající added value. Nicméně politika AMD mi přijde lepší, protože aspoň nevykřikuje do světa, jak víc jader = víc adidas. Plány AMD na integrování jednoduché grafiky do CPU se mi vcelku líbí, pro notebooky a kancelářské počítače to bude přínosné. A o žádných dalších multicore nějak zatím nehovoří (resp. pouze pro servery, kde to má význam).

Citace:

---

Původně odeslal Eagle

Tím druhým myslíš AMD ? Pokud ano, tak tě zklamu, protože i od něj si nic nekoupím, pokud to nebude mít odpovídající added value. Nicméně politika AMD mi přijde lepší, protože aspoň nevykřikuje do světa, jak víc jader = víc adidas. Plány AMD na integrování jednoduché grafiky do CPU se mi vcelku líbí, pro notebooky a kancelářské počítače to bude přínosné. A o žádných dalších multicore nějak zatím nehovoří (resp. pouze pro servery, kde to má význam).

---

nee, tim druhym mam namysli programatory ...

Citace:

---

Původně odeslal Fox!MURDER

nee, tim druhym mam namysli programatory ...

---

Očekávám, že za minimální cenu mi bude nabídnut maximální benefit. Tj. programátor to musí udělat co nejlevněji a rozumně a výrobce CPU to samé. Doteď to fungovalo, výrobce CPU se staral o výkon, programátor o zbytek. Z logiky věci vyplývá, že výrobce CPU svým snažením (na rozdíl od programátora) zvyšuje výkon ve všech aplikacích, tedy dosahuje economy of scale. A já rozhodně nehodlám podporovat to, že se zvýší celkové náklady.

Je samozřejmě jasné, že Intel nechce investovat celý svůj zisk do R&D. Pro něj je mnohem jednodušší vyrábět další jádra, protože to mu ušetří spoustu prachů a když dobře zfixluje benchmarky a udělá marketingovou masáž, neznalí a ovlivnitelní lidé mu na to skočí.

Citace:

---

Původně odeslal Eagle

Je samozřejmě jasné, že Intel nechce investovat celý svůj zisk do R&D. Pro něj je mnohem jednodušší vyrábět další jádra, protože to mu ušetří spoustu prachů a když dobře zfixluje benchmarky a udělá marketingovou masáž, neznalí a ovlivnitelní lidé mu na to skočí.

---

Je samozřejmě jasné, že programator nechce investovat celý svůj zisk do R&D. Pro něj je mnohem jednodušší naklikat další okenka a tlacitka, protože to mu ušetří spoustu prachů a když dobře zfixluje prezentace a udělá marketingovou masáž, neznalí a ovlivnitelní lidé mu na to skočí.

Citace:

---

Původně odeslal THX

Je samozřejmě jasné, že programator nechce investovat celý svůj zisk do R&D. Pro něj je mnohem jednodušší naklikat další okenka a tlacitka, protože to mu ušetří spoustu prachů a když dobře zfixluje prezentace a udělá marketingovou masáž, neznalí a ovlivnitelní lidé mu na to skočí.

---

1) Programy se nedají benchmarkovat, a tedy zákazník nemá jak určit, zda je jeden program lepší než druhý. Zákazník si objednává software a v zásadě je pro něj všechen stejný, a proto má tendenci volit takový program, který je nejlevnější. I kdyby měl možnost poznat optimalizovaný software, nebude za něj ochoten platit dramaticky vyšší (např. dvojnásobné) částky, protože 1) by mu to přineslo benefit pouze v tom jednom konkrétním případě, 2) cena software už tak není úplně malá, jelikož se u něj neaplikuje economy of scale.

2) Programátor nemá dost peněz na reklamní kampaň, aby mohl ovlivnit zákazníka, neboť všichni zákazníci ho tlačí k nízké ceně. Pokud toto neplatí, např. Microsoft, pak se jedná o oligopolistu, který zase nemá motivaci dělat něco navíc.

3) Programátor soupeří o zakázky cenou a to za jedno konkrétní dílo, takže nemá kde nahrabat vyšší marže.

Citace:

---

Původně odeslal Eagle

1) Programy se nedají benchmarkovat, a tedy zákazník nemá jak určit, zda je jeden program lepší než druhý. Zákazník si objednává software a v zásadě je pro něj všechen stejný, a proto má tendenci volit takový program, který je nejlevnější. I kdyby měl možnost poznat optimalizovaný software, nebude za něj ochoten platit dramaticky vyšší (např. dvojnásobné) částky, protože 1) by mu to přineslo benefit pouze v tom jednom konkrétním případě, 2) cena software už tak není úplně malá, jelikož se u něj neaplikuje economy of scale.

2) Programátor nemá dost peněz na reklamní kampaň, aby mohl ovlivnit zákazníka, neboť všichni zákazníci ho tlačí k nízké ceně. Pokud toto neplatí, např. Microsoft, pak se jedná o oligopolistu, který zase nemá motivaci dělat něco navíc.

3) Programátor soupeří o zakázky cenou a to za jedno konkrétní dílo, takže nemá kde nahrabat vyšší marže.

---

1. Ak robia dva programy tu istu vec, tak sa daju obenchmarkovat - pustia sa na rovnakom pocitaci a ten ktory vykona pracu rychlejsie/bude mat vyssi vykon je lepsi. Bol by si prekvapeny, ale niekedy nie je cena vykonnejsieho programu az tak vyssia, alebo z ineho pohladu - s 2x drahsim a o 20% rychlejsim programom dosiahnes taky vykon, ako keby si si namiesto normal procaku kupil nejaky extreme edition a pouzil pomalsi program a celkovo teda mozes usetrit.

2. medzi obrovskymi firmamy typu MS a jednotlivymi programatormi je este kopu roznych velkosti firiem, ktore si mozu dovolit reklamnu kampan.

3. Asi budes prekvapeny, ale nie vsetky programy sa robia na zakazku. A pozor, v trhovej ekonomike jaksi vsetky mozne vyrobky superia o zakaznika cenou (za jeden konkretny vyrobok) takze podla teba teda nikdy nikto nebude mat kde nabrat marze?


A praveze ked uz nerastie vykon pocitacov rychlo, tak sa zacne optimalizovat. Dobrym prikladom su konzole. Tie maju stale rovnaky vykon, ale ak chcu vydat novu lepsiu hru, tak ta musi mat lepsiu grafiku (a ine vlastnosti) a teda aby sa ziskala lepsia grafika, musi sa optimalizovat...

Eagle: tvuj nazor je spravny - aspon pro nynejsi dobu mas pravdu -ale na druhe strane je fakt ze ten vyvoj pujde nejspis cestou vice jader a casem - nerikam ze brzy programatori aby si vydelali v konkurenci budou muset programovat tak ze s tim budou pocitat. Pro dnesek treba vicejadro nebude mit uplatneni ale v budoucnu se asi prosadi a nekdy zacit muselo ;)
Stejne jako si MS prosadi pos*any Visty asi tak Intel prosadi Vicejadra a nic s tim nenadelame a kdo se tomu prvni prizpusobi tak na tom vydela.

Citace:

---

Původně odeslal THX

1. Ak robia dva programy tu istu vec, tak sa daju obenchmarkovat - pustia sa na rovnakom pocitaci a ten ktory vykona pracu rychlejsie/bude mat vyssi vykon je lepsi. Bol by si prekvapeny, ale niekedy nie je cena vykonnejsieho programu az tak vyssia, alebo z ineho pohladu - s 2x drahsim a o 20% rychlejsim programom dosiahnes taky vykon, ako keby si si namiesto normal procaku kupil nejaky extreme edition a pouzil pomalsi program a celkovo teda mozes usetrit.

---

Každý program má jiné rozhraní, jinou spolehlivost, jinou podporu, jinou kompatibilitu. Programy jsou navzájem jen sotva plnými substituty. A proto je nelze otestovat tak, jak navrhuješ. Nehledě na to, že většina end-userů si programy netestuje ani nemá možnost si jejich testy přečíst. Taky když si jdeš kupovat ledničku, sotva víš, co v ní je a zda je dobrá. Proto se orientuješ povětšinou podle ceny, přičemž usuzuješ, že dražší věc je zároveň kvalitnější (což nemusí být vůbec pravda, protože cenu stanovuje marketing podle průzkumu trhu - proto taky všechny výrobky stejné kategorie stojí plus mínus podobně). Když máš ale dvě ledničky s plus mínus stejnými parametry, koupíš spíš tu levnější. Určitě třeba nevyplázneš další dva litry jenom proto, že jedna z ledniček má LCD display.

Komponenty do PC jsou jiné, protože jsou snadno otestovatelné, podobně jako např. služby bankovních ústavů. A proto to tam výrobci nemají tak jednoduché obalamutit zákazníka. Oni se o to ale samozřejmě snaží a to ovlivňováním testů, testerů a také vymýváním mozku reklamou.

Citace:

---

Původně odeslal THX

2. medzi obrovskymi firmamy typu MS a jednotlivymi programatormi je este kopu roznych velkosti firiem, ktore si mozu dovolit reklamnu kampan.

---

Např. která?

Citace:

---

Původně odeslal THX

3. Asi budes prekvapeny, ale nie vsetky programy sa robia na zakazku. A pozor, v trhovej ekonomike jaksi vsetky mozne vyrobky superia o zakaznika cenou (za jeden konkretny vyrobok) takze podla teba teda nikdy nikto nebude mat kde nabrat marze?

---

Pokud je konkurence velká, zisky se blíží nule. To je jednoduchá ekonomická teorie (dokonalá konkurence).

Citace:

---

Původně odeslal Poofy

Eagle: tvuj nazor je spravny - aspon pro nynejsi dobu mas pravdu -ale na druhe strane je fakt ze ten vyvoj pujde nejspis cestou vice jader a casem - nerikam ze brzy programatori aby si vydelali v konkurenci budou muset programovat tak ze s tim budou pocitat. Pro dnesek treba vicejadro nebude mit uplatneni ale v budoucnu se asi prosadi a nekdy zacit muselo ;)
Stejne jako si MS prosadi pos*any Visty asi tak Intel prosadi Vicejadra a nic s tim nenadelame a kdo se tomu prvni prizpusobi tak na tom vydela.

---

Asi nás to čeká, je to pravda. Nejsem si ale vůbec jistý tím, zda to bude ku prospěchu uživatele. Třeba takové ty moderní výrobky, co se porouchají hned po skončení záruční doby, taky nejsou úplně ideální (když to řeknu slušně). Jinak osobně si myslím, že nejvíc na tom vydělá ten, kdo si z těch nových trendů vezme to pro něj dobré a na zbytek se vykašle. Tj. když nebudu mít využití pro dual-core, můžu profitovat z poklesu cen single-core.

Dobre, Eagle, ty si tedy zustan u SC procesoru, ktere budes brzy patrne kupovat po bazarech. My ostatni, az to bude dostupne, pujdeme do multi core procesoru, ktere umozni pro SC nemyslitelne aplikace. Plati? Jsem zvedav, jaky procesor budes mit za treba 5 let....vsadim se ze SC to nebude :)

V prvni fazi tyto mnoha jadrove procesory samozrejmne nebudou urcene do beznych pocitacu, prvotni nasazeni se planuje do super pocitacu, gridu a pro pouziti ve vede vubec. Jak to ale byva, vetsina podobnych technoligii se drive ci pozdeji dostane i do bezneho zivota, takze je mozne, ze vize, kdy mnoha jadrovy procesor v lednicce a toustovaci pomaha pocitat kodovani videa do fraktaloveho codecu zas tak vzdalene byt nemusi :)

Citace:

---

Původně odeslal Petrik

Dobre, Eagle, ty si tedy zustan u SC procesoru, ktere budes brzy patrne kupovat po bazarech. My ostatni, az to bude dostupne, pujdeme do multi core procesoru, ktere umozni pro SC nemyslitelne aplikace. Plati? Jsem zvedav, jaky procesor budes mit za treba 5 let....vsadim se ze SC to nebude :)

---

A já se zase vsadím, že tvoje TCO budou podstatně vyšší než moje :-).

ja som si napriklad doknale isty, ze za 5 rokov rozhodne nebudem mat ten procak co mam dnes, nech je to akykolvek, kludne aj quad core ... ;)

Citace:

---

Původně odeslal Eagle

Každý program má jiné rozhraní, jinou spolehlivost, jinou podporu, jinou kompatibilitu. Programy jsou navzájem jen sotva plnými substituty. A proto je nelze otestovat tak, jak navrhuješ. Nehledě na to, že většina end-userů si programy netestuje ani nemá možnost si jejich testy přečíst.

---

Nemyslim. Napr. take antiviry. Da sa otestovat rychlost detekcie atd. Ani procesory si nie su plne substituovatelne, take AMD ma 3dnow, teda niekedy v niektorych programoch moze mat nejaku vyhodu ktoru intel nema a tak su tie CPU neporovnatelne...

Citace:

---

Taky když si jdeš kupovat ledničku, sotva víš, co v ní je a zda je dobrá. Proto se orientuješ povětšinou podle ceny, přičemž usuzuješ, že dražší věc je zároveň kvalitnější (což nemusí být vůbec pravda, protože cenu stanovuje marketing podle průzkumu trhu - proto taky všechny výrobky stejné kategorie stojí plus mínus podobně). Když máš ale dvě ledničky s plus mínus stejnými parametry, koupíš spíš tu levnější. Určitě třeba nevyplázneš další dva litry jenom proto, že jedna z ledniček má LCD display.

---

a myslis ze bezny user tusi co ma v pocitaci? hlavne ze to ma najnovsi procesor od intelu ako videl v reklame...
To samozrejme vobec nehovori o vyzname DC. Rovnako to totizto bolo aj pred prichodom DC, vtedy sa proste kupoval pentium.

Citace:

---

Komponenty do PC jsou jiné, protože jsou snadno otestovatelné, podobně jako např. služby bankovních ústavů. A proto to tam výrobci nemají tak jednoduché obalamutit zákazníka. Oni se o to ale samozřejmě snaží a to ovlivňováním testů, testerů a také vymýváním mozku reklamou.

---

sluzby bankovych ustavov by som mohol povedat ze kazda banka ponuka predsa nieco extra, nieco trocha ine navyse a tak ich nemozno uplne porovnavat...

Citace:

---

Např. která?

---

co ja viem, napr. grisoft, eset a vobec, zober si nejaky casopis napr. chip, computer a popozeraj reklamy, urcite najdes reklamu na SW, ktora nie je od gigantickej firmy typu MS.

Citace:

---

Pokud je konkurence velká, zisky se blíží nule. To je jednoduchá ekonomická teorie (dokonalá konkurence).

---

Dokonala konkurence v reale neexistuje (resp. je velmi tazke ju dosiahnut). Staci ak maju vsetci rovnake ceny a jeden z vyrobcov ma trocha nizsie naklady a uz ma oproti ostatnym vacsi zisk.

Citace:

---

Asi nás to čeká, je to pravda. Nejsem si ale vůbec jistý tím, zda to bude ku prospěchu uživatele. Třeba takové ty moderní výrobky, co se porouchají hned po skončení záruční doby, taky nejsou úplně ideální (když to řeknu slušně). Jinak osobně si myslím, že nejvíc na tom vydělá ten, kdo si z těch nových trendů vezme to pro něj dobré a na zbytek se vykašle. Tj. když nebudu mít využití pro dual-core, můžu profitovat z poklesu cen single-core.

---

lenze tato diskusia nie je o tom, ze ci prave teraz pre teba je vhodne DC, ale o vyzname a pouzitelnosti DC vseobecne. A myslim ze svoj vyznam to ma. Ak by som si mal vybrat medzi nejakymi SSE8 alebo druhym jadrom, tak beriem druhe jadro, pretoze to viem vyuzit aj dnes a nemusim cakat na nejake pre nove instrukcie optimalizovane programy.

Proste dnes to pojde viac smerom k CISC, pretoze nejak radikalne zvysovat frekvencie nemozes, zato mozes zvysovat pocet tranzistorov a tak sa bude coraz viac funkcii ktore sa dnes robia softwareovo implementuvavat do hw. Skratka uz ziadne sw zvukovky sietovky atd. ale vsetko hw riesenia, ktore nezatazia procesor. A prave to planuje aj intel - ak si vsimnes v tom clanku co je link v bud. intel procesoroch je tam napr. ukazka integrovanej sietovky na cpu (teda - jedno z tych malych jadier bude "sietove").

Citace:

---

Původně odeslal THX

...lenze tato diskusia nie je o tom, ze ci prave teraz pre teba je vhodne DC, ale o vyzname a pouzitelnosti DC vseobecne. A myslim ze svoj vyznam to ma. Ak by som si mal vybrat medzi nejakymi SSE8 alebo druhym jadrom, tak beriem druhe jadro, pretoze to viem vyuzit aj dnes a nemusim cakat na nejake pre nove instrukcie optimalizovane programy. ...

---

Sorry za kratky prispevok, ale :lol: :mweheh: :lol:

A doporucujem si precitat tento thread odznova.

Teraz to praveze vyznam nema :) Vyznam to bude mat mozno v buducnosti, ked bude optimalizovany software. Pre SSE8 zoptimalizujes kompilator a ficis. Pre DC/MC treba aby rozmyslal programator a nie vsetko je paralelizovatelne...

zase dalsi co zacne tvrdit ze to vyznam nema? Ked to nema vyznam pre vas, neznamena to automaticky, ze to nema vyznam pre nikoho.

"Ale Plho, vždyť o tom už zde dobrou půlhodinu hovoříme!":D:p

...nemáte pocit, že už se tady delší dobu mlátí prázdná sláma?;)

Citace:

---

Původně odeslal tomase

zase dalsi co zacne tvrdit ze to vyznam nema? Ked to nema vyznam pre vas, neznamena to automaticky, ze to nema vyznam pre nikoho.

---

Takmer vsetky Vase argumenty boli vyvratene, ale nie, DC MA zmysel, je to super-duper :rolleyes:

Zmysel to bude mat, ked pre to bude vacsina aplikacii (a nie jedna-dve), co tak skoro nebude.

Citace:

---

Původně odeslal PiT

Takmer vsetky Vase argumenty boli vyvratene, ale nie, DC MA zmysel, je to super-duper :rolleyes:

Zmysel to bude mat, ked pre to bude vacsina aplikacii (a nie jedna-dve), co tak skoro nebude.

---

nebylo vyvraceno nic. jen nam bylo naznaceno, ze eagluv dosbox proste dc nepodporuje, tak je to spatny.

a ano, dokazali jsme tu, ze programovat pro SMP je slozitejsi.

ovsem ja porad rikam, ze mame na vyber. bud zustaneme u soucasnejch cpu a spokojime se s vykonem, kterej mame ted, nebo si koupime DC a budem tlacit na vyvojare SW, ze chceme SW, kterej to podporuje. bohuzel nevidim cestu, jak donutit intel/amd/kohokoli jinyho, aby obchazel fyzikalni zakony.

:D:D Presne tak, kdo pouziva kvalitni OS, ma podporu pro DC jiz dnes :)
Jeste neco: jasne ze vetsina aplikaci pro wokna, ale asi i pro ostatni OS, DC nevyuzijou. Duvod je vetsinou ten, ze to neni potreba. U vetsiny aplikaci, ktere potrebuji vysoky vykon CPU, uz podpora pro DC je dnes. Dukazem jsou ruzne profi CAD/CAM a grafika obecne. Prakticky vsechno, co bezi na applu, vice CPU podporuje. Stejne tak dalsi skupina programu, velmi zavislich na CPU - hry - jiz z DC alespon trochu tezi. Nektere vice, jine mene. Takze podle me neni nutne, aby absolutni vetsina SW DC podporovala. Nutne je, aby ty aplikace, u kterych to je potreba, DC vyuzili, coz uz podle me nastalo dnes.

Jinak kamos, co dela profesionalne se zvukem, si koupil ntb s C2D a je z toho uplne na vetvi. Muze tam pry navesit kolik pluginu chce a odezva systemu, u zvuku dost zasadni vec, je porad stejna :) Kazdy plugin je totiz samostatny proces :) U SC by tomu tak nebylo.

Citace:

---

Původně odeslal Fox!MURDER

nebylo vyvraceno nic. jen nam bylo naznaceno, ze eagluv dosbox proste dc nepodporuje, tak je to spatny.

---

Citace:

---

Původně odeslal Fox!MURDER

nebylo vyvraceno nic....

---

MP3 neskodujes bez straty kvality efektivnejsie ako SC.
DivX/XviD neskodujes bez straty kvality efektivnejsie ako SC.
WinRARom nespakujes bez straty kvality v porovnani so SC pakovanim rychlejsie.

Citace:

---

Původně odeslal Petrik

:D:D Presne tak, kdo pouziva kvalitni OS, ma podporu pro DC jiz dnes :)

---

jj, len skoda, ze pre kvalitny OS (unix/linux) neexistuje ta tebou proklamovana "vetsina aplikaci, ktere potrebuji vysoky vykon CPU, uz podporu pro DC maji dnes"

Dnes a rovnako aj v minulosti mal DC vyznam *IBA* v CAD/CAM systemoch a specializovanych systemoch na strih videa obecne. (vynechajme servery, vojenske, technicke simulacie a pod.)

Citace:

---

Původně odeslal Petrik

Prakticky vsechno, co bezi na applu, vice CPU podporuje.

---

Priklad prosim.

Citace:

---

Původně odeslal Petrik

Stejne tak dalsi skupina programu, velmi zavislich na CPU - hry - jiz z DC alespon trochu tezi. Nektere vice, jine mene.

---

Dnes z toho tazi iba Doom3 po patchi resp. Q4. Ostatne hry ani popel. V buducnosti je nastastie velka pravedpodobnost, ze to bude inak - ak to tak bude - bude DC vyhodne kupit. Dnes to tak nie je.

Citace:

---

Původně odeslal Petrik

Takze podle me neni nutne, aby absolutni vetsina SW DC podporovala. Nutne je, aby ty aplikace, u kterych to je potreba, DC vyuzili, coz uz podle me nastalo dnes.

---

Ani zdaleka.
Tie, ktore to potrebovali a su drahe, boli vyuzivane v profi sfere to podporovali uz aj pred tym. Nove aplikacie, ktore boli nasadzovane beznym ludom to nepodporovali a tak skoro podporovat nebudu - dovody su jednoduche, ekonomicky to Eagle myslim nacrtol viac ako dobre v poslednych prispevkoch.

Citace:

---

Původně odeslal Petrik

Jinak kamos, co dela profesionalne se zvukem, si koupil ntb s C2D a je z toho uplne na vetvi. Muze tam pry navesit kolik pluginu chce a odezva systemu, u zvuku dost zasadni vec, je porad stejna :) Kazdy plugin je totiz samostatny proces :) U SC by tomu tak nebylo.

---

Keby tvoj kamos pracoval na tebou chvalenych Apploch alebo si nastavoval priority procesov rucne, tak by mal odozvu rovnaku alebo porovnatelnu... (ano, uznavam, ze nastavovat procesy rucne je nepohodlne)

Citace:

---

Původně odeslal PiT

WinRARom nespakujes bez straty kvality v porovnani so SC pakovanim rychlejsie.

---

jeziskunabrisku. 0.05%, nebo kolik byl ten rozdil ve velikosti, ti fakt urve disketovku ...
a to ze je winrar spatne napsanej, neni dukaz spatnosti DC. pokud bude 7zip fungovat lip, budu pouzivat 7zip. zvlast kdyz je zadarmo.

Citace:

---

Původně odeslal Fox!MURDER

jeziskunabrisku. 0.05%, nebo kolik byl ten rozdil ve velikosti, ti fakt urve disketovku ...

---

Urve. Pokial tam bude rozdiel, nie je to kvalitne riesenie ale riesenie z nudze.

Citace:

---

Původně odeslal Fox!MURDER

a to ze je winrar spatne napsanej, neni dukaz spatnosti DC. pokud bude 7zip fungovat lip, budu pouzivat 7zip. zvlast kdyz je zadarmo.

---

S tym suhlasim. Ak bude 7zip davat rovnake vysledky na SC a MC, pricom bude na MC rychlejsi a zaroven bude celkovo lepsi ako RAR, sem s nim.

Citace:

---

Původně odeslal PiT

Takmer vsetky Vase argumenty boli vyvratene, ale nie, DC MA zmysel, je to super-duper :rolleyes:

Zmysel to bude mat, ked pre to bude vacsina aplikacii (a nie jedna-dve), co tak skoro nebude.

---

takmer vsetky != vsetky, tzn. ze pre cast pripadov DC jednoducho vyuzitelne je, tym padom pre ludi pouzivajucich tieto "pripady" ma DC vyznam a to nemaly.

1)To se pletes, pro linux uz existuje docela hodne progamu na CAD, dokonce uz i zivotaschopne programy na vektorovou i rastrovou grafiku. Navic docela hodne vyrobcu profi aplikaci ohlasili portaci na linux.

2)To neni pravda, napr. hry ale i dalsi aplikace, ktere potrebuji CPU.

3)Creative suit, programy na zpracovani zvuku atd. Apply maji vice CPU uz pomerne dlouho, je tedy logicke, ze programy, ktere potrebuji vice CPU, je podporuji.

4)Tak se koukni na benchmarky treba na http://www23.tomshardware.com/cpu.html . Kdyby jsi cetl cely tento trhead, tak bys zjistil, ze VSECHNY hry bezi na DC lepe, protoze graficky driver bezi oddelne od herniho enginu, navic nove ovladace DC podporuji. Rozdil je vetsinou 10-20%. Pak tu jsou moderni hry typu GRAW, ktere DC podporuji primo a rozdil je u nich klidne vice nez 50%.

5) to jsou ale vetsinou aplikace typu winamp, ktere vice CPU nepodporuji, protoze to neni potreba. Ty aplikace, ktere DC nepodporuji a pritom by to bylo potreba, se zacinaj iprepisovat za ucelem podpory DC, viz WinRAR.

6) On pracuje se zvukem v realnem case, takze tim, ze da nejakemu pluginu mensi prioritu, si fakt nepomuze, maximalne to ten plugin prestane stihat uplne :)) A ver tomu, ze kdyz pluginy pracuji interne na 36/48bit a 192kHz, ze jsou pomerne hodne procesorove narocne :) to nemluvim o pripadu, kdy mixujes treba 5 kanalu a zaroven bys na ne chtel aplikovat nejaky ty pluginy.

Citace:

---

Původně odeslal PiT

MP3 neskodujes bez straty kvality efektivnejsie ako SC.
DivX/XviD neskodujes bez straty kvality efektivnejsie ako SC.
WinRARom nespakujes bez straty kvality v porovnani so SC pakovanim rychlejsie.


jj, len skoda, ze pre kvalitny OS (unix/linux) neexistuje ta tebou proklamovana "vetsina aplikaci, ktere potrebuji vysoky vykon CPU, uz podporu pro DC maji dnes"

Dnes a rovnako aj v minulosti mal DC vyznam *IBA* v CAD/CAM systemoch a specializovanych systemoch na strih videa obecne. (vynechajme servery, vojenske, technicke simulacie a pod.)


Priklad prosim.


Dnes z toho tazi iba Doom3 po patchi resp. Q4. Ostatne hry ani popel. V buducnosti je nastastie velka pravedpodobnost, ze to bude inak - ak to tak bude - bude DC vyhodne kupit. Dnes to tak nie je.


Ani zdaleka.
Tie, ktore to potrebovali a su drahe, boli vyuzivane v profi sfere to podporovali uz aj pred tym. Nove aplikacie, ktore boli nasadzovane beznym ludom to nepodporovali a tak skoro podporovat nebudu - dovody su jednoduche, ekonomicky to Eagle myslim nacrtol viac ako dobre v poslednych prispevkoch.


Keby tvoj kamos pracoval na tebou chvalenych Apploch alebo si nastavoval priority procesov rucne, tak by mal odozvu rovnaku alebo porovnatelnu... (ano, uznavam, ze nastavovat procesy rucne je nepohodlne)

---

Citace:

---

Původně odeslal PiT

Dnes z toho tazi iba Doom3 po patchi resp. Q4. Ostatne hry ani popel.

---

http://forumz.tomshardware.com/games...pict94969.html

Programatori ze na zakaznika utoci nizkou cenou? Ale to preci neni pravda. Utoci se bezvyznamnymi featurami...nebo na nas MS utoci cenou? Tomu se fakt musim smat.

preco generalizujes programatorov na M$?

Citace:

---

Původně odeslal PiT

Takmer vsetky Vase argumenty boli vyvratene, ale nie, DC MA zmysel, je to super-duper :rolleyes:

Zmysel to bude mat, ked pre to bude vacsina aplikacii (a nie jedna-dve), co tak skoro nebude.

---

ja myslim ze neboli vyvratene. Staci mi pustit dva programy naraz a uz to vyuzivam. Nemusi byt ani jeden z nich optimalizovany pre DC.

Citace:

---

Původně odeslal PiT

MP3 neskodujes bez straty kvality efektivnejsie ako SC.
DivX/XviD neskodujes bez straty kvality efektivnejsie ako SC.
WinRARom nespakujes bez straty kvality v porovnani so SC pakovanim rychlejsie.

---

nepravda. mp3 skodujem bez straty kvality 2x efektivnejsie na DC - staci skladbu rozdelit na 2 casti. Je ale pravda ze na DC bude vysledny subor asi o promile vacsi.
DivX/Xvid skodujem bez straty kvality 2x efektivnejsie na DC - staci video rozdelit na 2 casti. Opat bude vysledny subor trocha vacsi.
Winrarom spakujem SO ZISKOM KVALITY v porovnani so SC rychlejsie - viz. fox murderov priklad na program files.

Vo vacsine pripadov je zvacsenie vyslednych suborov minimalne. Otazne je teda, ci budete lpiet na usetreni tych par byteov, alebo vam to pojde 2x rychlejsie.

Citace:

---

Dnes a rovnako aj v minulosti mal DC vyznam *IBA* v CAD/CAM systemoch a specializovanych systemoch na strih videa obecne. (vynechajme servery, vojenske, technicke simulacie a pod.)

---

Iba? ale ved sme si tu ukazali mnoho inych pouziti, kde DC vyznam ma.

Citace:

---

Dnes z toho tazi iba Doom3 po patchi resp. Q4. Ostatne hry ani popel. V buducnosti je nastastie velka pravedpodobnost, ze to bude inak - ak to tak bude - bude DC vyhodne kupit. Dnes to tak nie je.

---

driver uz mas multithreaded a uz tu niekto daval link na tomshw fora so zoznamom hier ktore podporuju dc.

a niekto tu spominal winamp... bol som prekvapeny, ale winamp s pustenymi AVS dokazal vytazit HT p4 na 80%, t.j. 60% vykonu druheho "jadra" vedel vyuzit.

Asi by to chcelo pekne spisat vsetky argumenty proti a vsetky argumenty za. Celkovo mi DC pride omnoho uzitocnejsie ako sse8.

Citace:

---

Původně odeslal PiT

Sorry za kratky prispevok, ale :lol: :mweheh: :lol:

A doporucujem si precitat tento thread odznova.

Teraz to praveze vyznam nema :) Vyznam to bude mat mozno v buducnosti, ked bude optimalizovany software. Pre SSE8 zoptimalizujes kompilator a ficis. Pre DC/MC treba aby rozmyslal programator a nie vsetko je paralelizovatelne...

---

podobne si to precitaj ty, mohol by som sa obdobne smiat, bolo tu ukazanych zopar pripadov kedy sa to vyuziva prave teraz....

pre DC zoptimalizujes kompilator a ficis. Skutocne optimalizacie na SSE a SSE2, take ktore mali razantny prinos vykonu, sa robili rucne.

A co sa tyka toho programovania, myslim ze programovat viacvlaknove aplikacie nie je az o tolko tazsie ako jednovlakna.

me se zda ze tady panove ac tomu zajiste rozumi vic nez ja, tak proste nahlizi na vec stylem, ze kdyz ja pro linux a programovani nepotrebuju DC tak musi byt nahov*o.
Ale pro uz ted pro bezne uzivatele neni! Ve windows ktery vetsina lidi pouziva je prechod na DC dost znat v beznem uzivani i se SC aplikacemi stejne tak dekodovani videa je rychlejsi (o tom ze bych ztracel kvalitu slysim teda prvne) a proto Vase argumenty jsou mozna technicky spravne - ale v praxi a na nejpouzivanejsim OS je to jinak.
To ze programatori budou mit vic prace s optimalizaci je smutne ale pokud budou chtit obstat v konkurenci budou muset optimalizovat at chteji nebo ne.

Citace:

---

Původně odeslal THX

nepravda. mp3 skodujem bez straty kvality 2x efektivnejsie na DC - staci skladbu rozdelit na 2 casti. Je ale pravda ze na DC bude vysledny subor asi o promile vacsi.
DivX/Xvid skodujem bez straty kvality 2x efektivnejsie na DC - staci video rozdelit na 2 casti.

---

OMG, kolikrat se to tu resilo - jak psal Pit, doporucuji ti si opravdu precist tento thread (pripadne nam ukazat jak rozdelujes a pak spojujes MP3)

Citace:

---

Původně odeslal Caleb

OMG, kolikrat se to tu resilo - jak psal Pit, doporucuji ti si opravdu precist tento thread (pripadne nam ukazat jak rozdelujes a pak spojujes MP3)

---

ha, to bolo popisane v jednom linku ktory tu tusim dal eagle ako priklad ze sa to neda

Ako to teda rozdelim? Nezkodovany subor bez problemov rozdelim na dve casti. Ako spojim mp3ku? Jednoducho spojim dva skodovane mp3 zasebou a upravim hlavicku. A ak by som bol drsnak, tak ani neupravim tu hlavicku a pojde to prehrat, akurat nebude to asi ukazovat spravnu dlzku a niektore playere s tym mozu mat rozne mensie problemy.

A ze budes mit uprostred lupanec (v dusledku nedelitelnosti frame) to ti moc nevadi, ze? A to ze ti samotne rozdelovani a spojovani zabere vice casu nez kdyby si to enkodoval na SC (neni mi znam zadny nastroj ktery by tuto cinnost automatizoval) ti take nevadi?
Jiste existuje DC-optimalizovany Lame (s horsi kvalitou nez SC), muzes enkodovat vice WAVu najednou, ale tebou popsany postup je imho nesmyslny. Nebo si to snad zkousel?

Citace:

---

Původně odeslal Caleb

A ze budes mit uprostred lupanec (v dusledku nedelitelnosti frame) to ti moc nevadi, ze? A to ze ti samotne rozdelovani a spojovani zabere vice casu nez kdyby si to enkodoval na SC (neni mi znam zadny nastroj ktery by tuto cinnost automatizoval) ti take nevadi?
Jiste existuje DC-optimalizovany Lame (s horsi kvalitou nez SC), muzes enkodovat vice WAVu najednou, ale tebou popsany postup je imho nesmyslny. Nebo si to snad zkousel?

---

Praveze lupanec tam nebude, pretoze sa vytvori novy frame a to je tiez dovod, preco bude vysledny subor trocha vacsi. Rozdelovanie a spajanie ak mi ma zabrat vela castu v porovnani s enkodingom znamena, ze enkodujem kratke skladby - ak su to napr. pesnicky albumu, mozem ich enkodovat paralelne, ak je to jedna dlha hodinova skladba, tak potom mi delenie a spajanie prinesie usporu.

(tento link sem dal eagle) http://forum.doom9.org/showthread.php?t=115822

Citace:

---

Původně odeslal omion

Quote:
Originally Posted by emmel
Yes. But why not simply split the file in N-parts, and trivially distribute them over N-cores? And finally join the results. That would scale exactly linearly, or does it? Of course, if N is big, exact load balancing may be problematic (one thread could run much longer than the others). But anyways.

I actually made a program that could do that with x264, but it's not quite linear. I got something like 1.95x with 2 processors (although it's been a while since I've used it, so that number may be way off).

The main problem with many processors is with the splitting. There's no easy way to determine where x264 will put an I frames without analyzing each frame, so chances are the split point will be in the middle of a scene. For consistant quality, you need to re-render that scene. Obviously, this will not scale well if your number of processors is greater than the number of scenes in your movie.

I minimized the load-balancing problem by splitting to more parts than cores, then having each core "check out" the next split part. This, of course, increased the number of split frames and therefore the number of re-encoded scenes.

I think the reason that my setup didn't scale perfectly had to do with disk accesses. Two programs were reading and writing in two separate places on the same hard disk.

But as I said, it's been a while since I used that program to encode anything, and it was in the super-pre-alpha stage, so it may be a problem with my optimizations.

---

Teda, nie neviem o programe ktory by to robil automatizovane, ani som ho nerobil, ale vravim ze to nebude zlozite a ze tento program bude robit:
1. rozdeli neenkodovany subor na dva casti
2. pusti paralelne enkodovanie oboch casti
3. pospaja vysledne subory (a to sice tak, ze z nich povyhadzuje hlavicky a vezme iba data)
4. vytvori novu hlavicku kde nastavi spravne informacie o dlzke atd.
Tuto novu hlavicku moze vytvorit modifikovanim hlavicky 1. vysledneho mp3 suboru kde zmeni informacie na skutocne po pospajani odpovedajuce.

V bode 2 predpokladam enkodovanie s rovnakymi nastaveniami enkodera.

Citace:

---

Původně odeslal tomase

preco generalizujes programatorov na M$?

---

Kdybych ti dal priklad z aplikacnich serveru nebo z IDE, tak nevis o cem mluvim ;-)

Citace:

---

Původně odeslal THX

Praveze lupanec tam nebude, pretoze sa vytvori novy frame a to je tiez dovod, preco bude vysledny subor trocha vacsi.

---

Muzes nejak dokazat, ze to lze? Pomoci kterych nastroju by si to vytvoril (tj. nastaveni enkoderu Lame aby nevytvarel na zacatku a konci MP3ky mezery) a pomoci ceho by si to spojoval? To ze je neco teoreticky mozne (coz ale imho neni tento pripad) neznamena ze to je prakticky realizovatelne (se softwarovymi nastroji ktere jsou k dispozici). Mam neustale pocit, ze varis z vody - nebo si snad myslis ze vyvojari Multi-threading LAME sou tak hloupi, ze by neprisli na to, ze (podle tebe) staci vstupni soubor rozsekat na kousicky, paralelne enkodovat a pak pospojovat a misto toho resi nejakou DC optimalizovanou verzi co enkoduje stejne sekvencne. Chci dukaz misto slibu :p

Citace:

---

Původně odeslal Caleb

Muzes nejak dokazat, ze to lze? Pomoci kterych nastroju by si to vytvoril (tj. nastaveni enkoderu Lame aby nevytvarel na zacatku a konci MP3ky mezery) a pomoci ceho by si to spojoval? To ze je neco teoreticky mozne (coz ale imho neni tento pripad) neznamena ze to je prakticky realizovatelne (se softwarovymi nastroji ktere jsou k dispozici). Mam neustale pocit, ze varis z vody - nebo si snad myslis ze vyvojari Multi-threading LAME sou tak hloupi, ze by neprisli na to, ze (podle tebe) staci vstupni soubor rozsekat na kousicky, paralelne enkodovat a pak pospojovat a misto toho resi nejakou DC optimalizovanou verzi co enkoduje stejne sekvencne. Chci dukaz misto slibu :p

---

novy frame tam vznikne, pretoze na zaciatku kazdej jednotlivej casti samozrejme bude novy frame. Ake nastavenia lame pouzit neviem - nepouzivam lame. V podstate si uz ani nepamatam kedy som naposledy enkodoval. Ale predpokladam ze existuje nejake nastavenie lame, ktore do enkodovanej skladby nepridava na zaciatku ani na konci ziadne medzery, fadeouty atd. a ze len enkoduje presne to co dostane nekomprimovane na vstupe.
Mam dojem, ze vyvojari multithreaded lame sa vybrali inou cestou ako delenie suborov a teda tam robia ten multihreading uplne inac (tak, aby mohli spracovat subor sekvencne).
Program ktory by delil skladby a potom ich spajal potrebuje od enkodera v podstate iba vytvorenie frameov. Ak ma lame nejaky option, nech nepridava na zaciatok (ani koniec) id3 tagy, tak by malo stacit appendnut tie dva subory. Potom by to chcelo este k vyslednemu suboru pridat tie id3 tagy...

Citace:

---

Původně odeslal Petrik

1)To se pletes, pro linux uz existuje docela hodne progamu na CAD, dokonce uz i zivotaschopne programy na vektorovou i rastrovou grafiku. Navic docela hodne vyrobcu profi aplikaci ohlasili portaci na linux.

---

Preco potom vsetci, ktorych poznam, pouzivaju ACAD a Cinemu, ked je tak vela CADovych programov pre linux?
O rastrovych programoch by som rad vedel, pretoze to je to jedine, co ma momentalne drzi pri Windoozoch.
Ktore velke firmy konkretne?

Citace:

---

Původně odeslal Petrik

2)To neni pravda, napr. hry ale i dalsi aplikace, ktere potrebuji CPU.

---

Ktore?
Pre bezneho pouzivatela iba multimedia a pakovanie programov.

Multimedia - bolo tu toho dost. So sucasnymi kodekmi nepohnes bez straty kvality. Ako to vymyslia u novych, uvidime.

Pakovanie - tiez to tu bolo - bez straty kvality (velkosti) v sucasnosti nepohnes, uvidime o par mesiacov.

Citace:

---

Původně odeslal Petrik

3)Creative suit, programy na zpracovani zvuku atd. Apply maji vice CPU uz pomerne dlouho, je tedy logicke, ze programy, ktere potrebuji vice CPU, je podporuji.

---

http://forums.macrumors.com/showthread.php?t=245733

"As far I know, neither of these apps are built to exploit multi-processor machines."

Citace:

---

Původně odeslal mraky

Programatori ze na zakaznika utoci nizkou cenou? Ale to preci neni pravda. Utoci se bezvyznamnymi featurami...nebo na nas MS utoci cenou? Tomu se fakt musim smat.

---

M$ ma na desktopovom trhu bohuzial prakticky monopol...

Citace:

---

Původně odeslal THX

Staci mi pustit dva programy naraz a uz to vyuzivam. Nemusi byt ani jeden z nich optimalizovany pre DC.

---

Omyl, dva programy, ktore dokopy zatazuju jeden procesor na viac ako 100%.
Inak nie. A aj to za predpokladu, ze ti dementny windows scheduler nebude ich vykon nahodne prehadzovat z jadra na jadro.

Citace:

---

Původně odeslal THX

nepravda. mp3 skodujem bez straty kvality 2x efektivnejsie na DC - staci skladbu rozdelit na 2 casti. Je ale pravda ze na DC bude vysledny subor asi o promile vacsi.

---

Zacal som debatu o tom v tomto threade podobne ako ty. Selskym rozumom su multimedia totizto jedna z mala spolahlivo paralelizovatelnych veci.
U LAMEu a navrhu MP3 ako takom je to vdaka bit reservoir a samotnej specifikacii MP3 s 3ma typmi blokov nerealizovatelne bez straty kvality (bud lupanec v strede alebo v strede znizena/zvysena kvalita => vysledny subor iny)

Citace:

---

Původně odeslal THX

DivX/Xvid skodujem bez straty kvality 2x efektivnejsie na DC - staci video rozdelit na 2 casti. Opat bude vysledny subor trocha vacsi.

---

Vysledny subor bude bud mensi alebo vacsi... Kvalita rovnaka nebude. Zhodli sme sa tu na tom, ze prvy pass je lahko paralelizovatelny (aspon u XviDu), pretoze tam ide kodek na maximalnu velkost... Druhy uz ma opat problem podobny ako u MP3, no v x264 kodeku to uz nejako vyvojari tusim okaslali.

Citace:

---

Původně odeslal THX

Winrarom spakujem SO ZISKOM KVALITY v porovnani so SC rychlejsie - viz. fox murderov priklad na program files.

Vo vacsine pripadov je zvacsenie vyslednych suborov minimalne. Otazne je teda, ci budete lpiet na usetreni tych par byteov, alebo vam to pojde 2x rychlejsie.

---

Vysledna velkost suboru je vacsia. Je to teda ZISK kvality alebo STRATA kvality?

Zasadna otazka pre mna je ale ta, ze dostanem uplne iny subor... Proste spustim tu istu vec na roznych pocitacoch a dostanem iny vysledok. To je na pozastavenie sa.

Citace:

---

Původně odeslal THX

Asi by to chcelo pekne spisat vsetky argumenty proti a vsetky argumenty za. Celkovo mi DC pride omnoho uzitocnejsie ako sse8.

---

Asi by chcelo.
Asi by to chcelo poriadne otestovat vsetko mozne na nejakom C2D a na tom istom akurat s disablovanym jednym core.

Citace:

---

Původně odeslal THX

pre DC zoptimalizujes kompilator a ficis. ...

A co sa tyka toho programovania, myslim ze programovat viacvlaknove aplikacie nie je az o tolko tazsie ako jednovlakna.

---

Programoval si niekedy?

Citace:

---

Původně odeslal Poofy

me se zda ze tady panove ac tomu zajiste rozumi vic nez ja, tak proste nahlizi na vec stylem, ze kdyz ja pro linux a programovani nepotrebuju DC tak musi byt nahov*o.

---

Linux ma prave MC riesene podstatne lepsie ako Windows

Citace:

---

Původně odeslal Poofy

Ale pro uz ted pro bezne uzivatele neni! Ve windows ktery vetsina lidi pouziva je prechod na DC dost znat v beznem uzivani i se SC aplikacemi stejne tak dekodovani videa je rychlejsi (o tom ze bych ztracel kvalitu slysim teda prvne) a proto Vase argumenty jsou mozna technicky spravne - ale v praxi a na nejpouzivanejsim OS je to jinak.

---

Bavili sme sa o kodovani videa, nie dekodovani. Ak dekodovanie pouziva obe jadra, stracas vyhodu multitaskingu.

Citace:

---

Původně odeslal Poofy

To ze programatori budou mit vic prace s optimalizaci je smutne ale pokud budou chtit obstat v konkurenci budou muset optimalizovat at chteji nebo ne.

---

To je to, na co Eagle poukazuje v podlednych postoch. M$ nic nenuti to robit, lebo ma dominantne postavenie. Beznych programatorov nic nenuti to robit, lebo im to nikto nezaplati. A programatori, ktorym to niekto zaplati, to uz davno spravili/robia :)

Citace:

---

Původně odeslal THX

Ale predpokladam ze existuje nejake nastavenie lame, ktore do enkodovanej skladby nepridava na zaciatku ani na konci ziadne medzery

---

A myslim ze u pocitu to zustane - je to problem samotneho navrhu formatu MP3.

Citace:

---

Původně odeslal PiT

bud lupanec v strede alebo v strede znizena/zvysena kvalita => vysledny subor iny

---

Presne tak, jeden spojovaci frame by kvalitu asi moc neovlivnil, ale pri prechodu na multicore by techto framu bylo v souboru cim dal tim vice a kvalita by byla o necem jinem.
2THX - nejde o to, ze by idea rozdeleni souboru a enkodovani byla spatna, pouze je konkretne u MP3 formatu nerealizovatelna - imho by se s timto muselo pocitat uz pri navrhu samotneho formatu (jak zde psal Pit) a je dost dobre mozne, ze diky teto vlastnosti by mel ve vysledku horsi pomer velikost/kvalita.

Citace:

---

Původně odeslal PiT

Zacal som debatu o tom v tomto threade podobne ako ty. Selskym rozumom su multimedia totizto jedna z mala spolahlivo paralelizovatelnych veci.
U LAMEu a navrhu MP3 ako takom je to vdaka bit reservoir a samotnej specifikacii MP3 s 3ma typmi blokov nerealizovatelne bez straty kvality (bud lupanec v strede alebo v strede znizena/zvysena kvalita => vysledny subor iny)

---

ja tvrdim zvysena kvalita, lebo novy keyframe a preto aj vacsi vysledny subor

Citace:

---

Původně odeslal PiT

Vysledny subor bude bud mensi alebo vacsi... Kvalita rovnaka nebude. Zhodli sme sa tu na tom, ze prvy pass je lahko paralelizovatelny (aspon u XviDu), pretoze tam ide kodek na maximalnu velkost... Druhy uz ma opat problem podobny ako u MP3, no v x264 kodeku to uz nejako vyvojari tusim okaslali.

---

OK, vysledna kvalita, ani subor rovnaky nebude. Ja tvrdim ze sa to bude lisit zanedbatelne, naproti comu sa rychlost enkodovania bude lisit vyrazne a teda mi to za tu malu zmenu stoji. Tak ci tak - je to stratova kompresia, takze ma vobec nezaujima ci na dvoch pocitacoch bude ten subor presne rovnaky.

Citace:

---

Vysledna velkost suboru je vacsia. Je to teda ZISK kvality alebo STRATA kvality?

---

Citace:

---

Původně odeslal Fox!MURDER

Program Files MT WinRAR 2,50MB/s (317MB, 127sec) (117% vykonu ST) (affinity CPU0 + CPU1) (vyslednej soubor 95,702,859 bytes)
Program Files ST WinRAR 2,12MB/s (317MB, 149sec) (100% vykonu ST) (affinity CPU0) (vyslednej soubor 95,851,150 bytes)

---

Podla mna je 851 150 viac ako 702 859 a teda mutithreaded verzia okrem toho ze bola rychlejsia, v tomto pripade este aj lepsie spakovala. Ale opat opakujem - tie rozdiely su tak male, ze su (podla mna) zanedbatelne.

Citace:

---

Zasadna otazka pre mna je ale ta, ze dostanem uplne iny subor... Proste spustim tu istu vec na roznych pocitacoch a dostanem iny vysledok. To je na pozastavenie sa.

---

to je ako keby si si pustil dva rozne verzie wordu a napisal tam presne uplne rovnaky text a saveol to a vadilo by ti ze to ma roznu velkost. Aj ked je to korektne ulozene a korektne precitatelne. Co ti vadi na tom ze multithreaded winrar produkuje ine vysledky ako single threaded? Preco by to malo byt zle? Co ak ma problem viacero spravnych rieseni a nie len jedno?

Citace:

---

Programoval si niekedy?

---

ano

Citace:

---

Původně odeslal THX

ja tvrdim zvysena kvalita, lebo novy keyframe a preto aj vacsi vysledny subor

---

To zalezi od toho, ako to vide. Ak vide dobre, kvalitu toho frejmu zvysi, ak zle, znizi :)

Citace:

---

Původně odeslal THX

OK, vysledna kvalita, ani subor rovnaky nebude. Ja tvrdim ze sa to bude lisit zanedbatelne, naproti comu sa rychlost enkodovania bude lisit vyrazne a teda mi to za tu malu zmenu stoji. Tak ci tak - je to stratova kompresia, takze ma vobec nezaujima ci na dvoch pocitacoch bude ten subor presne rovnaky.

---

Ak to bude nepostrehnutelne, tak je to v podstate jedno. V sucasnej dobe to ale bud nejde alebo to postrehnutelne je (lupanec). Uvidime u buducich kodekov.

Foxov test: Na nete je zasa presny opak :) Co uz.

Word: Nezmyselny argument.

WinRAR: Pokial budu mutlithreaded vysledky vzdy lepsie, tak nic :)

Programovanie: A programoval si aj pre viacprocesorove systemy resp. vies ako funguje linker a kompilator, ked si myslis, ze kompilatorom to vyriesis?

Citace:

---

Původně odeslal PiT

Programovanie: A programoval si aj pre viacprocesorove systemy resp. vies ako funguje linker a kompilator, ked si myslis, ze kompilatorom to vyriesis?

---

kompilatorom sa to v niektorych pripadoch moze ciastocne zlepsit - optimalizovat pre instrukcie je samozrejme jednoduchsie. Intel teraz chysta nejaky novy optimalizovany kompiler pre DC. Chcel som tym len povedat to, ze skutocne optimalizacie, ci uz na SSE alebo DC sa nakoniec robia tak ci tak "rucne" a automatickymi optimalizaciami kompilatora mozno dosiahnut ciastocne uspechy, ale velmi to zavisi na tom, co sa kompiluje.

Ad. foxov test - ide len o to, ze ktosi tu tvrdil ze to bude VZDY horsie a to sice takym sposobom, ze nestoji za to to vyuzivat.

Citace:

---

Původně odeslal THX

Nemyslim. Napr. take antiviry. Da sa otestovat rychlost detekcie atd.

---

Ty by sis koupil antivir kvůli rychlosti detekce? Já teda kvůli co nejvyšší pravděpodobnosti odhalení virů a kvůli nejlepší podpoře. Pak mi taky musí sednout jeho ovládání. Rychlost je až někde na konci, protože si scan pustím v době, kdy bude počítač málo vytížen.

Citace:

---

Původně odeslal THX

Ani procesory si nie su plne substituovatelne, take AMD ma 3dnow, teda niekedy v niektorych programoch moze mat nejaku vyhodu ktoru intel nema a tak su tie CPU neporovnatelne...

---

Tady tě asi překvapím - end-usera absolutně nezajímá, jaké instrukce procesor má. Jeho dokonce ani nezajímá, jestli je to z transistorů, laserů nebo čehosi. Jemu jde v zásadě jen o jedno - aby pro něj měl odpovídající hodnotu. Ta se povětšinou měří spolehlivostí (lidi chápou PC jako služku, ne něco, čemu budou sloužit oni) a výkonem v jimi oblíbených aplikacích.

Citace:

---

Původně odeslal THX

co ja viem, napr. grisoft, eset a vobec

---

Takže podle tebe třeba Grisoft tě může ovlivnit na jeho antivir tím, že bude tvrdit, že poběží o 10 % rychleji na dual-core (víc asi sotva - limitace diskem)? Tak to nevím, co by jim na to zákazníci řekli - viz moje odpověď na první citaci.

Citace:

---

Původně odeslal THX

lenze tato diskusia nie je o tom, ze ci prave teraz pre teba je vhodne DC, ale o vyzname a pouzitelnosti DC vseobecne

---

A já tvrdím, že až na specifické úkoly orientované především do oblasti serverů a pracovních stanic (kde si za příslušný software náležitě zaplatíš) a na některé typy multimédií to pro lidi momentálně význam nemá. Možná v budoucnu, ale do té doby klidně ušetřím.

Citace:

---

Původně odeslal THX

teda - jedno z tych malych jadier bude "sietove").

---

Tak to je super. A kvůli takovéhle kravině poběží můj oblíbený program pomaleji? Děkuji, nemám zájem.

Citace:

---

Původně odeslal Fox!MURDER

a ano, dokazali jsme tu, ze programovat pro SMP je slozitejsi.

---

My jsme tu především dokázali, že to je podstatně dražší! Dneska se všichni na všechno dívají přes peněženku, se podívej na prodeje hardware, co frčí. A prostě málokdo bude ochoten zaplatit dvojnásobek. Podívej se třeba tady na propagátora Petrika - jede na ušmudlaném přetaktovaném Sempronu. Proč? Protože prostě nechtěl dát do počítače víc peněz. Bude je chtít dát do software?

Citace:

---

Původně odeslal Fox!MURDER

ovsem ja porad rikam, ze mame na vyber. bud zustaneme u soucasnejch cpu a spokojime se s vykonem, kterej mame ted, nebo si koupime DC a budem tlacit na vyvojare SW, ze chceme SW, kterej to podporuje. bohuzel nevidim cestu, jak donutit intel/amd/kohokoli jinyho, aby obchazel fyzikalni zakony.

---

Tohle není věc, která se nabízí. Vnímáš to lehce zkresleně. Pomineme-li to, že pro výrobce procesorů je podstatně levnější vymýšlet jednoduchá jádra než investovat zisky do R&D a zlepšovat paralelismus / frekvenci (i to se dá), pak máš dvě situace:
1) Jedno jádro (případně málo jader) na vyšší frekvenci.
2) Hodně jader s nízkou frekvencí.
Nic mezi tím neexistuje. Protože aplikace většinou další jádra nedokázou využít (a nebo si za ně sakra dobře zaplatíš!), jsem pro první řešení. Nehodlám obětovat 20 % výkonu ve většině aplikací tomu, aby mi pár aplikací běželo o řádově 40 % rychleji.

Citace:

---

Původně odeslal Petrik

U vetsiny aplikaci, ktere potrebuji vysoky vykon CPU, uz podpora pro DC je dnes. Dukazem jsou ruzne profi CAD/CAM a grafika obecne.

---

Takže sám uznáváš, že "profi CAD/CAM". Kolik že tyhle programy stojí a pro koho že jsou určeny?

Citace:

---

Původně odeslal Petrik

Stejne tak dalsi skupina programu, velmi zavislich na CPU - hry - jiz z DC alespon trochu tezi.

---

Jistě. Za cenu toho, že náklady na vývoj hry budou vyšší, a tedy se to buďto projeví na prodejní ceně nebo bude nutné, aby z trhu někteří hráči zmizeli (pokud se trh nebude rozšiřovat). A už tady IMHO zaznělo, že hry zas tak ideálně paralelizovatelné nejsou a že především jsou většinou limitovány výkonem grafické karty a nikoli výkonem procesoru.

Citace:

---

Původně odeslal Petrik

Jinak kamos, co dela profesionalne se zvukem, si koupil ntb s C2D a je z toho uplne na vetvi. Muze tam pry navesit kolik pluginu chce a odezva systemu, u zvuku dost zasadni vec, je porad stejna

---

Kolik z toho dělá:
1) Novější architektura se spekulací a lepším paralelismem?
2) Velká rychlá L2 cache?
Jinak opět operuješ se slovem "profesionalne". To asi není úplně typické, že?

Citace:

---

Původně odeslal Fox!MURDER

a to ze je winrar spatne napsanej, neni dukaz spatnosti DC. pokud bude 7zip fungovat lip, budu pouzivat 7zip. zvlast kdyz je zadarmo.

---

Tak to jsem zvědav, jak ke změně přesvědčíš BFU ;-). To je podobné jak s Microsoftem - udělal výborný support pro školy, a tak si vychovává základnu uživatelů. Přeškolit lidi je mnohem dražší než koupit jejich software.

Citace:

---

Původně odeslal Petrik

VSECHNY hry bezi na DC lepe, protoze graficky driver bezi oddelne od herniho enginu, navic nove ovladace DC podporuji. Rozdil je vetsinou 10-20%. Pak tu jsou moderni hry typu GRAW, ktere DC podporuji primo a rozdil je u nich klidne vice nez 50%.

---

To je sice pravda, ale když ušetřené peníze vrazíš do grafické karty, získáš mnohem víc. Jakmile jsi totiž limitován grafikou (a to jsi v 90 % případů), pak je rozdíl mezi různými CPU téměř zanedbatelný.

Citace:

---

Původně odeslal Petrik

Ty aplikace, ktere DC nepodporuji a pritom by to bylo potreba, se zacinaj iprepisovat za ucelem podpory DC, viz WinRAR.

---

1) Kdo tohle přepisování zaplatí? Ty? Pokud ano, tak si DC taky koupím.
2) Kolik že výkonu navíc WinRAR přinese? Dělaly se tu nějaké testy a z nich vyplynulo, že v průměru tak 10-15 %. Jaké že je snížení frekvence kvůli druhému jádru? Není to takhle náhodou taky tak těch 20 % ? :-)

NetBurst: 3800 MHz SC vs. 3200 MHz DC
A64: 3000 MHz SC vs. 2800 MHz DC

Přičemž DC má v obou případech vyšší spotřebu.

Citace:

---

Původně odeslal THX

pre DC zoptimalizujes kompilator a ficis

---

Který kompilátor? Já žádný takový neznám.

Citace:

---

Původně odeslal THX

Skutocne optimalizacie na SSE a SSE2, take ktore mali razantny prinos vykonu, sa robili rucne.

---

V některých případech pomáhal na SSE i kompilátor. Pro určité typy struktur (zejména loopy) se to dá automatizovat a výsledky nejsou tak špatné. Optimalizace tohoto charakteru je podstatně jednodušší než pro DC.

Citace:

---

Původně odeslal THX

A co sa tyka toho programovania, myslim ze programovat viacvlaknove aplikacie nie je az o tolko tazsie ako jednovlakna.

---

Jeden myslel a vymyslel trakař. Pokud si tím nejsi jistý (nic jsi nenaprogramoval nebo o tom nemáš aspoň zcela jasnou představu), tak to nekomentuj.

Citace:

---

Původně odeslal Poofy

Ve windows ktery vetsina lidi pouziva je prechod na DC dost znat

---

Já jsem si žádného razantního rozdílu nevšimnul. Mnohem víc vidím více paměti a rychlý disk (Raptor). Jediný znatelný efekt z DC je při více zátěžových aplikacích spuštěných současně, přičemž:
1) se to dá na SC vyřešit prioritami
2) ti na to DC z dlouhodobého hlediska nepomůže, neboť multithreadová aplikace obsadí obě jádra a odezva půjde opět do kytek (schválně si zkus spustit dva zátěžové programy naráz, tak to bude vypadat, až budeš mít jeden optimalizovaný).

Citace:

---

Původně odeslal Poofy

proto Vase argumenty jsou mozna technicky spravne - ale v praxi a na nejpouzivanejsim OS je to jinak.

---

Věci jako MP3 standard jsou nezávislé na použitém OS, a proto je lhostejné, kde to spouštíš. Optimalizovat bez ztráty kvality to prostě nejde, i kdyby ses na hlavu stavěl.

Citace:

---

Původně odeslal Poofy

pokud budou chtit obstat v konkurenci budou muset optimalizovat at chteji nebo ne.

---

Oni ti to samozřejmě naúčtují, toho se neboj. Dvojnásobek práce by nikdo za stejné peníze nedělal. A ano, ladění multithreaded programů do fáze spolehlivosti může znamenat klidně i takové zatížení navíc.

Citace:

---

Původně odeslal THX

ja tvrdim zvysena kvalita, lebo novy keyframe a preto aj vacsi vysledny subor

---

Další keyframe je vyšší kvalita? :-O Takže nejvyšší kvalita je nekomprimované video o velikosti pár set GB na hodinu? A to i když bude vizuálně stejné jako komprimované bez keyframes?

Citace:

---

Původně odeslal THX

Podla mna je 851 150 viac ako 702 859 a teda mutithreaded verzia okrem toho ze bola rychlejsia, v tomto pripade este aj lepsie spakovala. Ale opat opakujem - tie rozdiely su tak male, ze su (podla mna) zanedbatelne.

---

Provedl jsem testy na víc adresářích / souborech a to i s různým počtem vláken (pomocí command-line přepínače). Výsledný soubor byl při více vláknech vždy (!) větší. BTW, co ten bug ve WinRARu 3.60, který u multithreaded komprese mohl způsobit poškození dat?

Citace:

---

Původně odeslal THX

Co ak ma problem viacero spravnych rieseni a nie len jedno?

---

Správné řešení je takové, kde je nejlepší kompresní poměr. A z onoho slova "nejlepší" zjevně plyne, že pravděpodobnost, že takových řešení bude víc, je poměrně malá.

Citace:

---

Původně odeslal THX

Intel teraz chysta nejaky novy optimalizovany kompiler pre DC.

---

Tahle vlastnost už je v jejich kompilátoru tak asi dva roky. Přínosy jsou prakticky nula.

Citace:

---

Původně odeslal THX

Chcel som tym len povedat to, ze skutocne optimalizacie, ci uz na SSE alebo DC sa nakoniec robia tak ci tak "rucne" a automatickymi optimalizaciami kompilatora mozno dosiahnut ciastocne uspechy, ale velmi to zavisi na tom, co sa kompiluje.

---

Takže nepopíráš, že optimalizace na DC bude drahá a budeš jí muset jakožto koncový uživatel zaplatit? Dále budeš muset zaplatit dražší DC CPU (víc křemíku = vyšší cena). Takže ve výsledku to bude vše třeba 3x tak drahé, přičemž ti to přinese možná 50 % výkonu navíc (když budu optimista).

vsetci sa tu opierate o argumenty, ktore zavazia pri rozhodovani mozno 1% uzivatelov. Ostatnych 99% da aj tak na marketing a svoj subjektivny pocit (pripadne kamarata mi povedal, ze...). Takze tak :roll:

Citace:

---

Původně odeslal tomase

vsetci sa tu opierate o argumenty, ktore zavazia pri rozhodovani mozno 1% uzivatelov. Ostatnych 99% da aj tak na marketing a svoj subjektivny pocit (pripadne kamarata mi povedal, ze...). Takze tak :roll:

---

Bohužel to pro ně ale znamená, že budou platit zbytečně moc. Za věci, které nejspíš nevyužijí.

Citace:

---

Původně odeslal Eagle

Bohužel to pro ně ale znamená, že budou platit zbytečně moc. Za věci, které nejspíš nevyužijí.

---

Je to cena za luxus, komfort. Naco je komu BMW 5, ked ho do prace po meste odvezie aj Felicia a rovnako rychlo?

Citace:

---

Původně odeslal tomase

vsetci sa tu opierate o argumenty, ktore zavazia pri rozhodovani mozno 1% uzivatelov. Ostatnych 99% da aj tak na marketing a svoj subjektivny pocit (pripadne kamarata mi povedal, ze...). Takze tak :roll:

---

"To borrow from a human euphemism, it is not a perfect galaxy."
-Thor, Supreme Commander of the Asgard fleet :mweheh:

Citace:

---

Původně odeslal Petrik

U vetsiny aplikaci, ktere potrebuji vysoky vykon CPU, uz podpora pro DC je dnes. Dukazem jsou ruzne profi CAD/CAM a grafika obecne.

---

prides domov z prace a pustis si pre zabavu Max/Cinemu/Mayu/Combustion ? myslim ze takto sibnutych nas je mizive mnozstvo.

Citace:

---

Původně odeslal Petrik

To se pletes, pro linux uz existuje docela hodne progamu na CAD, dokonce uz i zivotaschopne programy na vektorovou i rastrovou grafiku. Navic docela hodne vyrobcu profi aplikaci ohlasili portaci na linux.

---

budem ti vdacny ked mi najdes nieco a-la max/cinema pre linucha a PiT ti myslim ze verejne podakuje ked jemu najdes pre linucha ekvivalent Photoshopu

Citace:

---

Původně odeslal -=HaDeS=-

PiT ti myslim ze verejne podakuje ked jemu najdes pre linucha ekvivalent Photoshopu

---

pls, at sem nekdo napise ze "GIMP"
:mweheh:

Citace:

---

Původně odeslal tominek

pls, at sem nekdo napise ze "GIMP"
:mweheh:

---

GIMP

BTW. Bolo by vhodne skoncit s OT.

dobra omlouvam se za vtipek.

bylo to mysleno jako narazka na to ze existuji kvalitni bitmapove editory pro tucnakoidni system.

NEEXISTUJI

a ze by adobe zacalo sve produkty nejak portovat pod linux o tom taky nevim.

Citace:

---

Původně odeslal tominek

dobra omlouvam se za vtipek.

bylo to mysleno jako narazka na to ze existuji kvalitni bitmapove editory pro tucnakoidni system.

NEEXISTUJI

a ze by adobe zacalo sve produkty nejak portovat pod linux o tom taky nevim.

---

treba se chyti pixel ...

ale uz vazne dost ot ...