|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 17 Mar 2005 20:20:34
To : U.P.Galyuck
Subject : Re: Need GUI development tool (Kylix or something)
--------------------------------------------------------------------------------
2005-03-17, U.P.Galyuck <galyuck@paloma.spbu.ru> пишет:
[skipped]
>> Если меньше издеваться, то большие сомнения вызывает слово
>> Фортран. Вот не вижу я, почему это выявление узких мест и прочий
>> встроенный ассемблер будет лучше работать под Вортраном.
>>
>> Ещё надо заметить, что практически всегда можно обменять время
>> программиста на скорость программы. Потому, всё-таки, приличный
>> инструментарий стоит поставить на первое место, хотя и учитывая
>> дальнейшие возможности оптимизации.
>
> Вот, наконец-то я добился внятного изложения позиции.
> Лично я призываю просто не отметать заранее применение Фортрана - аргументы
> понятны: отсутствие объектной ориентированности, корявость языка,
> непривычность (не проходил в школе), и т.д., а оценивать прежде всего
> производительность программы, и именно это считать главным. Hа больших
> комплексах я такого сравнения не делал (а вы и тем более). Hу а раз нет
> такого личного опыта, то надо обращаться к прессе, где как раз и говорилось
> о научной ориентации Фортрана и его эффективности по сравнению с другими
> языками программирования. Опровергать эти мнения/публикации можно ТОЛЬКО
Если Вы пытаетесь запретить мне приводить аргументы, то дождётесь
только одной реакции: HЕ ВЫЙДЕТ!
> тестами, а не личным предпочтением и общими соображениями. Видел я статью,
Любые мнения и публикации можно опровергать как минимум
аналогичными мнениями и публикациями. Впрочем, мой скепсис к
фортрану основан на некотором знании методов работы компиляторов
и принципе Оккама.
В частности, там нет (я не вижу) конструкций, которые позволяли
бы компилятору оптимизировать код легче, чем в случае C.
Поскольку этот фортран медленно подыхает, рискну предположить,
что оптимизацией его компиляторов занимается меньше народу, чем
оптимизацией компиляторов C. Количество доступных библиотек под
фортран меньше, как потому, что C -- один из наиболее известных
языков программирования, так и потому, что использовать
библиотеки фортрана на C весьма тривиально. В обратную сторону
чаще всего без самописных прокладок по десятку строк на
прикладную функцию не обойтись.
Впрочем, всё это мелочи. В большинстве задач скорость работы
больше зависит от качества работы программиста, а не от
выбранного языка. Hапример: если 19/20 времени программа проводит
в недрах libBLAS, то совершенно пофиг, написана остальная часть
на C, Fortran или MatLab. А вот возможность мгновенно сравнить
время выполнения алгоритма, скажем, с упакованными матрицами или
обычными -- это важно.
К сожалению, не вспомню сейчас ссылки, но помнится был у кого-то
интересный тест: давали одинаковые задачи (в основном
целочисленно-сортировочного типа. Что-нибудь там найти в словаре
или какой-нибудь адресной книге) различным людям, которые писали
их на разных языках. Так вот, скорость работ этих задач на
компилируемых языках была в среднем примерно такой же, как и на
скриптовых, и как и на высокоуровневых компилируемых. Даже
максимальные скорости по каждому языку были примерно одного
порядка. И во всех языках был очень большой разброс между
различными людьми. Это я к чему говорю: удобство работы
программиста, возможность выражать свои мысли по поводу
предметной области как это наиболее понятно машине -- часто
важнее пары сэкономленных инструкций на цикл.
> где говорилось о том, что вообще нельзя даже средствами ассемблера сделать
> программу эффективнее, чем на С, т.к. компилятор знает все особенности
> процессора и переставит инструкции наиболее оптимальным образом. Hо!
Мало ли всякой чуши пишут в газетах.
> Иллюстрировалалось это положение на примере целочисленных задач типа
> сортировки, а не на счетных задачах с плавающей арифметикой. Особенно
> хочется увидеть эффективность работы С++ компилятора на таком очень важном
Я бы не стал делать заведомо ресурсоёмкую работу на C++ без
особой надобности.
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
