Vlákno názorů k článku Rust: funkce, lambda výrazy a rozhodovací konstrukce match od Pavel - Je vhodny Rust pro numericke vypocty? Obsahuje nejake...
-
Inkvizitor (neregistrovaný)
Pokud vím, tak konkrétně Julia si nevede vůbec špatně a snaží se ty low level konstrukce optimalizovat, viz třeba http://julialang.org/benchmarks/
Tudíž by mě zajímalo, jestli to někomu přijde jako taková tragédie, aby lovil zrovna ve vodách Rustu, který je podle mě z hlediska zápisu pro tyto účely míň vhodný, než třeba Python+Cython, Julia nebo já nevím - třeba Nim.
-
Radek Miček (neregistrovaný)
> Pokud vím, tak konkrétně Julia si nevede vůbec špatně
Otázkou je, jak jsou optimalizace v Julii robustní - aby člověk nestrávil hodiny hledáním důvodů, proč se určitý kousek kódu nezoptimalizoval, jak měl - viz třeba http://zverovich.net/2016/05/13/giving-up-on-julia.html nebo https://www.reddit.com/r/Julia/comments/3x6tg9/why_is_this_loop_in_julia_slower_than_the_python/
-
Inkvizitor (neregistrovaný)
Jasně, je to interpretovaný jazyk s JIT, jeho JIT je možná v něčem horší než JIT pro Python z odkazu, má pomalejší rozjezd než třeba Python, Julia je ve verzi 0.5 a na nedokonalost má nárok. Otázka je, co z toho komu vadí. Docela bych souhlasil s pohledem, který zde psali jiní - na prototypování (třeba) Python, na velkou aplikaci, která pravidelně chroustá spoustu dat, (třeba) Rust.
-
asdf (neregistrovaný)
Nějaká nuimerické a algebraické knihovny tu jsou, ale je to dost fragmentované:
num - další numerické typy (bigint, complex, ...)
nalgebra - dobře optimalizovaná lineární algebra pro nízké dimenze
ndarray - N-dimenzionální matice a metody na nichLetos na RustConf byli nějací chlapíci s machine learningem a docela shrnuli co od toho očekávat:
https://www.youtube.com/watch?v=lY10kTcM8ek
Není to moc pro prototypování protože to není dynamickty typovaný jazyk, není interpretovaný a nemá moc vizualizační nástroje. Ale je rychlý, dobře se paralelizuje, dobrý networking, error handling atd. -
kozzi11 (neregistrovaný)
Kasli na rust a pouzivej jazyk D :D.
http://mir.rocks
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html -
mr president (neregistrovaný)
Muzou tam byt navic treba ruzne run-time testy, napr. meze poli, ukazatele, ...
Kdyz jsem kdysi cetl o vypujcenych ukazatelich v Rustu tak me treba pripadalo ze nektere veci budou muset testovat v run-time. Ale treba jsou chytri a vyresili to jinak... :-)
Potom podle semantiky jazyka nemusi nektere veci jit implementovat tak efektivne, treba dynamic dispatch. Nerikam ze tohle je pripad Rustu.
Dalsi co me napada je treba pattern matching. Kdybys to v C++ delal "rucne" tak tam treba vyuzijes nejakou znalost problemu a udelas to lip...
-
Nebo naopak růstu (třeba časem) vymyslí nějakou mikrooptimalizaci a udělá to lépe než vývojář v C++. Podobně jako dnes GCC někdy poráží vývojáře v assembleru (pokud nejsou extrémně zkušení), protože kompilátory jsou v některých mikrooptimalizacích dobré (resp. vývojáři kompilátorů jsou dobří) a optimalizovat to ručně by si vyžádalo tunu zkušeností a času.
-
karel (neregistrovaný)
"Muzou tam byt navic treba ruzne run-time testy, napr. meze poli, ukazatele, ..." " ... tak me treba pripadalo ze nektere veci budou muset testovat v run-time... " " ... Potom podle semantiky jazyka nemusi nektere veci jit implementovat tak efektivne,... " " ... Dalsi co me napada je treba pattern matching. ..."
Typická ukázka předčasné optimalizace založené na dojmech. Víc k těm nesmyslům asi nemá cenu dodávat.
-
mr president (neregistrovaný)
a jeje, nekomu jsem narusil belief system, aby me ted nezacal kamenovat ;-)
Jinak to co jsem psal neni mysleno jako kritika Rustu, spis me slo o to ukazat ze kdyz 2 jazyky maji stejny backend tak to neznamena ze budou stejne efektivni... ;-)
Kdyz vezmu napr tu kontrolu mezi poli - vubec nevim jestli to rust dela nebo ne - ale jazyk ktery to dela nebude tak efektivni jako jazyk ktery to nedela, i kdyz bude mit stejny backend.
-
You have completely missed the point. Jde o princip, že stejný backend nemusí zajistit stejný výkon, ne o konkrétní případ polí.
Stejně tak Java, Groovy a Scala nad stejným JVM mohou mít jiný výkon, a to někdy dost zásadně. Ano, některé výkonové charakteristiky a optimalizace budou mít podobné, ale dá se – i mezi Javou a Scalou – najít spousta rozdilů, někdy i velkých.
-
JerryG (neregistrovaný)
Tak jsem udelal maly testik, aby to nebylo mlaceni prazdne slamy, jednoducha smycka, sum square pro i od 0 do milionu, rust vs c, rustc vs clang, bez optimalizace c o rad rychlejsi, s optimalizaci O3 taky c rychlejsi, ale nechce se mi hrabat v rust deklaracich, abych zjistil presnejsi rozdily pro O3. Jen tak pro info, size rust exe codu 240kB, size c exe codu 8kB.
-
JerryG (neregistrovaný)
Kdyz mi das mail, tak ti to poslu, rust dnes vidim asi tak po treti, takze jestli je to zcela identicke, to fakt nevim, vysledky jsou kazdopadne stejne, mozna deklarace promennych neni identicka. Kazdopadne zaklad pro rust jsem vzal v tomto clanku, napsat c code je easy. Kompilovano pod Fedorou 24, rustc i clang jsou defaultni verze z Fedory. V nejhorsim to sem muzu pastnout, zdrojaky jsou kratke.
-
tisnik (neregistrovaný)
zkus optimalizace, Rust schvalne by default neoptimalizuje vubec, viz FAQ:
Why is my program slow?
The Rust compiler doesn’t compile with optimizations unless asked to, as optimizations slow down compilation and are usually undesirable during development.:
Ale jinak z takto kratkeho programu se moc nezjisti, protoze 6 nebo 10 ms je tak nizka hodnota, ze se do toho nutne zapocita start runtime (to je problem vetsiny mikrobenchmarku). Zacal bych s necim slozitejsim, co psali lidi, kteri ten ktery jazyk znaji:
-
kozzi11 (neregistrovaný)
Moje testy:
Kod D:
import std.range: iota;
import std.stdio : writeln;
import std.algorithm : fold;enum MAX = 1_000_000UL;
void main()
{
iota(0, MAX).fold!"a + b^^2".writeln;
}D (ldc bez optimalizace)
13msD (ldc optimalizace)
3msC (clang bez optimalizace)
13msC (clang optimalizace)
2msrust (rustc bez optimalizace)
48msrust (rustc optimalizace)
5ms -
jelenice (neregistrovaný)
Rust má podstatně větší standardní knihovnu než C a další věci co v C nejsou (např. panic! macro) a v základu linkuje staticky. Pokud opravdu potřebuješ minimální velikost, musíš si s tím vyhrát trochu víc (hledej bare metal rust). Jinak těžko říct cos tam proved, protože imho jenom smyčka by vyšla zhruba stejně rychlá i v Javě.
-
asdf (neregistrovaný)
Co se velikosti binárka týče, https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html je pěkný čtení.
TL;DR: Rozebírá se tam velikost "Hello World" kde Rust má 650kB a C jen 8,5kB. Je tam něco o debugovacích symbolech (moc nevim co to je) - obsahuje jemalloc pro dynamické alokace ikdyž nejsou v programu, backtrace a jeho stringy ikdyž v programu není panic. Po odstranění dohodle je to na 113kB. Taky knihovny jsou linknutý staticky a ne dynamicky jako u C. Rust má nějaký závislosti na standardní C knihovně, linkuje je staticky, jakýmsi příkazem kompilátoru se dá linknout dynamicky a pak je Rust stejně velký jako C. -
Pavel TišnovskýZlatý podporovatelDebug symboly je možné odstranit příkazem "strip", stejně jako u jiných binárek, třeba u céčka přeloženého s přepínačem -g). Tím se velikost sníží na cca 360kB (v tom článku to zmiňují). Nevýhodou je, že při ladění přes gdb (lze volat i rust-gdb) nebudou jednoduše k dispozici názvy funkcí atd. gdb pouze lakonicky vypíše:
Reading symbols from hello_world...(no debugging symbols found)...done.
A i tak základní příkazy jako "break main" už nebudou funkční:
(gdb) break main
Function "main" not defined.Jde to sice obejít, pro distribuci aplikace je možné použít externí symboly (distra to tak běžně dělají, protože většina lidí asi debug symboly nevyužije, prakticky jen pro ABRT, takže proč zaplňovat disk objemnými soubory), ale pro vývoj to asi nemá cenu řešit.
-
Pavel TišnovskýZlatý podporovatel
Zapomněl jsem poděkovat za ten odkaz, skutečně pěkné čtení. Takže dík!
-
Ivan (neregistrovaný)
Tezko rict kam az ten optimalizator "vidi". "Moderni" C++ ma tu vyhodu, ze vsechno jsou jen sablony, ktere obsahuji pouze inline metody. Spojenim takovych sablon pak vznikne velice dlouhy kod, na kterem ze muze opimalizator vyradit. Dneska se ale daji podobnym zpusobem optimalizovat i non-inline funkce. Za urcitych okolnosti optimalizotor vi, ze po zavolani nejake jednoduche funkce zustanou registry nezmenene.
-
Petr Bolf (neregistrovaný)
No, když Rust, C++, D a další budou kompilovat přes LLVM, pak se lišit moc nebudou a důležité pro volbu jazyka bude to, jak se v něm dělá. To je jednak syntax (každému vyhovuje jiná, někdo se nevzdá té céčkovské, někomu se líbí Rust) a pak (asi hlavně) práce s knihovnama.
A Rust je v tomhle dobrý (poučený z Javy, Pythonu, Nodejs, ....) a přes cargo nabízí snadnou práci s knihovnami (nevím proč tomu říkají crates).
V C/C++ už jsem nějaký rok nedělal, ale s knohovnama byl někdy problém. Hlavně s různými verzemi knihoven.
ČLÁNKY DO MAILU
