przetwarzanie liczb zmiennoprzecinkowych w procesorze jest proste. Wg standardu IEEE liczba taka składa się ze ZNAKU, CECHY i MANTYSY. Każdy jednak wie, że podczas operacji na liczbach double dochodzi do pewnych fiksacji związanych z precyzją.
A może czas na inteligentny procesor gdzie liczba zmiennoprzecinkowa będzie wyrażana tak:
ZNAK, CECHA, MANTYSA, OKRES.
A może w ogóle procesor powinien już przetwarzać symbolicznie?
0
0
A kto ci broni zaimplementować własny typ danych? Oczywiście bez wsparcia sprzętowego będzie się to wolno wykonywać, ale przynajmniej nie tracisz tranzystorów niepotrzebnie. Z drugiej strony, po co komu binarne okresy? A co z liczbami niewymiernymi nieokresowymi? Okresowych jest względnie mało.
0
maszynaz napisał(a)
A może w ogóle procesor powinien już przetwarzać symbolicznie?
Sprzętowe implementacje LISPu (w formie procesora z GC itd.) były na długo zanim się urodziłeś...
A poważnie to wszystko cacy, tylko chyba o czymś zapomniałeś - im bardziej skomplikowane operacje tym ich koszt jest większy. Na co komu superinteligentny procesor, który wreszcie będzie wiedział co programista miał na myśli jeżeli dziesięcioletni kalkulator go przebije wydajnością?
0
A po cholere procesrowi na desktopy obsługa działań symbolicznych skoro IEEE754 sprawdza się doskonale? Do zastosowań naukowych i tak często używa się innych procesorów, które obsługują liczby o znacznie większej precyzji niż float czy double. Już pomijam fakt, że działania symboliczne miały by pewnie kilkaset razy większy narzut czasowy o ile w ogóle to by było możliwe do zaimplementowania na procesorze.
0
Mocno dojrzała już Java 5 ma klasę BigDecimal i leje na wasze problemy :)
Ja jestem zdania, że procesory powinny być maksymalnie proste w budowie, ale być jak najbardziej elastyczne, mieć dużą wydajność teoretyczną i niskie czasy dostępu do pamięci. Obecne GPU są bliskie tym założeniom, niestety nie da się na nich odpalić np systemu operacyjnego czy programów o podobnych możliwościach, tzn zarządzanie innym sprzętem, a programy pisane pod zwykłe, małowątkowe CPU, odpalają się na nich zbyt wolno.
0
Z drugiej strony Intel nawrzucał kosmicznej logiki w x86, z czego wykorzystuje się ledwo 10-20% chociażby dlatego, że Windows czy Linux starają się być przenośne.
0
Każdy jednak wie, że podczas operacji na liczbach double dochodzi do pewnych fiksacji związanych z precyzją.
http://4programmers.net/Forum/Kosz/175219-dziwny_blad :P
Z drugiej strony Intel nawrzucał kosmicznej logiki w x86, z czego wykorzystuje się ledwo 10-20% chociażby dlatego, że Windows czy Linux starają się być przenośne.
Chodzi o MMX SSE itp? Jeśli tak to może nie są za często używane ale za to dają niezłego boosta jeśli już zostaną właściwie wykorzystane. (Jeśli nie to dokładnie o co chodzi?)
0
Do technologii SIMD nic nie mam, bo to jedyny sposób na ogromne podniesienie wydajności x86. Miałem na myśli milion mechanizmów ochrony, skomplikowaną mechanikę segmentów, callgate'ów, taskgate'ów itd. itd. Czytanie trzeciego manuala Intela jest naprawdę zabawne.
0
Ja się zszokowałem gdy czytałem o ichniejszym wynalazku o nazwie Itanium (a dokładniej o zestawie instrukcji do tego). Miało to być niby rewolucyjne, wpakowali mnóstwo kasy w zaprojektowanie tego, nie byli obciążenie kompatybilnością wsteczną, a na końcu chyba i tak zrobili chipa, który ledwo może walczyć z x86.
0
Niektórzy nawet idą w przeciwną stronę. Słyszałem że intel lub inna firma miała w planie robić procki o dużo mniejszej precyzji do zastosowań w różnych odtwarzaczach video i audio. Tam ponoć nie potrzeba takiej dokładności a miało to się odbić na poborze prądu i może czymś jeszcze o czym nie wiem. Słyszałem o tym jakieś dwa lata temu.
0
deus napisał(a)
Do technologii SIMD nic nie mam, bo to jedyny sposób na ogromne podniesienie wydajności x86. Miałem na myśli milion mechanizmów ochrony, skomplikowaną mechanikę segmentów, callgate'ów, taskgate'ów itd. itd. Czytanie trzeciego manuala Intela jest naprawdę zabawne.
Większość z wymienionych przez ciebie rzeczy wycięło AMD w swojej architekturze 64-bitowej, a Intel wyciszył swoje Itanium i się dostosował do AMD64.
Dla zachowania kompatybilności musi to wszystko zostać do pracy w trybach 16- i 32-bitowych…