|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 23 Mar 2005 22:23:32
To : U.P.Galyuck
Subject : Re: Need GUI development tool (Kylix or something)
--------------------------------------------------------------------------------
2005-03-23, U.P.Galyuck <galyuck@paloma.spbu.ru> пишет:
>> >> В GNU C комплексная арифметика есть.
>> >
>> > Расскажи, пожалуйста, в какой версии С-компилятора комплексная
>> > арифметика присутствует, какие ключевые слова при этом используются, и
> по
>> > какому стандарту это реализовано. Без этих пояснений отвечать на
> остальные
>>
>> man 5 complex, далее по ссылкам, включая C99.
>> Или info libc /complex (откуда я впервые про это узнал).
>> Тогда, когда я этим пользовался, был, кажется, gcc 2.7.2.1
>> Впрочем, это я мог и запамятовать, и там уже был 2.9x, x < 5.
>
> Спасибо, я, действительно, обнаружил у себя (gcc 3.2.2) эту так сказать
> комплексную арифметику. Hет, не зря я не знал о ее существовании. Это
Пожалста.
[skipped]
> требуются по алгоритму, получается 4 умножения и два сложения. Еще хуже
> ситуация, когда программируется выражение вида a*b*z, где a, b - типа float,
> а z - complex. Сначала вычисляется b*z, и т.к. они разных типов, происходит
> приведение вещественного b к комплексому типу с перемножением общего вида,
> после чего уже переменная a приводится к комплексному типу и снова
> перемножаются комплексные операнды. Итого - вместо 3-х умножений было
> потрачено 12 умножений и 4 сложения, не считая затраты на приведения
> (пересылки), которые в современных процессорах занимают такое же время, как
> и арифметические операции. Замечу, что усли записать выражение в виде z*b*a,
> т.е. вещественные операнды после комплексного, то оно делается за 5
> умножений и 4 сложения, что тоже далеко от идеального с 3-мя умножениями.
> Оптимизация (-О3) никак не изменила количества операций. Все это происходит
> потому, что компилятор ничего не знает о свойствах этого типа данных
> (коммутативности и ассоциативности) и не может так переставить операции,
> чтобы сначала делалась вещественная арифметика, а потом комплексная, да еще
> учитывалась перегруженность операций с разными сочетаниями типов.
> В Фортране, для которого комплексный тип является встроенным, это делается
> достаточно просто. В С, и как я подозреваю в С++ , это либо не делается
> вообще (главное, чтобы формально поддерживался этот тип данных), либо очень
Для начала, в C этот тип также является встроенным. Поскольку
перегрузки операторов в C нет, и на макросах они (операторы) не
делаются.
Вот только я что-то совсем не понял, к чему Вы написали этот
пассаж? При чём тут качество ко-дегенератора из коллекции GNU и
выбор Fortran vs other world? То есть Вы что думаете, если
замените C Compiler на Fortran Compiler, то всё станет сразу
хорошо? Фигушки-заюшки. В GNU Compiler Collection для фортрана
точно тот же самый генератор кода. Более того, GNU Fortran всё
ещё основан на f2c, потому узких мест там будет ещё больше.
Специально для проф. спорщиков: не надо мне тут рассказывать про
другие компиляторы фортрана. Другие компиляторы для C тоже
имеются, тот же Intel C на IA32 считается существенно оптимальнее
гнутого.
По поводу конкретного примера умножения комплексного и
действительного: это почему-то посчитали рискованным. Включается
опцией -ffast-math.
Ещё я бы пожалуй посоветовал что-нибудь вроде -mcpu=pentium4
-march=pentium4 -msse2 -mfpmath=sse .
> трудно реализовать. Поэтому научные программы еще долго будут
> разрабатываться на специально для этого приспособленном языке - Фортран, а
> все логические умозаключения, основанные на собственном понимании проблемы,
> и "принципе Оккама", оказываются опровергнутыми элементарными тестами (все,
> что я описал, я выяснил, вычитывая ассемблерный листинг результатов
> компиляции).
Да-дад. Скажите мне, какой результат вам нужен, и я скажу, какой
тест выбрать. Вообще, мне бы очень хотелось, чтобы в
предъявляемых в качестве опровержения элементарных тестах было
меньше логических и фактических ошибок. Hапример, совершенно
непонятно, что же вы на результат тестирования такого же
фортрановского кода не посмотрели хотя бы.
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
