Pytanie o optymalność kodu

@tester_68k:

Napisz co chcesz osiągnąć na przykładach, czyli kilka danych wejściowych i ich odpowiedniki wyjścia.

Co do kodu:

Result:=0;
     for i:=0 to 7 do
          if Boolean(Maska and LongWord(1 shl i)) then
               Result:=Result+(Dana and (1 shl i));

To co by on nie liczył:
1)

if Boolean(operacja-bitowa) 

• nie wygląda dobrze (styl), powinno być raczej:

if (operacja-bitowa)<> 0 then

1. dwa razy liczysz (1 shl i) w każdym kroku pętli

2. przesuwasz w każdym kroku pętli i razy zamiast raz (styl):

Result:=0;
SMaska := 1;
for i:=0 to 7 do
begin
  if Maska and SMaska <> 0 then
  begin
     Result := Result + (Dana and SMaska);
  end;
  SMaska := SMaska shl 1;
end;

1. kod:

Result := Result+(Dana and (1 shl i));

jest podejrzany, bo jak ktoś napisał wynika z niego, że potrzebujesz po prostu funkcji:

function PozostawBity(Dana,Maska: byte):byte; overload;
begin
     Result:= Dana and Maska;
end;

A przecież nie robił byś do tego funkcji chyba?

Wibowit napisał(a):

Ani VS ani FPC nie są znane z szybkości kodu wykonywalnego. Za to Intel C++ czy nowe GCC już raczej tak.

Z moich testów wynikało coś zupełnie przeciwnego. Kompilatory C++ które mają gębę "superwydajnych" były najsłabsze, a FPC jeszcze szybszy.
Zależy od zadania pewnie. Heurystyki mają to do siebie że nie zawsze się uaktywniają.

Przykłady:
http://4programmers.net/Forum/C_i_C++/183852-kalkulator_onp_-_c++_vs_delphi?start=40

• VS najszybszy w zestawieniu z GCC, Intel, PGI, BCB (Intel możliwe że szybszy jeśli by włączyć fastfp - ale już nie mam go zainstalowanego (trial)

http://4programmers.net/Forum/C_i_C++/201193-c++11_-_przedluzanie_agonii_czy_zbawienie_dla_c++?p=862635

• FPC najszybszy w zestawieniu

Może się nie znam, może coś źle skonfigurowałem... Sam sprawdź.

Obecnie są to wyniki dla mojego kodu,kiedy zrobię funkcjonalny program będę optymalizował to co zaznaczam jako
funkcje decydujące o szybkości.

A to jeszcze wyniki dla Atmeg8 wychodzi na to ,że AT8515 i Atmega8 to to samo w wydajności tylko nazwa inna
Mikrokontroler rozmiar pętli 50 000 rozmiar pętli 500 000
Atmega8 15.169 ms 207.674 ms

pogubiłem się, czy pozostaw bity ma działać tak:

dana    xABx xCxx
maska   0110 0100
wyjście 0000 0ABC 

Witam

dana xABx xCxx
maska 0110 0100
wyjście 0000 0ABC

dokładnie tak to ma działać, przepraszam za opóźnienie w odpowiedziach ale kiedy tylko mam czas odpisuje.

tester_68k napisał(a):

Witam

dana xABx xCxx
maska 0110 0100
wyjście 0000 0ABC

dokładnie tak to ma działać, przepraszam za opóźnienie w odpowiedziach ale kiedy tylko mam czas odpisuje.

To ja jestem ciekawy co robił mój kod asm, skoro nie to samo.

Z moich testów wynikało coś zupełnie przeciwnego. Kompilatory C++ które mają gębę "superwydajnych" były najsłabsze, a FPC jeszcze szybszy.
Zależy od zadania pewnie. Heurystyki mają to do siebie że nie zawsze się uaktywniają.

Przykłady:
http://4programmers.net/Forum/[...]r_onp_-_c++_vs_delphi?start=40

• VS najszybszy w zestawieniu z GCC, Intel, PGI, BCB (Intel możliwe że szybszy jeśli by włączyć fastfp - ale już nie mam go zainstalowanego (trial)

http://4programmers.net/Forum/[...]czy_zbawienie_dla_c++?p=862635

• FPC najszybszy w zestawieniu

To dziwne bo z budowy kompilatorów wynikałoby że FPC zazwyczaj będzie wolniejszy przez wewnętrznie referencyjne stringi, tablice etc. Widać kody nie wykorzystywały tego, nie mniej nie obstawiałbym że FPC jest szybsze. Z testów twórców wynika że FPC w większości przypadków jest nieznacznie wolniejszy.
Te zestawienia bym włożył między bajki, nie popadajmy w zachwyt dobrym kompilatorem którym jest FPC w porównaniu z GCC który jest wspierany przez parę większych firm. To że jest wolniejszy wynika nie tylko z dopracowania kompilatora ale też z konstrukcji języka które w Pascalu są bardziej user friendly.

Wibowit napisał(a):

...Pojedyncza iteracja będzie wolniejsza (możliwe że i tak niewiele wolniejsza na nowych prockach) niż w twojej wersji. Za to iteracji będzie tylko tyle ile jest zapalonych bitów w masce, a w twojej wersji iteracji jest tyle ile wynosi szerokość słowa w bitach...

Co do podejścia mniej iteracji/wolniejszy krok. Może to być wolniejsze zwłaszcza dla 8-bitowych liczb. Jeśli by walnąć pętelkę na sztywno 8 iteracji to kompilator mógłby ją rozwinąć generując szybszy kod.

Podejrzewam, że dla bajtów ten kod może wymiatać:

int dana;
int maska;
dana &= maska;
maska = ~maska;
for (int i = 0; i < 8; i++, maska >>= 1) {
    dana >>= maska & 1;
}

lub taki:

for (int i = 0; i < 8 && maska != 0; i++, maska >>= 1) {
    dana >>= maska & 1;
}

w zależności od gęstości maski
Jeśli wam się jeszcze chce, to możecie sprawdzić :)</del>

A czy to robi to co autor chce? Bo mi się wydaje, że nie.

No faktycznie. Kod nieważny. Idea pozostaje - zamiast zapętlonego skoku rozwinięcie instrukcji w drabinkę.