|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : U.P.Galyuck 2:5020/400 18 Mar 2005 13:52:25
To : Ilya Anfimov
Subject : Re: Need GUI development tool (Kylix or something)
--------------------------------------------------------------------------------
> Если Вы пытаетесь запретить мне приводить аргументы, то дождётесь
> только одной реакции: HЕ ВЫЙДЕТ!
Я этого как раз и жду.
> > тестами, а не личным предпочтением и общими соображениями. Видел я
статью,
>
> Любые мнения и публикации можно опровергать как минимум
> аналогичными мнениями и публикациями. Впрочем, мой скепсис к
Об этом я и талдычу - где эти самые аналогичные публикации. А вот личное
мнение - вижу.
> фортрану основан на некотором знании методов работы компиляторов
> и принципе Оккама.
> В частности, там нет (я не вижу) конструкций, которые позволяли
> бы компилятору оптимизировать код легче, чем в случае C.
> Поскольку этот фортран медленно подыхает, рискну предположить,
> что оптимизацией его компиляторов занимается меньше народу, чем
> оптимизацией компиляторов C. Количество доступных библиотек под
> фортран меньше, как потому, что C -- один из наиболее известных
> языков программирования, так и потому, что использовать
> библиотеки фортрана на C весьма тривиально. В обратную сторону
> чаще всего без самописных прокладок по десятку строк на
> прикладную функцию не обойтись.
>
> Впрочем, всё это мелочи. В большинстве задач скорость работы
> больше зависит от качества работы программиста, а не от
> выбранного языка. Hапример: если 19/20 времени программа проводит
> в недрах libBLAS, то совершенно пофиг, написана остальная часть
> на C, Fortran или MatLab. А вот возможность мгновенно сравнить
> время выполнения алгоритма, скажем, с упакованными матрицами или
> обычными -- это важно.
Hаучные программы решают еще нерешенные задачи, хотя, конечно,
используют стандартные пакеты. И время счета обычно определяется не временем
решения систем линейных уравнений, а, в отличии от теста linpack, временем
счета коэффициентов этих самых уравнения. Практический пример - в пакете
crystal методом итераций ищется минимум энергии по нескольким параметрам.
Каждая итерация (решается система линейных уравнений) идет несколько часов
(время зависит от параметров задачи). Все время идет на расчет
коэффициентов.
> К сожалению, не вспомню сейчас ссылки, но помнится был у кого-то
> интересный тест: давали одинаковые задачи (в основном
> целочисленно-сортировочного типа. Что-нибудь там найти в словаре
> или какой-нибудь адресной книге) различным людям, которые писали
> их на разных языках. Так вот, скорость работ этих задач на
> компилируемых языках была в среднем примерно такой же, как и на
> скриптовых, и как и на высокоуровневых компилируемых. Даже
> максимальные скорости по каждому языку были примерно одного
> порядка. И во всех языках был очень большой разброс между
> различными людьми. Это я к чему говорю: удобство работы
> программиста, возможность выражать свои мысли по поводу
> предметной области как это наиболее понятно машине -- часто
> важнее пары сэкономленных инструкций на цикл.
А что, против этого кто-то возражает? Только все вышесказанное не
является аргументом в данном конкретном вопросе.
> > где говорилось о том, что вообще нельзя даже средствами ассемблера
сделать
> > программу эффективнее, чем на С, т.к. компилятор знает все особенности
> > процессора и переставит инструкции наиболее оптимальным образом. Hо!
>
> Мало ли всякой чуши пишут в газетах.
Я имел в виду статью Криса Касперски в журнале "Программист". Я даже не
собираюсь защищать положения этой статьи (лично я никогда бы не стал
называть чушью статью, которую не читал). Просто эта фраза замечательно
иллюстрирует стиль ваших ответов - ни одного аргумента , проверенного лично
вами, только собственные убеждения. Ведь видно невооруженным глазом, что
Фортран вы видели один раз в жизни - и не понравилось. А раз не понравилось,
то и не пользуетесь. Hо именно этот факт и не позволяет вам рассуждать
свысока над вещами, в которых не разбираетесь. Вернее, конечно, можете, но
если вы честный человек, то всегда надо добавлять - "я хотя и не проверял,
но мне кажется". Это нужно, чтобы другие читающие люди отделяли факты от
домыслов.
> > Иллюстрировалалось это положение на примере целочисленных задач типа
> > сортировки, а не на счетных задачах с плавающей арифметикой. Особенно
> > хочется увидеть эффективность работы С++ компилятора на таком очень
важном
>
> Я бы не стал делать заведомо ресурсоёмкую работу на C++ без
> особой надобности.
Тогда на чем бы стал? Изначально разговор идет о системах
программирования для научных расчетов. И личное добавление - с комплексной
арифметикой. Просто очень большая область применения комплексных чисел -
радиофизика, квантовая механика, ...
Галюк Юрий
--- ifmail v.2.15dev5.3
* Origin: St.Petersburg University (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
