OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 24 Июнь, 2018 12:00

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 96 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Вторник, 13 Март, 2018 15:56 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 51
Дмитрий Дагаев писал(а):
Поэтому - вот есть данные, они получены в таких-то условиях.


Изображение


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Вторник, 13 Март, 2018 17:09 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 467
Владимир Ситников писал(а):
Kemet писал(а):
А компилятор в ББ делает кое-какую оптимизацию.
Вообще в данном случае про сравнение производительности вообще не стоит говорить

Сравнение производительности делать стоит (чтобы убедиться, что оно не в 100500 раз медленнее простой программы на C++).
Ну и что. В Обероне всё равно нет кода на C++. Поэтому, хоть быстрее, хоть медленнее. Есть реализация и стоит говорить о ней, об особенностях реализации, о проблемах и достоинствах разных подходов, очевидно, проблема не в языках, она в компиляторах, роэтому быстрее/медленнее не C++/Оберон, а полученный код. НО. реализация может вносить свои копейки, и иногда копейка рубль бережет.

Ну а так, думаю, для компилятора Активного Оберона в А2 появится оптимизация, но на уровне IR, без машинной специфики, ну и есть особенности языка и системы, препятствующие глобальной всепоглощающей оптимизации :mrgreen: :mrgreen:
Владимир Ситников писал(а):
Но вот говорить "SclVectors demonstrate 40% better results against 'std::vector without iterators', especially with array bounds check as a bonus." уж точно не стоит. Равно как и говорить "более простые решения более эффективны в плане быстродействия..." тоже не стоит.

Так я именно об этом - сравнение явно было лишним, трудно написать одинаковый для сравнения код, и учесть все особенности.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Вторник, 13 Март, 2018 17:32 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 51
Kemet писал(а):
Ну и что. В Обероне всё равно нет кода на C++. Поэтому, хоть быстрее, хоть медленнее. Есть реализация и стоит говорить о ней, об особенностях реализации, о проблемах и достоинствах разных подходов, очевидно, проблема не в языках, она в компиляторах, роэтому быстрее/медленнее не C++/Оберон, а полученный код. НО. реализация может вносить свои копейки, и иногда копейка рубль бережет.


Не понимаю вашего логического построения.
Я имел ввиду следующее:
1) Замеры (даже на BlackBox'е) имеют смысл, т.к. нужно знать "а нет ли в предлагаемой библиотеке фатальных недостатков". Иными словами, если BlackBox vector будет работать в 100500 раз медленнее, чем C++ vector, то что-то не то в консерватории. Либо опечатка, либо ещё хрень какая-то
2) Сравнивать имеет смысл с "штатным" (с активными оптимизациями) режимом работы C++ и/или Java. Ну, какой смысл сравниваться с "отладочным режимом работы C++"? Как раз нужно взять нормальный режим (например, -O3) и тогда будет видно: весь из себя крутой GCC работает за X миллисекунд, а BlackBox за Y миллисекунд. Очевидно, что BlackBox код должен работать медленнее. Вопрос "во сколько раз".
Иными словами, стоит рассматривать C++ как мифический идеал.
3) Все размышления "BlackBox на таком-то сценарии в X раз быстрее C++" стоит крайне аккуратно проверять. Ну, по факту же GCC гораздо более продвинутый компилятор, и по логике, C++ должен работать гораздо быстрее.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Вторник, 13 Март, 2018 17:57 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 467
Владимир Ситников писал(а):
1) Замеры (даже на BlackBox'е) имеют смысл, т.к. нужно знать "а нет ли в предлагаемой библиотеке фатальных недостатков". Иными словами, если BlackBox vector будет работать в 100500 раз медленнее, чем C++ vector, то что-то не то в консерватории. Либо опечатка, либо ещё хрень какая-то
Не, не имеют смысла. Имеет смысл проверять и сравнивать функционал, а не скорость. Ну и очевидно же, что автор проверил работоспособность. Понятно, что, как и в любой программе на любом яп там могут быть ошибки. Замер производительности их вряд ли выявит, ну и к тому же, с самим замером могут быть проблемы, нужно использовать одинаковый механизм. Штатные средства в ББ, например, считают просто прошедшее время, без учета, сколь из этого времени потребили другие процессы.
В общем, смысла нет, это не убийца stl, это решение для замкнутой самодостаточной экосистемы.
Владимир Ситников писал(а):
2) Сравнивать имеет смысл с "штатным" (с активными оптимизациями) режимом работы C++ и/или Java. Ну, какой смысл сравниваться с "отладочным режимом работы C++"? Как раз нужно взять нормальный режим (например, -O3) и тогда будет видно: весь из себя крутой GCC работает за X миллисекунд, а BlackBox за Y миллисекунд. Очевидно, что BlackBox код должен работать медленнее. Вопрос "во сколько раз".
Иными словами, стоит рассматривать C++ как мифический идеал.

во первых, нет смысла сравнивать оптимизирующий компилятор с неоптимизирующим.
во вторых выше я писал, замем сравнивать, что этим достигается, если учесть, что stl в ББ не работает, а этот код КП не скомпилировать GCC и он не заменит там stl шаблоны.
Владимир Ситников писал(а):
3) Все размышления "BlackBox на таком-то сценарии в X раз быстрее C++" стоит крайне аккуратно проверять. Ну, по факту же GCC гораздо более продвинутый компилятор, и по логике, C++ должен работать гораздо быстрее.

Это вообще не стоит делать, об этом я и писал.
Ну а то, что код на C++ порвёт всё как тузик грелку, может оказаться лишь предположением, потому что там куча кода и лишних телодвижений, оптимизирующий компилятор частично решает эту проблему, но, в общем случае, код на простом Си будет быстрее, и вполне может оказаться, что и код на каком-нибудь Обероне в итоге окажется быстрее.
Но это имеет смысл только в теоретическом смысле, ради исследований, а не в контексте описания данного решения.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Вторник, 13 Март, 2018 18:29 

Зарегистрирован: Среда, 31 Январь, 2018 19:54
Сообщения: 25
Владимир Ситников писал(а):
... C++ должен работать гораздо быстрее.

Kemet писал(а):
Так я именно об этом - сравнение явно было лишним, трудно написать одинаковый для сравнения код, и учесть все особенности.

Для тестирования лучше брать группу студентов, прошедших курс ВВ и курс С++, и + курс матметодов. Но не Гуру, который всю свою сознательную жизнь работал на С++.
Несколько лучших результатов, например 3 из 10, будет показателем среднего уровня технологий, а не "трюков" с помощью С++. Сравнивать так же требуется время, которое потребовалось для написания кода.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Четверг, 15 Март, 2018 08:47 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 51
arlean1 писал(а):
Kemet писал(а):
Так я именно об этом - сравнение явно было лишним, трудно написать одинаковый для сравнения код, и учесть все особенности.

Для тестирования лучше брать группу студентов, прошедших курс ВВ и курс С++, и + курс матметодов. Но не Гуру, который всю свою сознательную жизнь работал на С++.
Несколько лучших результатов, например 3 из 10, будет показателем среднего уровня технологий, а не "трюков" с помощью С++. Сравнивать так же требуется время, которое потребовалось для написания кода.

По-вашему, замеры производительности вообще не нужны?

И, да, сравнивать 'на студентах' имеет смысл только когда ваш проект пишут студенты, код которых напрямую идёт в эксплуатацию. У вас реально так?

Всё, о чём я говорил относится к базовым знаниям C++. Речи о тонкой настройке C++ даже и не заходило.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Четверг, 15 Март, 2018 09:23 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 985
Владимир Ситников писал(а):
По-вашему, замеры производительности вообще не нужны?
Не помешают, попробуйте сами замерить.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Четверг, 15 Март, 2018 10:02 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 51
Сергей Оборотов писал(а):
Не помешают

По-моему, оно не просто "не помешает", а замеры нужны.

Сергей Оборотов писал(а):
попробуйте сами замерить.

На текущий момент у меня нет ни потребности, ни желания, ни времени этим заниматься.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Четверг, 15 Март, 2018 11:58 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 985
Все изобретатели – великие лентяи.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Четверг, 15 Март, 2018 17:10 

Зарегистрирован: Среда, 31 Январь, 2018 19:54
Сообщения: 25
Владимир Ситников писал(а):
Всё, о чём я говорил относится к базовым знаниям C++. Речи о тонкой настройке C++ даже и не заходило.

Даже если Вы не заводили, заведёт какой-нибудь Си-шник. И именно этим всегда заканчивались споры о сравнении языков, которые я встречал.
Владимир Ситников писал(а):
И, да, сравнивать 'на студентах' имеет смысл только когда ваш проект пишут студенты, код которых напрямую идёт в эксплуатацию. У вас реально так?

Судя по многим проектам по созданию новых языков, их часто пишут аспиранты. Студенты нужны чтобы понять как язык воспринимается - их легче собрать вместе, они слушают одни и те же курсы и пр. И ведь студентов часто привлекают к коммерческим проектам - именно они и являются носителями новых технологий. Но в любом случае это лучше спора двух состоявшихся фанатов каких языков программирования. Здесь скорее можно увидеть, что разница в скорости работы разработанных программ будет не так велика, а качество кода и скорость разработки будут сильно отличаться. Это и проявляется в коммерческих проектах.

Почему Оберона нет на олимпиадах - это ещё вопрос продвижения Оберона. Паскаль уже не в моде. http://codeforces.com/blog/entry/1917


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Четверг, 15 Март, 2018 17:45 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 51
arlean1 писал(а):
Даже если Вы не заводили, заведёт какой-нибудь Си-шник. И именно этим всегда заканчивались споры о сравнении языков, которые я встречал.

Вот когда заведёт этот самый Си-шник, с ним обсуждать и будете. Незачем за меня домысливать то, что я не говорил.

И я тут не спор о языках развожу. Я протестую против косого сравнения библиотек.

arlean1 писал(а):
Владимир Ситников писал(а):
И, да, сравнивать 'на студентах' имеет смысл только когда ваш проект пишут студенты, код которых напрямую идёт в эксплуатацию. У вас реально так?

Судя по многим проектам по созданию новых языков, их часто пишут аспиранты. Студенты нужны чтобы понять как язык воспринимается - их легче собрать вместе, они слушают одни и те же курсы и пр. И ведь студентов часто привлекают к коммерческим проектам - именно они и являются носителями новых технологий. Но в любом случае это лучше спора двух состоявшихся фанатов каких языков программирования. Здесь скорее можно увидеть, что разница в скорости работы разработанных программ будет не так велика, а качество кода и скорость разработки будут сильно отличаться. Это и проявляется в коммерческих проектах.


Я задал простой вопрос: у вас реально студенты пишут боевой код и этот код без какого-либо рецензирования попадает в эксплуатацию?
Вы же отвечаете совсем мимо.

По моему опыту, тормозящий код выходит даже из под пера опытных программистов. У студентов -- вообще на раз получается тормозной код.
Так вот. Например, автор Scl написал C++ замер, в котором реально перемудрил. Вот зачем было делать "str.resize(256)"?
Далее, замер делался в режиме "по умолчанию". Очевидно же, что замеры времени нужно делать в режиме "с оптимизациями".
Разумеется, подобные ошибки запросто допустит студент. И задача его наставника как раз в том, чтобы заметить эти ошибки и скорректировать.

Вы же пишете про исследование "сколько времени у студентов будет уходить на реализацию той или иной задачи", и это СОВСЕМ никак не связано с обсуждаемой "скоростью работы Scl".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Четверг, 15 Март, 2018 22:43 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1076
Владимир Ситников писал(а):
Очевидно же, что замеры времени нужно делать в режиме "с оптимизациями".

Как правилоЮ ошибка скрывается за словами "очевидно, что".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Четверг, 15 Март, 2018 22:52 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 51
Trurl писал(а):
Владимир Ситников писал(а):
Очевидно же, что замеры времени нужно делать в режиме "с оптимизациями".

Как правилоЮ ошибка скрывается за словами "очевидно, что".

И?
Если видите ошибку -- говорите прямо.
Если ничего не понимаете в производительности, то зачем пишете "как правило"?

Если интересно меня затроллить -- вперёд и с песней. Только вряд ли получится, ведь я не адепт Оберона, не адепт C++, и не адепт C.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Пятница, 16 Март, 2018 05:27 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2089
Откуда: Красноярск
Владимир Ситников писал(а):
Очевидно же, что замеры времени нужно делать в режиме "с оптимизациями".

Вот тут не соглашусь. Ведь задача сравнить реализации алгоритмов, а не реализации оптимизаторов. По дефолту ББ имеет такую же скорость как GCC без оптимизации. Вот и надо сравнивать дальше без оптимизации, если мы сравниваем алгоритмы, реализации библиотек и т.п. Иначе эксперимент получается не чистый.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Пятница, 16 Март, 2018 07:48 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2089
Откуда: Красноярск
Мне Влад объяснил, что STL проектируется с учетом последующей оптимизации компилятором, иначе они не работают быстро. Так что невозможно получается сравнения с ББ проводить таким методом замеров.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Пятница, 16 Март, 2018 08:24 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1076
Владимир Ситников писал(а):
И?

Ну, вот мне, например, неочевидно. Не могли бы Вы привести какие-то аргументы в подтвердение тезиса?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Пятница, 16 Март, 2018 16:08 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 51
Trurl писал(а):
Владимир Ситников писал(а):
И?

Ну, вот мне, например, неочевидно. Не могли бы Вы привести какие-то аргументы в подтвердение тезиса?

Вот же: viewtopic.php?f=47&t=6234&start=20#p103970

Владимир Ситников писал(а):
Сравнение производительности делать стоит (чтобы убедиться, что оно не в 100500 раз медленнее простой программы на C++).


Ну и более подробно: viewtopic.php?f=47&t=6234&start=40#p103978

Ещё раз: цель сравнения не в том, чтобы узнать что круче GCC или ББ.
Цель замеров в том, чтобы понять насколько хорошо-плохо работает конкретная библиотека.
Например, мы знаем, что сложность поиска в красно-чёрном дереве составляет O(logN). По факту, в Scl реализации может быть ошибка. Поэтому логично сделать замер и посмотреть сколько работает Scl дерево. Допустим, получилось, что Scl отработало за 10 секунд. Это много? Мало?
Как понять сколько должно быть?
Как раз на подобные вопросы отвечает замер аналогичного кода в гарантированно быстрых компиляторах. Пишем простейший пример на C++/Java и получаем, например, цифру 5секунд. Если получится, что C++ работает 5 секунд, а ББ 10, то всё не так плохо. Если же окажется, что C++ работает 0.005сек, а ББ 10 секунд, то очевидно, что в ББ что-то сломано.


Для того, чтобы сравнивать нужна какая-то точка отсчёта.
За основу можно взять производительность C++ и/или Java на схожих задачах.

Теперь к вопросу "почему нужно активировать оптимизации в C++ компиляторе".
1) А почему бы тогда вообще не отключить все оптимизации в C++? Есть же опции. Можно взять и отключить все оптимизации. Давайте так сравнивать? Ну и вдобавок ББ код будем писать на ассемблере.

2) Как уже сказал Иван, часть STL кода написана именно с оглядкой на то, что оптимизирующий компилятор потом соптимизирует. Если запускать "без оптимизаций", то замер времени покажет погоду. Можно ещё и логирования понатыкать в каждой строке C++ кода, и замерять как оно будет работать.

3) Само по себе включение оптимизаций (-O3) нужно для того, чтобы можно было писать код по-простому (например, без ассемблерных вставок), и чтобы этот код потом работал быстро. Более того, как раз O3 и показывает, что многие абстракции в C++ (например, перегрузка оператора [] ) могут превращаться компилятором в прямые обращения к массиву. Т.е. по факту эта "абстракция" может быть "бесплатной" (в плане накладных расходов).

Например, при компиляции по умолчанию, обращение к перегруженному оператору [] это прямо CALL инструкция в ассемблерном коде.
Даже на уровне -O1 инструкция call пропадает, и в машинном коде используется просто обращение по адресу.

Получается, язык C++ с одной стороны допускает компактный и человекопонятный код, а с другой стороны, язык допускает эффективную компиляцию этого самого кода.

Поэтому за основу сравнения "эффективности работы" нужно именно C++ с включенными оптимизациями. Ну или Java.

Если же окажется, что ББ, например, генерирует CALL на каждый чих, то скорее повод добавить оптимизацию в ББ нежели сравниваться с "C++ без оптимизаций".


Последний раз редактировалось Владимир Ситников Пятница, 16 Март, 2018 17:05, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Пятница, 16 Март, 2018 16:33 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 51
Иван Денисов писал(а):
Вот и надо сравнивать дальше без оптимизации,

Надо зачем? Что вы получите из замера "C++ без оптимизаций"?
В реальных проектах С++ будет с оптимизациями. Это как раз то, что упрощает работу программистам: пиши как хочешь, компилятор стерпит.

Иван Денисов писал(а):
если мы сравниваем алгоритмы, реализации библиотек и т.п

В C++ операция std::list.sort() реализует алгоритм merge sort, т.к. в стандарте C++ класс list это неупорядоченный список.
Вы же в Scl реализовали какую-то разновидность QuickSort. В итоге вы сравниваете *разные* алгоритмы сортировки на *разных* языках.

Ну и, кстати, непонятно является ли Scl сортировка устойчивой или нет (stable). В стандарте C++ сортировка должна быть stable.

Но, опять же, в реальных проектах глупо не использовать оптимизации компилятора, поэтому делать замеры "неоптимизированного C++" смысла нет.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Пятница, 16 Март, 2018 21:28 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 51
Владимир Ситников писал(а):
В C++ операция std::list.sort() реализует алгоритм merge sort, т.к. в стандарте C++ класс list это неупорядоченный список .

Упорядоченный, конечно. Это же список. Хотел сказать "без быстрого доступа к произвольному элементу"


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Standard Container Library
СообщениеДобавлено: Суббота, 17 Март, 2018 19:15 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1076
Вот, все оказалось не так очевидно.
Чтобы убедитяся, что сложность составляет O(logN), сравнивать с другими программами не нужно и бесполезно.
Много или мало 10 секунд? Это просто. Если у нас есть 10 секунд, то нормально, если нет - много.
Ладно, пусть нам все же хочется сравнить. Допустим, C++ без оптимизации работает 15 секунд, а с оптимизацией 0.005сек, какой из этого сделать вывод?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 96 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB