Testowanie porównawcze to samodzielny artformat, zwykle łatwy do manipulowania wynikami, aby pokazać, co chcesz. Nie spodziewałbym się, że kompilatory wygenerują takie same wyniki, z wyjątkiem bardzo małych przypadków testowych, a czasami w tych małych przypadkach testowych ich wyniki są albo identyczne, albo czasami znacznie różne, ponieważ test ujawnił optymalizację, którą jeden kompilator zna/używa i jeden z nich inne nie.
Kiedyś śledziłem takie rzeczy (numery wydajności kompilatorów) z dhrystone na przykład, ale w przypadku znanych benchmarków (nie, że dhrystone znaczy dużo więcej, ale inne) może się okazać, że niektóre kompilatory dostosowują się do wyglądają dobrze w testach porównawczych, być może kosztem czegoś innego.
Nie ma właściwej odpowiedzi, nie ma uniwersalnego "najlepszego", wszystko jest w oku patrzącego, ciebie. Które narzędzie jest łatwiejsze w użyciu, a które lubisz lepiej, jeśli chcesz uzyskać gui lub ładne kolory lub dźwięki karty dźwiękowej? I stamtąd.
Ogólnie kompilator gnu dla testowanych przeze mnie aplikacji nie tworzy kodu jako "szybkiego", który jest moim punktem odniesienia, w porównaniu do innych, ale jest znacznie więcej osób korzystających z bezpłatnych narzędzi gnu, więc wsparcie dla niego jest znacznie szersze ze względu na liczbę stron internetowych i forów oraz przykładów. gnu nie będzie mieć ograniczenia rozmiaru, ale może wymagać więcej nauki lub czegoś innego, aby zacząć działać ...
Korty-ms są podzielone na rodziny armv6m i armv7m, v6m (cortex-m0) mają tylko niewielka liczba rozszerzeń thumb2, armv7m ma około 150 rozszerzeń thumbv2 do kciuka, więc musisz wiedzieć, jakie narzędzia obsługują i nie używać niewłaściwych rzeczy na niewłaściwym chipie. Następnie kompilatory, jeśli wiedzą o tym wszystkim, mogą i będą produkować różne miksy instrukcji z tego samego kodu źródłowego. Dalej w obrębie tego samego kompilatora lub rodziny, używając różnych opcji wiersza poleceń, możesz/otrzymasz znacznie inny kod. A poza tym za pomocą cortex-m4 z pamięcią podręczną, jeśli posiadasz coś takiego, w zależności od tego, w jaki sposób kod leży w liniach pamięci podręcznej, możesz uzyskać bardzo różne wyniki, więc testowanie porównawcze to projekt badawczy sam w sobie dla każdego bloba Kod C, który chcesz porównać. Zakres wydajności w pojedynczym kompilatorze może zacieniać inny kompilator lub nakładanie się może nie wystarczyć.
Jeśli masz dostęp do narzędzi, które dodajesz do siebie wartość zawodową, ucząc się korzystać z konkurencyjnych narzędzi i będąc w stanie podjąć pracę lub w pracy, wybierz to, co uważasz za właściwe narzędzie do pracy lub chodzenia do domu w Kilonii i możesz od razu pracować lub pracować w gnu i pracować. Gdzie możesz stracić pracę, jeśli jesteś tylko gnu, a praca jest dla domu w Kilonii.
Czy głównym problemem jest nauka? Dlaczego więc zależy Ci na wydajności kompilatora? Linaro i Yagarto to dwie wersje gcc (różne biblioteki). Wybrałbym ostatni [do którego łączyłeś] (https://launchpad.net/gcc-arm-embedded). Numery prędkości/rozmiaru są zawsze oparte na syntetycznym benchmarku. Zrób/utwórz swój kod i skompiluj go z różnymi kompilatorami. Generalnie sposób, w jaki kodujesz, będzie odzwierciedlał wyniki bardziej niż kompilator. Tj, ten sam algorytm z inną implementacją "C". –
Moim głównym zmartwieniem jest oczywiście nauka, ale wydajność nie jest czymś złym do osiągnięcia (i dużo zabawy w pracy). Jednak postąpię zgodnie z sugestią, podając ten sam kod do różnych kompilatorów, a ja sprawdzę, który z nich jest bardziej znajomy. Dzięki za komentarz –
Pytanie jest równie ważne poza kontekstem uczenia się, więc proszę nie odrzucaj go z "nie ma znaczenia, który wybierzesz, jeśli się uczysz". Nie uczę się, ale moje pytanie jest bardzo podobne i chciałbym na przykład wiedzieć, czy opcje komercyjne zapewniają znaczącą wydajność lub różnice w rozmiarach kodu w łańcuchu narzędzi GNU ARM. –