Kompilowanie i optymalizacja dla różnych architektur docelowych

Tak, to możliwe. Skompiluj wszystkie różnie zoptymalizowane wersje jako różne dynamiczne biblioteki ze wspólnym punktem wejścia i zapewnij plik wykonywalny, który ładuje się i uruchamia poprawną bibliotekę w czasie uruchamiania, poprzez punkt wejścia, w zależności od pliku konfiguracyjnego lub innych informacji.

Czy Można używać skryptu?

Możesz wykryć PROCESOR za pomocą skryptu i dynamicznie załadować plik wykonywalny, który jest najbardziej zoptymalizowany pod kątem architektury. Może również wybrać wersje 32/64 bitowe.

Jeśli używasz Linuksa, możesz odpytywać procesor za pomocą

cat /proc/cpuinfo

Prawdopodobnie możesz to zrobić za pomocą skryptu bash / perl / python lub hosta skryptów windows w systemie windows. Prawdopodobnie nie chcesz zmuszać użytkownika do zainstalowania silnika skryptów. Taki, który działa na OS po wyjęciu z pudełka IMHO byłby najlepszy.

W rzeczywistości, w systemie windows prawdopodobnie chciałbyś napisać małą aplikację C#, aby łatwiej było odpytywać architekturę. Aplikacja C# może po prostu wywołać dowolny plik wykonywalny.

Alternatywnie możesz umieścić różne wersje kodu w bibliotekach dll lub obiektach współdzielonych, a następnie dynamicznie załadować je w oparciu o wykrytą architekturę. Tak długo, jak mają ten sam podpis połączenia powinno działać.

Spójrz na liboil: http://liboil.freedesktop.org/wiki /. Może dynamicznie wybierać implementacje obliczeń związanych z multimediami w czasie wykonywania. Może się okazać, że możesz liboil się, a nie tylko jego techniki.

Skoro wspomniałeś, że używasz GCC, zakładam, że Twój kod jest w C (lub c++).

Neil Butterworth zasugerował już utworzenie osobnych bibliotek dynamicznych, ale wymaga to pewnych nietrywialnych rozważań międzyplatformowych (ręczne ładowanie bibliotek dynamicznych jest INNE na Linuksie, Windows, OSX itp., a poprawienie tego prawdopodobnie zajmie trochę czasu).

Tanim rozwiązaniem jest po prostu zapisanie wszystkich wariantów za pomocą unikalnych nazw i użycie wskaźnika funkcji, aby wybrać właściwy w czasie wykonywania.

Podejrzewam, że dodatkowa dereferencja spowodowana wskaźnikiem funkcji będzie amortyzowana przez rzeczywistą pracę, którą wykonujesz (ale będziesz chciał to potwierdzić).

Ponadto uzyskanie różnych optymalizacji kompilatora będzie prawdopodobnie wymagało innych .c/.pliki cpp, a także niektóre przekręcanie narzędzia do budowania. Ale to chyba mniej ogólna praca niż oddzielne biblioteki(które potrzebowały tego już w takiej czy innej formie).

Ponieważ nie określiłeś, czy masz limity na liczbę plików, proponuję inne rozwiązanie: skompilować 5 plików wykonywalnych, a następnie utworzyć szósty plik wykonywalny, który uruchomi odpowiedni plik binarny. Oto jakiś pseudokod, dla Linuksa

int main(int argc, char* argv[])
{
    char* target_path[MAXPATH];
    char* new_argv[];
    char* specific_version = determine_name_of_specific_version();
    strcpy(target_path, "/usr/lib/myapp/versions");
    strcat(target_path, specific_version);

    /* append NULL to argv */
    new_argv = malloc(sizeof(char*)*(argc+1));
    memcpy(new_argv, argv, argc*sizeof(char*));
    new_argv[argc] = 0;
    /* optionally set new_argv[0] to target_path */

    execv(target_path, new_argv);
}

Na plus, takie podejście pozwala na zapewnienie użytkownikowi zarówno 32-bitowych, jak i 64-bitowych binariów, w przeciwieństwie do wszelkich metod bibliotecznych, które zostały zaproponowane. Na minus nie ma execv w Win32 (ale dobra emulacja w cygwin); w systemie Windows musisz utworzyć nowy proces, a nie ponownie wykonać bieżący.

Wspomniałeś o kompilatorze Intela. To zabawne, ponieważ domyślnie może zrobić coś takiego. Jest jednak pewien haczyk. Kompilator Intela nie wstawił sprawdzeń pod kątem funkcjonalności SSE. Zamiast tego sprawdzili, czy masz konkretny chip Intela. Nadal byłby powolny przypadek domyślny. W rezultacie procesory AMD nie otrzymałyby odpowiednich wersji zoptymalizowanych pod kątem SSE. Wokół krążą hacki, które zastąpią sprawdzenie Intela odpowiednim sprawdzeniem SSE.

32/64 bity różnica będzie wymagała dwóch plików wykonywalnych. Zarówno format ELF, jak i PE przechowują te informacje w nagłówku plików wykonywalnych. Nie jest zbyt trudne, aby uruchomić wersję 32 bitów domyślnie, sprawdź, czy jesteś na systemie 64 bitowym, a następnie uruchom ponownie wersję 64 bitową. Ale może być łatwiejsze utworzenie odpowiedniego dowiązania symbolicznego w czasie instalacji.

Pozwala podzielić problem na dwie części składowe. 1) Tworzenie zoptymalizowanego kodu zależnego od platformy i 2) budowanie na wielu platformach.

Pierwszy problem jest dość prosty. Enkapsuluje kod zależny od platformy w zestaw funkcji. Stwórz inną implementację każdej funkcji dla każdej platformy. Umieść każdą implementację w swoim własnym pliku lub zestawie plików. Jest to najłatwiejsze dla systemu budowania, jeśli umieścisz Kod każdej platformy w osobnym katalogu.

W części drugiej proponuję przyjrzeć się Gnu Atuotools(Automake, AutoConf i Libtool). Jeśli kiedykolwiek ściągnąłeś i zbudowałeś program GNU z kodu źródłowego, wiesz, że musisz go uruchomić ./ configure przed uruchomieniem make. Celem skryptu configure jest 1) sprawdzenie, czy Twój system posiada wszystkie wymagane biblioteki i narzędzia potrzebne do zbudowania i uruchomienia programu oraz 2) dostosowanie plików Makefile dla docelowej platformy. Autotools to zestaw narzędzi do generowania konfiguracji scenariusz.

Używając autoconf, możesz tworzyć małe makra, aby sprawdzić, czy maszyna obsługuje wszystkie instrukcje procesora, których potrzebuje twój kod zależny od platformy. W większości przypadków makra już istnieją, wystarczy skopiować je do skryptu autoconf. Następnie automake i autoconf mogą skonfigurować pliki Makefile tak, aby pobierały odpowiednią implementację.

To wszystko jest trochę za dużo dla tworzenia przykładu tutaj. Potrzeba trochę czasu, żeby się nauczyć. Ale cała dokumentacja się wyczerpała. tam. Istnieje nawet darmowa książka dostępna online. Proces ten ma zastosowanie do Twoich przyszłych projektów. W przypadku wsparcia dla wielu platform jest to naprawdę najbardziej niezawodny i najłatwiejszy sposób, jak sądzę. Wiele sugestii zamieszczonych w innych odpowiedziach to rzeczy, z którymi zajmuje się Autotools (wykrywanie procesora, obsługa statycznych i współdzielonych bibliotek) bez konieczności zbytniego myślenia o tym. Jedyną zmarszczką, z którą możesz mieć do czynienia, jest sprawdzenie, czy Autotools są dostępne dla MinGW. Wiem. są częścią Cygwin, jeśli można iść tą drogą zamiast.