_FREZA_, JANFROG: ale specialisti na tyhle veci jsou pomerne slusne placeny jsem koukal ;) tjo

JANFROG: jojo, presne tak. teda s tim ze do FPGA to budes hazet jenom kdyz toho vyrabis relativne malo. kdyz chces tech procesoru pak mit vagon, tak si to nechas napalit do ASICu (vyjde to levnejc, FPGAcko stoji radove desitky az stovky dolaru na kus - aspon co vim).

achjo :) no to tedy je

SEJDA: No, ono pisi procesory je IMHO presnejsi - dnes uz se to nekresli hradlo po hradle a proste se to chovani toho procesoru naprogramuje (= napise) v nejakem prostredi - VHDL, Verilog...pak se to akorat predhodi k synteze a vysmahne na FPGA :-) To je uroven, co? :-))

:) no 0.00000000025s .... to mi pripomina DATA (toho ze startreku) to je totiz pro androida, straaaasne dlouha doba .))) me slo proste o to, ze tyhle pomaly instrukce strasne zdrzujou a to ze tam je napr. 2x FPU + 3x ALU to je prima, ale FDIV treba zablokuje obe ty FPU jednotky... proste to tak je na x86.

ja sam umim trosku x86 a pak uz jen velmi bidne na mc6502 (atari) - to tenkrat jeste slo presne spocitat kolik ktera instrukce trva, u soucasnych x86 procesoru to proste nejde...

to je k hovnu :D pojdme neco resit. at se neco priucim taky .)

ja nemyslel pisou procesory .. ja myslel navrhuji procesory ..

no kluci v praci taky pisou procesory, ale takovy malinky specializovany jednoduchy, takze nevim... ;)

Tezko rict jestli rikas bludy .. ono je na procesorech nekolik stovek patentu, a vypocet CISC instrukci .. to je co intrukce to patent :o))

SEJDA: kdyz si vezmes se je mikrosekunda je prodleva 'viditelna pouhym okem' (tj. v programovani je to pozorovatelne dlouha doba. mam napr. napsanej dost slusne presnej mikrosekundovej delay [1]), tak 25ns na jednu operaci neni uplne fajn ;-).

Jinak, ono kdyz si clovek predstavi jak pomalej je uz jenom blbej komparator [2] tak je lepsi na floating point zapomenout (v extra kritickejch castech extra kritickyho kodu) :-)

[1] Je to busy loop, predem kalibrovana pres gettimeofday. Presnost overena na osciloskopu. Unixovy usleep pouzit nejde (je to syscall, jenom zavolani vezme nekolik mikrosekund), gettimeofday k samotnymu cekani taky dobry neni (na PC pro zmenu cte RTC, pomalejsi nez syscall).

[2] Naivni implementace je linearni vzhledem k delce registru (stromecek ANDu), lepsi implementace je logaritmicka (hierarchie lookup tablu), ale moznosti je urcite vic. (tohle je uvaha specificka pro programovani FPGA, z ceho se pisou ASICy nemam predstavu ;).

(moje znalosti low-level hw jsou omezeny na to co pochytim od kolegu, takze sorry pokud rikam bludy)

HYBY: no, presnost je dana vnitrim mechanismem zpracovani .. ruznymy vypocty muzes dojit k ruzne presnym vysledkum .. to se tyka i elementarnich operaci pri deleni a nasobeni.

LITTLELI: 250 ? Ja myslel za na PII MMX to bylo tak 42 .. ale i tak mas na PII 1x FPU + 2x ALU .. na vyssich pentii je to snad 2x FPU + 3x ALU .. takze komu vadi, ze se cast procesoru bude 0,000000025s zabyvat delenim s presnosti na uznevim kolik (asi 19) desetinnych mist ..

LITTLELI: co se tyce fixed x floating point tak snad nelze mluvit o presnosti (to je proste dano sirkou registru), ale o zpusobu prace s registrem. pokud mam v tomhle nejaky nejasnosti tak me prosim oprav.

fixed point poskytuje ale pomerne slusnou presnost .-) hlavne si clovek dopredu
muze urcit, jak moc presne to potrebuje
float point muze byt sice presnejsi, ale zase je to pomaly.... az hruza.
takovej fdiv nebo fmul trvaji radove nekolik desitek cyklu (tusim ze fdiv dokonce 250...)
nejake veci jsou uvedene v tech dokumentech co jsem je pridaval,
nenechte se zmast, ze je tam optimalizace pro Athlon a P4, nektere
rady jsou i obecnejsiho charakteru, takze jsou pouzitelne i pro procesory
nizsich trid.

obycejna pentia nemaji MMX .. a ty jsou na to snad nejrychlejsi .. hodne se vyplati pouzivat SIMD instrukce ..

Nazdar, ma tady nekdo zkusenost se psanim 3d primitiv(v asm samozrejme) + blending, stinovani apod? Btw je nejaky rozdil mezi floating a fixed point aritmetikou krome onoho "fixedp je rychlejsi a floatp je presnejsi"? Taky bych byl vdecny za jakekoli optimalizacni rady, ono se na xp1700+ preci jen blbe optimalizuje pro obycejna pentia ;)

tak jsem to dal obe do zahlavi .]

tjo vubec nechapu jak jsem to tam pred casem nalezl :)

AMD Athlon™ Processor x86 Code Optimization Guide

jo hodim... moment

LITTLELI: a nechtel bys nekam hodit link/ty dokumenty ?

ty brdo fakt to je husty cteni :))
Intel se priznava, ze spousta veci na P4 bezi ponekud dele nez na predeslych procesorech (tj. P3, P2).. a furt tam propagujou Intel Compiler (a ze je to buhvijak rychlejsi nez GCC apod.)
Athlon a optimalizace pro nej jsou naprosto bajecne napsany... to se musi cist :).

ale vyborne jsou (myslim v Intelove dokumentaci) popsany struktury pro vektorizaci
dat v SIMD. aaachjo. potiz je v tom, ze nektere instrukce jsou pomerne komplexni
a nedokazu si predstavit, ze to napisu lip nez dobre nastavenej kompiler.

littleli: necetl, copak pisou?