AMD konci s x86?!?

Hfmcons hfmcons na gmail.com
Středa Listopad 30 09:39:48 CET 2011


Rovněž si dovolím link na celkem zajímavý článek.
http://www.ddworld.cz/aktuality/procesory-cpu/amd-neopousti-pc-platformu-ale-konkurenci-prozatim-top-procesorum-intel-necekejte.html

Snad se odkaz nezalomí.
S pozdravem,
		Miloš Dašek


Dne 30.11.2011 8:57, Marek Sembol napsal(a):
> Dovolim si lehce vstoupit do diskuze:)
> Nejdriv se vyjadrim k tomu, ze "po prepsani do .NET je to pooooomale":
> zde je problem prekvapivy - programovani v .NET je (zdanlive) prilis
> jednoduche a tak si kazdy BFU mysli, ze je Pan Programator, Ten
> Nejchytrejsi a tak. Kdysi, kdyz to bylo v C tak clovek prece jen musel
> neco malo umet. Ted to splaca v .NET kdekdo a vysledky byvaji obcas
> tristni:( Sam jsem zazil nasledujici situaci ve zdrojaku (VB.NET).
> Funkce GetCount byla deklarovana, ze vraci String! Uvnitr se samo
> vracelo cislo (takze chudak framework si musel Int32 prekonvertovat do
> textove podoby, naalokovat na to pamet, inicializovat objekt a tak).
> No a na strane odkud se to volalo byl vysledek (zcela logicky)
> prirazen do Int32 (takze opet si musel framework rozparsovat ten
> String co dostal vcetne vsech kontrol zda to opravdu cislo
> predstavuje). Ja rikam: neni problem v .NET, ale v programatorech (a
> tech co se za ne vydavaj)
>
> Proc "neni calc v .NET"? Nevim co k tomu M$ vedlo. Jeden velmi dobry
> duvod mne napada: mne osobne se nezda .NET prilis vhodny na malicke
> utilitky (kterou calc bezesporu je). Nemile na .NET je to, ze i
> drobnost naroste v pameti do nechutnych rozmeru. U vetsiny sluzeb to
> neni problem (vetsinou to neni jen "mala utilitka"). U baliku typu
> Visual Studio ci Office to taky neni problem (jestli to bere 60M nebo
> 65M uz neni takove nestesti). Horsi je to u tech drobnosti (clovek ma
> rozjeto bezne 20 "drobnosti" a kdyz kazda bere 20M misto 2M tak je to
> nestesti). Ale treba byl duvod ten, ze to opravdu prislo jednoduzsi M$
> jen "trochu prepsat stavajici kod".
>
> Proc je .NET prinosem?
> -automaticke uvolnovani pameti. Ja vim, opravdovi programatori to
> nepotrebuji:) Ale kdo z nas se nikdy netrapil s tim, ze mu aplikace
> uzirala.... Mnozi z nas resili problemy ne s "neuvolnovanim" pameti,
> ale s rozfragmentovanim pameti (a to byvalo jeste horsi). U slozitych
> datovych struktur jsme venovali hromadu usili pocitani referenci na
> naalokovanou pamet a travili bezesne noci kde jsme ji zapomneli zvysit
> (a aplikace padala) ci snizit (a zrala pamet).
> -kontrola bufferu. Komu z nas se nestalo, ze si "cmaral po pameti"
> (vetsinou psal par bajtu za naalokovane pole) a ono to pak "nekdy
> spadlo". Hodne neprijemne se to hledalo. Ja sam jsem vydelal celkem
> dobre penize u nekolika externich firem kdyz jsem jim pomahal s
> hledanim techto problemu. Podobne problemy s bezpecnostnimi derami
> typu "podteceni/preteceni bufferu". Techy taky bylo az az...
> -zavedeni atributu ohromne zjednodusilo a zprehlednilo hodne problemu
> -reflexe taktez
> -velmi zajimava je nezavislost na CPU (mne osobne stejna aplikace bezi
> na 64bit OS jako 64bit, na x86 bezi jako 32bit a na par prenosnych
> terminalech bezi ani nevim na jakem CPU (asi ARM? bez zaruky). Vse
> stejny EXE! Teoreticky by asi bezela i na Linuxu s Mono...
> -hodne veci se zjednodusilo (napr. lokalizace)
> Takhle by slo pokracovat asi jeste dlouho. ANO, prinasi i radu
> nevyhod, to nepopiram:)
>
> Marek
>
>
>
> 2011/11/30 Miroslav Šinko<sinkomiro na gmail.com>:
>> On 29. 11. 2011 20:44, Petr Zahradnik wrote:
>>>
>>> Od Microsoftu je toho v .NET napsáno mnoho a mnoho. Že jádro
>>> operačního systému není napsáno v .NET, to je rozumné, že aplikace
>>> typu Kalkulačka nejsou přepsané do .NET, to mi nevadí a je to i
>>> logické.
>>
>> Toto ma zaujalo. Aby som uviedol suvislosti.. som programator, vacsinou
>> robim ANSI C procesy pod Win (teda okrem startupu by mali byt platformovo
>> nezavisle, ale na nicom inom ako Win32 a WinCE testovane neboli), poznam
>> Win32API (pred nejakymi rokmi som vyvijal Win aplikacie, t.j. GUI, atd je mi
>> celkom doverne zname). Naopak Linux nepoznam takmer vobec (ako BFU som
>> chvilu cez GUI Debianu cosi obsluhoval, spustal, apod).
>>
>> Ale nerozumiem nazoru, ze to ze Kalkulacka nie je v .NET, je logicke. Na
>> Win7 je prave ta kalkulacka uplne ina, ako na W2k/XP (este aj na W95 snad
>> bola rovnaka). T.j. pre Win7 ju prepisovali. Preco nie .NET? A preco je to
>> logicke?
>>
>> Zaverecne suvislossti: podla mna je .NET blbost (ok, mozno silne slovo,
>> subjektivny nazor, ale stojim si za nim). Prave preto, ze poznam WinAPI, mi
>> .NET nesedi. Co prinas nove? Kniznice? Daju sa urobit aj pre WinAPI. Mensie
>> naroky na programatorov? OK... Ale za cenu vyssich narokov na RAM vykon PC
>> atd... preco? naco? aj zabudanie uvolnovania buffrov programatormi sa da
>> riesit kniznicne. Ked si za nim MS tak stoji, preco aj tu kalkulku neurobila
>> v nom? Na tak primitivnej aplikacii by to vobec, ale vobec nevadilo
>> (spomalenie by nebolo na sucasnych PC pozorovatelne).
>> Sam tiez nepoznam "nic viditelne" od MS napisane v .NET. Pozrime sa inde.
>> Take ovladace ATI kariet. Kedysi bol Control Panel pisany vo WinPAI...
>> click, click, OK a bolo. Potom prisiel .NET Control Center.
>> 1) nesiel spustit, ziadal instalaciu .NET Framework. OK, dnes to ma kazdy,
>> ale vtedy to bol krok navyse (a par 10-tok MB cohosi na HDD)..
>> 2) click................wait............aaa nieco nabehlo....
>> click..........wait..... no a tak. OK na sucasnych strojoch wait=1s, ale kde
>> je prinos? Preco by nesiel ovladaci panel aj dnes napisat jednoducho a rycho
>> pri zachovani funkcnosti?
>>
>> Tot votazky. A este raz opakujem - som vyvojar pod Windows.
>>
>> miro
>>
>>
>>> Že má Microsoft tuny kódu už napsaného a chce ho využít, to
>>> je také logické. K čemu by bylo, kdyby ty malé aplikace, které jsou
>>> součástí operačního systému, jsou tam už roky, jsou spolehlivé a ten
>>> kód existuje, někdo přepisoval?
>>




Další informace o konferenci Hw-list