Kod natywny - definicja

Znalazłem następującą definicję tego zagadnienia:

Natywny - łac. nativus "urodzony, wrodzony". Natywny program, to program "wrodzony" w daną platformę sprzętowo-programową, a więc działający na niej bezpośrednio, bez pomocy innych programów, takich jak emulatory czy maszyny wirtualne. To inaczej w przybliżeniu "dedykowany". Dla przykładu - natywny program dla AmigaOS 4.0 to program, który został skompilowany dla procesora PowerPC i systemu AmigaOS 4.0. Inaczej mówiąc - natywny program lub system, to taki, który działa bez konieczności emulacji procesora innej maszyny i/lub stosowania wrapperów.

Wniosek jest taki, że aplikacja napisana w C# nie jest natywna, bo potrzeba .NET'a, aplikacja z C++ Buildera, czy Delphi jest natywna, bo poleci na "gołym" Windowsie.
Z drugiej strony po przeczytaniu definicji Wrappera na Wikipedii nie jestem już taki pewien jak to jest z tą natywnością, a VCL'em.
http://pl.wikipedia.org/wiki/Wrapper
Z trzeciej strony na stronie Embarcadero jest napisane, że w C++ Builderze jednak można tworzyć aplikacje natywne.
http://www.embarcadero.com.pl/produkty/cbuilder/

Wytłumaczy mi ktoś jak to jest tak dokładnie?

Wniosek jest taki, że aplikacja napisana w C# nie jest natywna, bo potrzeba .NET'a, aplikacja z C++ Buildera, czy Delphi jest natywna, bo poleci na "gołym"

Gołym tzn.? Delphi jest natywne dla Windowsa, a assembler dla x86/x64. Coś jest natywne dla czegoś, np. .NET jest natywne dla środowiska .NET .

Z drugiej strony po przeczytaniu definicji Wrappera na Wikipedii nie jestem już taki pewien jak to jest z tą natywnością, a VCL'em.

Ale wrapper to coś co ujednolica albo zastępuje.
WinApi ma wrappery ale sam w sobie wrapperem nie jest.
Przykładem wrappera jest wine.

Czyli generalnie pisząc w Javie wydzielony plik JAR nie jest natywny dla Windowsa, ale jak skleisz JARa z JVMem to już masz aplikację natywną :D

Powiedziałbym tak: natywny jest program, który jest przechowywany w formie kodu maszynowego danego procesora, i który nie wymaga do uruchomienia przetłumaczenia na zupełnie inny kod, ani znacznych modyfikacji (najwyżej aktualizacji wskaźników – tzw. relokacja). Załadowany kod jest wykonywany przez procesor bezpośrednio, czyli uruchomienie kodu polega na wykonaniu instrukcji skoku w miejsce, gdzie został załadowany. Kod jest również przechowywany w całości, a nie generowany na bieżąco dopiero podczas pracy programu.

Pod taką definicję Java czy C# na pewno się nie załapuje, choć można się spierać jak wygląda sprawa użycia ngen…

Powiedziałbym tak: natywny jest program, który jest przechowywany w formie kodu maszynowego danego procesora, i który nie wymaga do uruchomienia przetłumaczenia na zupełnie inny kod, ani znacznych modyfikacji (najwyżej aktualizacji wskaźników – tzw. relokacja). Załadowany kod jest wykonywany przez procesor bezpośrednio, czyli uruchomienie kodu polega na wykonaniu instrukcji skoku w miejsce, gdzie został załadowany. Kod jest również przechowywany w całości, a nie generowany na bieżąco dopiero podczas pracy programu.

A jak pociągne po nim UPX? Przecież wtedy mój kod jest skompresowany/zaszyfrowany. Nie jest on przechowywany na dysku w postaci wykonywalnej, tylko jest stub dekompresujący. Czy to wtedy nie jest kod natywny? Jest.

No to w końcu badamy natywność konkretnego egzemplarza programu czy też może języka? W zasadzie to każdy język można skompilować do postaci tzw natywnej.

A co powiecie o LLVM? Natywne czy nie?

Uwielbiam gadanie o takich drobnostkach

WinAPI to też częściowo wrapper na kernel NT, bo winapi jądrem systemu nie jest.

Napisałem przecież że winapi posiada wrappery, tak jak każde API które jest od dłuższego czasu w użyciu ze względów historycznych etc. Zresztą, wszystko korzysta z czegoś więc czy wszystko jest wrapperem? :P (bo tak by wynikało z twojej wypowiedzi jakoby winapi było wrapperem na kernel).

No to w końcu badamy natywność konkretnego egzemplarza programu czy też może języka? W zasadzie to każdy język można skompilować do postaci tzw natywnej.

Tak samo jak każdy natywny można zacząć sobie jakoś emulować.

Czyli generalnie pisząc w Javie wydzielony plik JAR nie jest natywny dla Windowsa, ale jak skleisz JARa z JVMem to już masz aplikację natywną

To jeszcze nic: http://en.wikipedia.org/wiki/PicoJava - są procesory dla których bytecode javy jest natywny.

A co powiecie o LLVM? Natywne czy nie?

Ja się będę skłaniać ku mojej teorii że coś jest natywne dla czegoś.

a czym taka dekompresja się różni od kompilacji bytecode'u przed uruchomieniem programu?

Tym że to nie jest konwersja a jedynie odtworzenie danych które są tam zawarte.

No to ciekawe, bo np w przypadku http://shootout.alioth.debian.org/u64q/benchmark.php?test=fasta&lang=all język C++ na pewno na natywny nie wygląda.

Są jeszcze inne ciekawe przypadki.

http://shootout.alioth.debian.org/u64q/benchmark.php?test=threadring&lang=all
Najszybsze implementacje omijają chyba w całości wbudowane w system mechanizmy.

http://shootout.alioth.debian.org/u64q/benchmark.php?test=binarytrees&lang=all
Tutaj w sumie też - jedyne rozwiązania C/ C++, które są szybsze od Javowych korzystają z pul obiektów (Javowa wersja nie korzysta z pul). Te które korzystają są sporo (2x - 3x) wolniejsze od rozwiązania Javowego.

Haskell produkuje kod natywny (GHC), a jest wolniejszy od Javy.

VMki mają więc nawet potencjał na produkowanie kodu szybszego niż natywny dzięki temu, że mogą omijać prawie w całości wolne mechanizmy wbudowane w system. Ponadto widzę jeszcze więcej możliwości:

• dynamiczna dewirtualizacja/ deoptymalizacja/ itp - jeśli funkcja przyjmuje powiedzmy parametr typu List, to czasem może to być ArrayList a czasem LinkedList. Załóżmy, że przez 5 min jest to ArrayList, a przez następne 5 min jest to LinkedList. VMka ma możliwość przekompilowania kodu po 5 min i zoptymalizowania go dla LinkedList zamiast dla ArrayList. Kompilacja statyczna tego nie umożliwia,
• switche i tym podobne: załóżmy że mamy switcha na 10 możliwości i przez pierwsze 5 min najczęstsza jest pozycja 3. a przez następne 5 min najczęstsza jest pozycja 7. Sytuacja jest analogiczna jak powyżej.
• fragmentacja pamięci - standardowo w x86 tłumaczeniem adresów logicznych i fizycznych zajmuje się sam procesor i to przy wykonywaniu każdej instrukcji ładowania/ zapisywania pamięci. Można wyrzucić ten mechanizm z CPU, zamieniając go na np kolejne jednostki obliczeniowe, a sam mechanizm zaimplementować programowo. VMka mogłaby dynamicznie optymalizować kod dla pofragmentowanej pamięci jak i dla niepofragmentowanej, ponadto odśmiecacz generalnie defragmentuje pamięć, mógłby ją też w odpowiedniej kolejności układać, tak aby można było zoptymalizować odwołania do pamięci,
• i tak dalej, moim zdaniem dzisiejsze VMki typu JVM mają jeszcze długą drogę przed sobą jeśli chodzi o dynamiczne optymalizacje,

Ogólnie rzecz biorąc: kryterium szybkości wykonywania kodu jest kiepskim kryterium dla określenia poziomu natywności kodu.

Natywność można by w sumie zmierzyć ilością warstw abstrakcji nad sprzętem/ systemem - im mniej warstw tym bardziej natywny kod.

@Wibowit, czy potrafisz odróżnić "da się oprogramować" od oprogramowano przez kogoś?
"VMki mają więc nawet potencjał na produkowanie kodu szybszego niż natywny" - czy pisząc w C nie dasz rady oprogramować żadnego z tych tryków?

Oczywiście, że się da, przecież większość JVMów jest napisana w C/ C++ :] Problem w tym, że ciężko nazwać dynamicznie rekompilowany kod natywnym.

Można jeszcze zrobić rozróżnienie na dynamiczną rekompilację (w której kod nie wie, że jest dynamicznie rekompilowany) i samomodyfikujący się kod (w którym ręcznie zastępuje się rekompilację). Niestety ma to sporą wadę: trudność oprogramowania czegoś takiego jest ogromna, a zmniejszenie narzutu (o ile w ogóle) w stosunku do VMki minimalne.

To KOD jest natywny dla danego procesora, to po prostu ciąg instrukcji, które procesor wykonać. Natywny może być zatem wynik działania kompilatora.
Nie ma natywnych języków, bo to nie od języka zależy, czy zostanie przekształcony do właściwej dla procesora postaci, czy nie. Asembler chyba również nie jest kodem natywnym, nie?