31
-
kel634 #31 Csak ne kövessék el ugyanazt a hibát mint a Microsoft... -
gettoharcos2 #30 még jó hogy nem integráljanak bele a prociba rögtön egy komplett Windowst, abból is mindjárt a 7-es verziót 
hadd szokja a pancser
Linuxot még el tudnék viselni... különösen az olyan megoldást, hogy mondjuk az alaplapi BIOS chipben frissíthető a kernel, vagy az oprendszer mag része(i)..
különösen netbookoknál lenne jó végre egy ilyesmi megoldás
Azt viszont végképp felejtsék el hogy bevezetnek egy új processzor-szabványt ami totálisan inkompatibilis visszafele eddig bármelyik (x86, 5x86, 6x86, x64 stb..) procival, megmagyarázzák , hogy ez miért lesz majd hűdejó a lúzernak, kiadják egy rakás pénzbe fog kerülni és kezdetben még csak program se lessz rá.. aztán jönnek a reklámhuszárok elkezdik pátyolgatni kijön rá vagy keményen 3 db DirectXtizenf*szomtuggyahanyas játék meg egy Mikroszoft féle operációs rencer (?) aztán már az lesz onnantól a menő, a trendi , meg a p*cs*m
-
Komolytalan #29 Egy java szervert fejlesztgetek, jelenleg 3-500Mbit/sec amit tud A/V+adat szerverként (szétkapja packetekre, framet dob ha kell, újra összerakja, adatot kinyer, feldolgoz, újat belerak) - szóval nem olyan lassú az. Persze C++ gyorsabb, asm meg még gyorsabb, de én XP alatt lefordítom, linuxos szerverre feltöltöm a fordított kódot, és megy. Ezt mondjuk C++-ban szerintem senki se csinálja meg.
A java legnagyobb baja szerintem a fatengelyes memória felépítése. Erősen multithread (adja magát, hogy külön szálra rakj sokmindent), de minden közös heapbe kakál, éppen ezért nincs benne tisztességes memória felszabadításra lehetőség (majd ha a gc úgy gondolja, vagy meghívod te kézzel, akkor esetleg lesz valami). Amikor meg több 100 MBytenyi változó jön létre másodpercenként, és kerül feldolgozás után kukába, akkor egyátalán nem mindegy, hogy egy általános, de buta gc takarítja-e a memóriát, vagy normális memória foglalás, és fordított sorrendben felszabadítás van. Jelenleg elég kellemetlen az, hogy gc elindul, egyik szál közben memóriát foglalna, dob egy out of mem exceptiont, gc felszabadít 1 gigát, és a többi szál megy tovább. Ez a megoldás az én olvasatomban a gagyi szinonímája, SUN ide vagy oda.
Szálanként külön stack kéne, és döntési lehetőség hogy stackbe vagy közös heapbe teszem a változókat. Stacken nem kell gc, szál létrehozásakor lefoglalni a megadott méretet, szál befejezésekor kidobni egyben. A heapen lehet gc, oda memóriaintenzív cuccok úgyse kerülnének, ha normális a programozó.
Zárt szabványok meg monnyanak le. -
gettoharcos2 #28 pont ezért óvom én a jónépet az előreintegrált zárt forráskódú szar szabványoktól amikről csak a jóég tudja mikor élnek vele vissza a hátad mögött:
Intel jön most a processzorával, a Microsoft a Win7-es csodájával
és egytől egyik tele lesznek integrálva trójai megfigyelőrendszerekkel, kiskapukkal, meg még talán gyárkapukkal is,amiket csak a vak nem lát, mint pl. a Vista UAC-ja és az XP-ben a SYSTEM-ként való beloggolás lehetősége.
-
gettoharcos2 #27 hogy mást ne mondjak
http://pcforum.hu/hirek/11171/Matol+torhetok+a+biztonsagosnak+hitt+Wi-Fi+halozatok+is.html
Pontosan az ilyen szabványködösítések miatt tették SZÁNDÉKOSAN törhetővé a WPA és a WPA2 szabványokon belül a PSK és TKIP kulcsolásokat, már eleve a tervezéskor.. az ilyen globálcionista titkosszolgálatos görények
Persze évekkel később kiderült, hogy törhetők és, mint a Rodolfó bácsi : figyeld a kezem, mert csalok...
na pont ezért mondom én, hogy ott az AES, ami FULL nyílt forráskódú, tehát full szájbarágósan dokumentált (pl. neten), nincs Rodolfőbácsi, meg nem csalás, ámítás, meg rizsa, meg melléködösítés pl. ha rákeresel googliban hogy mi az a tököm az a PSK, meg a TKIP...;, hanem a WPA2 +AES és egy jó hosszú kóddal, máig nem törhető és sem a közel , sem a távoljövőben SENKI, nem is fogja megtörni. -
#26
öhát tudod, hogy ez nem működik így. Wifi és blútút több ketyerében is van szerte a világon, mobilokban, munkagépekben és ezek ugyanígy a szabványos frekvenciákat kell, hogy használják ha kommunikálni szeretnének 1mással. Namármost, ha az intel elkezd valami kigondolt szabvány szerint gyártani csippeket amik semmivel sem kompatibilisek saját magukon kívül, akkor a kutya se tudja őket semmire sem használni. Nem éppen fényes üzleti fogás lenne a bevételeket nézve sztem. -
gettoharcos2 #25 "a vezetéknélküli elérést támogató megoldások, ezeket ugyanis az Intel szintén beemelné az egyes chipekbe, hogy ezzel oldja meg a számos eltérő szabvány jelentette gondokat"
miféle eltérésről csúsztatnak itt éppen irdatlan nagyot? tudtommal egy WiFi szabvány van a 802.11x ezen belül is az a/b/g kompatibilis egymással és én még nem nagyon láttam volna hogy ezen belül ne működött volna eszköz egymással együtt TÖKÉLETESEN... de neeem intelnek ez kevés és a jól bevált szabványok helyett most éppen monopolizálni akarja a saját SZAR, globálcionista diktatúra által megrendelt szabványát, amelyet csak ők tudnak megfigyelni bármikor bárhonnan bárkit, akinek a jövőben ilyen vezetéknélküli megoldása lesz. -
#24
Igen, a gyengén megírt vsti-k elmaradnak minőségben a professzionális hardware-s szintetizátoroktól, de én professzionális vsti-ket haszálok és több (befutott) embert is ismerek akik nagyrész vagy kizárólag csak vsti ket használnak pont a flexibilitásuk és a könnyű kezelhezőségük miatt. A végeredmény magáért beszél általában (ha gondolod cserélhetünk is pár munkát), de gyakorlatilag nincs különbség hangzásban manapság már egy jól megírt vsti és a hardware között, és az előbbiből annyit nyit az ember 1x-re meg amennyit a gépe elbir, míg hardware-ból csak 1 van és max kirendereléssel tudja megoldani ha több helyen szeretné megszólaltatni. Hozzá kell még tennem, hogy természetesen mint ahogy a hardware is, magus a vsti-k is nagyon szépen fejlődnek az idő múlásával, de a vsti-knél még jó pont, hogy az új funkciók 1update segítségével elérhetőek, még ugye a hardware adott és nehezebb dolga van az embernek ha újítani szeretne. -
gettoharcos2 #23 a funkciókat kenjék a hajukra . különösen, ha nem kompatibilis leaglább 110%-ig visszafele a régebbi processzorokkal (x86) -
eax #22 "a java nem azért lassabb mert multiplatform hanem azért mert interpretálva soronként hajtja végig a kódot"
Fogalom nelkul. -
jozzee #21 Zenei felhasználásra, ha mindent egy gépen akarsz megoldani valóban nincs az a teljesítmény ami elég, ezt én is tapasztaltam, habár én mamár visszatértem a hardveres valódi szintikre(PCn csak workstation host fut ami vezérli őket) és azért tegyük hozzá, hogy hangszintézist komolyabb helyeken valódi, professzionális szintetizátorokkal oldják meg, nem véletlenül.....és elsősorban nem a nagy hardverigény miatt, hanem profi végeredményt a gyengén megírt vsti plug in ektől senki se várjon, pláne ha még ezekből se képes kellő mennyiséget futtatni egy vagy több gép vagy ha tud akkor viszont a gond az, hogy ezek minőségbe így is elmaradnak egy profi szintitől..... -
#20
Nem a mezei felhasználásra gondoltam mint a netezés, zenehallgatás netán MSword, azt már a mai mobilokkal is meg tudod oldani, hanem munkára. Ebben a pillanatban zenével foglalkozok és van, hogy 50-60+ vsti-t is szeretnék kezelni 1 számban realtime. Ide kell a teljesítmény, főleg ha komplexebbek a hangok és több oscillator modulálja 1mást, időben változó envelope-okkal. A host programom támogatja a multi core technológiát, már vagy 3+ éve megvan az e6300(1.8ghz) procim szénnéhúzva ~3.4ghz ig, de még ígyis van hogy erőforrás korlátokba ütközöm és örülnék ha többszörös teljesítményem lenne ami biztosítaná a kényelmes munkát minden helyzetben. Ez csak 1 személyes példa volt, de számos munkában örülnének az emberek a jóval nagyobb teljesítménynek mint pl az animálás, renderelés, kompresszáló technológiák, video munkálatok és lehetne sorolni. -
Myron #19 a java nem azért lassabb mert multiplatform hanem azért mert interpretálva soronként hajtja végig a kódot. C# is multiplatform elvileg (az más kérdés h basznak keretrendszert csinálni linuxra meg mac-re (habár a mono project egy kezdeteleges megoldás)), de az azért gyorsabb mert első futás után a köztes kódból natív kód lesz, és ezután már ugyan olyan gyors mintha natívba lett volna írva. szóval csak az első futáskor lassabb, de az ngen.exe -vel legenerálhatjuk előre a natív kódot és akkor még elsőre se lassabb.
lehet h még ekkor is lassabb esetenként a kód futása, de az csak azért van mert van benne csomó fincsi dolog pl reflexió meg ilyenek amik lassabban futnak -
Myron #18 hát órajelet már kb 3 éve nem emeltek szal nemtom mi itt a meglepetés h most se fognak :D -
#17
Miért, most mire kell az a hatalmas teljesítmény? Csak mert én egy mezei amd athlon1200 mhz cpus pcvel bőven elvagyok, 3d játékon és baromira hd filmeken kívül nem is nagyon van olyan dolog amire kevés lenne. -
#16
Bloatware procikat akarnak fejleszteni a sebesebbek helyett? :O
Nem kösz, akinek sebességre van szüksége annak édeskevés ha azt kapja hogy: gyorsabbak ugyan nem, de van belénk integrálva blútút, wifi és hangkártya... -
torcipepe #15 azt látnám már egyszer, hogy egy processzor a terhelés függvényében automatikusan változtassa a szorzóját. az Atom prociknál ezt be lehetett volna vetni. egy kis CS után új értelmet nyer a hotkey kifejezés: a proci feletti gombok nagyon felmelegednek.
lényegében ami eddig az alaplapon volt, az belekerülhet a prociba, de feleslegesen zsúfolnak mindent egyetlen helyre. a sok I/O csatlakozó között elférnek. ehelyett akarnak egy tenyérnyi alaplapot, amire ha rádugsz mindenféle kábelt, nem lesz hely.
én inkább olyan dolgokat építenék a prociba, mint pl hw-s kodekek, amik az asztali lejátszókban és hifikben vannak. mert az elég csúnya, hogy a drága windows nem játsza le a DVD filmet, ami egy mezei ezeréves lejátszóban elfut. -
Dr Adee #14 Értelmetlen az alacsony szintű programozás ősrégi nyelvekkel, ott ahol folyamatosan fejlődik a hardwer és már most sokkal többre képes mint amit a programok kihasználni képesek. éppen a virtuális gépek amik felgyorsíthatják a programokat. -
#13
java nem azért "lassú" mert optimalizálatlan, hanem ezt a multiplatform léte miatt kellett beáldozni, ha érdekel olvass utána.
C# meg persze lassúbb, mint egy ansiC vagy asm, de ez megint csak az absztrakciós szint emelésével jár. -
barii #12 ...de manapság nem divat a szoftver optimalizálás, legjobb példa erre a Java és a C# -
waterman #11 mi baj lenne azzal, hogy mindent egybe raknak? semmi. a legtöbb embernek az lenne a legjobb, ha a számítógép még kenyérpirító méretű sem lenne és tenné csak a dolgát.
különben most is minden egyben van.. ha intelt veszel, akkor csak ahhoz illő alaplapot, ahhoz illő chipkészletet veszel. amd-nél ugyanez, ma sincs akkora választási lehetőségünk. 10 év múlva meg majd bemész a boltba és kérsz egy amd procit, és a típusszámmal már minden el is dőlt. nincs ezzel semmi gond, mert a teljesítményük meg növekszik. -
#10
20év és beléd is ültetik!! 
-
#9
hát azért szar lesz az ha mindent egybe raknak 1 valami megfő aztán akkor lényegébe minden mehet a kukába... lassan konzolosítani akarják a gépeket vagy mi a szösz?:) -
feamatar #8 add1:minek tovább optimalizálni, ha a vas gyorsabban fejlődik mint a szoftver... verhetnek milliókat az optimalizálásba, és félév melót, ha közben értelmetlenné válik a plussz erőfeszítés. Ezt mérlegelnie kell a producernek, meg a managereknek.
add2: lehet úgy is játékot fejleszeteni, hogy nem éri meg, de annak nem is olyan hosszú távú eredményeit nem kell feszegetnem...
add3: fix hardware esetén(lásd konzolok), megfigyelhető az egyre nagyobb optimalizálás. De a programok méretének és komplexitásának növekedésével meg kell érteni, hogy a low-level optimalizálást a fordítóra kell bízni(hisz azok is fejlődtek az évek alatt) és magasabb szintű optimalizálásban kell gondolkodni(ugyebár több szálúsítás, párhuzamosítás) -
#7
igen, de manapság nem divat a szoftver optimalizálás, legjobb példa erre a Crysis. Nincs az a csúcs vas, amin tökéletesen elfutna. Mert még a takarító gizi néni is tudta, h még legalább 1 év kellett volna hozzá, h optimalizáltan kiadhassák, de hát ugyebár akkor nem üt akkorát, és nem lehet vele annyit kaszálni... Ezért van az, h még mindig nincs megfelelő mennyiségü szoftver 64bit-re, és több magra optimalizálva, pedig a technológia már évek óta adott. -
bigjoe #6 Hát lassan itt az ideje.. Sztem, ha jobban odafigyelnének az operációs rendszerek fejlesztésére és a programok optimalitására még sok is a mai rendszerek teljesítménye. A játékra meg ott vannak a konzolok..
Évekkel ezelőtt az ELTE-n egy tanár jó nagy prímet talált viszonylag primitív hardverral megverve sokkal nagyobb teljesítményű gépeket.. Annyi volt a trükk, hogy jó programot irt (és lement regiszter szintre).. -
Doktor Kotász #5 Az, hogy egy számítógép perifériákból áll, az csak egy szükséges kompromisszum.
Én eltudnék képzelni rétegesen felépülő szilícium lapkát, amiben minden benne van. Pár giga gyors operatív memória, pár terrabájt háttértár, mindenféle I/O vezérlő. Szóval nem egy sík felületen terülnének el tranzisztorok a szilíciumkristályon, hanem tömbszerűen 3D-ben. -
kisb92 #4 És így vész el a modularitás, feladva a PC alapelveit, a szabadságot, minden egyes alkatrész ára pedig az Intelnek megy, mert már a WiFit és minden szart megveszel, hiába akarsz egy sima processzort... -
#3
3G? Milyen szép is lesz, amikor a prociba helyezett telefonkártyát ropogósra süti egy jó kis fps játék :DDDD -
#2
Csak nehogy a terroristák kezébe kerüljön... -
balee66 #1 Én tudom a megoldást... TOR!! :-D