Здравствуйте, Сергей Губанов, Вы писали:
СГ>В результате, программа Ткачёва на Component Pascal оказалась в 8 раз быстрее программы на С++ и работала правильно, в то время как программа на С++ работала нестабильно, падала, страдала утечками памяти и т.п. Обвинить конкурента в криворукости нельзя — он действительно классно знает С++. Просто алгоритмы очень сложные — надо интенсивно работать с гигабайтными динамическими структурами.
Код программы на С++ в студию. А мы уже решим на сколько хорошо автор знает программирование вобще и С++ в частности.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
eao197 wrote: > Помнится, здесь была большая тема про сборку мусора в real-time > системах. И приводилась ссылка на компанию, которая продавала > программно-аппаратный комплекс, разработанный на основе Oberon.
Я спросил у знакомых real-time'щиков. Про Обероновые системы они ничего
не слышали вообще (как и про сам Оберон).
Из наиболее близкого — Inferno VM. Там использовался Паскаль-подобный
язык, но это далеко не Оберон. Компания появилась в конце 90-х и продает
встраиваемые системы, не очень успешно.
Здравствуйте, McSeem2, Вы писали:
E>>>Дело не в скорости самой программы, а в том, насколько удобнее будет программитам-математикам писать программу на этих языках. Делать расчеты на Паскале было гораздо проще, чем на C++ (хотя в некоторых случаях C++ и рулил, сам сталкивался).
MS>Пробовали ли вы закодировать простейшее выражение с комплексными числами на голом C?
А работу с разреженными матрицами на Паскале?
Как раз из-за таких вещей я предпочитал C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
McSeem2 wrote: > E>>Дело не в скорости самой программы, а в том, насколько удобнее будет > программитам-математикам писать программу на этих языках. Делать расчеты > на Паскале было гораздо проще, чем на C++ (хотя в некоторых случаях C++ > и рулил, сам сталкивался). > Пробовали ли вы закодировать простейшее выражение с комплексными числами > на голом C?
No problem:
complex double square_d(complex double a)
{
return (a * a);
}
(это С99)
> Я не знаю, что такое Оберон, но однозначно могу сказать, что на > комплексных числах Фортран кроет С++ по скорости. И иначе быть не может, > поскольку комплексные числа — это встроенный тип в Фортране и > оптимизатор все про них знает. А в C++ это некий класс, просто класс.
Ну не совсем так. Intel C++, например, знает про комплексные числа из
стандартной библиотеки и использует для них специальные оптимизации.
Здравствуйте, Cyberax, Вы писали:
C>Для модулей собираются добавить GC. То есть неиспользуемые сборки будут C>просто прибиваться сборщиком мусора. В отличие от явной выгрузки, это C>вполне безопасно (а в Java уже лет 5 код классов собирается GC).
Как интересно GC должен решить задачу о возможности выгрузки вот такого модуля:
MODULE M;
VAR a*: INTEGER;
END M.
или на C#:
public sealed class M
{
private M ()
{
}
public static int a;
}
Допустим количество ссылок на модуль M сейчас равно нулю. Значит его уже можно выгружать, да?
А вот и нельзя!!!
Вдруг через 3 часа в систему будет загружен некий другой модуль, который захочет считать значение переменной M.a???? И что он прочтёт??? Если модуль M будет выгружен, а потом опять загружен, то M.a будет равно 0.
Вывод.
Модули нельзя выгружать "автоматически". Их можно выгружать только по явной просьбе.
Здравствуйте, eao197, Вы писали:
E>Моменты наступления сборки мусора априори предсказуемы или об этом нужно вручную заботится?
А в Обероне уже нет сборщика мусора? E>Помнится, здесь была большая тема про сборку мусора в real-time системах. И приводилась ссылка на компанию, которая продавала программно-аппаратный комплекс, разработанный на основе Oberon.
И в чем проблема посадить C# на сборщик мусора работающий в реальном времени?
E>Например, на QNX, VxWorks, LynxOS, OS-9, или любой другой из этих.
А оберон на них есть?
E>Глупость -- может быть. Но большое количество критически важного софта пишется именно на императивных языках. На том же C, в частности.
Ты думаешь это хорошо?
E>Оговорюсь, не по скорости, а по удобству для программистов-математиков. А где -- например, при расчете надежности ленточных фундаментов методом конечных элементов, при расчете распределения температуры на лопастях турбин методом граничных элементов, при расчетах надежности конструкций методом конечных разностей, при реализации расчетов оптимизации чего-нибудь различными вариантами методов оптимизации (того же симплекс метода, к примеру). Поскольку я специализировался на кафедре Вычислительной Математики и Программирования, могу утверждать, что математики предпочитали пользоваться Паскалем, а не C++.
Исключительно по тому что они привыкли к Паслаю и ничего не знают о С++. Да и опять же математикам должны быть ближе функциональные языки.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Нет конечно. Точно так же как нельзя вернуть адрес любой локальной сущности.
Это не настолько очевидно. В современных языках это можно. В том же Шарпе, например. Только не адрес, а объект — функция + замыкание. СГ>Вложенная процедура живет в контексте процедуры её вызвавшей и имеет доступ к её локальным переменным. Поэтому снаружи её вызывать нельзя. Раз нельзя, то и указатель на неё получить нельзя.
Так а в чем ее смысл? Главное в анонимных методах, лямбда функциях и всех их родственниках — это то, что они хранят замыкание — контекст, в котором их вызвали. В Шарпе, насколько я видел, анонимные методы применяют для создания однострочных коллбэков. А в Обероне так можно?
Здравствуйте, Cyberax, Вы писали:
C>Я спросил у знакомых real-time'щиков. Про Обероновые системы они ничего C>не слышали вообще (как и про сам Оберон).
Сергей Губанов wrote: > WH>Это шутка да? Я не могу себе представить ситуации где бы Оберон по > сравнению с С++ рулил в расчетах. Может ты мне продемонстрируешь это? > Легко. > Ткачёв думаете просто так что ли перешёл на Оберон/Компонентный-Паскаль?
Может из-за того, что не смог освоить альтернативы?
> Фишка в том, что алгоритм расчёта может быть чрезвычайно сложен. > Правильно реализовать чрезвычайно сложный алгоритм на языке C++ гораздо > сложнее чем на Oberon/Component Pascal, которые имеют сборщик мусора.
1. Сборщик мусора (причем не хуже Обероновского) к С++ прикручивается за
5 минут. Не верите? Давайте поспорим.
2. Перегрузка операторов в С++ позволяет записывать многие алгоритмы
_гораздо_ красивее Оберона.
> Он в BlackBox на Component Pascal реализовал алгоритм за 3 месяца. > Его конкурент решал ту же самую задачу на С++ 3 года.
"Один журнал погружаем в серную кислоту, а TV Park в дистиллированую
воду. Видите? С TV Park'ом ничего не случилось!" (с) реклама.
> Обвинить конкурента в криворукости нельзя — он действительно классно > знает С++.
Да-да. Мы уже, кажется, смеялись над примерами его знаний.
Здравствуйте, eao197, Вы писали:
Q>>Такое ощущение, что вы не в курсе, что представляет собой язык со встроенной поддержкой многозадачности. Это тоже самое, что язык с GC на фоне языка с ручным управлением памятью. Когда такая поддержка есть на уровне языка, то многие вещи становятся значительно проще, многие проблемы исчезают, а многие дополнительные возможности появляются.
E>Очень может быть. А на какие языки со встроенной многозадачностью, кроме Erlang, еще можно посмотреть?
Здравствуйте, Mamut, Вы писали:
M>Это мне напоминает мою первую книжку по Турбо Паскалю. Десять глав, по-моему было. Из них девяь — все нормально. В десятой объяснялись указатели... Указатели обозначались знаком "вертикальная стрелочка вверх" То есть не "^", а натурально
Тебя, наверное, нагло обманули. Это была книжка по просто Паскалю.
Здравствуйте, WolfHound, Вы писали:
E>>Моменты наступления сборки мусора априори предсказуемы или об этом нужно вручную заботится? WH>А в Обероне уже нет сборщика мусора?
WH>И в чем проблема посадить C# на сборщик мусора работающий в реальном времени?
В том, что этого еще нет. Или уже есть?
WH>А оберон на них есть?
Там, я думаю, нет. Уто у Сергея Губанова нужно спрашивать, где есть Оберон.
А вот где есть C# и так понятно. Я не в обиду C#, просто думаю, что встраиваемые системы вряд ли когда-нибудь на C# будут делать. Хотя бы потому, что там уже, кроме C и C++, еще и J2ME есть.
E>>Глупость -- может быть. Но большое количество критически важного софта пишется именно на императивных языках. На том же C, в частности. WH>Ты думаешь это хорошо?
Не мне решать, хорошо это или нет. Так есть. И с этим нужно считаться.
WH>Да и опять же математикам должны быть ближе функциональные языки.
Математикам, имхо, должна быть ближе математика. Как я смог заметить, нельзя от них требовать досканального знания особенностей языка. И, поэтому, чем более тривиальный язык, тем лучше. Поэтому C++ со своими заморочками многим не подходил.
А вот устроят ли математиков функциональные языки по скорости работы кода -- это большой вопрос. Особенно в числодробительных областях.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Сергей Губанов, Вы писали:
WH>>Код программы на С++ в студию. СГ>Недождётесь...
Тогда я делаю единственно возможной в этой ситуации вывод: Все это не болие чем маркетинговый бред.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>Математикам, имхо, должна быть ближе математика. Как я смог заметить, нельзя от них требовать досканального знания особенностей языка. И, поэтому, чем более тривиальный язык, тем лучше. Поэтому C++ со своими заморочками многим не подходил. E>А вот устроят ли математиков функциональные языки по скорости работы кода -- это большой вопрос. Особенно в числодробительных областях.
ML и его вариации очень хорошо поддаются оптимизации.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Сергей Губанов wrote: > _>Кстати в обероне можно вернуть указатель на локальную функцию? > Нет конечно. Точно так же как нельзя вернуть адрес любой локальной сущности. > Вложенная процедура живет в контексте процедуры её вызвавшей и имеет > доступ к её локальным переменным. Поэтому снаружи её вызывать нельзя. > Раз нельзя, то и указатель на неё получить нельзя.
А почему бы и нет? В Lisp'е и JavaScript есть continuation'ы — то есть
можно передать снимок состояния как обычное значение.
Здравствуйте, WolfHound, Вы писали:
WH>Код программы на С++ в студию. А мы уже решим на сколько хорошо автор знает программирование вобще и С++ в частности.
+1
Полностью поддерживаю. Имхо, вообще сравнения что кто-на на языке N сделал что-то лучше чем тот-то на языке K не корректны. Гораздо интереснее, когда один человек делает реализацию одной задачи на разных языках и говорит о своих впечатления. Но и здесь не так все просто. Во-первых, потому, что вторая реализаця, обычно, проще, т.к. идет по "проторенной" дорожке. А, во-вторых, имхо, это крайне редко бывает, чтобы одно и то же делали на разных языках (особенно для действительно сложных задач).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote: > C>А у вас математики что-то знают, кроме Паскаля? Я удивлен. > Знали. 12-13 лет назад.
Так бы сразу и сказали. Тогда действительно особого выбора не было, а
Turbo Pascal был вполне адекватен.
> Что сейчас -- даже не представляю. Вероятно, большинству пришлось от > Паскаля отказаться.
Знаю нескольких исследователей, двое пишут на Mathematica, один на С++ с
использованием VTK.
Сергей Губанов wrote: > C>Для модулей собираются добавить GC. То есть неиспользуемые сборки будут > C>просто прибиваться сборщиком мусора. В отличие от явной выгрузки, это > C>вполне безопасно (а в Java уже лет 5 код классов собирается GC). > Как интересно GC должен решить задачу о возможности выгрузки вот такого > модуля
Очень просто. Строим граф зависимостей кода, как только класс M попадает
в изолированый подграф — выгружаем его.
Собственно, так и работает обычный GC.
> Допустим количество ссылок на модуль M сейчас равно нулю. Значит его уже > можно выгружать, да?
Да.
> Вдруг через 3 часа в систему будет загружен некий другой модуль, который > захочет считать значение переменной M.a???? И что он прочтёт??? Если > модуль M будет выгружен, а потом опять загружен, то M.a будет равно 0.
Ну и держите ссылку на этот модуль явно. Какие проблемы?
> Модули нельзя выгружать "автоматически". Их можно выгружать только по > явной просьбе.
По явной просьбе их тоже выгружать нельзя.
Перекуём баги на фичи!
То есть не "^", а натурально 
