Příspěvky

976

Windows a jiné systémy / Re:Macbook Pro 2015 i7 je rychlejsi nez Macbook 2020 Air i7

« kdy: 26. 04. 2021, 14:55:20 »

Ja bych to shrnul nasledovne.
Pozn.: Pouzivam Apple MacBook Pro 13" z 2020

1) Apple SW neni dokonaly a je na tom vicmene podobne jako vsichni ostatni. Apple jen profituje z toho, ze na majoritni vyuziti FB a YT je to cele perfektne odladne diky integraci HW se SW. Pamatujte, ze MacOS na jiny nez Apple dodany HW nenainstalujete (alespon oficialne). Takze s dodavanym HW to funguje lepe nez napr. s Win10 nainstalovanym na jakemkoliv vlastnim HW.

2) Apple notebooky jsou stylovky, ktere vic hledi na vzhled, vahu a delku vydrze na baterku (opet FB a YT optimalizace). Vsechny modely z posledni dobou maji poddimenzovane chlazeni na narocnejsi praci a proklamovany Turbo Boost je jen hodnota napsana na papire. MacBook Pro je na tom mozna lepe, ale za cenu mnohem vyssi hlucnosti a i tak zdaleka ne vyuziti plneho potencialu procesoru.
Vsak se podivejte na (opravdove) pracovni stanice (pripadne herni stroje) od Dell, Lenovo ci jinych. Ne nadarmo vypadaji jako MacBook z pred 10 a vice lety. Odpadni teplo z CPU (pripadne GPU) je potreba nejak odvest a jinak nez pres poradny chladic a vetracek to neumime.

Chapu ze iluze, kterou se nam vyrobci snazi podsunout je krasna, ale neni realna. Ac se nejaky vyvoj udal (mezigeneracne cca 2-5%), tak zdaleka nebyl schopny porazit mantru vyssi vykon -> vetsi produkce tepla. Ikdyz jsou dnesni procesory vykonnejsi a uspornejsi nez pred 5ti lety, tak zazraky neumi. Apple to zene do extremu kdy oseka chlazeni na minimum, v zajmu uzivatelskeho zazitku nastavi pokud mozno nulove otacky vetracku, nacpe tam radoby usporny procesor a pak se vsichni divi, ze kdyz po nem neco chteji, tak to nestiha a 100 stupnu je tam i pri serfovani ( => zpomalovani taktu => vykon niz, nez lepe chlazeny starsi CPU). Perpetuum mobile se snazi lidstvo objevit od nepameti, ale zatim to bud byli sarlatani nebo si na tom vylamali zuby.

Šmejd jsou ty CPU o pod Intelu. Navzdory všemu třeba MacBooky Pro 15” běží většinu času bez hluku větráku. Tragickou měly (první modely s touchbarem) jen klávesnici.

977

Windows a jiné systémy / Re:Macbook Pro 2015 i7 je rychlejsi nez Macbook 2020 Air i7

« kdy: 26. 04. 2021, 12:02:41 »

Vite co udelali v Apple na tom Airovi? Oni normalne vzali vetrak, a misto aby ho nechali chladit CPU, ze by k nemu pripojili Heatsink, tak tam nedali nic. Udelali to schvalne. Protoze kdo by jinak kupoval Macbook Pro s touchbarem, kdyz Air i7 by mel stejny performance. Ten vetrak proste fouka vzduch do prazdna.

Tak úplně stejné by to nebylo - intelové MBP 13" s touchbarem bývaly dělané na TDP 28W .. Intelové Airy od roku 2018 měly core-y s tdp 7-10W .. Ale jinak jo, leckomu by to stačilo kdyby to bylo normálně chlazené.

A co teprve MacBook 12" úplně bez větráku.

978

Hardware / Re:Intel NUC jako pracovní počítač

« kdy: 26. 04. 2021, 11:47:23 »

Pokud bych chtel neco maleho a vykonneho, tak bych zvazoval tohle Intel® NUC 9 Extreme Kit - NUC9i9QNX

Tohle je novější: https://simplynuc.co.uk/phantom-canyon/

979

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 26. 04. 2021, 10:57:47 »

Squeak Magma? Persistence by reachability [...] proxies are used to truncate the portions of the domain model that are not currently in memory

Koukám, že používání proxy objektů v obj. databázích je dost rozšířené. Jakpak by to asi udělali v C++ nebo Rustu

V Rustu makrem, tipnul bych si.

Proxy makrem? To bych chtěl vidět, to bude hodně sofistikované.

980

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 26. 04. 2021, 10:43:10 »

Squeak Magma? Persistence by reachability [...] proxies are used to truncate the portions of the domain model that are not currently in memory

Koukám, že používání proxy objektů v obj. databázích je dost rozšířené. Jakpak by to asi udělali v C++ nebo Rustu

981

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 26. 04. 2021, 00:59:01 »

ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.

Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.

A nechceš si napsat prototyp, ať se máme nad čím bavit? Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.

Chci. Je to aktuálně můj primární hobby projekt. Ale je málo času, tak o tom maximálně žvaním tady na rootu :-)

Ono by to nemělo být nijak zvlášť náročné, stačí nějaká atributová LR-gramatika na experimenty s interpretem Akorát pozor, atributové (LR-)gramatiky mohou být NP-těžké a generovat/přijímat i dost divné kontextové jazyky (v exp. čase) Ale jinak to je zábava, zvlášť má-li být jazyk staticky typovaný a přitom nepříliš ukecaný.

982

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 26. 04. 2021, 00:07:24 »

ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.

Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.

A nechceš si napsat prototyp, ať se máme nad čím bavit? Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.

983

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 22:15:06 »

Ve kterých databázích? Je vůbec nějaků důvod, proč by funkcionální API (streamy, map, reduce) nemělo být pro objekty v paměti  dostatečné?

Například db4objects nebo Realm. Ono to právě není pro objekty v paměti, je to pro objekty na disku v embedded databázi. Proto tam mají ty proxy objekty. No a podle mě jsou lepším řešením streamy, ale možná mi uniká nějaký zásadní důvod, proč jsou proxy objekty lepší.

984

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 21:29:31 »

ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tak mě v této souvislosti napadá, že místo kolekcí s proxy objekty, používaných v současných objektových databázích, by byly efektivnější streamy (bez proxy objektů).

985

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 10:14:06 »

Co zaznělo v diskuzi, tak se vývojáři objektových databází zaměřili na co nejlepší bezešvou integraci databáze s objektovým prostředím. Ale pak naráží na  efektivitu přístupu ke uložišti. SQL databáze na to jdou úplně z druhé strany. V prvé řadě řeší efektivitu přístupu k datům (minimalizace random IO, minimalizace přenesených dat po síti). Pokud mám data uložená lokálně (nedochází ke sdílení, nemusím řešit síťovou komunikaci, data jsou na ssd - nemusím řešit random IO), tak ten objektový přístup může fungovat. V opačném případě si to moc nedovedu představit. SQL databáze se snaží vývojáře izolovat od některých implementačních detailů (nemusí řešit jestli se použije seq io nebo random IO, nemusí řešit síťovou komunikaci) - a tím končí. Vůbec se nesnaží o nějakou integraci s vývojovým prostředím. To ani nejde. Nemám a ani nechci Postgres pro Javu, a jiný pro C#.

Většina objektových databází, co se aspoň trochu chytly, fungovala lokálně (embedded). DB servery, co se nabízely, byly často nadstavbou nad tím lokálním řešením. Co si tak matně pamatuju db4objects, tak si v paměti držela výsledky dotazů v kolekci proxy objektů, které se nahrály do paměti, jakmile k nim chtěl kód přistupovat.

986

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 02:34:11 »

Ano, nejspíš to tak je. Ale distr. transakce jsou celkem velká komplikace. Možná právě tento typ problémů tenhle typ řešení persistence zazdil? Na mě to působí jako málo muziky za hodně peněz. Každopádně nevím o žádné implementaci, která by nebyla jen akademickým experimentem. Ale úvahy to jsou bezpochyby zajímavé.

Mě se to nezdá. Na základě kanálů, které se začali používat v posledním roce dokazuješ, že se to proto neujalo?

IMHO se to neujalo proto, páč na začátku jsme u C byli rádi, když přišel GC. Pozdějc přišla móda dynamický jazyků se svým "hele jak hezky se to dá napsat". A pak už se usadil ten mindset, že data se vytahují a vrací z/do persistence. Technické obtíže bych v tom nehledal.

Nic nedokazuju, ani na to nemám vyhraněný názor a nejspíš vůbec nejde říct jeden důvod neúspěchu. Nicméně v tomto případě je mnoho technických komplikací, které nějakou dostatečně robustní implementaci sabotují. Už jen u těch distr. objektů (bez úložiště) vznikaly problémy se správou paměti, asynchronním zpracováním apod.

Enterprise Objects Framework je asi jediná technologie, která ty největší problémy se ctí překonala.

987

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 02:05:18 »

Kód: [Vybrat]

let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }

A teď mi příjemce na druhé straně síťového kanálu změní size (řekněme, že hodnotu zmenší). Co se stane s tím for-cyklem?

Jako že za běhu cyklu změní size použitý v podmínce cyklu? Stane se IMHO to stejné jako pokud na tu size sáhnu z jiného vlákna?

Viděl bych to tak.

Některé jazyky pro foreach vytvoří kopii té kolekce (varianta optimistické transakce).

To je jen ilustrace možných problémů. V rámci jedné aplikace se dají změny z jiného vlákna (nebo korutiny) ohlídat (v Rustu v době překladu), ale nad změnami na jiném stroji už člověk kontrolu nemá. Vytvoření kopie range řešení není, když ten objekt už bude menší.

Ale v principu to jsou úplně stejné problémy konkurentního přístupu jako u jediné aplikace, ne? Které by šly řešit nějakou distribuovanou transakcí?

Ano, nejspíš to tak je. Ale distr. transakce jsou celkem velká komplikace. Možná právě tento typ problémů tenhle typ řešení persistence zazdil? Na mě to působí jako málo muziky za hodně peněz. Každopádně nevím o žádné implementaci, která by nebyla jen akademickým experimentem. Ale úvahy to jsou bezpochyby zajímavé.

988

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 01:55:01 »

Kód: [Vybrat]

let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }

A teď mi příjemce na druhé straně síťového kanálu změní size (řekněme, že hodnotu zmenší). Co se stane s tím for-cyklem?

Jako že za běhu cyklu změní size použitý v podmínce cyklu? Stane se IMHO to stejné jako pokud na tu size sáhnu z jiného vlákna?

Viděl bych to tak.

Některé jazyky pro foreach vytvoří kopii té kolekce (varianta optimistické transakce).

To je jen ilustrace možných problémů. V rámci jedné aplikace se dají změny z jiného vlákna (nebo korutiny) ohlídat (v Rustu v době překladu), ale nad změnami na jiném stroji už člověk kontrolu nemá. Vytvoření kopie range řešení není, když ten objekt už bude menší.

989

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 01:27:46 »

Co když třeba najdu objekt v kolekci, pošlu ho kanálem (CSP) na jiný stroj a tam ho změním?

Když ho pošlu tím kanálem, ztratím nad ním vlastnictví? Pokud ne, tak se mi změní v instanci, ze které jsem jej poslal, i v druhé instanci.

No právě, když chci, aby se změnil, není úplně jednoduché to naimplementovat. Teoreticky to vypadá hezky, ale všichni víme, jak spolehlivé jsou sítě.

To je jistě problém. Ale nesouvisí s mou vizí. Má vize je: udělá to engine/jazyk. Aktuální situace: musím si to naprogramovat sám.

OK. Teď už jen brainstormuju, ale co když mám třeba:

Kód: [Vybrat]

let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }

A teď mi příjemce na druhé straně síťového kanálu změní size (řekněme, že hodnotu zmenší). Co se stane s tím for-cyklem?

990

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 01:20:05 »

Co když třeba najdu objekt v kolekci, pošlu ho kanálem (CSP) na jiný stroj a tam ho změním?

Když ho pošlu tím kanálem, ztratím nad ním vlastnictví? Pokud ne, tak se mi změní v instanci, ze které jsem jej poslal, i v druhé instanci.

No právě, když chci, aby se změnil, není úplně jednoduché to naimplementovat. Teoreticky to vypadá hezky, ale všichni víme, jak spolehlivé jsou sítě.