SAP - tomiposerzádatohleto...

18.2.2025 19:31 | Přečteno: 2248× | plky | poslední úprava: 18.2.2025 19:34

Bylo nebylo, v SAPu se posrali...

Měl jsem meet ohledně S4H

Klasika, tlačeníčko, konec podpory 3rd db, nastává období SAP HANA. Řeší se tedy případná migrace na SAP HANA, řeší se, zda migrovat do cloudu, nebo do on-prem atd.

Intel only bro

Opravdu jsem to nečekal. Běh SAP HANA je podporováno jen na procesorech Intelu a IBM Power. Když mi to říkali, myslel jsem si, že si dělají prdel. Fakt ne, SAP nutí zákazníky kupovat hw, co je sto let za vopicema (jo, myslím teď ten Intel). Googlil jsem, googlil, kontroloval ofiko kompatibility listy apod. a fakt je to tak. Mně normálně vomeje. Čekal jsem cokoli, že si řeknou u relativně malé db o aspoň 512GB ram a v případě i test/dev prostředí celkem 1.5TB/server jsem tak nějak čekal. Ale že budou nutit kupovat lidi zaostalý Intel, to mi vyrazilo dech.

Reálně na to asi sere pes, jelikož k jednomu CPU lze možná narvat 16x256GB ram, a to je vzhledem k poměru kapacita/cena docela nedobrá kombinace. Nehledě na to, že prý dost topí, takže pak je možné narazit na nějaké limity v osazení apod. Tím chci říci, že v serveru pro SAP by asi nic jiného, kromě SAPu (a věcí okolo) běžet nemohlo, bo už by pro další app nebyla k dispozici ram. Ale stejně je to prostě nehomogenní prostředí pro virtualizaci :-/. A ano, u kontejnerizace to nevadí a je to nastupující trend, takže časem to asi také odpadne. Hmm...

Paradox

Každopádně paradox v nepodporování AMD, a dokonce i zakazování (prý to instalátor kontroluje) je, že HANA Express prý jde nainstalovat na Ryzen CPU a prý to funguje. SAP si zároveň před několika lety vybral cloud infra od Google postavenou na AMD. Navíc je podporován běh současné db na CPU Intelu, které jsou staré 8 let, bavíme se např. o HPE DL380 Gen9. Celé je to tedy umělé omezení díky nějakým sračkopřátelstvím s Intelem a SAP se vymlouvá na nepodporu některých instrukcí. Zároveň ale zavádí podporu pro ARM :D. Takže jasný umělý fuckup.

Závěr

Potřeboval jsem si prostě jen postěžovat, jelikož jsem nečekal, že je v roce 2025 něco takového možné.

Zdar Max

       

Komentáře

[RealJ]

"jelikož k jednomu CPU lze možná narvat 16x256GB ram" - to mas nejake lokalni omezeni? Co vim tak maximum u xeonu je 192 slotu, tudiz 24TB na 1 cpu. A jo, je to licencne udelane tak aby si musel jit do intelu protoze max ram. U amd s pres 2TB nedostanes a misto srani se s migraci v pripade ze narazis na takovy limit chteji proste rovnou intel s "nekonecno" ram. V cloudu je to fuk, vejdes se do 2TB tak ses vpohode, budes potrebovat vice tak te premigruji na instanci s vice ram a intel cpu.

[Max]

Bavím se o běžném serveru. V našem případě bereme HPE DL380/385.
AMD EPYC má limit 6TB, je to limit od 4. generace.

Intel má limit u 6. generace Xeonů 3TB (některé modely mají 4TB limit), takže je na tom v současné době hůř. Aspoň tedy podle datasheetu.
Zdar Max

[RealJ]

Tak s beznym serverem to chapu, s tim epycem mas pravdu.
Tak treba https://www.broadberry.com/quad-xeon-scalable-processors-rackmount-servers?srsltid=AfmBOopYQW90eNlV9mmTNTMGZwdSOzyqAgY18VnrSWZGXNFEICzF3uNp
Up to 224 cores and 36TB of memory.
Up to 192 DIMM slots.
Up to 24TB DDR4 RAM.

[Max]

To jsem našel a o tom jsem mluvil, viz níže. Prostě 4x socket a pak můžeš mít 24TB ram, protože určitý typ stařičkých Intelů podporuje 6TB per CPU. Takže 4x socket = max 24TB ram. A otázka stále platí, zda lze toto na Intelu i s DDR5 a aktuální řadou CPU?
Zdar Max

[Max]

Jinak těch 24TB dosáhneš s Intelem v případě nějakého čtyřsocketového řešení (per CPU 192 memory slotů fakt nemáš). Ale musíš mít Platinium CPU, ještě ke všemu těch modelů s limitem 6TB ram nemají mnoho (Intel® Xeon® Platinum 8358P Processor ), ale je to stará technologie s DDR4. Pak je i diskutabilní výkon, protože dual scoket nemá výkon 2x CPU, ale je tam performance impact a čtyřsocket na tom bude ještě hůř. A s tím, jak Intel vyrábí sporáky, tak by byl asi quad scoket v dnešní době neuchladitelný, těžko říci, zda vůbec quad socket pro DDR5 dělají.
Zdar Max

[RealJunk]

lol, njn, takze je to zase ponekud jinak nez psal RealJ se svoji "znalosti" uplne vseho od cpu pres programovaci jazyky az po tradicni japonske rezbarstvi :D

[RealJ]

s tema sockety samozrejme vykon neroste rovnomerne, ale stroj s 8 sockety je furt rychlejsi nez stroj se dvema sockety. ;) A jo, je to postavene na DDR4, nevim o nicem rychlejsim. Chlazeni tohodle v dc neni problem, huci to ale jako letadlo.

[Max]

Ale stroj s dvěma sockety Intelu není rychlejší, než stroj s jedním socketem AMD, nehledě na to, že s tím Intelem vytopíš barák, což znamená, že musíš mít klimy, co ten barák vychladí. Prostě TCO poměr spotřeba/výkon brutálně nevychází.
Zdar Max

[Max]

Ještě k tomu cloudu. Neděláš si nějaké velké iluze? Několik příkladů:

Přemýšleli jsme o Oracle DB v Cloudu. V režimu, kdy by to mělo stejný počet licencí / stejnou cenu nám byli schopní nabídnout 64GB ram, přitom v on-prem v současné době saturujeme 300GB + 64GB. Oracle Cloud má pevný poměr, takže pokud bychom chtěli paměťove ukrmit naší DB, tak by Cloud vyšel fakt kolosálně draho, a to tak kolosálně, že jeden rok provozu v Cloudu zaplatí 5 let provozu v on-premu.

Stejně je to třeba s Exchange on-prem vs O365. Náklady jdou do násobků. Ano, v rámci O365 dostaneš hafec fcí, které nepoužiješ a musíš zaměstnat licenční firmu, aby jsi nemusel přeplácet ještě víc a aby jsi se vůbec vyznal v nákupech.

Pak tu máme virtualizaci a kontejnerizaci, kde těžko budeš jednomu kontejneru přidělovat zdroje z více serverů, nebo jedné VM přidělovat zdroje z více serverů. Taktéž narazíš na jiné limity virtualizace, ESXi mělo u verze 7 limit asi 6TB, u verze 8 má limit 24TB, kvm má limit aktuálně asi 16TB, ale vše je to podmíněno jinými věcmi jako NUMA, omezení live migrace atd. Tím chci říci, že minimálně v případě x86 cloudu bych na vertikální škálování tolik nespoléhal a snažil se aplikace navrhovat na horizontální škálování.
Zdar Max

[RealJ]

jinak mame jednoho zakaznika ktery historicky provozuje sap na ibm power a maji tam snad pres 30TB ram a budou muset upgradovat za strasny prachy... jako nevim co v tom ukladaji ze jim to zere 30TB RAM ale presne tohle povazuji za reseni kde amd nema odpoved na intel (nebo v tomhle pripade na power).

[Max]

Tak to není. My teď máme SAP nad OracleDB a celý server (DB + aplikáč) má alokováno 32GB ram. Pokud bychom toto teď chtěli převést na SAP HANA, tak stejná DB bude na SAP HANA vyžadovat 512GB ram a k tomu 32GB pro aplikační část.
SAP HANA se snaží být in-memory kompletně a těžko říci, do jaké míry to má smsyl. My jsme u OracleDB dělali analýzu, zda se nám vyplatí in-memory option a dle všech dostupných stats se došlo k tomu, že by se db nezrychlila, jelikož diskové operace to nebrzdí a současná SGA keš je dostatečná.
Zdar Max

[xvasek]

Stejně jsou ty serverové věci srandovní. Jeden zákazník má virtualizační infrastrukturu, disková pole, serverové servery, optické optiky, high availability, kdesi cosi. Udělali jsme VM, nainstalovali jsme tam systém (ERP), fungoval, ale za nějakou dobu jsme se začali bavit o odezvách a že by mohly být lepší. Samozřejmě ty serverové CPU úplně nevynikají single-thread výkonem, 2.8GHz není u serveru žádná ostuda, taky je otázka, co s tím dělá ta virtualizace / HA a zátěž na ostatních VM atd., tak že uděláme pokus. Vzali jsme běžné PC z kaceláře - levná deska, jedno SSDčko, dali jsme do něj herní Ryzen, přidali nějaké RAMky - upgrade na zkoušku za pár tisíc. KVM, migrace VM, hotovo. Časy odezvy klesly asi na čtvrtinu a od té doby tam ten systém takto běží a nikomu se nechce to migrovat zpět.

[Max]

Serverové věci moc srandovní nejsou, jen jsi popsal nějaký špátný, nebo poddimenzovaný návrh infrastruktury.
Jinak ten desktop, super, ale pak narazíš asi na milion věcí, počínaje monitoringem, HA, DR, failover přístupem apod.
Např. pokud máš HPE server, tak máš iLO. To jednak umožňuje vzdálený přístup (KVM), dále monitoruje kompletní stav hw, takže pokud zašolíchá jeden větráček, disk, keš na řadiči, paměťový modul a další věci, tak to víš z dohledu hned nezávisle na tom, co ti tam běží za OS. Prostě je to jednotná vrstva pro správu a monitoring. A to je jen jeden příklad z množiny věcí, co je třeba u většího počtu hw řešit. Pokud např. potřebuješ provádět údržbu hw bez odstávky služeb, tak jsi bez HA druhej. A tak dále.
Zdar Max

[xvasek]

Jo, to je všechno jasné. Záleží kde děláš, ale v ERP mám tu zkušenost, že se stejně věci pokazí asi tak v 99% na té úrovni, že to není problém hardware, ale logiky. Stejně tak odstávky nebývají problém hardware, ale spíš softwarové údržby systému. Jasně že jsou suprovní postupy a lidi, kteří dokáží udržet v běhu cloud i když na jednu serverovnu spadne asteroid (kudos - fakt), ale co je to platné, když pak přijde nějaký projektový týpek, který řekne, že měníme softwarovou architekturu tohoto a tím pádem bude systém týden offline.

Jinými slovy: HA je taky v podstatě naprd, když někdo smaže databázi. Rozdíl je jenom v tom, že ji máš smazanou dvakrát.

Tím nechci říct, že monitoring a údržba hardware je kravina. Samozřejmě že není a děláme to všichni. Jenom množství incidentů z hardware tvoří jenom zlomeček množství incidentů způsobených logikou provozu systémů, zejména protože s nimi dělají lidi.

[Max]

To je polopravda. Samozřejmě, že potřebuješ dělat i sw maintenance, ale prostě potřebuješ dělat i hw maintenance (výměnu vadných komponent, patchování, výměnu celého hw atd.). Takže dobrou infrastrukturou minimalizuješ polovinu možných odstávek, které třeba nemusí mít impact na běh firmy, ale mají impact na IT (tj. např. nemůže dělat rychlý update hned po peaku pracovní doby, ale musí ho dělat někdy v noci, musí sundat a odstavit systém, než provede údržbu a pak ho nahodit atd.).

HA naprd není, a to ani když něco na produkci mázneš. Opět záleží na návrhu celého řešení. Není problém se třeba v záložní lokalitě vrátit s db do nějakého času, než se znovu nahodí. Bavíme se o konzistentním vrácení (rollback transakcí do nějakého času). Tj. máš DR lokalitu, kam replikuješ a z podstaty věci je ta replika v read-only režimu s tím, že když nastane problém, můžeš jí dát do režimu zápisu, nebo vrátit nějaké transakce a pak dát do režimu zápisu atd.

Každopádně před nějakou sw úpravou se většinou udělá snapshot, odleje se záloha, odpojí se konektory atd. Pokud se tedy nestíhá vymezené okno, lze opět udělat rollback do původního stavu.

Jinými slovy, tvá představa HA, Failover / DR je na úrovni toho desktopu, přitom je to ale reálně o dimenze jinde.
Zdar Max
PS: Pokud jde o poruchovost hw, tak nemám moc dobré zkušenosti, ani s HPE, i když poslední roky už mi to přijde dobrý.

Spíše bych řekl zaostalá x86. AMD v tomto není o mnoho lepší volbou.

[Max]

Pořád se mluví o zaostalé x86, ale nikdo zatím nepředvedl něco lepšího.
Vždy někdo přijde s WoW syndromem jako:
Koukej, výpočty na GPU jsou pekelný, fuj x86. Ale že se jedná o jednu, dvě specifické výpočetní úlohy už všichni mlčí.
Koukej, ten Apple M2 dává na prdel všem, fuj x86. Ale opět, specifický usecase, jeden dva benchmarky před x86, v ostatních daleko v zádeli a když je potřeba něco víc, tak smolík.
Koukej, ten ARM, x86 nemá šanci, budoucnost je ARM. Ale opět, pokud by ARM mělo nahradit x86, tak to nakonec s tou efektivitou není tak slavné a opět se jedná o určitý typ nasazení a ne tak universální jako u x86

Vývoj v x86 světě jde taktéž rychle kupředu. Stagnující doba před 7 lety, kdy Intel několik let přešlapoval a dal tak šanci ostatním architekturám, nezajistila jejich výhru. Stále zatím ne.
Zdar Max

[kvr]

Tady se dá souhlasit jenom s tou první větou - ano, GPU je na specifické činnosti.

V tom zbytku: Kde přesně je x86 univerzálnější než ARM? V AWS je dnes půlka serverů na ARM, Google, Microsoft se snaží o to samé. Facebook chce ARM CPU pro vlastní datacentra, což možná donutí ARM i skutečně vyrábět místo jenom licencování. Apple Silicon měl před čtyřmi lety poměr výkonu na spotřebu o řád jinde než zbytek světa a teď se mu Intel či AMD možná začínají přibližovat.

Jsi posledních 5 let spal, ne?

[Ovoce]

Apple Silicon měl před čtyřmi lety poměr výkonu na spotřebu o řád jinde než zbytek světa

O něco jo, ale o řád (10x) lepší to mohlo vyjít jenom při zavádějícím srovnání jablek s hruškama (typicky použití trošku přehnaných dojmo"čísel" u Applu a/nebo volba x86 hardwaru tak, aby drtivá většina spotřeby vůbec nebyla CPU jádro).

[Max]

Ano, ARM pro specifické nasazení. A s tou účinností opět, tam je ten poměr u specifických úloh. U některých úloh jde poměr do kýblu.
Proč myslíš, že x86 má tolik instrukcí? Proč myslíš, že se mění/upravují/vyvíjí pro specifické úlohy? x86 platforma obsahuje komplexní instrukční sadu, zato ARM jí má silně redukovanou. A o tom to je. Pokud máš úlohy, kde si vystačíš s pár jednodušími instrukcemi, tak super, budeš nadšený z poměru výkon/spotřeba. Pokud potřebuješ měnit typ workloadu, tak zabrečíš. Ostatně proto se i do ARM přidávají další a další instrukce.
Dobře je to shrnuto třeba zde: ARM or x86? ISA Doesn’t Matter.
A přesně o tom mluvím. Lidi posledních 10 let dělají WoW, 10 let říkají, jak ARM top a x86 odpad, ale reál je úplně jinde. Každopádně ARM byla a stále je primárně optimalizována pro nízký výkon i spotřebu.

Podívej se na nějaké porovnávání výkonu a spotřeby v serverové kategorii, kde je např. Ampere Altra. Něco vyšlo i na Phoronixu. Vidíš tam nižší spotřebu ARM, ale i mnohem nižší výkon a velké úlety u různýh úloh.

Takže ne, nespal jsem, jen se nevezu na vyhypovaný vlně něčeho, co získalo slávu na základě pár benchmarků. Úplně stejně, jak jsi nyní odvařený z ARM, tak úplně stejně bylo hafec lidí odvařeno v začátcích CUDA a dalších, kde se porovnávala specifická zátěž / specifické výpočty s x86 architekturou.
Každopádně aby bylo jasno, nehejtím ARM, fandím tomu, jen upozorňuji, aby si někteří sundaly růžové brýle.
Zdar Max

[kralyk z abclinuxu]

Za mě ten wow dojem je oprávněný u GPU i ARM.

GPU se z hraček na renderování her staly mozkem AI revoluce. ARM vytlačil x86 z čehokoli mobilního (kromě Ryzenu v EVs), slušně zaťal zuby v laptopech, teď začíná i v serverech.

Podívej se na nějaké porovnávání výkonu a spotřeby v serverové kategorii, kde je např. Ampere Altra. Něco vyšlo i na Phoronixu.

Ok, ale to je jen Ampere. Co Google Axion? [phoronix]

[Max]

Z notebooků nikdo nikoho nevytlačil, těch pár ks s ARM je zanedbatelná minorita, pokud se nepočitá Apple. Když by se Apple počítal, tak je to kolik? 2% ze všech ntb?
A pokud jde o tel., tak tam snad x86 ani moc nebyla, resp. možná tak za Windows Mobile. Android začínal na ARM based. To samé tablety.
Kde si ten Google ARM mohu koupit? Nemohu, musím spoléhat na nastavení jejich cloudu, o kterém vím tušku a nejsem schopný ani přesně změřit spotřebu.
Zdar Max

[Ovoce]

ARM už nemá silně redukovanou ISA, jen ta 64bitová verze má přes tisíc instrukcí a to v roce 2012 začali odznova a to staré zahodili. Je to ISA co sere na ideologii a je pragmaticky optimalizovaná na výkon a spíš trochu CISC (tahle nomenklatura už ale 20 let nemá smysl, lidi co diskutujou RISC vs CISC zaspali jako svině... (RISC-V je taky koncepčně celkem zastaralá a bohužel má spoustu problémů, které s tím souvisí, btw)

Jediné co v ARMv8/ARMv9 zbylo z RISC konceptu a co je pořád relevantní proti x86/"CISC" ve starém slova smyslu je konstantní délka instrukcí.

ARMv8/9 není rozhodně špatná ISA, je optimálnější než x86, ale to neznamená, že procesory s ní musí být nějak radikálně lepší. A SVE/SVE2 nejspíš byla chyba (to samé RVV u RISC-V, ale tam je to ještě mnohem víc posranější, protože RISC-V nemá žádnou alternativu, zatímco ARM má normální SIMD instrukce NEON, i když jsou jenom 128bit - ale zaplať Pán Bůh za ně).

BTW myslím že dost lidí tady bude mít zastaralé představy, viz ten člvěk argumentující IPC u 386ky nebo tím, že "paměť a PCI jde přes bus". PCI už ani dneska neexistuje a možná by to chtělo se podívat, jak dnešní x86 SoCy jsou řešené (stejně jako ARM SoCy).

[Ben]

Ty prognozy o zaostalosti x86 jsem slysel uz v 90kach na vejsce. Nic z toho se nenaplnilo, CISC procaky proste maji porad prim potoze kazdy novy problem vyresite novym setem instrukci. A samotne krmeni daty, kouzla prefetch units, kesky atd dokazi technologicky drzet krok s konkurencnimi architekturami. A to si vemte, ze porad mame RAM a PCI reseno pres bus. Az se to zadratuje primo do cipu tak vykonnostni boost bude neskutecny. Jo ubyde moznosti modularity ale kdo uz dnes sklada PC ci server?

Misto toho tady mame hrbitov:

• motorka 68 - v pocitacich uz nenajdete, pouze nejake specializovane desky pro sitarinu
• PPC - labuti pisen pred 20 lety v Playstation a XBOX a pak utrum. V pocitacich uz jej nenajdete.
• VLIW - to bylo peni chvaly na Itania ci Transmety a umreli vicemene proto, ze NIKDO nebude prepisovat stavajici x86 kody. To ostatne videt v ARM ci RISC-V svete kde je vyber SW radove mensi nez u x86 a jen tak se to nezlepsi i kdyz se ten SW kodi uz od dob prvnich iPhonu a Androidu.

[plostenka]

Itania umrely, protoze se Intel s HPE vzajemne vyzmrdili s vendor lockinem. Jinak myslenka na ciste x64 procesor bez 32bit balastu byla v te dobe dobra...

[Ben]

vyzmrdili s vendor lockinem - ano i ne, to uz byla marketing polivcicka a proste ji pretahli, to nemelo nic s technologickou nedokonalosti.

Vyzmrdil je spise AMD Opteron kde za zlomek ceny bylo 64bit k dispozici a x86 kody dokazali bezet bez zmeny. A ze dozene Itanium i vykonove uz byla jen otazka casu a pokroku v litografii. Tenhle pruser si Intel zahy uvedomil a radeji si amd64 rovnou licencoval. Na oplatku pak pozdeji Intel vydelal na licencovani MMX, SSE atd.

[kralyk z abclinuxu]

Ty prognozy o zaostalosti x86 jsem slysel uz v 90kach na vejsce. Nic z toho se nenaplnilo, CISC procaky proste maji porad prim potoze kazdy novy problem vyresite novym setem instrukci. A samotne krmeni daty, kouzla prefetch units, kesky atd dokazi technologicky drzet krok s konkurencnimi architekturami.

V tom se ARM neliší, ISA extensions a cache má pochopitelně taky.

A to si vemte, ze porad mame RAM a PCI reseno pres bus. Az se to zadratuje primo do cipu tak vykonnostni boost bude neskutecny.

To je asi jediná šance x86 no. Nezkouší tohle AMD s APU?

[kvr]

Ty prognozy o zaostalosti x86 jsem slysel uz v 90kach na vejsce.

A byla to pravda už tehdy. Intel to tehdy stále vyhrával kvůli svému příjmu z trhu a schopnosti investovat do vývoje. Ale tohle mělo své limity:

• Už v roce 1986 byl ARM2 (32-bit) na poloviční frekvenci dvakrát rychlejší než 386
• Většina CISC instrukcí na x86_64 se vůbec nepoužívá - jenom zabírají místo v ISA
• CISC instrukce, které se používají, se interně překládají na několik vnitřních instrukcí
• Nové instrukce nebo jen staré instrukce s novými registry vyžadují prefix či několik prefixů a ve výsledku tak zabírají 4 a více bytů. Extrém je AVX-512
• Na ARM64 každá instrukce zabírá přesně 4 byty
• Pro porovnání - kdysi jsem psal test na násobení matic: 128-bit Neon na Apple M1 byl mírně rychlejší než 512-bit AVX-512 na Intel. Zároveň byl kód na ARM64 kratší, přestože vyžadoval teoreticky 4-krát více operací (možná víc kvůli teoretické výhodě x86 pracovat přímo s operandem z paměti) ! U SVE na Graviton 3+ byla pak rychlost úplně jinde.
• Ty prefixy výše jsou brzdou pro superscalární zpracování, kde jsou dneska největší limity.
• TSO memory model je taky brzdou, která prakticky nic nepřináší.
• Ani ARM32 nebyl dokonalý a nesl si následky rozhodnutí, které se ve své době zdála akceptovatelná. ARM64 celou zpětnou kompatibilitu zahodil na základě znalostí moderních CPU.

Ještě:

• CISC procaky proste maji porad prim potoze kazdy novy problem vyresite novym setem instrukci : Nic takového magického opravdu neexistuje. AVX-512 asi v některých věcech umí víc, ale nic dramatického. Za posledních 10 let nic extra zvláštního nepřišlo.
• RAM a PCI reseno pres bus. Az se to zadratuje primo do cipu : to se snažil Intel u Lunar Lake, spolu s aktuálně nejlepším výrobním procesem, ne? Posun je znát, ale jsou prakticky na limitu a stejně se u spotřeby jenom přiblížili Apple Mx na Qualcomm Snapdragon.
• Testy Intel vs AMD vs Ampere ARM64 : Irelevantní. Ampere je relativně minimalistická verze. Porovnávej s Graviton 4, který je minimálně dvakrát rychlejší.
• Spotřeba: Někde Amazon tvrdil, že je Graviton 2 snad třikrát energeticky efektivnější. Pokud Intel či AMD bude přecejen rychlejší, k čemu mi to bude, není lepší si za stejnou cenu koupit trojnásobek procesorů a mít třikrát větší výkon??

[kralyk z abclinuxu]

TSO memory model je taky brzdou, která prakticky nic nepřináší.

Zajímavá poznámka, přemýšlim, jestli to má nějakou výhodu a nic moc mě nenapadá. Spousta atomických operací se na x86 přeloží jako jen prostá základní instrukce, takže by teoreticky explicitně atomické být nemusely, ale stejně prakticky vždycky chci, aby to fungovalo i na jiných platformách a/nebo byla z kódu zřejmá MT sémantika té operace.

[Ben]

TSO je chimera. Dnesni bezpecnostni protokoly o "random" ulozeni v pameti ti to smetou ze stola tak jako tak. Dulezita je fyzicka rychlost - na jake frekvenci kmita bus a DDR, jaka je propustnost socketu, paralelizace pametovych cipu atd. To ze se dnes na notasech a lepsich servrech letuji RAM primo na desku je hlavne o vyhnuti se socketu a fyzickeho zpomaleni prenosu. Drive ci pozdeji dojde k setreni rozdilu mezi Harwardem a vonNeumanem a pamet primo v CPU vyhraje. A nemluvim jen o RAM, v podstate jde i o SSD.

[kvr]

Atomické operace jsou všechny v rámci velikosti a zarovnání, shodně na x86 a ARM. Pro atomickou read-operation-write vyžaduje x86 LOCK prefix, ARM má na to speciální instrukce (původní ARM32 měl load-exclusive store-exclusive, ARM64 toho umí víc - v tomhle je spíš CISC).

TSO je spíš o tom, v jakém pořadí se ten zápis provede. x86 musí neustále synchronizovat cache mezi procesory, zatímco ARM jen, když přijde memory barrier. A memory barrier se používá poměrně ojediněle - v Java cokoliv volatile či synchronized, tedy přístup ke globálním sdíleným objektům. V rámci lokálního kódu si ARM může paměť a kód přeuspořádat jak chce, zatímco x86 musí pesimisticky předpokládat, že na pořadí může záležet.

Zajímavé je, že třeba Sparc byl taky TSO, ale pro RISC spíše výjimka. A jak Ben píše, jde o to udělat, otázka je, za jakou cenu... Apple Mx implementoval TSO, ale zapíná ho jenom pro emulovaný x86 kód z důvodu emulace paměťového modelu.

[bEKO]

Ono je to dokonca ešte trošku komplikovanejšie. Pôvodne sa dala HANA prevádzkovať iba na tzv. appliance HW. To boli servery s fixnou konfiguráciou v niekoľkých variantoch a nedalo sa nič zmeniť.

Dnes sa dá HANA postaviť na takzvanom TDI HW, kde si môžeš jednotlivé komponenty zvoliť.

Ale stále sa musíš držať zoznamu podporovaného HW a áno, podporované sú iba Interl a Power CPU: https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=v:deCertified&sort=Latest%20Certification&sortDesc=true

Zaujímavé je, že AMD už niekoľko rokov dozadu oznámilo spoluprácu, ale nevidel som žiadny reálny dopad tohto oznámenia https://www.youtube.com/clip/Ugkx61JeT5eGZSIpRYekShLtAKu1AYccSWDA

[Max]

To já vše vím. A pořád to nechápu. Také nechápu, na koho SAP reálně cílí, protože postavit řešení na tom, že se škáluje vertikálně, je docela zvláštní. Fakt nevím, jak chtějí škálovat obrovská nasazení. To asi jen nějakým monstrózním nasazením Power CPU.
Asi je SAP jiný level, no.
Zdar Max

[bEKO]

On ale SAP onprem vôbec nechce.. Všade tlačí cloud licencie - virtualizácia hyperscaleroch (AWS, Azure, Google,...), alebo ešte lepšie (pre nich) Public Cloud. A to je teda úplne iná pesnička.

[Max]

Hele, to nechce dnes žádný dodavatel, protože každý ví, že si za to samé v cloudu může říci 3x víc. A to se prostě vyplatí. Jsou v tom neskutečný prachy.
Zdar Max

[Salamek]

Narvat to do virtualizace a nafejkovat CPU nejde? (Setup dela SAP/Dodavatel?)

[Max]

Tohle fakt ne :). Pokud platíš šílený prachy za SAP, za support a zamilion věcí, tak fakt nechceš celé to kolečko provozovat na nepodporovaném hw.
Blog je jen postesk nad umělým omezováním a tlačením sračkohw a o pokrytectví (když si SAP vyjednal u Google cloud postavený na AMD)
Zdar Max

[pushkin]

SAP? To je to, co mělo ještě před pár lety GUI jak vystřižené z MS-DOSu?

[Max]

Co si ho pamatuji, cca posledních 12 let, tak vypadá stále stejně (jen vylepšují téma), tj. takto: SAP GUI s tím, že mají verzi v jave, takže na Linuxu ok, a pak mají webovou verzi (tu zatím nijak nepoužíváme).
V UI se většinou člověk pohybuje psaním čísel transakcí / čísel konkrétních sekcí, protože pokud je složitý strom a člověk má toho zpřístupněno hodně, je rychlejší zavolat transakci (např. napsat a dát enter: SM21), než se ve stromu proklikávat.
Zdar Max