|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 25 Mar 2005 01:29:34
To : U.P.Galyuck
Subject : Re: Need GUI development tool (Kylix or something)
--------------------------------------------------------------------------------
2005-03-24, U.P.Galyuck <galyuck@paloma.spbu.ru> пишет:
>> > Hет, это не совсем так. В оптимизирующем компиляторе не надо
> разбивать
>> > длинные выражения на короткие, думая, что так будет эффективнее, не
> надо
>> > чистить циклы, не надо группировать выражения, не надо расставлять метки
>> > (это сужает область оптимизации) - надо поручить это компилятору, т.к.
> он
>> > это сделает эффективнее.
>>
>> При чём здесь вообще <<не надо разбивать длинные выражения на
>> короткие>>? Вы вообще про что? А то мы тут про то, что
>> предложение поменять a*(b*z) на (a*b)*z компилятору C, и не
>> только -- это хреновое предложение.
>
> Я - про меры ухудшающие эффективность оптимизации, включая расстановку
> скобок, мешающую это сделать. А вы, что думаете, что компилятор не знает об
> коммутативности умножений встроенных вещественных типов? Интересно
Вероятно, знает. Точнее, это, вероятно, знает его разработчик.
> получается, вынести за скобки общее выражение и вычислить его один раз,
> чтобы потом использовать в нескольких местах можно, а переставить порядок
> выполнения нельзя?
Переставить порядок двух последовательных умножений -- нельзя.
Порядок вычисления операндов -- можно. Порядок загрузок их в
регистры -- тоже. RTFM.
> Да, и почему это хреновое предложение? Hаоборот, перестановка сомножителей,
> приводящая к уменьшению количества арифметических операций, практически
> всегда увеличивает устойчивость ко всякого рода переполнениям.
Вообще-то то, что Вы предлагаете -- это воспользоваться
ассоциативностью операции умножения встроенных вещественных
типов. Коей ассоциативности _ПРОСТО_HЕТ_!
И никакой устойчивости отсебятина, противоречащая стандартам, не
увеличивает. Что характерно, ни на Си, ни на фортране. А если
кто-то неосведомлён об оных стандартах, то это нисколько не наши
трудности.
Коммутативность у этой операции есть. Какой-либо разницы в
использовании коммутативности в Си и фортране -- я пока что не
вижу.
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
