Vlákno názorů k článku
Snižování prodejů osobních počítačů znamená v této chvíli pro Intel velký problém
od Petr M - A vůbec, x86 je tak zprzněná a opatchovaná...
-
Petr M (neregistrovaný)
A vůbec, x86 je tak zprzněná a opatchovaná architektura (16b s 20b segmentovanou adresou na začátku, CISC simulovaný RISCem, rozšíření na 32b a pak na 64b, dolepování paralalního provádění instrukcí, SSE, MMX,... , připlácávání cache,...), že už by bylo fajn se po těch desítkách let obscénností na ni vybodnout a používat něco o trochu míň překombinovanýho. PPC se, bohužel, nechytlo, až teď se tlačí ke slovu ARM.
Že se s x86 do muzea nejspíš sveze i Intel je celkem jasný.
-
Nemo (neregistrovaný)
Trosku pletiete hrusky s jablkami. Od ARMu nikto doteraz nechcel aby na tom bezali desktop aplikacie natoz nejake serverove veci. Tak isto AMRacke SoCy sa predavaju za par $ ako teple rozky ale Itanium bol uplne iny cenovy segment. A tak isto od ARMu ani nikto neocakaval ze tam budu bezat Windowsy a spustim si desktopovy Office a podobne. Na ARMe sa kompletne nastartoval novy ekosystem OS aj aplikacii ale to akosi nebolo uplne mozne pri Itaniu.
-
Lael Ophir (neregistrovaný)
Jasně, to bude tím. Akorát že Windows Itanium (IA-64) umožňují běžet 32-bitové x86 aplikace. První verze IA-64 procesorů měly CPU mode, který umožnil provádět většinu x86 instrukcí (ty zbylé se triviálně emulovaly). Problémem byl slabý výkon. Pokud jste měl jen x86 aplikaci, běžela na IA-64 s podobným výkonem, jako na tehdejším desktopovém HW. A protože nativních IA64 aplikací bylo málo, nemělo moc smysl kupovat poměrně drahé stroje s Itaniem, abyste na nich běžel x86 SW cca stejně rychle, jako na levném x86 desktopu.
Později Intel vyvinul emulátor (IA-32 Execution Layer), který překládá x86 kód na IA-64. Bylo to kupodivu rychlejší, než x86 mód IA-64 procesorů. Podobné překladače umožňují běžet na Itaniu aplikace pro PA-RISC, MIPS a SPARC.
-
Lael Ophir (neregistrovaný)
To bych neřekl. IA-64 je kvalitní architektura. Problém je v tom, že je pro ní minimum nativního SW, a při emulaci instrukční sady je ten výkon tak nízký, že nemá smysl kupovat drahé Itanium.
Je to tedy problém setrvačnosti trhu. MS to zjistil, když kdysi portoval Windows NT na PowerPC, Alpha AXP a MIPS. S Intelem pak vyzkoušeli, že se neprodává ani port na IA-64, přestože je IA-64 od Intelu a lze na něm provozovat x86 aplikace.
-
Nemo (neregistrovaný)
Prave naopak Itanium bola velmi zaujimava architektura a v niektorych veciach docela pokrokova. Ostatne by som sa nedivil keby z mnohych veci co vyvynuli pre Itanium, Intel zil a pouzival aj v dnesnych CPU. Problemom bolo, ako to uz bolo spomenute, ze bol nezaujem zo strany vyvjarov SW a tym aj malo nativnych aplikacii, a preto Intel musel pritupit k emulacii cim sa samozrejme stracala vyhoda Itania.
-
Muzeum (neregistrovaný)
honeywell holt není dobrej oddíl.
- soudobá segmentace na x86 nemá 20 bitů, ale nejméně 43 bitů
- soudobá segmentace na x86 se nepoužívá
- na x64 segmentace vůbec není
- CISC realizovaný RISCem je konkurenční výhoda oproti RISC platformám
- přidávání koprocesorů SSE, MMX a spol je přirozený vývoj u všech procesorů, stejně to probíhalo na ARMu
- Potenciál ARM je dávno vyčerpaný, táhne ho ke dnu kotva RISC, která neumožňuje další rozvoj
- Budoucnost patří Intelu, nikoliv ARMu, v telefonech a tabletech bude normální Intel Atom s plnohodnotným OS jako Windows nebo Linux a žádné náhražky jako Android nebo iOS. -
Lael Ophir (neregistrovaný)
Telefony chtějí trochu jiné GUI, jiný aplikační model, X11 také není moc dobrý nápad, nemluvě o power managementu... Pokud jde o drivery, tak to nebude o "zkurvenosti" chipů. Výrobci drivery rádi napíšou, pokud za to dostanou zaplaceno, a nebudete je nutit uvolnit kód pod GPL.
-
Petr M (neregistrovaný)
Ne, nezůstalo by hodně netknutýho kódu, protože hodně kódu nezohleňuje výpadky připojení, uspání na delší dobu, power management atd.
Ne, power management není věc ovladačů. Je to věc jádra, protože jenom a jenom jádro
- přiděluje čas procesům a má právo odstavit od lizu nenažranou aplikaci
- může ovladačům posílat zprávu o stavu systému
- může vyhodnotit, co se dá vypnout - těžko bude třeba WiFi objektivně rozhodovat o tom, že se obětuje pro GPS apod., pokud navíc nemá přístup k ovladačům pro smart battery
- posílá jádro procesoru do spánku, pokud není co dělat
Na ovladačích je fakticky jenom podpora signálů pro regulaci spotřeby a pro odpojení. -
Lael Ophir (neregistrovaný)
Koukněte se například na multitasking na Windows Phone, iOS a Adnroidu. V podstatě mají společné to, že aplikace kvůli úspoře energie nemá zaručený běh, pokud neběží na popředí. Dalším rozdílem je bezpečnost. Všechny tři systémy mají (nebo se snaží o) obdobu MAC, a nestaví na tradičním konceptu "aplikace může všechno, na co má právo uživatel".
Jak ukazuje desktopový Linux, dokumentace pro výrobu kvalitních ovladačů nestačí - ještě je potřeba mít lidi, HW, důsledně provádět testy atd. Navíc se výrobcům nechce dávat z ruky know how, které mnohdy dali veliké peníze.
-
Petr M (neregistrovaný)
Jo, příkladů by se našlo... Nechci napovídat tomu, co tohle téma nahodil, ale kdysi jsem měl analogovou TV kartu. Jela dobře, ale měli zmršený softy, tak jsem hledal náhradu. Našel jsem, nainstaloval, všechno perfektně jelo, až na ten zvuk, ten pro jistotu nejel vůbec. Příčina byla:
- použili standardní čip na digitalizaci videa (BT818 nebo tak nějak), proto jel perfektně obraz
- karta nepodporovala interně audio, to bylo prosmyčkováno do linkovýho vstupu zvukovky
- nějaký šmoula nechtěl vypínat zvuk standardně na zvukovce, pokud to nehrálo, a dal tam přepínač z 4053, který jako default táhnul audio výstup do země a připojil ho ve chvíli, kdy jejich soft poslal povel... A s cizím softem to najednou bylo bez zvuku.Takže brouk byl proklemován, alternativní soft standardně mutoval linkový vstup a všechno bylo v pohodě...
-
Lael Ophir (neregistrovaný)
A co je konkrétně na takovém HW špatně? Výrobce dodává HW a driver, a funguje to. Nikde přece není psáno, že TV karta nemůže vypínat zvuk interně. Vy pouze nesprávně předpokládáte, že je HW implementovaný nějakým konkrétním způsobem. Samozřejmě byste měl pro komunikaci s HW použít driver.
-
mhi (neregistrovaný)
S poslednimi dvema odrazkami naprosto nesouhlasim. Windows ani GNU/Linux (ve smyslu uziv. rozhrani) bych na telefon rozhodne nechtel, zrejme bych to nechtel ani na tablet. Linux pouzivam denne, jako system se mi moc libi, ale uzivatelska privetivost velmi pokulhava.
Nesouhlasim ani s RISCem, ale i tak: ARM ma obrovskou vyhodu low-cost SoC, to Intel bude mit opravdu velmi tezko. Pokud tady budou ruzne MTK, Allwinnery apod., je ARM naprosto jasnou volbou pro armadu cinanu kompletujicich jakekoliv consumer zarizeni.
-
Karel (neregistrovaný)
Ta výhoda low-cost SoC je právě jeden problém. ARM má v rukávu plno dalších triků, kam to posunout dál. Jenže to znamená nekompatibilitu s mraky SoC, navíc vyráběných desítkami firem, se kterými se těžko dohodnout. Mají obrovskou setrvačnost a jakýkoliv pohyb kupředu je pro ně těžší a těžší.
Největším strašákem je pak možnost, že se objeví majoritní výrobce, který se vyprdne na inovace od ARMu a bude několik let chrlit jen drobné variace některého modelu za tak nehorázně nízkou cenu, že se prostě těch pár let nic jiného do consumer zařízení dávat nebude. Pak by se mohlo stát, že ARM "zaspí dobu", aniž by vlastně sám zaspal. Někteří lidé si myslí, že se to dokonce už děje.
-
strepty (neregistrovaný)
Pre telefony mozu robit evoluciu cipu rychlejsie ako pre PC lebo mobil ma zivotnost 2 roky, od pc cakam aspom 5 rokov.
Stale je tu ale problem ze dnesne army su vykonovo na urovni pentia, ak sa ma zvysovat vykon podla Mohrovho zakona tak tu mame prechodnu dobu 10 rokov kedy sa uz nebudu robit x86 vo velkom (tj. budu drahe) a army nebudu stihat byt na serveroch. Kam sa potom tie sluzby co bezia v kazdej firmicke na serveroch stratia? Mozno nastane doba cloudu.
-
Petr M (neregistrovaný)
A čemu ten nižší výkon vadí? Na ARMech (obvykle) nejedou widle. A s GUI se dalo pracovat i na 486DX2. Moje první PC s Widlema bylo 6x86MX@233MHz s 4MB RAM a šlo tam skoro všechno (pravda, převod multimédií běžel v noci), ale na protokoly do školy a tak nebyl problém V tomto ohledu je i mobil výkonnější, než tehdejší PC. pro BFU je to víc než dostačující výkon.
Firmy a korporátní sféra si PC udrží ještě relativně dlouho. Spíš to tam bude o optimalizaci nákladů. A proč vlastně musí být ve skříni jeden supervýkonný drahý stroj s velkým odběrem, když je možnost tam mít low cost hloupý chassis a do něho a běhu strkat procesorový karty, který zvládnou elementární úkoly - jedna bude posílat obrázky, druhá podrží v cache statický obsah, dalších pět odbaví po 10 požadavcích na PHP... A když bude potřeba vyšší výkon, stačí přikoupit pár levných karet. Není pak potřeba investovat jednorázově do supervýkonnýho serveru, část se toho dá při menší zátěži vypnout a během minuty nahodit z FLASH do provozu a když to bude máít ještě navíc zajímavou spotřebu...
-
Nemo (neregistrovaný)
Comu vadi nizsi vykon ? No v pripade ARMu napriklad pod iOS prakticky nicomu. Tam to vcelku svizne zvlada dvojadro na 1GHz s 1GB RAM. Ale uz taky Android je na tom tragicky, kde sa obcas zapoti aj 4 jardo na vyssich taktoch s 2GB RAM. A nemam iluziu ze bude horsie. Nuz a vzhladom na to ze prave Android sa tlaci ako dominantny mobilny os, netreba nic dodavat.
Co sa tyka desktopov tak neni cely svet len nejaky blbi cloud a web requesty na server/db koli nejakej sprostej office web aplikacii. Stale je dost aplikacii kde je potrebny hruby vykon na desktope a niesu to ani nejake obskurne zalezitosti. -
Nemo (neregistrovaný)
Ale ved to sa uz deje. MediaTek a podobny chrlia ARM SoCy vo velkych kvantach za smiesne ceny a bezne tlacia do tabletov/telefonov z dnesneho pohladu uz pomale ARM Cortex A7. Pritom uz je tu davno CortexA9 a A15 a pomali sa presadzuje 64bit A53/A57. V podstate nebyt Applu ktory to tak trochu taha, co sa tyka highendu (lebo sa mu to vrati) tak ten pokrok bol este pomalsi. A ani sa tomu neda divit, ved pri tych malych marziach je otazne ci sa vobec vyrobcom/vyvojarom vracaju naklady na vyvoj. Im by vobec nevadilo keby sa dana architektura pradavala o par rokov dlhsie, aby na tom aj zarobili.
-
Muzeum (neregistrovaný)
Není moc co rozvádět, to jsou jasné fakta. RISC všeobecně dojelo na soudobé zaostávání rychlostí pamětí za rychlostí procesorů a rychlost dneska stojí a padá na hustotě kódu, která je u CISC mnohem vyšší. Potenciál ARM jako typického představitele RISC se vyčerpal s nutností přechodu na 64-bit, kde už tak nízká hustota kódu je ještě mnohem nižší. ARM jistě nezanikne, ale v telefonech a tabletech nebude.
-
mhi (neregistrovaný)
Jak myslite. Ja to moc jako dukaz nevidim. Ano, problem hustoty kodu zde je a CISC je na tom v mnoha pripadech lepe (v drtive vetsine dokonce, mnohdy ale ne o moc), otazkou je to, zda si zakaznik kupuje zarizeni kvuli tomu, ze kod je hodne husty. Ja si telefon kupuji kvuli telefonovani, vydrzi baterky, aplikacim co tam jdou spustit a zejmena jednoduchosti pouziti. To jestli se cile na HW urovni (rychlost a spotreba) dosahne tim, ze procesor bude maly a efektivni a bude mit velkou cache, nebo to bude moloch se supervykonem ale velkou spotrebou a velkou baterkou je mi jedno. Cenu to ale ovlivni a ta evidentne rozhoduje.
S temi 10nm nize zapominate na to, ze ARM take nespi, takze oni se take "zmensuji".
Kdo chvíli stál, již stojí opodál.
-
Radovan (neregistrovaný)
"soudobé zaostávání rychlostí pamětí za rychlostí procesorů"
Řekl bych že tohle bylo soudobé někdy kolem roku 1960, cache to celkem úspěšně řeší. Teď spíš než paměti zaostávají procesory ve zrychlování, nějak se to honění za frekvencí zabrzdilo...
Kromě toho není problém mít víc instrukcí v jednom slově, s ideou RISC se to naopak docela dobře doplňuje, takže v budoucnosti se 64 bity problém u ARMu nevidím.A u toho prosazování bych místo slova bohužel použil spíš bohudík, Intel toho za ty desítky let zprznil už dost, je načase poskytnout prostor jiným.
-
j (neregistrovaný)
Pamatuju casy, kdy intel tvrdil, ze do 2-3 let bude vyrabet 10GHz CPU. A ... kde nic tu nic ... ;D potiz je, ze se v poslednich rekneme 10ti letech dospelo na samotne fyzikalni hranice - jak co do frekvenci, tak co do hustoty/zmensovani technologii. Ne ze by to neslo dal vubec, ale postup je pomaly a nevnimatelny, zato naklady na kazdy dasli kousek vykonu rostou a rostou ...
Bejvaly casy, kdy si uzivatel na rok, ci dva starem HW uz temer nic nespustil, pripadne nakup noveho HW vnimal jako vyraznou zmenu a narust vykonu. Dneska pokud nekdo vymeni 5let stary stroj za zbrusu novy ... tak nepozna temer nic.
-
Karel (neregistrovaný)
Ty časy jsou tu stále. Ale rozmělnilo se to tím, že:
1. Máme několik výkonnostních kategorií
2. Programy se umí škálovat
3. Plno programů už nemá jak vyšší výkon využítTo první znamená velký rozptyl (místo low endu mohu koupit middle class s trojnásobným výkonem) a to druhé možnost kompromisu (nižší detaily ve hře, menší složitost scény, nižší rozlišení videa). No a poslední bod popisuje stav, kdy nová auta dokáží jet rychlostí až 500km/h, ale na okreskách, kudy jezdíte, to nemáte jak využít.
Díky tomu všemu HW opticky nezastarává tak rychle, jako dříve. Ale pokud se věnujete grafice, videu, hrajete hry, věnujete se simulacím apod., tak rozdíl mezi současným HW a tím 5 let starým vidíte.
-
Lael Ophir (neregistrovaný)
3. Tak aplikaci přepíšeme do JavaScriptu, a ono to ten CPU sežere.
Podle mě se celé Wintel soukolí poněkud zadrhlo už s příchodem netbooků, které později nahradily tablety. Wintel s překvapením zjistil, že ačkoliv Moore's law dál platí (za stejné peníze koupíte za 18 měsíců dvojnásobný výkon), zákazníci koupí daleko víc HW, když je cena nižší. Následně MS přestal zvyšovat HW nároky Windows, aby mu neutíkaly tržby, a proces výměny HW u zákazníků se výrazně zpomalil.
-
SB (neregistrovaný)
To je taky důvodem, proč se místo do výšky muselo začít přecházet na šířku - paralelizaci. Před 10 lety se na paralelní zpracování dat na osobních počítačích sralo, nikoho to nezajímalo.
Ano, počítače jsou dnes tak rychlé a obsažné, že má i Microsoft problém je zajebat bordelem. Důsledkem je propad prodejů PC, to se ale dalo čekat. -
Karel (neregistrovaný)
Z jistého úhlu pohledu se dá CISC považovat za "vyšší jazyk" a "CISC realizovaná RISCem" za interpretter. Ta podstatná vlastnost je ta, že se ten interpretter zlepšuje, takže dnešní generace procesoru dokáže starý CISC kód vykonávat efektivněji.
Pokud dostanete kód pro RISC optimalizovaný na nějakou starší architekturu, pak s tím moc nenaděláte a musíte ho vykonat. Máte sice škálu možností, jak se s tím vypořádat lépe (více pipelines atd.), ovšem pokud dostanete kód pro CISC, tak těch možností máte krapet více.
Připomínku o vyčerpaném potenciálu kvůli RISC ale také nechápu.
-
Petr M (neregistrovaný)
Když už řešíte hyustotu kódu, měl by jste se podívat na instrukční sadu. Víte řeba o tom, že ARM používá v 32b módu horní bity jako podmínku, kdy se provede instrukce? Takže tím, že tu instrukci podmíním a nemusím ji přeskakovat, dosáhnu toho, že
- nemusím zahazovat kvůli skoku obsah pipeline
- můžu zredukovat predikci skoků
- ušetřím si jednu instrukci (dvě při if-else nebo ternárním operátoru)Jsou situace, kde se to opravdu hodí, jinde je zase efektivnější THUMB. Ale dá se to přepnout za běhu. Takže nic není tak černobílý.
RISC vede co do rychlosti, CISC co do složitosti řadiče, nerovnoměrnosti délky instrukcí atd. Každý je lepší na něco jinýho - třeba DSP jsou většinou RISC nebo jeho modifikace. V tomhle je snaha o superpočítač na x86 v Ostravě komická (jo, uznávám, má to hodně velký frekvence, ale neefektivně využívaný. Ale v tomhle oboru se počítají PFLOPy).
A navíc, ARM SoC má ve standardu věci jako bus matrix - ne jedna, ale řada sběrnic a na čipu se tak děje několik věcí najednou. Třeba procesor nastavuje periferku, jiný systém by čekal. Ale procesor má kód v I cache a sběrnici potřebuje jenom na komunikaci s periferkou, takže jiný master (třeba grafika nebo USB host nebo MAC) se připojí ve stejné chvíli k RAMce a sosá klidně data. Zkuste to předhonit s necachovaným CISCem s jednou sběrnicí, který valí na trojnásobné frekvenci.
Prostě výkon systému (datová propustnost,...) nestojí na nanometrech, megahertzích a podobných blbostech. Strojí na tom, jak moc se při vývoji myslelo a jak moc byl autor svázaný minulostí. A to závaží minulosti je, chtě nechtě, u x86 moc těžký.
-
Petr M (neregistrovaný)
Tak tak, neotestovatelný, velký a žravý.
IA64 ani PPC se nechytly hlavně proto, protože byly ve stejným produktu jako x86 - v PC. A nebylo by moc masochystů, kteří by to na sobě zkoušeli a řešili problémy s komaptibilitou... Teď ARM uspěl, ale proto, že je to nová třída zařízení, kterou BFU chtějí a která byla vytvořená bez zátěže z minulosti.
