reklama

O kolik je Intel Optane výkonější než současné notebookové SSD?

PetrM

Re:O kolik je Intel Optane výkonější než současné notebookové SSD?
« Odpověď #75 kdy: 11. 07. 2018, 09:35:23 »
Ne, není to o stylu práce. Můj styl práce je správný.

Ne, není.

1) Když refaktoruješ malý kousek, proč sakra buildíš všechno? I to blbý make na Unixu v 70. letech vědělo, co se v projektu změnilo a na co volat kompilátor, tak proč to, sakra, nejde na hyper super moderním cool IDE s jazykem, co umí všechno?
2) Refaktoruješ/měníš komplet všechno v projektu? Proč, ty vole? Udělej si test projekt pro konkrétní modul (= doba jednoho testování), přetáhni do něho jenom to, co se ho týká (unit testy, kód) = třeba hodina práce, to je 6 těch desetiminutových testů. Projeď úvodní test a pak refaktoruj. V tom okamžiku už děláš v rozsahu třeba 5% projektu a build + testy za 20s. Jak budeš spokojený, commitneš to, merge do integračního testu a tam se o to automaticky postará třeba pan Jenkins na pozadí a pošle ti pak mailem, jestli to prošlo (komplet UT + IT). Když jo, tak to odešleš tesťákům, když ne, opravíš to. Než dojde výsledek od CI, můžeš si třeba chystat práci na další modul. V té chvíli tě netrápí ani testy na 30 minut, pokud se dějí automaticky na pozadí, že...
3) Zkus se podívat, jestli tvůj framework nemá overhead při buildu jako kráva - závislosti všeho na všem, zatahování nepotřebných kosočtvercovin,...
4) Čím slabší stroj, tím lepší SW. Budeš blíž k realitě, kterou má uživatel aplikace a budeš sám vidět, kde ho tlačí bota.

reklama


kraxna

Re:O kolik je Intel Optane výkonější než současné notebookové SSD?
« Odpověď #76 kdy: 11. 07. 2018, 17:53:15 »
1) Když refaktoruješ malý kousek, proč sakra buildíš všechno? I to blbý make na Unixu v 70. letech vědělo, co se v projektu změnilo a na co volat kompilátor, tak proč to, sakra, nejde na hyper super moderním cool IDE s jazykem, co umí všechno?
2) Refaktoruješ/měníš komplet všechno v projektu? Proč, ty vole? Udělej si test projekt pro konkrétní modul (= doba jednoho testování), přetáhni do něho jenom to, co se ho týká (unit testy, kód) = třeba hodina práce, to je 6 těch desetiminutových testů. Projeď úvodní test a pak refaktoruj. V tom okamžiku už děláš v rozsahu třeba 5% projektu a build + testy za 20s. Jak budeš spokojený, commitneš to, merge do integračního testu a tam se o to automaticky postará třeba pan Jenkins na pozadí a pošle ti pak mailem, jestli to prošlo (komplet UT + IT). Když jo, tak to odešleš tesťákům, když ne, opravíš to. Než dojde výsledek od CI, můžeš si třeba chystat práci na další modul. V té chvíli tě netrápí ani testy na 30 minut, pokud se dějí automaticky na pozadí, že...
3) Zkus se podívat, jestli tvůj framework nemá overhead při buildu jako kráva - závislosti všeho na všem, zatahování nepotřebných kosočtvercovin,...
4) Čím slabší stroj, tím lepší SW. Budeš blíž k realitě, kterou má uživatel aplikace a budeš sám vidět, kde ho tlačí bota.

Jen doplnim mozna par veci k tomu, ceho se to tyka (protoze tvoje prohlaseni je dost obecne).

LR moduly se builduji pomoci maven ci gradle, inkrementalni kompilaci umi oba
Poustet testy se da jednotlive nebo po skupinach, staci si vybrat, nemusi se kvuli tomu ani kompilovat vse, ani poustet vsechny.
Restartovat LR se kvuli nahrani nove verze modulu nemusi
Integracni testy se pousti v LR na bezici LR, deployuje se jen ten modul nic vic (a nemusi ani cely, pokud to ma clovek rozumne navrzene).
Frameworkem v LR je prave ten LR, nebo max. osekany Spring.Nevim co si predstavujes, ze v Jave zpusobuje overhead jak krava pri buildu - framework se nekompiluje, jen se nacitaji class soubory, build zavislosti nijak extremne nezpomaluji.
Bliz k realite uzivatele ? Vzdyt je to LR, bezi to na serveru, uzivatel to nikdy poustet nebude, takze to neni nijak vypovidajici vec o uzivatelske zkusenosti :-d

PetrM

Re:O kolik je Intel Optane výkonější než současné notebookové SSD?
« Odpověď #77 kdy: 12. 07. 2018, 06:43:35 »
Jen doplnim mozna par veci k tomu, ceho se to tyka (protoze tvoje prohlaseni je dost obecne).

Nedělám Javu, takže konkrétní nástroje neznám. Jenom nemůžu pochopit, že někdo po změně pěti řádků pět minut buildí na tom nejvýkonnějším železe, co má k dispozici. A při tom ještě tvrdí, že to dělá správně.

Bez ohledu na jazyk a tooly, tohle není programátor, ale vůl. Místo pročítání benchmarků by se měl soustředit na příručk k nástrojům a pochopení, s čím pracuje. A tím bych to uzavřel.

Bliz k realite uzivatele ? Vzdyt je to LR, bezi to na serveru, uzivatel to nikdy poustet nebude, takze to neni nijak vypovidajici vec o uzivatelske zkusenosti :-d

Předpokládám, že na tom samým stroji co to builduje, bude i některý věci zkoušet. A je moc fajn, když ti někdo něco odladí na osmijádře @3,5GHz s 32GB RAM a pak to najednou jde na čtyřjádro @2,5GHz s 8GB RAM. To se pak někdy chová trochu jinak a uživatel nemusí být vždycky spokojený s pomalejší odezvou a swapováním...

neeemeee

Re:O kolik je Intel Optane výkonější než současné notebookové SSD?
« Odpověď #78 kdy: 12. 07. 2018, 23:53:50 »
Divím se, že jste tak dlouho vydrželi diskutovat s někým, kdo nepozná rozdíl mezi prasetem a krávou. Tenhle člověk je úplně mimo a pokud něco opravdu programuje, tak maximálně piškvorky, a to na své černobílé televizi s vlastnoručně vyřezanou klávesnicí z bukového dřeva a s papírovou čepicí na hlavě. 

Re:O kolik je Intel Optane výkonější než současné notebookové SSD?
« Odpověď #79 kdy: 19. 09. 2018, 10:35:53 »
Omluva za exhumaci šťastně zesnulé flame war...

Narazil jsem na tuto debatu tak, že jsem se snažil domáknout něco o reálných vlastnostech reálně dostupných produktů Intel Optane. S tím že mě osobně nijak zvlášť netankuje rychlost, ale tankuje mě odolnost/výdrž za provozu. A přestože Intel detaily moc nekomentuje, tak mám pocit, že se marketingová mlha díky reálnému uvedení na trh přeci jen už trochu rozestupuje.

Konkrétně lze nalézt čísla, jako že konzumní 32GB Optane modulky mají slíbený zapsatelný objem 180 TB (tzn. "TBW"). To je asi 5600 kompletních přepisů. Pokud vezmu jako "benchmark" klasickou MLC flashku, tak ta dovolovala natočit cca 3000 přepisů. Tzn oproti 22nm MLC NAND Flash jsme na první pohled cca na dvojnásobné životnosti. Oproti MLC v jemnější litografii a moderním TLC je ten poměr pro Optane lichotivější.

"Enterprise" verze Optane mají např. 20 PBW při kapacitě 375 GB. To už vychází asi na 50 000 kompletních přepisů. Kapacita 375 GB podle mého znamená, že zbytek do 512 GB je "odložený stranou" jako rezerva na "vadné sektory".

Pro srovnání, technologie SLC NAND Flash mívá taky udáváno řádově 50k mazacích cyklů (kompletní přepis SSD) při citelně menší "rezervě", kapacity SLC SSD se dodnes udávají obvykle v "binárně kulatých" číslech. A pravda je, že optane je asi levnější než SLC a odhadem i rychlejší (kratší "doba vystavení").

Pro srovnání, produktová řada Innodisk iSLC (MLC NAND Flash čipy, kde je nejspíš cca půlka odložena na rezervu) má slíbených 20k přepisů - v první generaci s hrubší litografií to bylo dokonce 30k.

Čili původní představa (možná jenom moje halucinace) že 3D Xpoint znamená neomezeně přepisovatelnou EEPROM, je zjevně zcestná. Reálná SSDčka Optane mají omezenou životnost.

Otázkou zůstává srovnatelnost čísel TBW/PBW mezi NAND Flash a 3D X-point. Z toho, že Intel tato čísla udává, podle mého plyne, že Optane SSD interně používají nějaké hlídání a remapování vadných sektorů, nebo spíš starý dobrý wear leveling. V tom případě je otázkou, jak velká je alokační jednotka pro zápis (1 bajt? nebo 4k jako u Flashek? Nebo něco mezi) a jak velký je "erase blok". Jestli to jede ve dvou patrech jako Flash, nebo třeba jenom jednopatrově. Nejede to třeba zápisy i mazání klasicky po sektorech 512B nebo 4k? S tím souvisí objem a organizace interních metadat pro mapování uživatelského LBA adresního prostoru na fyzické čipy a jejich interně alokovatelnou granularitu - a potažmo rychlost a další chování při zápisu, čtení apod. A především: z detailů této organizace bude plynout "amplifikace počtu přepisů" při zápisu drobnými transakcemi, menšími než "erase block". Tolik ke srovnatelnosti TBW/PBW mezi flashkami a Optane. Je možné, že to číslo bude "za jinak stejných okolností" (konkrétní mix zápisové zátěže) znamenat u každé technologie jinou reálnou dobu fungování.

Je možné, že 3D X-point jde přinejmenším jednotlivě po bajtu *číst*. Z toho by mohla plynout hodně krátká latence - četl jsem správně že desetinová oproti NAND Flash?

A ještě jak jste si tu vjeli do vlasů ohledně závislosti doby buildu čehosi v Javě na různých faktorech... co takhle CAS latency použitých RAMek? Myslím spíš v nanosekundách než v počtech taktů. Pokud běh Java VM reálně znamená procházení rozsáhlého grafu všelijakých referencí / nepřímých odkazů, které značně přesahují kapacitu CPU cache všech tří úrovní, může to celé záviset právě na "vystavovací době" DRAMek. Když musí CPU čekat na přístup na náhodnou adresu do DRAM, lítají vzduchem vysoké desítky wait states. Pokud se dá benchmarkovaná úloha paralelizovat, může více CPU jader využít více kanálů DRAM (a možná líp když nepojedou prokládaně = nebudou "synchronizovat seeky".) Průser je, že CAS latency v nanosekundách se moc nevyvíjí. Tuším v dobách EDO DRAM byla CAS latency nějakých 50 ns. Další vývoj jsem zrovna našel v hezké tabulce u firmy Crucial. For the record: u PC100 SDRAM je udáváno 24 ns, pak skokem zlepšení na 15 ns u DDR, a dál v podstatě už nic, DDR4 je někde na 13.5 ns. Navíc si nejsem jistý, jestli ta čísla nejsou ještě dost optimistická (přímo na nožičkách DRAM čipů nebo tak něco). Nějaká čísla si počítá taky heslo na Wikipedii, ale podle mého jsou odtržená od reality (paměti DRAM s CL pod 10 ns se reálně neprodávají). Napadá mě, proč se do serverů nedělají DIMMy se SRAM namísto DRAM - no zjevně nejsem první koho to napadlo. Odpověď zní: v gigabajtových kapacitách by to stejně nakonec nebylo rychlejší. Čili závěr z toho by mohl být: paralelizovat úlohu a provozovat ji na masivně paralelním CPU s mnoha nezávislými kanály paměťového řadiče (HBM? jak vypadá řadič?)


 

reklama