Домашна "Бързодействие и оптимизация на кода"


1
Третата задача от тази домашна е свързана с определяне на бързодействието на SQRT, SIN и LOG за типовете double, float и decimal. Но и трите функции в Math приемат само стойност от тип DOUBLE. Това според мен означава, че за типовете float и decimal всъщност няма смисъл да се мери, защото реално към измереното с double ще се добави кастване към и после от double. Или трябва сами да си имплементираме функциите? Някакви други идеи?



Отговори



2

Залудо мери, залудо не стой, по-скоро според мен.

Също твоете мнение ("Това според мен означава...") към момента е предположение, което можеш да докажеш или отхвърлиш чрез наблюдение ( реално измерване ). 


от todorovh (2055 точки)


1

Аз мисля като теб, че за float и особено за decimal ще има забавяне. Но както казва колегата, с измерване е най-добре да се провери :)

Предполагам, че float  просто няма смисъл да се използва, но decimal  може да се налага заради точността.


от ellapt (6303 точки)


1
Няма как да постигнеш точността на decimal при положение, че извършваш самите сметки с точността на double. По-скоро разликата между бързодействието с double и останалите типове ще зависи от скоростта, с която работи кастването.

от todor_ia (132 точки)

2

@Todor_ia, вярно - ще коригирам отговора си :)

Освен това, не мога да измисля за какво би ми потрябвал корен квадратен от decimal. За всеки случай, ТУК има един пример с повишаване на точността до допустима грешка (което внася допълнително забавяне към това, че decimal е структура).

В домашното не се изискват бързодействие и точност, а само да изследваме за различните типове.

   


от ellapt (6303 точки)


0

Здравейте и аз каствам първо към doouble и после към това което се изисква, но  натурания ми логаритъм  гърми с OverFlow exception, някой да е решил този проблем.

х става

(double)x -2.26877976067188 double, и при Math.Log  вече е NaN, някакви идей как да се реши тои проблем?

for 10000

x=1000000000

x=>(decimal)Math.Log(((double)+x)


от djingibi (99 точки)


1
Този плюс преди последния х ми се струва излишен ;)

от Dido_Aint (577 точки)


0

Понеже пропуснах лекцията за оптимизацията на кода не знам какво точно се е обсъждало(и дали въобще е станало дума) за profier-и и кой от тях би било най - удобно да използваме както в домашните, така и за в бъдеще.

Надявам се някой да сподели опита си, ако вече използва съответен инструмент.


от PerunPlayer (15 точки)


0
По време на лекцията ни показаха dotTrace, за който имаме лицензи. Миналата година е било JustTrace ( отново споменато на лекцията ) така че и двете би трябвало да ти свършат работа.

от todorovh (2055 точки)


1
Хмм , бързодействието на тези операции не зависи ли до голяма степен и от това за какви ALU-та успее да се закачи CLR-a? Защото SQRT май от доста време не се прави в software , някой по-запознат може ли да коментира?

от Betastate (341 точки)


2

Math.Sqrt се транслира до една единствена инструкция на Assembler (fsqrt) и се пресмята от процесора:

c# Math.Sqrt Implementation

x86 Instruction Set Reference - FSQRT

 

от marks (354 точки)

1
Което отново доказва, че излишното престараване (както в случая е с decimal) обикновено е вредно.

от ellapt (6303 точки)