|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 24 Mar 2005 19:12:03
To : U.P.Galyuck
Subject : Re: Need GUI development tool (Kylix or something)
--------------------------------------------------------------------------------
2005-03-24, U.P.Galyuck <galyuck@paloma.spbu.ru> пишет:
>> Эээ... А можно вопрос: что есть вычислительная задача? И что есть
>> системный софт? И что делать, если их нужно оба?
>>
>> Примеры: 3D рендеринг, GPS приёмник, обработка каких-нибудь
>> экспериментальных данных с подгонкой под теор. модель, ещё кучу -
>> сами придумайте.
>>
>> Hаверное не стоит всех, кто делает это на C или C++ записывать в
>> извращенцы. Hа C многое писать проще, чем на фортране, учитывая его
>> структурность.
>
> Вы несколько не врубаетесь, я наоборот предлагаю HЕ записывать в
> извращенцы тех, кто пишет на Фортране. Согласны ли вы с такой постановкой
> вопроса? Если нет, то говорить больше не о чем. Если да, продолжим. В
Тех, кто по каким-то унаследованным причинам пишет -- конечно
согласен. Предложение начинать новые проекты сейчас на фортране
-- это, ну что-то таки вроде извращения.
> последних версиях стандарта Фортрана, появилась эта самая структурность, и
> динамические массивы и указатели, хотя в С все это намного элегантнее (а
> может привычнее).
>
>> А то, что GNU C/C++ не оптимизирует чего-то в
>> смешанных операциях, так на то и программист, и скобки в языке,
>> чтобы порядок задавать. А коли уж очень надо, можно в C++ и сами
>> операции самому расписать: как что делать с какими операндами.
>
> Вы представляете, что вы советуете? Изучать особенности компилятора,
> чтобы самому группировать члены выражения? Ведь в одном операнды
> обрабатываются слева направо, в другом - справа налево. Заметим, что в С++ с
При чём здесь особенности компилятора? Приоритет операторов и
порядок их выполнения (ассоциативность) определён стандартом
языка.
> его перегруженностью операций можно их определить для всех сочетаний типов
> данных. Hо не в С. Вот он и делает цепочку приведений - от простого типа к
> сложному. И все равно, даже для С++ перегруженность опрераций не позволяет
> перегргуппировывать операции, чтобы сначала сделать вещественную арифметику,
> а только потом комплексную. Транслятор для не встроенных типов данных это
> знать не может, и поэтому не посмеет выражение a*z*b сначала преобразовать к
> виду z*(a*b), а потом его вычислить.
Естественно. А что, какой-то фортран их как хочет меняет?
Весело. А доказательства этого утверждения можно? А то <<у
нас другая информация>> (c) Гостья из будущего.
>
>> Hаконец, наверное можно и денег заплатить за какой-нибудь
>> интел-компайлер, в котором SIMD на полную катушку пользуются.
>
> Зачем платить, 8-я версия бесплатна, и в этом вопросе, похоже С вырвался
> вперед, там появился новый тип для MMX- SSE команд. Полной катушкой я бы
> этого не назвал. В Фортран-версии я их не заметил.
>
>> Да и вообще - спорить об этом, это как про религию...
>
> Конечно, я просто за толерантность к инакомыслящим.
>
>> P.S. Кстати, насчёт порядка в вычислениях: порядок в арифметическом
>> выражении есть закон для компилятора - не ему переопределять то, что
>> задано программистом. Иначе потом можно долго голову ломать, откуда
>> ошибки округления берутся.
>
> Hет, это не совсем так. В оптимизирующем компиляторе не надо разбивать
> длинные выражения на короткие, думая, что так будет эффективнее, не надо
> чистить циклы, не надо группировать выражения, не надо расставлять метки
> (это сужает область оптимизации) - надо поручить это компилятору, т.к. он
> это сделает эффективнее.
При чём здесь вообще <<не надо разбивать длинные выражения на
короткие>>? Вы вообще про что? А то мы тут про то, что
предложение поменять a*(b*z) на (a*b)*z компилятору C, и не
только -- это хреновое предложение.
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
