|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 22 Mar 2005 19:29:51
To : U.P.Galyuck
Subject : Re: Need GUI development tool (Kylix or something)
--------------------------------------------------------------------------------
2005-03-18, U.P.Galyuck <galyuck@paloma.spbu.ru> пишет:
[skipped]
>> > тестами, а не личным предпочтением и общими соображениями. Видел я
> статью,
>>
>> Любые мнения и публикации можно опровергать как минимум
>> аналогичными мнениями и публикациями. Впрочем, мой скепсис к
>
> Об этом я и талдычу - где эти самые аналогичные публикации. А вот личное
> мнение - вижу.
Здесь я от и от вас не видел каких-то ссылок на публикации.
[skipped]
>> больше зависит от качества работы программиста, а не от
>> выбранного языка. Hапример: если 19/20 времени программа проводит
>> в недрах libBLAS, то совершенно пофиг, написана остальная часть
>> на C, Fortran или MatLab. А вот возможность мгновенно сравнить
>> время выполнения алгоритма, скажем, с упакованными матрицами или
>> обычными -- это важно.
>
> Hаучные программы решают еще нерешенные задачи, хотя, конечно,
> используют стандартные пакеты. И время счета обычно определяется не временем
> решения систем линейных уравнений, а, в отличии от теста linpack, временем
> счета коэффициентов этих самых уравнения. Практический пример - в пакете
> crystal методом итераций ищется минимум энергии по нескольким параметрам.
> Каждая итерация (решается система линейных уравнений) идет несколько часов
> (время зависит от параметров задачи). Все время идет на расчет
> коэффициентов.
Hичего сказать не могу. Даже подтвердить твой пример. Ты мог бы
как-нибудь более конкретно указывать?
>
[skipped]
>
>> > где говорилось о том, что вообще нельзя даже средствами ассемблера
> сделать
>> > программу эффективнее, чем на С, т.к. компилятор знает все особенности
>> > процессора и переставит инструкции наиболее оптимальным образом. Hо!
>>
>> Мало ли всякой чуши пишут в газетах.
>
> Я имел в виду статью Криса Касперски в журнале "Программист". Я даже не
> собираюсь защищать положения этой статьи (лично я никогда бы не стал
И не защищайте.
> называть чушью статью, которую не читал). Просто эта фраза замечательно
Впрочем, эту статью я и не назвал чушью.
> иллюстрирует стиль ваших ответов - ни одного аргумента , проверенного лично
Я не хочу аргументировать элементарные вещи без особой
необходимости. В частности, если есть какая-то техника
оптимизации, которая применялась в компиляторе C, то человек пока
что вполне способен её повторить. Кроме того, сам по себе язык C
весьма убог в плане расстановки приоритетов -- что будет
выполняться часто, что можно оставить в регистрах. Соответсвенно,
из этой убогости вытекает большая консервативность в работе с
памятью. Далее, человек со свободным временем может провести
отбор алгоритмов на ассемблере: что можно упаковать, что
перекинуть поближе, etc. Общеизвестные компиляторы C под
доступные архитектуры такой возможности лишены.
И это я даже не перешёл к столь распространённому сейчас SIMD,
оптимальной работы с которым я пока что не видел ни у одного
компилятора.
> вами, только собственные убеждения. Ведь видно невооруженным глазом, что
> Фортран вы видели один раз в жизни - и не понравилось. А раз не понравилось,
Два. А COBOL -- пол-раза. A PL/I вообще не видел.
Это совершенно не мешает мне утверждать, что брать Fortran, COBOL или
PL/I для каких-то новых проектов сейчас не нужно.
> то и не пользуетесь. Hо именно этот факт и не позволяет вам рассуждать
> свысока над вещами, в которых не разбираетесь. Вернее, конечно, можете, но
> если вы честный человек, то всегда надо добавлять - "я хотя и не проверял,
> но мне кажется". Это нужно, чтобы другие читающие люди отделяли факты от
> домыслов.
Ты когда-нибудь говно ел?
>
>> > Иллюстрировалалось это положение на примере целочисленных задач типа
>> > сортировки, а не на счетных задачах с плавающей арифметикой. Особенно
>> > хочется увидеть эффективность работы С++ компилятора на таком очень
> важном
>>
>> Я бы не стал делать заведомо ресурсоёмкую работу на C++ без
>> особой надобности.
>
> Тогда на чем бы стал? Изначально разговор идет о системах
> программирования для научных расчетов. И личное добавление - с комплексной
В своё время я делал на scilab и C. Часть -- на C и Gnuplot.
Сейчас посоветовал бы Octave, или, если есть где нарыть, родной
Matlab. И тот же C.
Впрочем, сам, пожалуй, стал бы писать прототип на erlang. А
когда припёрло бы со скоростью -- начал бы изворачиваться, как бы
это каким-нибудь Allegro Lisp скомпилировать. Впрочем, однозначно
советовать я бы этого не стал.
> арифметикой. Просто очень большая область применения комплексных чисел -
> радиофизика, квантовая механика, ...
В GNU C комплексная арифметика есть.
>
> Галюк Юрий
>
>
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
