Ryan Gordon chce v Linuxu univerzální spustitelné binární soubory

Není v podstatě žádný důvod, proč by to v paměti mělo zabírat více místa.

Ehm, Firefox je z hodne velke casti psany v Javascriptu, ktery interpretuje XUL Runner (Gecko). Pouze core veci jsou psane v C++ (navic hodne legacy kodu z Netscape). Takze kdyby byly tyto casti psane v Jave s pouzitim JIT, mozna by nam liska bezela naopak rychleji;-). No offense

Nechci flamovat, ale kód co jenom počítá je v Javě rychlejší než v C++. Samozřejmě musíme uvážit dobu startu a JIT a kompilaci C++ kódu pro „univerzální x86“ nebo pro přímo ten můj procesor.

Vzdy sem upozornoval na to, ze problem rychlosti firefoxu neni v javascriptu, ale ve vykreslovani.

firefox je panda cervena

Nikdo neříkal psát v nich OS. Aplikace stačí ;)

Zvláštní názor, nechci být nezdvořilý, ale k čemu je dobré, že program je v nativním kódu, je to nějaký psychologický efekt? A s tou rychlostí, kdyby se před tak 10 roky výlučně používaly bytecody a VM, dnes by všechny programy pracovaly několikanásobně rychleji, protože bychom nebyli svázání kompatibilitou s neefektivní architekturou. Hardwaráři by mohli místo tuny tranďáků, který řeší jen, jak x86 kód zpracovat rozumnou rychlostí tam hodit další výpočetní jednotky a efektivnější instrukce. A kdyby se něco neosvědčilo? Tak by se to přestalo používat… Takže s rychlostí je to přesně naopak a čím dřív se odprostíme od nativního kódu, tím dřív bude možné přejít na výkonnější procesory…

Jinak jeden z největších problémů dneska řešených je jak programy paralelizovat. Pokud jedno jádro zabiju tím, že na druhém ten program poběží 2× rychleji, tak jsem happy. A pokud jedno jádro ze 4 zabiju tím, aby program běžel i na dalších třech, místo toho, aby běžel jen na jednom, tak jsem happy³.

Jestli nekdo chce prenositelnou aplikaci tak at to napise v jave…to celkem funguje:) Jinak si myslim, ze vzit kod a prelozit ho pro jinou architekturu neni takovy problem…ale musi se na to nejspis myslet uz pri vyvoji aplikace…

„…Jinak si myslim, ze vzit kod a prelozit ho pro jinou architekturu neni takovy problem…“ No, pokud by ho opravdu stačilo vzít a spustit make, tak by to problém nebyl. Ovšem realita je výrazně jiná. Už si někdy zkoušel portovat nějakou reálnou aplikaci na odlišnou architekturu? Myslím, že ne.

No…chapu ze kdyz pouzivaji treba nejake knihovny, ktere pro danou architekturu neexistuji tak to problem je…ja jako vyvojar do toho moc mluvit nemuzu jedine co jsem zkousel prelozit na vice platformach (x86 a x86_64 chapu…to neni nijak reprezentativni) byl muj jabber klient v c++/Qt a bylo to v pohode… ale jak rikam chapu ze u velkych projektu to muze byt problem… nicmene pak je tady ta java :)

že ho některé trubky neumí používat je věc jiná :-) Jmenuje se to Makefile a obstarává to ty starosti okolo. Tady krásný a přehledný příklad.

http://www.openbsd.org/…use/Makefile?…

A další expert. Nevdí ti, že samotný Makefile nic neřeší a že podstatnej je ten zdroják v C-čku?

No asi tim chtel jemne naznacit, ze Unixy jsou v C a tudiz neni problem s prenositelnosti jako napriklad u http://www.netbsd.org/…ackages.html#…

ať si to napíše, to je jednoduché…

LLVM je něco jako JVM pro C a C++ a umí to i kompilaci z (platformově nezávislého) bajtkódu do binárního kódu dané platformy. To je podle mě řešení, ne univerzální binárky.