Vlákno názorů k článku Go: minimalistický a překvapivě výkonný programovací jazyk od Yenya - Pěkný úvod, díky. Vypadá to, že není vůbec důležité,...

No vidíte, a přitom je spousta zařízení, které koupite letos, v roce 2018, a u kterých se očekává funkčnost v řádech desítek let, a tato zařízení mají primární způsob ovládání ve formě toho údajně mrtvého Javového appletu. Ne že by na tom pět let stará zařízení (očekávaná doba provozu dalších minimálně 15 let) byla lépe. Je teda pravda, že když budete na dodavatele dostatečně drsní, tak většinou připustí i existenci nějakého Modbusu, SNMP nebo BACnetu, nebo aspoň RS232/422/485 s nějakým proprietárním ovládáním, ke kterému po další dávce výhružek je ochoten vydat i nějakou dokumentaci (nebo teda zbude reverse engineering komunikace toho appletu).

Ale to už fakt odbočujeme od tématu Go. O Javě můžeme diskutovat jinde.

Zpátky ke Go: s tímto jazykem jsem se potkal u jednoho relativně triviálního projektu (firmware uploader pro RC vysílačku), kde na githubu v repozitáři měli zdroják, ale taky .exe a linuxovou binárku(!}. Zdroják se nepodařilo přeložit, protože (pokud si dobře pamatuju) to mělo snahu stahovat nějakou knihovnu/balík, která ale v systému už byla nainstalovaná z repozitářů Fedory. Linuxová binárka fungovala (dokonce i .exe pod Wine fungoval), tak jsem to dál neřešil, jen jsem si učinil mentální poznámku, že Go asi není to co bych chtěl používat.

-Yenya

Nicméně aplikace na vzduchotechniku mají obrovskou setrvačnost a natolik specifické požadavky, že je nejlepší je pouštět na PC vyčleněném přímo pro ně. Nedivil bych se, kdyby běžely v nejlepším na 10 let staré Javě a Windows Serveru 2003 s admin právy a Internet Explorerem 6. Aspoň taková je moje dávná zkušenost, když jsem o ně zavadil.

Diky za info. Ty applety ... ok, ty neznam. Ale Freemind pouzivam od Javy 6 (Fedora, Mint, eeebuntu, Windows XP) a tedy nevsiml jsem si, ze by padal nebo vyzadoval konkretni verzi. Pise to jen par hlasek typu:

STDOUT: User patterns file /home/tester/.freemind/patterns.xml not found.
STDOUT: User patterns file /home/tester/.freemind/patterns.xml not found.Nov 2

Já jsem freemind zkoušel používat tak kolem roku 2010, a nakonec jsem našel verzi Javy, se kterou fungoval, i když občas padal. Je pravda, že aktuálnější informace nemám. Pak jsem objevil vimoutliner, a od té doby pro podobné účely používám místo freemindu ten. Má to výhodu, že .otl soubor je lidsky čitelný a jde ho commitovat do gitového repozitáře tak, aby i jednotlivé změny v git diff dávaly smysl.

-Yenya

@Yenya

Trochu jsem se v tom ztratil, zamotala se do toho ta Java ... jaký má být smysl tvého sdělení?

"různé javové applety" - Applety jsou technologie skutecne poplatna dobe pred rokem 2000. Za vse mluvi jejich lonska deprekace a letosni kompletni odstraneni z Javy... achjo

Lžeš. Pokud dáš jako target Javu 7, tak kód zkompilovaný JDK 8 samozřejmě jde spustit na JRE 7.

Potom i kradu, ze? Neprogramuji pro Javu. Ale musim nejake Java aplikace provozovat, tazke mam jen prakticke zkusenosti. Uz jsem se naucil, ze si musim pohlidat, aby dodavatel nemel aplikace prelozene poslednim kompilatorem, ale kompatibilni s nasazenou verzi Javy. A ti programatori to porad nechapou, porad maji predstavu, ze nejnovejsi je nejlepsi. A proto mam radsi skriptovaci jazyky... Nejvetsi riziko je, kdyz dodavaji jen "drobnou" opravu na starsi SW.

Podobnou zkusenost mam i s go, tam jen jeste nevim, co je zdrojem nekompatibility...

"A proto mam radsi skriptovaci jazyky..."

mno to taky narazis - Python 2/Python 3, PHP, BASH atd.

golang ma, teoreticky, jen minimalni pozadavky na kernel, ale ty pozadavky jsou specifikovane velmi vagne (kernel novejsi nez 2.6.23). Dusledkem je, ze funkcni program prelozeny novejsi verzi prekladace prestava na casti systemu fungovat. Ten probem se objevuje znovu a znovu, zeptejte se Google na "runtime epoolwait failed". Ano, problem postihuje jen starsi systemy, takze pokud mate vzdy nejnovejsi distribuci, tak jste za vodou...

1) mozno tak 1.6 a aj ten pluje warningy ze ho za chvilu zrusia (stav z 10), myslim ze v 11 bude 1.7+
2) neviem ci sa verzia kniznice nekontroluje vobec, alebo len "tak trochu", ale urcite som videl a aj sam napisal programy ktore padali na NoClassDefFou­ndError

> TLB v případě statického linkování žádnou režii nemá, protože celý kód je v rámci jednoho virtuálního adresového prostoru.
Opravdu? TLB přece figuruje při překladu virtuálních na fyzické adresy. Jeden virtuální adresový prostor mají jak staticky tak dynamicky linkované programy. A i ty staticky linkované musí přes tlb protáhnout záznam pro každou použitou stránku.

Se statickým linkování funguje TLB nejefektivněji, jak může, veškerý kód je v adresovém prostoru vedle sebe. S dynamickým linkováním to neplatí, kód je v adresovém prostoru rozstrkán všude možně po více stránkách, režie TLB je vyšší.

Je vedle sebe jen ve virtuálním adresovém prostoru, ne? Fyzicky jsou stránky rozstrkané po fyzické paměti dost náhodně. Takže statiké linkování ušetří akorát pár stránek na hranicích dynamických knihoven.
A u dynamického linkování je možné v tlb nechat kusy pro sdílené části adresového prostoru. Třeba libc a podobně. Při statickém linkování znamená každé přepnutí procesu kompletní výmaz tlb.

Jde o densitu kódu. Když se volá funkce, tak se statickým linkováním je nějaká pravděpodobnost, že bude ve stejné stránce. S dynamickým linkováním je ta pravděpodobnost nulová, volání funkce z dynamické knihovny jde vždy do jiné stránky.

"Když se volá funkce, tak se statickým linkováním je nějaká pravděpodobnost, že bude ve stejné stránce. "

- Toto je snad ten nejhloupější argument, který jsem na téma static vs dynamic linking kdy slyšel. Ale můžeš v něm pokračovat a zkusit tu pravděpodobnost nějak dokázat a taky změřit jaký dopad to má celkově na výkon. Asi už znám výsledek - 0, protože procesor má cache (a instruction cache line je 64 bajtů a ne celá stránka) a je mu úplně jedno, kde ten kód je. Jo, kdybys zmínil např. .got (global offset table) overhead , TLS access overhead, a další věci, kde nastává overhead při dynamickém likování, tak bych to pochopil, ale stránkování IMO není problém a pokud tvoje aplikace nemá limit 4kB tak je to naprosto irelevantí.

Já ti to nebudu znovu vysvětlovat, když jsi to nepochopil. Zkus třeba i jiné zdroje, třeba ti to dojde: https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.performance/when_dyn_linking_static_linking.htm

A more subtle effect is a reduction in "locality of reference." You may be interested in only a few of the routines in a library, and these routines may be scattered widely in the virtual address space of the library. Thus, the total number of pages you need to touch to access all of your routines is significantly higher than if these routines were all bound directly into your executable program. One impact of this situation is that, if you are the only user of these routines, you experience more page faults to get them all into real memory. In addition, because more pages are touched, there is a greater likelihood of causing an instruction translation lookaside buffer (TLB) miss.