|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 24 Mar 2005 17:50:30
To : U.P.Galyuck
Subject : Re: Need GUI development tool (Kylix or something)
--------------------------------------------------------------------------------
2005-03-24, U.P.Galyuck <galyuck@paloma.spbu.ru> пишет:
>> Вот только я что-то совсем не понял, к чему Вы написали этот
>> пассаж? При чём тут качество ко-дегенератора из коллекции GNU и
>> выбор Fortran vs other world? То есть Вы что думаете, если
>> замените C Compiler на Fortran Compiler, то всё станет сразу
>> хорошо? Фигушки-заюшки. В GNU Compiler Collection для фортрана
>> точно тот же самый генератор кода. Более того, GNU Fortran всё
>> ещё основан на f2c, потому узких мест там будет ещё больше.
>
> Разумеется, я этого не думаю. Конечно, g77 и gcc хреновые компиляторы.
> Именно поэтому профессиональные программисты во всем мире используют
> коммерческие компиляторы типа pg90. Hо именно вы предложили использовать
А давайте не будем кивать на профессиональных программистов во
всём мире? Тем более, что любое сравнение того, что они в среднем
используют, будет на в Вашу пользу?
> для арифметических операций с комплексными числами GNU C. Именно поэтому я
> его и исследовал.
Я предложил использовать C. Можно, в частности, GNU.
>
>> Специально для проф. спорщиков: не надо мне тут рассказывать про
>> другие компиляторы фортрана. Другие компиляторы для C тоже
>> имеются, тот же Intel C на IA32 считается существенно оптимальнее
>> гнутого.
>
> То есть вы предлагаете проверить и его на адекватность? Или вы знаете,
Проверьте. А ещё я предлагаю проверить на адекватность фортран.
> что комплексная арифметика там реализована лучше? Хорошо, в свободное время
Возможность реализовать комплексную арифметику лучше, чем в GNU C
Вами пока что не показана.
> я попробую это сделать - о результатах, если это интересно, доложу.
>
>> По поводу конкретного примера умножения комплексного и
>> действительного: это почему-то посчитали рискованным. Включается
>> опцией -ffast-math.
>
> Да, стало лучше. Умножение вещ. на комплексное делается за две операции
> (но реализация этого лежит на поверхности). Hо все равно ни о какой
> перестановке сомножителей разных типов с целью оптимизации выражений и речи
> нет.
Это ничего, что в IEEE floating point arithmetics
(a*b)*c вообще говоря не равно a*(b*c)?
>
>> Да-дад. Скажите мне, какой результат вам нужен, и я скажу, какой
>> тест выбрать. Вообще, мне бы очень хотелось, чтобы в
>> предъявляемых в качестве опровержения элементарных тестах было
>> меньше логических и фактических ошибок. Hапример, совершенно
>> непонятно, что же вы на результат тестирования такого же
>> фортрановского кода не посмотрели хотя бы.
>
> А я, как и вы, уверен в результате. Именно исходя из глубокой связи
> разработчиков gcc и g77 почти наверняка результат будет такой же. Hо я
Замечательно. Я мог бы и не париться, проверяя.
> ничего и не утверждаю о компиляторе g77. А вот то, что я говорю об
> оптимизации выражений при комплексной арифметике, известно давным-давно со
> времен транслятора "Альфа", т.е. уже в 70-ые годы подобного рода оптимизация
> была реализована. И о каких это элементарных ошибках идет, интересно, речь?
> Я, по крайней мере, честно провел эксперименты, о параметрах которых я и
> сообщил. Я ничего не придумал и не додумал.
Вы не провели _никакого_ сравнения фортрана и C.
Для профессиональных спорщиков: если скажете, что сравнение
подразумевало отсутствие в фортране тех вещей, в которых Вы
обвиняли C, то я там показал, что в фортране они присутствуют в
том же объёме.
>
> Галюк Юрий
>
>
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
