Vlákno názorů k článku Jaké je Intel Pentium 4 z roku 2005 v roce 2025? od 8665c891-f916-47c6-829f-8c9c4dbd - Jednojadrovy stroj je z pouzivatelskeho hladiska uz srot....

Jednojadrovy stroj je z pouzivatelskeho hladiska uz srot. Velmi rychlo a velmi rad som na to zabudol pri prechode na Core 2 Duo a zistil som to ked som kvoli niecomu musel stary desktop spustit. Ze nieco trva dlho je jedna vec, ale ked sa cele UI zasekne to je nieco ine. Samozrejme tomu ani nepomaha ani obmedzena velkosti pamate a srotenie HDD.

Zaseknuté GUI je chyba plánovače nebo jiného softwaru, ne pomalost procesoru.

A ktory OS teda nema chybu v planovaci? (spoiler alert - nie je to Windows 95, 98, ME, XP ani Linux)

A nie, nenapisal som, ze je to pomalost. Ale cim pomalsie jednojadrove CPU, tym horsie. Obviously.

5. 9. 2025, 12:40 editováno autorem komentáře

Třeba Apple dával velkou prioritu GUI už v MacOS Classic na Motorolách. Pokud bys na to byl citlivý, tak už v pravěkých dobách jsi měl na výběr ;-)

To je citlivost ak niekto odmietne roku pana 2025 downgrade na 1 jadro?

Napsal jsi „Ze nieco trva dlho je jedna vec, ale ked sa cele UI zasekne to je nieco ine.“

To zaseknuté GUI může mít v zásadě tři příčiny:

a) je potřeba najednou vykreslit příliš mnoho tlačítek, políček atd.
b) chyba plánovače - jiný proces/vlákno dostane prioritu, i když ji mělo mít spíš GUI vlákno
c) špatně napsaná aplikace, která v GUI vlákně dělá nějakou pomalou činnost (typicky IO) a ta blokuje to překreslování GUI

Jen případ a) znamená, že daný CPU nemá na kreslení daného GUI dostatek výkonu. Ale to nebývá příliš časté. Mnohem častěji se stává b) nebo c) – tyto chyby se dají výrazně rychlejším procesorem zamaskovat, ale reálně tam jsou pořád a jsou to chyby – kdyby ten software byl napsaný dobře, tak se GUI sekat nebude. Případ b) je věc nastavení priorit, ale obecně platí, že na desktopu chceš mít rychlé GUI a vše ostatní, ať CPU dělá ve „volném čase“. Případ c) se správně řeší tak, že se GUI řízeně zamkne, kreslí se tam třeba přesýpací hodiny a čeká se až pomalá úloha doběhne v jiném vlákně. Případně to GUI může být zamčené jen částečně a některé činnosti stále umožnit (programátorsky náročnější a náchylnější k chybám). Schválně píšu správně kurzívou, protože ono to správně sice je, ale reálný dopad na uživatele je dost podobný, jako když je to špatně – program se v danou chvíli nedá používat a je potřeba počkat, až pomalá úloha (např. uložení souboru) doběhne. Jen to správné řešení působí lépe a uživatel není nervózní, že to zamrzlo úplně, a uživatel-programátor ocení, že to je správně, programované někým zkušenějším a ne naivně nebo odfláknuté.

Alebo je multitasking nad moznosti hardveru. Ubehlo uz 20 rokov, tak je pochopitelne, ze niektori ludia si uz celkom nepamataju ako huciaci disk blikal oknami, start menu alebo trhal mysou. Alebo lag pri pisani pismenok do TTY.