Wojciech Muła <w...@p...null.onet.pl.invalid> napisał(a):

> On Sat, 25 Jul 2009 21:58:33 +0100 Bronek Kozicki <b...@s...net>
> wrote:
>
> > P. Owca wrote:
> > >>> i tak musi odczyta=E6 zawarto=B6=E6 pami=EAci, gdzie jest kod
> > >>> programu pro-
> > >>> cedury.
> > >> To mog=B3oby by=E6 ta=F1sze ni=BF od=B3o=BFenie bie=BF=B1cego PC na st=
> os, zmiana
> > >> PC, wykonanie powrotu (odtworznie PC). Szczeg=F3lnie w procesorach
> > >> potokowych, gdzie mo=BFna to wykona=E6 w miar=EA wcze=B6nie.
> >=20
> > wykonanie tych wszystkich instrukcji na nowoczesnych procesorach to=20
> > jeden do kilkudziesi=EAciu cykli. Odczytanie pami=EAci RAM (znalezienie
> > tego samotnego "ret" z pami=EAci kt=F3ra nie jest w cache) mo=BFe trwa=E6
> > ponad 200 cykli.
>
> Chybiony argument - przecie=BF ta pami=EA=E6 i tak musi zosta=E6 odczytana
> w celu wykonania instrukcji tam zapisanych.

Jeśli interesuje Cię to na poważnie, to przygotuj dane (na ile to możliwe) i
policz esperancje.

Pozdrawiam



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Wojciech Muła wrote:
> On Sat, 25 Jul 2009 21:58:33 +0100 Bronek Kozicki <b...@s...net>
> wrote:
>
>> P. Owca wrote:
>>>>> i tak musi odczytać zawartość pamięci, gdzie jest kod
>>>>> programu pro-
>>>>> cedury.
>>>> To mogłoby być tańsze niż odłożenie bieżącego PC na stos, zmiana
>>>> PC, wykonanie powrotu (odtworznie PC). Szczególnie w procesorach
>>>> potokowych, gdzie można to wykonać w miarę wcześnie.
>> wykonanie tych wszystkich instrukcji na nowoczesnych procesorach to
>> jeden do kilkudziesięciu cykli. Odczytanie pamięci RAM (znalezienie
>> tego samotnego "ret" z pamięci która nie jest w cache) może trwać
>> ponad 200 cykli.
>
> Chybiony argument - przecież ta pamięć i tak musi zostać odczytana
> w celu wykonania instrukcji tam zapisanych.

no właśnie - i dlatego nie warto optymalizować wykonania instrukcji.
Optymalizowany jest dostęp do pamięci (predykcja skoków, cache itd.),
aby zamiast kilkudziesięciu było kilka albo jeden, oraz aby tych ponad
200 cykli czekania na pamięć nie było.


B.


--
Remove -trap- when replying. Usun -trap- gdy odpisujesz.

do góry

Wojciech Muła <w...@p...null.onet.pl.invalid> wrote:
> Czy jest jakiś procesor, który "widząc", że pierwszym
> rozkazem procedury jest powrót z podprogramu, w ogóle
> nie przekazuje tam sterowania?
... tym zajmoje sie kompilator, przyklad z gcc:
smtp:/home/adam>gcc -S x.c
smtp:/home/adam>mv x.s x.s1
smtp:/home/adam>gcc -O2 -S x.c
smtp:/home/adam>diff x.s x.s1
3d2
< .p2align 4,,15
12c11
< .section .rodata.str1.1,"aMS",@progbits,1
---
> .section .rodata
16d14
< .p2align 4,,15
28a27
> call x
smtp:/home/adam>cat x.c
#include <stdio.h>
void x() { };
int main() {
printf("123\n");
x();
}
smtp:/home/adam>

jak widzisz, kod wygenerowany przy optymalizacji -O2 nie wywoluje procedury
pustej. Inne kompilatory maja tak samo IMHO. Z powazaniem
Adam Przybyla

do góry

Adam Przybyla pisze:
> Wojciech Muła <w...@p...null.onet.pl.invalid> wrote:
>> Czy jest jakiś procesor, który "widząc", że pierwszym
>> rozkazem procedury jest powrót z podprogramu, w ogóle
>> nie przekazuje tam sterowania?
> ... tym zajmoje sie kompilator, przyklad z gcc:
> smtp:/home/adam>gcc -S x.c
> smtp:/home/adam>mv x.s x.s1
> smtp:/home/adam>gcc -O2 -S x.c
> smtp:/home/adam>diff x.s x.s1
> 3d2
> < .p2align 4,,15
> 12c11
> < .section .rodata.str1.1,"aMS",@progbits,1
> ---
>> .section .rodata
> 16d14
> < .p2align 4,,15
> 28a27
>> call x
> smtp:/home/adam>cat x.c
> #include <stdio.h>
> void x() { };
> int main() {
> printf("123\n");
> x();
> }
> smtp:/home/adam>
>
> jak widzisz, kod wygenerowany przy optymalizacji -O2 nie wywoluje procedury
> pustej. Inne kompilatory maja tak samo IMHO.
rzekłeś wodu:
a) kompilatory (wątek chyba jest zainteresowany CPU)
b) funkcja lokalna w jednostce kompilacji (module) bo tylko wtedy
kompilator posiada tę wiedzę. Ciekaw będę twojego testu, czy
kwalifikatory przy funkcji x coś zmieniają (np. static ale i
niestandardowe) lub f. x jest zewnętrzna.

W podanych warunkach minusów nie ma, tylko można zyskać.

do góry

Jacek Czerwinski <...@...z.pl> wrote:
> Adam Przybyla pisze:
>> Wojciech Muła <w...@p...null.onet.pl.invalid> wrote:
>>> Czy jest jakiś procesor, który "widząc", że pierwszym
>>> rozkazem procedury jest powrót z podprogramu, w ogóle
>>> nie przekazuje tam sterowania?
>> ... tym zajmoje sie kompilator, przyklad z gcc:
>> smtp:/home/adam>gcc -S x.c
>> smtp:/home/adam>mv x.s x.s1
>> smtp:/home/adam>gcc -O2 -S x.c
>> smtp:/home/adam>diff x.s x.s1
>> 3d2
>> < .p2align 4,,15
>> 12c11
>> < .section .rodata.str1.1,"aMS",@progbits,1
>> ---
>>> .section .rodata
>> 16d14
>> < .p2align 4,,15
>> 28a27
>>> call x
>> smtp:/home/adam>cat x.c
>> #include <stdio.h>
>> void x() { };
>> int main() {
>> printf("123\n");
>> x();
>> }
>> smtp:/home/adam>
>>
>> jak widzisz, kod wygenerowany przy optymalizacji -O2 nie wywoluje procedury
>> pustej. Inne kompilatory maja tak samo IMHO.
> rzekłeś wodu:
> a) kompilatory (wątek chyba jest zainteresowany CPU)
> b) funkcja lokalna w jednostce kompilacji (module) bo tylko wtedy
> kompilator posiada tę wiedzę. Ciekaw będę twojego testu, czy
> kwalifikatory przy funkcji x coś zmieniają (np. static ale i
> niestandardowe) lub f. x jest zewnętrzna.
>
> W podanych warunkach minusów nie ma, tylko można zyskać.
... hmm, JIT moze miec ta wiedze. Bo jesli jest zewnetrza,
to nie ma co liczyc na funkcje wrozki kompilatora;-)
Z powazaniem
Adam Przybyla

do góry