ďťż
 
Co szybciej dodawanie czy mnozenie ? ďťż
 
Co szybciej dodawanie czy mnozenie ?
Zobacz wiadomości
 
Cytat
A gdyby tak się wedrzeć na umysłów górę, / Gdyby stanąć na ludzkich myśli piramidzie, / I przebić czołem przesądów chmurę, / I być najwyższą myślą wcieloną. . . Juliusz Słowacki, Kordian
Indeks BCB i MySQL subiekt gt fototapeta
 
  Witamy

Co szybciej dodawanie czy mnozenie ?



ZauraK - 11-04-2006 00:25
Co szybciej dodawanie czy mnozenie ?
  Witam.
Jakie zadanie wykona się szybciej (C++)
1) dodawanie kolejnych X liczb w pętli
2) czy wyrażenie X*(X+Z)/Y ?
Ilość i wartości liczb są powiedzmy rzędu 10^10.
Mnie się wydaje że druga opcja, ale nie jestem pewny.
--
Pozdrawiam
ZauraK





Krzysztof Stachlewski - 11-04-2006 00:25

  ZauraK wrote:

> Jakie zadanie wykona się szybciej (C++)
> 1) dodawanie kolejnych X liczb w pętli
> 2) czy wyrażenie X*(X+Z)/Y ?
> Ilość i wartości liczb są powiedzmy rzędu 10^10.
> Mnie się wydaje że druga opcja, ale nie jestem pewny.

To żeby mieć pewność, przetestuj, zrób pomiary.
I nie ekstrapoluj wyników na inne kompilatory i procesory. :-)

--
Tlen:stachobywatelpl Jabber:stach@jabber.atman.pl GG:1811474




Tomek[TK] - 11-04-2006 00:25

  Krzysztof Stachlewski napisał(a):
>>Jakie zadanie wykona się szybciej (C++)
>>1) dodawanie kolejnych X liczb w pętli
>>2) czy wyrażenie X*(X+Z)/Y ?
>>Ilość i wartości liczb są powiedzmy rzędu 10^10.
>>Mnie się wydaje że druga opcja, ale nie jestem pewny.
>
>
> To żeby mieć pewność, przetestuj, zrób pomiary.
> I nie ekstrapoluj wyników na inne kompilatory i procesory. :-)

I przedstaw wyniki na grupie :)

--
Tomek
http://www.osiedle-er.prv.pl/




Tomasz Kaczanowski - 12-04-2006 00:38

  ZauraK wrote:
> Witam.
> Jakie zadanie wykona się szybciej (C++)
> 1) dodawanie kolejnych X liczb w pętli
> 2) czy wyrażenie X*(X+Z)/Y ?
> Ilość i wartości liczb są powiedzmy rzędu 10^10.
> Mnie się wydaje że druga opcja, ale nie jestem pewny.

A co do tego ma C++ To bardziej zalezy od procesora... Najdluzej
wykonywac sie bedzie dzielenie, jesli sa to liczby zmiennoprzecinkowe to
najwiekszy blad bedzie przy dodawaniu.

--
Kaczus/Pegasos User
http://kaczus.republika.pl





.neter - 12-04-2006 00:38

  ZauraK wrote:
> Witam.
> Jakie zadanie wykona się szybciej (C++)
> 1) dodawanie kolejnych X liczb w pętli
> 2) czy wyrażenie X*(X+Z)/Y ?
> Ilość i wartości liczb są powiedzmy rzędu 10^10.
> Mnie się wydaje że druga opcja, ale nie jestem pewny.
No jesli X bedzie rzedu 10^10, to rzeczywiście pierwsza opcja może
okazać się bardzo pouczająca. Ale po co robić dodawanie X + Y - nie
lepiej w pętli Y razy dodawać 1 do X?
:)




Kmail - 12-04-2006 00:38

 
Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.onet.pl> napisał w wiadomości
news:e1fibl$f1f$1@news.onet.pl...
> ZauraK wrote:
> > Witam.
> > Jakie zadanie wykona się szybciej (C++)
> > 1) dodawanie kolejnych X liczb w pętli
> > 2) czy wyrażenie X*(X+Z)/Y ?
> > Ilość i wartości liczb są powiedzmy rzędu 10^10.
> > Mnie się wydaje że druga opcja, ale nie jestem pewny.
>
> A co do tego ma C++ To bardziej zalezy od procesora... Najdluzej
> wykonywac sie bedzie dzielenie, jesli sa to liczby zmiennoprzecinkowe to
> najwiekszy blad bedzie przy dodawaniu.

Dokup kooprocesor i bedzie ci hulać




Tomasz Kaczanowski - 12-04-2006 00:38

  Kmail wrote:
>> A co do tego ma C++ To bardziej zalezy od procesora... Najdluzej
>> wykonywac sie bedzie dzielenie, jesli sa to liczby zmiennoprzecinkowe to
>> najwiekszy blad bedzie przy dodawaniu.
>
> Dokup kooprocesor i bedzie ci hulać

To tak apropo konia?

--
Kaczus/Pegasos User
http://kaczus.republika.pl




Bernard - 12-04-2006 00:38

  Kmail wrote:
> Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.onet.pl> napisał w wiadomości
> news:e1fibl$f1f$1@news.onet.pl...
>> ZauraK wrote:
>>> Witam.
>>> Jakie zadanie wykona się szybciej (C++)
>>> 1) dodawanie kolejnych X liczb w pętli
>>> 2) czy wyrażenie X*(X+Z)/Y ?
>>> Ilość i wartości liczb są powiedzmy rzędu 10^10.
>>> Mnie się wydaje że druga opcja, ale nie jestem pewny.
>> A co do tego ma C++ To bardziej zalezy od procesora... Najdluzej
>> wykonywac sie bedzie dzielenie, jesli sa to liczby zmiennoprzecinkowe to
>> najwiekszy blad bedzie przy dodawaniu.
>
> Dokup kooprocesor i bedzie ci hulać

Bzdury piszesz (więc po co piszesz?).

Dzielenie jest zawsze najwolniejszym dzałaniem. Dodawanie/odejmowanie
jest zwykle szybsze od mnożenia, czasem mnożenie zmiennopozycyjne jest
równie szybkie jak dodawanie zmiennopozycyjne, stałopozycyjne zawsze
będzie wolniejsze od dodawania.




Tomasz Kaczanowski - 12-04-2006 00:38

  Bernard wrote:

>> Dokup kooprocesor i bedzie ci hulać
>
> Bzdury piszesz (więc po co piszesz?).
>
> Dzielenie jest zawsze najwolniejszym dzałaniem. Dodawanie/odejmowanie
> jest zwykle szybsze od mnożenia, czasem mnożenie zmiennopozycyjne jest
> równie szybkie jak dodawanie zmiennopozycyjne, stałopozycyjne zawsze
> będzie wolniejsze od dodawania.

Czasami mnozenie moze byc szybsze przy liczbach zmiennoprzecinkowych,
wszystko zalezy od zaangazowania czasu konwersji do wspólnego
wykładnika, co jest niezbedne przy dodawaniu. Dodatkowo juz kiedys
wspominalem, nowsze procesory "nie wypuszczaja" z koprocesora wynikow
posrednich, jesli nie jest to konieczne, wiec a*(b+c) moze byc wykonane
ze tak powiem w jednym ciagu, co na pewno przyspiesza dzialanie i
zmniejsza blad, gdyz brak jest konwersji z typow uzywanych przez
koprocesor do typow uzywanych w programie.

--
Kaczus/Pegasos User
http://kaczus.republika.pl




Lukasz - 12-04-2006 00:38

  Mnożenie w rzeczywistości jest realizowane przez wielokrotne dodawanie w
pętli, a dzielenie przez wielokrotne odejmowanie. Starze procki nie miały
osobnych rozkazów do mnożenia i dzielenia.

Zależy od implementacji. Prawie na pewno może Ci się udać tak zoptymalizować
kod dodawania w swoim przypadku, że zadziała szybciej, niż to robi fabryka
C++.

--
Lukasz
N 50 05' 04"
E 19 53' 43"




Tomasz Pyra - 12-04-2006 00:38

  Lukasz napisał(a):
> Mnożenie w rzeczywistości jest realizowane przez wielokrotne dodawanie w
> pętli, a dzielenie przez wielokrotne odejmowanie. Starze procki nie miały
> osobnych rozkazów do mnożenia i dzielenia.

Chyba żartujesz :)
Mnożenie 2 liczb po 64 bity trwało by latami ;)

Mnożenie w RISC-ach wykonuje się za pomocą przesunięć bitowych i
dodawania - idea podobna jak w mnożeniu pisemnym.

Po prostu mnoży się pierwszy czynnik przez kolejne bity drugiego
czynnika (a mnożenie razy jeden bit to trywialna operacja - wynikiem
jest albo zero, albo pierwszy czynnik), a wyniki sumuje się odpowiednio
przesuwając bity wyników.




.neter - 12-04-2006 00:38

  Lukasz wrote:
> MnoÂżenie w rzeczywistoÂści jest realizowane przez wielokrotne dodawanie w
> pĂŞtli, a dzielenie przez wielokrotne odejmowanie. Starze procki nie miaÂły
> osobnych rozkazów do mnoÂżenia i dzielenia.
No bez jaj, nie w tak naiwny sposób jak w tym wątku opisany
>
> ZaleÂży od implementacji. Prawie na pewno moÂże Ci siĂŞ udaĂŚ tak zoptymalizowaĂŚ
> kod dodawania w swoim przypadku, Âże zadziaÂła szybciej, niÂż to robi fabryka
> C++.




Kmail - 12-04-2006 00:38

  > Bzdury piszesz (więc po co piszesz?).
>
> Dzielenie jest zawsze najwolniejszym dzałaniem. Dodawanie/odejmowanie
> jest zwykle szybsze od mnożenia, czasem mnożenie zmiennopozycyjne jest
> równie szybkie jak dodawanie zmiennopozycyjne, stałopozycyjne zawsze
> będzie wolniejsze od dodawania.

Sam kocopoły walisz.
Szybsze będzie na szybszym procesorze tj. operacja mnozenia dwuch liczb
wykona sie szybciej na P3 (5 cykli) niz na P4(7 cykli).
A dlaczego to powinienieś się dowiedzieć a nie pisać co jest zwykle, czasem
lub równie szybkie.
A optymalizujac działania matematyczne musisz się dowiedziec nieco wiecej o
kooprocesorze, czyli jak wykozystac MMX a najlepiej SSE2 jeśli możliwe i jak
poukładać instrukcje aby wykożystać HT. A nie klepiąc pętle w C++.




Tomasz Kaczanowski - 12-04-2006 00:39

  Kmail wrote:
>> Bzdury piszesz (więc po co piszesz?).
>>
>> Dzielenie jest zawsze najwolniejszym dzałaniem. Dodawanie/odejmowanie
>> jest zwykle szybsze od mnożenia, czasem mnożenie zmiennopozycyjne jest
>> równie szybkie jak dodawanie zmiennopozycyjne, stałopozycyjne zawsze
>> będzie wolniejsze od dodawania.
>
> Sam kocopoły walisz.
> Szybsze będzie na szybszym procesorze tj. operacja mnozenia dwuch liczb
> wykona sie szybciej na P3 (5 cykli) niz na P4(7 cykli).
> A dlaczego to powinienieś się dowiedzieć a nie pisać co jest zwykle, czasem
> lub równie szybkie.
> A optymalizujac działania matematyczne musisz się dowiedziec nieco wiecej o
> kooprocesorze, czyli jak wykozystac MMX a najlepiej SSE2 jeśli możliwe i jak
> poukładać instrukcje aby wykożystać HT. A nie klepiąc pętle w C++.

Panowie, ale wy piszecie o 2 roznych rzeczach...

--
Kaczus/Pegasos User
http://kaczus.republika.pl




Bernard - 12-04-2006 00:39

  Kmail wrote:
>> Bzdury piszesz (więc po co piszesz?).
>>
>> Dzielenie jest zawsze najwolniejszym dzałaniem. Dodawanie/odejmowanie
>> jest zwykle szybsze od mnożenia, czasem mnożenie zmiennopozycyjne jest
>> równie szybkie jak dodawanie zmiennopozycyjne, stałopozycyjne zawsze
>> będzie wolniejsze od dodawania.
>
> Sam kocopoły walisz.
> Szybsze będzie na szybszym procesorze tj. operacja mnozenia dwuch liczb
> wykona sie szybciej na P3 (5 cykli) niz na P4(7 cykli).
> A dlaczego to powinienieś się dowiedzieć a nie pisać co jest zwykle, czasem
> lub równie szybkie.

Obawiam się, że Kolega ani nie wie, o czym ja napisałem, ani o czym sam
pisze, za to koniecznie chce na mnie pokrzyczeć.

> A optymalizujac działania matematyczne musisz się dowiedziec nieco wiecej o
> kooprocesorze, czyli jak wykozystac MMX a najlepiej SSE2 jeśli możliwe i jak
> poukładać instrukcje aby wykożystać HT. A nie klepiąc pętle w C++.

Może najpierw Kolega mi powie, co to jest ten "kooprocesor", bo ostatni
KOPROCESOR, a nie "kooprocesor" w stanie działającym widziałem jkieś 6
lat temu w zabytkowej dość maszynie.

Potem niech mi Kolega wytłumaczy, jak wykorzystać instrukcje MMX do
obróbki danych zmiennopozycyjnych, a potem jeszcze - jak się
optymalizuje sekwencję instrukcji jednego programu na procesor z HT.
Będę bardzo wdzięczny, bo w temacie siedzę zaledwie paręnaście lat i
jako osobnik mało doświadczony zawsze jestem ciekaw nowych rzeczy z
moich okolic.




Bernard - 12-04-2006 00:39

  Lukasz wrote:
> Mnożenie w rzeczywistości jest realizowane przez wielokrotne dodawanie w
> pętli, a dzielenie przez wielokrotne odejmowanie. Starze procki nie miały
> osobnych rozkazów do mnożenia i dzielenia.

Nic podobnego. SPARC nie miał instrukcji mnożenia, ale np. taki 8051
miał i ma, przy czym mnożenie wykonuje się na nimo się tylko 4x dłużej
od dodawania. MIPS miał od zawsze sprzętową jednostkę mnożącą, która
wykonywała operacje 32-bitowe w kilkunastu cyklach.

8086 wykonywał mnożenie i dzielenie prymitywnym algorytmem "pętlowym".
Większość procesorów z lat 80-tych i nowszych miało już szybsze
jednostki mnożące, a w latach 90-tych - mnożarki np. 16-bitowe (np.
Cyrix). Mnożenie 32-bitowe wymagało wtedy wykonania 4 mnożeń i sumowań.

Jednostki zmiennopozycyjne od dawna korzystają z mnożarek sprzętowych, i
to bardziej niż stałopozycyjne. W wielu nowszych procesorach Intela, w
tym w Pentium (80502), mnożenie liczb stałopozycyjnych odbywało się w
jednostce zmiennopozycyjnej i było wolniejsze od zmiennopozycyjnego z
powodu konieczności przesłań danych i konwersji.




Kmail - 12-04-2006 00:39

 
Użytkownik "Bernard" <bernard@earth.net> napisał w wiadomości
news:e1g5gk$i2m$1@achot.icm.edu.pl...
> Kmail wrote:
> >> Bzdury piszesz (więc po co piszesz?).
> >>
> >> Dzielenie jest zawsze najwolniejszym dzałaniem. Dodawanie/odejmowanie
> >> jest zwykle szybsze od mnożenia, czasem mnożenie zmiennopozycyjne jest
> >> równie szybkie jak dodawanie zmiennopozycyjne, stałopozycyjne zawsze
> >> będzie wolniejsze od dodawania.
> >
> > Sam kocopoły walisz.
> > Szybsze będzie na szybszym procesorze tj. operacja mnozenia dwuch liczb
> > wykona sie szybciej na P3 (5 cykli) niz na P4(7 cykli).
> > A dlaczego to powinienieś się dowiedzieć a nie pisać co jest zwykle,
czasem
> > lub równie szybkie.
>
> Obawiam się, że Kolega ani nie wie, o czym ja napisałem, ani o czym sam
> pisze, za to koniecznie chce na mnie pokrzyczeć.
>
> > A optymalizujac działania matematyczne musisz się dowiedziec nieco
wiecej o
> > kooprocesorze, czyli jak wykozystac MMX a najlepiej SSE2 jeśli możliwe i
jak
> > poukładać instrukcje aby wykożystać HT. A nie klepiąc pętle w C++.
>
> Może najpierw Kolega mi powie, co to jest ten "kooprocesor", bo ostatni
> KOPROCESOR, a nie "kooprocesor" w stanie działającym widziałem jkieś 6
> lat temu w zabytkowej dość maszynie.

Fakt KOPROCESOR a nie kooprocesor.
I pokolei:
Więc najpier cię odeśle do wikipedii jesli nie wiesz co to koprocesor:
http://pl.wikipedia.org/wiki/Koprocesor

Jak widzisz FPU ciągle jest, nawet w P4 gdzie SSE3 rozszezyło go o nową
instrukcje fisttp (Fp Integer Store with Truncation and Pop)

Ale skoro kolega nic nie wie na temat tego czego dotknąc nie może to
zakończete dyskusję.
Powodzenia w pracy Pa.




Lukasz - 12-04-2006 00:39

  Ok. Ok. Ok :) Już mnie nie pognębiajcie więcej. Wiem, wiem, wiem już i
przyznaję się bez bicia, że się musze w tym jeszcze douczyć.

--
Lukasz
N 50 05' 04"
E 19 53' 43"




Tomasz Kaczanowski - 12-04-2006 00:39

  Kmail wrote:
> Użytkownik "Bernard" <bernard@earth.net> napisał w wiadomości
> news:e1g5gk$i2m$1@achot.icm.edu.pl...
>> Kmail wrote:
>>>> Bzdury piszesz (więc po co piszesz?).
>>>>
>>>> Dzielenie jest zawsze najwolniejszym dzałaniem. Dodawanie/odejmowanie
>>>> jest zwykle szybsze od mnożenia, czasem mnożenie zmiennopozycyjne jest
>>>> równie szybkie jak dodawanie zmiennopozycyjne, stałopozycyjne zawsze
>>>> będzie wolniejsze od dodawania.
>>> Sam kocopoły walisz.
>>> Szybsze będzie na szybszym procesorze tj. operacja mnozenia dwuch liczb
>>> wykona sie szybciej na P3 (5 cykli) niz na P4(7 cykli).
>>> A dlaczego to powinienieś się dowiedzieć a nie pisać co jest zwykle,
> czasem
>>> lub równie szybkie.
>> Obawiam się, że Kolega ani nie wie, o czym ja napisałem, ani o czym sam
>> pisze, za to koniecznie chce na mnie pokrzyczeć.
>>
>>> A optymalizujac działania matematyczne musisz się dowiedziec nieco
> wiecej o
>>> kooprocesorze, czyli jak wykozystac MMX a najlepiej SSE2 jeśli możliwe i
> jak
>>> poukładać instrukcje aby wykożystać HT. A nie klepiąc pętle w C++.
>> Może najpierw Kolega mi powie, co to jest ten "kooprocesor", bo ostatni
>> KOPROCESOR, a nie "kooprocesor" w stanie działającym widziałem jkieś 6
>> lat temu w zabytkowej dość maszynie.
>
>
> Fakt KOPROCESOR a nie kooprocesor.
> I pokolei:
> Więc najpier cię odeśle do wikipedii jesli nie wiesz co to koprocesor:
> http://pl.wikipedia.org/wiki/Koprocesor

Definicja koprocesora jest tam troszke moim zdaniem za bardzo zawerzona
do FPU jedynie...

--
Kaczus/Pegasos User
http://kaczus.republika.pl




Bernard - 12-04-2006 00:39

  Kmail wrote:
> Użytkownik "Bernard" <bernard@earth.net> napisał w wiadomości
> news:e1g5gk$i2m$1@achot.icm.edu.pl...
>> Kmail wrote:
>>>> Bzdury piszesz (więc po co piszesz?).
>>>>
>>>> Dzielenie jest zawsze najwolniejszym dzałaniem. Dodawanie/odejmowanie
>>>> jest zwykle szybsze od mnożenia, czasem mnożenie zmiennopozycyjne jest
>>>> równie szybkie jak dodawanie zmiennopozycyjne, stałopozycyjne zawsze
>>>> będzie wolniejsze od dodawania.
>>> Sam kocopoły walisz.
>>> Szybsze będzie na szybszym procesorze tj. operacja mnozenia dwuch liczb
>>> wykona sie szybciej na P3 (5 cykli) niz na P4(7 cykli).
>>> A dlaczego to powinienieś się dowiedzieć a nie pisać co jest zwykle,
> czasem
>>> lub równie szybkie.
>> Obawiam się, że Kolega ani nie wie, o czym ja napisałem, ani o czym sam
>> pisze, za to koniecznie chce na mnie pokrzyczeć.
>>
>>> A optymalizujac działania matematyczne musisz się dowiedziec nieco
> wiecej o
>>> kooprocesorze, czyli jak wykozystac MMX a najlepiej SSE2 jeśli możliwe i
> jak
>>> poukładać instrukcje aby wykożystać HT. A nie klepiąc pętle w C++.
>> Może najpierw Kolega mi powie, co to jest ten "kooprocesor", bo ostatni
>> KOPROCESOR, a nie "kooprocesor" w stanie działającym widziałem jkieś 6
>> lat temu w zabytkowej dość maszynie.
>
>
> Fakt KOPROCESOR a nie kooprocesor.
> I pokolei:
> Więc najpier cię odeśle do wikipedii jesli nie wiesz co to koprocesor:
> http://pl.wikipedia.org/wiki/Koprocesor

Jak by Ci tu powiedzieć?... Sam pisałeś tę definicję? Jakoś wikipedia,
czyli zbiór wyobrażeń Małych Józiów na temat znaczenia pojęć, nie jest
dla mnie autorytetem, a ta konkretnie definicja jest kompletną bzdurą.
Istnieje wiele koprocesorów, niekoniecznie zmiennopozycyjnych (o czym
wikiautor nie wie). Koprocesor - to oddzielny blok funkcjonalny, luźno
związany z procesorem. Ostatnim koprocesorem dla x86 był 80387 (potem
jeszcze 4C87 dla Cx486DLC). FPU począwszy od procesora 486 koprocesorem
nie jest.

> Jak widzisz FPU ciągle jest, nawet w P4 gdzie SSE3 rozszezyło go o nową
> instrukcje fisttp (Fp Integer Store with Truncation and Pop)

FPU jest, koprocesora nie ma, z tym, że FPU też już niedługo nie będzie
- np. 64-bitowe Windows nie dopuszczają użycja FPU w aplikacjach
64-bitowych.

> Ale skoro kolega nic nie wie na temat tego czego dotknąc nie może to
> zakończete dyskusję.
> Powodzenia w pracy Pa.

Leczysz kompleksy pyskówką?




Bronek Kozicki - 12-04-2006 00:39
FPU i x64 (bylo: Co szybciej dodawanie czy mnozenie ?)
  Bernard <bernard@earth.net> wrote:
> FPU jest, koprocesora nie ma, z tym, że FPU też już niedługo nie
> będzie - np. 64-bitowe Windows nie dopuszczają użycja FPU w
> aplikacjach 64-bitowych.

ciekawe, możesz rozszerzyć?

B.




Sebastian Kaliszewski - 12-04-2006 00:39

  Bernard wrote:
> FPU jest, koprocesora nie ma, z tym, że FPU też już niedługo nie będzie
> - np. 64-bitowe Windows nie dopuszczają użycja FPU w aplikacjach
> 64-bitowych.

FPU będzie, powoli w x86 wycofują się tylko z zestawu instrukcji x87. SSE
też jest liczone w FPU (to że czasem niektórzy producencie nazwali FPU MMPU,
czyli MultiMedia Processing Unit to jest marketing i nic więcej).

pzdr
--
Sebastian Kaliszewski




Bernard - 12-04-2006 00:39

  Bronek Kozicki wrote:
> Bernard <bernard@earth.net> wrote:
>> FPU jest, koprocesora nie ma, z tym, że FPU też już niedługo nie
>> będzie - np. 64-bitowe Windows nie dopuszczają użycja FPU w
>> aplikacjach 64-bitowych.
>
> ciekawe, możesz rozszerzyć?

Ano tak po prostu. Jednostka SSE2 ma normalny, nie stosowy, zestaw
rejestrów i dzięki temu może być wydajniejsza niż archaiczna i
egzotyczna x87. Wyraźnie widać, że x87 (i MMX) jest skazany na
wyginięCie, a ich rolę przejmie SSE2. Widać to np. po tym, że w AMD64
zwiększono liczbę rejestrów stałopozycyjnych i SSE, a nie ruszono
x87/MMX, chociaż można byłoby zrobić to "za darmo". Współczesne
kompilatory (Intel, gcc dla AMD64) nie używają x87. Tak samo 64-bitowy
MS devstudio.




Kmail - 13-04-2006 00:12

  > Leczysz kompleksy pyskówką?

Nie miałem zamiaru nikogo wpieniać (jeśli tak to sorki) ani wracać do genezy
powstania układów scalonych ale zwrócić uwage na siłe assemblera i złożoność
zagadnienia. A siła leży w procku a nie w kompilatorze.
Pozdrwaim.




Tomasz Kaczanowski - 13-04-2006 00:12

  Sebastian Kaliszewski wrote:
> Bernard wrote:
>> FPU jest, koprocesora nie ma, z tym, że FPU też już niedługo nie
>> będzie - np. 64-bitowe Windows nie dopuszczają użycja FPU w
>> aplikacjach 64-bitowych.
>
> FPU będzie, powoli w x86 wycofują się tylko z zestawu instrukcji x87.
> SSE też jest liczone w FPU (to że czasem niektórzy producencie nazwali
> FPU MMPU, czyli MultiMedia Processing Unit to jest marketing i nic więcej).

Niekoniecznie, Altivec na przykład jest osobną jednostką niezależną od
FPU...

--
Kaczus/Pegasos User
http://kaczus.republika.pl




Tomasz Kaczanowski - 13-04-2006 00:12

  Bernard wrote:
> Bronek Kozicki wrote:
>> Bernard <bernard@earth.net> wrote:
>>> FPU jest, koprocesora nie ma, z tym, że FPU też już niedługo nie
>>> będzie - np. 64-bitowe Windows nie dopuszczają użycja FPU w
>>> aplikacjach 64-bitowych.
>>
>> ciekawe, możesz rozszerzyć?
>
> Ano tak po prostu. Jednostka SSE2 ma normalny, nie stosowy, zestaw
> rejestrów i dzięki temu może być wydajniejsza niż archaiczna i
> egzotyczna x87.

Archaiczne koprocesory w 68k komunikowaly sie przez rejestry z
procesorem, a nie przez stos...

--
Kaczus/Pegasos User
http://kaczus.republika.pl




=?iso-8859-2?Q?Pawe=B3_Kierski?= - 13-04-2006 00:12

  Tomasz Kaczanowski w wiadomości <e1i8hd$6i3$2@news.onet.pl> pisze:
> Bernard wrote:
> > Bronek Kozicki wrote:
> >> Bernard <bernard@earth.net> wrote:
> >>> FPU jest, koprocesora nie ma, z tym, że FPU też już niedługo nie
> >>> będzie - np. 64-bitowe Windows nie dopuszczają użycja FPU w
> >>> aplikacjach 64-bitowych.
> >>
> >> ciekawe, możesz rozszerzyć?
> >
> > Ano tak po prostu. Jednostka SSE2 ma normalny, nie stosowy, zestaw
> > rejestrów i dzięki temu może być wydajniejsza niż archaiczna i
> > egzotyczna x87.
>
> Archaiczne koprocesory w 68k komunikowaly sie przez rejestry z
> procesorem, a nie przez stos...

O ile pamiętam, to nie chodzi o komunikację przez stos, ale
architekturę stosową samego koprocesora - rejestry można adresować,
ale część operacji wykonuje się w RPN i tylko tak. Coś jakby
wierzchołek stosu był akumulatorem.

--
Paweł Kierski
news@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)




Bernard - 13-04-2006 00:12

  Tomasz Kaczanowski wrote:
>> Ano tak po prostu. Jednostka SSE2 ma normalny, nie stosowy, zestaw
>> rejestrów i dzięki temu może być wydajniejsza niż archaiczna i
>> egzotyczna x87.
>
> Archaiczne koprocesory w 68k komunikowaly sie przez rejestry z
> procesorem, a nie przez stos...

Ale nie mówimy o 68881 a o jednostce x87, i nie o komunikacji z
procesorem, a o architekturze zestawu rejestrów samej jednostki x87.
Stosowy zestaw rejestrów x87 był zabawny i przyjemny dla kompilatorów 30
lat temu, ale jest fatalny w implementacji współcześnie.

Nikt inny (poza INMOSem) nie używał stosowych zestawów rejestrów.
Obecnie jest to archaizm ograniczający na wydajność procesora.




Sebastian Kaliszewski - 13-04-2006 00:12

  Tomasz Kaczanowski wrote:
> Sebastian Kaliszewski wrote:
>
>> Bernard wrote:
>>
>>> FPU jest, koprocesora nie ma, z tym, że FPU też już niedługo nie
>>> będzie - np. 64-bitowe Windows nie dopuszczają użycja FPU w
>>> aplikacjach 64-bitowych.
>>
>>
>> FPU będzie, powoli w x86 wycofują się tylko z zestawu instrukcji x87.
>> SSE też jest liczone w FPU (to że czasem niektórzy producencie nazwali
>> FPU MMPU, czyli MultiMedia Processing Unit to jest marketing i nic
>> więcej).
>
>
> Niekoniecznie, Altivec na przykład jest osobną jednostką niezależną od
> FPU...

Tylko dlatego, że został niejako doklejony do gotowego projektu procesora (+
to że zawiera instrukcje permutacyjne).

Tak samo jak 3d-Now! w K6-2 i K6-III było osobną jednostką (razem z MMX). W
K7 i dalej zostało wchłonięte przez FPU (MMX choć z FP nie ma nic wspólnego
takoż).

Jako że Apple wycofało się PPC, nie jest wcale pewne, że Altivec będzie
nadal utrzymywany.

Bernard popełnił ten błąd, że utożsamił FPU (Floatingpoint Processing Unit)
z x87 -- archaicznym zestawem instrukcji FPU.

pzdr
--
Sebastian Kaliszewski




ZauraK - 14-04-2006 00:04

  Pewnego razu Tomek[TK] nabazgrał(a):

> Krzysztof Stachlewski napisał(a):
> > > Jakie zadanie wykona się szybciej (C++)
> > > 1) dodawanie kolejnych X liczb w pętli
> > > 2) czy wyrażenie X*(X+Z)/Y ?
> > > Ilość i wartości liczb są powiedzmy rzędu 10^10.
> > > Mnie się wydaje że druga opcja, ale nie jestem pewny.
> >
> >
> > To żeby mieć pewność, przetestuj, zrób pomiary.
> > I nie ekstrapoluj wyników na inne kompilatory i procesory. :-)
>
> I przedstaw wyniki na grupie :)

Gdybym tylko potrafił uzyskać miarodajne wyniki to chętnie, ale nie mam
żadnego doświadczenia w mierzeniem czasu. Przeciez nie usiądę ze
stoperem w ręku ;-)

--
Pozdrawiam
ZauraK




ZauraK - 14-04-2006 00:04

  Pewnego razu Tomasz Kaczanowski nabazgrał(a):

> ZauraK wrote:
> > Witam.
> > Jakie zadanie wykona się szybciej (C++)
> > 1) dodawanie kolejnych X liczb w pętli
> > 2) czy wyrażenie X*(X+Z)/Y ?
> > Ilość i wartości liczb są powiedzmy rzędu 10^10.
> > Mnie się wydaje że druga opcja, ale nie jestem pewny.
>
> A co do tego ma C++ To bardziej zalezy od procesora... Najdluzej
> wykonywac sie bedzie dzielenie, jesli sa to liczby zmiennoprzecinkowe
> to najwiekszy blad bedzie przy dodawaniu.

liczby całkowite, uporządkowany ciąg arytmetyczny 1..N no chodzi o
obliczenie sumy ciągu.
Wiem że dla małych wartości N napewno jest szbiej sumować.
Natomiast dla dużych raczej lepiej korzystać ze wzoru na sumę wyrazów
ciągu: konkretnie dla tego przypadku N(1+N)/2

Procesora nie jestem w stanie przecież określić. Chodzi mi tylko o
ogólną zasadę. Wiem że z podstawowych działań arytmetycznych dzielenie
wykonuje się najwolniej a dodawanie najszybciej, ale jest to pewnik
tylko dla dwóch liczb. Przy ilości 10^10 i wartościach od 1 do 10^10 to
już conajmniej jest uzasadniona wątpliwość do stosowania dodawania.

A o C++ tak mi się wyrwało. Ja tu teraz mówię o samym algorytmie
niezależnym od języka.

--
Pozdrawiam
ZauraK




ZauraK - 14-04-2006 00:04

  Pewnego razu .neter nabazgrał(a):

> ZauraK wrote:
> > Witam.
> > Jakie zadanie wykona się szybciej (C++)
> > 1) dodawanie kolejnych X liczb w pętli
> > 2) czy wyrażenie X*(X+Z)/Y ?
> > Ilość i wartości liczb są powiedzmy rzędu 10^10.
> > Mnie się wydaje że druga opcja, ale nie jestem pewny.
> No jesli X bedzie rzedu 10^10, to rzeczywiście pierwsza opcja może
> okazać się bardzo pouczająca. Ale po co robić dodawanie X + Y - nie
> lepiej w pętli Y razy dodawać 1 do X? :)

Jak już napisałem gdzieś przedchwilą chodzi o sumę N elementów ciągu
arytmetycznego 1..N ( 1<=N<=10^10)

--
Pozdrawiam
ZauraK




ZauraK - 14-04-2006 00:04

  Pewnego razu Bernard nabazgrał(a):

> Lukasz wrote:
> > Mnożenie w rzeczywistości jest realizowane przez wielokrotne
> > dodawanie w pętli, a dzielenie przez wielokrotne odejmowanie.
> > Starze procki nie miały osobnych rozkazów do mnożenia i dzielenia.
>
> Nic podobnego. SPARC nie miał instrukcji mnożenia, ale np. taki 8051
> miał i ma, przy czym mnożenie wykonuje się na nimo się tylko 4x
> dłużej od dodawania. MIPS miał od zawsze sprzętową jednostkę mnożącą,
> która wykonywała operacje 32-bitowe w kilkunastu cyklach.
>
> 8086 wykonywał mnożenie i dzielenie prymitywnym algorytmem
> "pętlowym". Większość procesorów z lat 80-tych i nowszych miało już
> szybsze jednostki mnożące, a w latach 90-tych - mnożarki np.
> 16-bitowe (np. Cyrix). Mnożenie 32-bitowe wymagało wtedy wykonania 4
> mnożeń i sumowań.
>
> Jednostki zmiennopozycyjne od dawna korzystają z mnożarek
> sprzętowych, i to bardziej niż stałopozycyjne. W wielu nowszych
> procesorach Intela, w tym w Pentium (80502), mnożenie liczb
> stałopozycyjnych odbywało się w jednostce zmiennopozycyjnej i było
> wolniejsze od zmiennopozycyjnego z powodu konieczności przesłań
> danych i konwersji.

Po tym krótkim streszczniu historii, mogę mniemać że jednak korzystanie
ze wzoru z mnożeniem będzie korzystniejsze (oczywiście dla znacznych
wartości)

--
Pozdrawiam
ZauraK




Tomasz Kaczanowski - 15-04-2006 00:11

  ZauraK wrote:

> Po tym krótkim streszczniu historii, mogę mniemać że jednak korzystanie
> ze wzoru z mnożeniem będzie korzystniejsze (oczywiście dla znacznych
> wartości)

Przy liczbach zmiennoprzecinkowych to bardzo mala wartosc...

--
Kaczus/Pegasos User
http://kaczus.republika.pl
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • effulla.pev.pl
  • comp
    =?ISO-8859-2?Q?Oracle_dodawanie_nowego_pakietu_wbudowane?==?I SO-8859-2?Q?go_dla_u=BFytkownika?= [Sprzedam] Konto w dodawarce adder, 13,5tys katalogów i for! dane automatycznie dodawane do tabeli. auto_increment Dziwne znaki przy dodawaniu wierszy w postgresql [Sprzedam]Dodawarka do katalogów qlweb TANIO Dodawanie linków do filmów/flashów/zdjęć [mysql] klucze obce a dodawanie rekordów [MS SQL] dodawanie użytkownika do bazy Dodawanie wartosci jesli nie istnieje w tabeli Dynamiczne dodawanie wiersza tabeli
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • tejsza.htw.pl
  • Cytat

    Decede mihi sole - nie zasłaniaj mi słonca.
    Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
    Hoc fac - tak czyń.
    A tergo - od tyłu; z tyłu.
    I czarne włosy posiwieją. Safona

    Valid HTML 4.01 Transitional

    Free website template provided by freeweblooks.com