Считает N членов ряда Тейлора? Или еще как?

И будет ли, скажем, 10 умножений и 20 сложений быстрей обсчета, скажем, трех арктангесов?

Заранее спасибо за ответ.

Здравствуйте, Rosco, Вы писали:

R>Считает N членов ряда Тейлора? Или еще как?

R>И будет ли, скажем, 10 умножений и 20 сложений быстрей обсчета, скажем, трех арктангесов?

R>Заранее спасибо за ответ.

Смотрим, какой листинг генерит VC 6:

; 5    :     
; 6    :     double x = tan(5);

    fld    QWORD PTR __real@8@4001a000000000000000
    fptan

то есть я так понимаю, что он считает его 1-2 коммандами. То есть естественно стандартная tan будет намного быстрее.
А вообще, я так понимаю, что стандартом такие вещи не предусмотрены => зависит от реализации.


P.S: а чего ты паришься? Думаешь свою функцию тангенса писать? Дык стандартные функции тоже не дураки писали, не думаю, что у тебя получится лучше, чем у них.

Здравствуйте, denisku, Вы писали:

D>

D>; 5    :     
D>; 6    :     double x = tan(5);

D>    fld    QWORD PTR __real@8@4001a000000000000000
D>    fptan
D>

D>то есть я так понимаю, что он считает его 1-2 коммандами. То есть естественно стандартная tan будет намного быстрее.
D>А вообще, я так понимаю, что стандартом такие вещи не предусмотрены => зависит от реализации.

Вот, например, что было получено от кода

atan(26);

; Line 6
    push    1077542912                ; 403a0000H
    push    0
    call    _atan

Т.е. происходит вызов функции. Однако это не значит, что все произошло за "1-2 команды" процессора.


D>P.S: а чего ты паришься? Думаешь свою функцию тангенса писать? Дык стандартные функции тоже не дураки писали, не думаю, что у тебя получится лучше, чем у них.

Нет, не думаю. Просто для решения некоторой задачи можно посупить двумя способами:
1. Найти три арка (по тупому)
2. Несколько умножений и сложений (с учетом аналитической геометрии)

Вытекает вопрос: что менее мучительно для CPU?

Здравствуйте, Аноним, Вы писали:

А>Нет, не думаю. Просто для решения некоторой задачи можно посупить двумя способами:
А>1. Найти три арка (по тупому)
А>2. Несколько умножений и сложений (с учетом аналитической геометрии)

А>Вытекает вопрос: что менее мучительно для CPU?

Совершенно очевидно что это "может" зависеть от компилятора.
Также очевидно что нельзя заниматься оптимизацией без измерений.
Либо используйте профайлер, либо замеряйте время на большом (например, 10,000) количестве вычислений.

Здравствуйте, Аноним, Вы писали:

А>

... skipped ...
А>

На каком компиляторе? MSVC7.1 спокойно оптимизирует до:

        fld QWORD PTR __real@403a000000000000
        fld1
        fpatan

Правда не стоит его идеализировать. Во-первых обрати внимание на fld1. Прежде чем вычислять арктангенс fpatan поделит аргумент на 1(или на любое другое число). Если в твоей задаче понадобится делать что-то типа atan(x/y), то
оптимизатор не поймет этого хитрого намека и будет делить при помощи fdiv(если делитель зараннее неизвестен) или при помощи fmul(предварительно превращая константу c в 1/c).

А>Нет, не думаю. Просто для решения некоторой задачи можно посупить двумя способами:
А>1. Найти три арка (по тупому)
А>2. Несколько умножений и сложений (с учетом аналитической геометрии)

А>Вытекает вопрос: что менее мучительно для CPU?
Точно не знаю, но почему-то мне кажется что вариант N2 будет явно быстрее чем ТРИ fpatan. Лучший способ проверить — измерить на твоей конкретной задаче. Но как бы не были оптимизированны инструкции типа fptan, fpatan и т.д., сложения и умножения все равно будут в разы быстрее. Для процессоров класса PI timing был примерно такой:

fpatan 17-173
fmul,fmulp,fadd,faddp 3

Нетрудно посчитать, что при самом благоприятном раскладе три fpatan равнозначны 17 умножениям/сложениям. Сейчас разрыв скорее всего сократился, но думаю не достаточно сильно для того, чтобы первый вариант выглядел предпочтительнее.

Здравствуйте, uw, Вы писали:

uw>Здравствуйте, Аноним, Вы писали:

А>>

uw>... skipped ...
А>>

uw>На каком компиляторе? MSVC7.1 спокойно оптимизирует до:
uw>

uw>        fld QWORD PTR __real@403a000000000000
uw>        fld1
uw>        fpatan
uw>

uw>Правда не стоит его идеализировать. Во-первых обрати внимание на fld1. Прежде чем вычислять арктангенс fpatan поделит аргумент на 1(или на любое другое число). Если в твоей задаче понадобится делать что-то типа atan(x/y), то
uw>оптимизатор не поймет этого хитрого намека и будет делить при помощи fdiv(если делитель зараннее неизвестен) или при помощи fmul(предварительно превращая константу c в 1/c).

А>>Нет, не думаю. Просто для решения некоторой задачи можно посупить двумя способами:
А>>1. Найти три арка (по тупому)
А>>2. Несколько умножений и сложений (с учетом аналитической геометрии)

А>>Вытекает вопрос: что менее мучительно для CPU?
uw>Точно не знаю, но почему-то мне кажется что вариант N2 будет явно быстрее чем ТРИ fpatan. Лучший способ проверить — измерить на твоей конкретной задаче. Но как бы не были оптимизированны инструкции типа fptan, fpatan и т.д., сложения и умножения все равно будут в разы быстрее. Для процессоров класса PI timing был примерно такой:
uw>

uw> fpatan 17-173
uw> fmul,fmulp,fadd,faddp 3

uw>Нетрудно посчитать, что при самом благоприятном раскладе три fpatan равнозначны 17 умножениям/сложениям. Сейчас разрыв скорее всего сократился, но думаю не достаточно сильно для того, чтобы первый вариант выглядел предпочтительнее.

Имх все же лучше взять в зубы профайлер и посмотреть. ранняя оптимизация до хорошего не доводит обычно