OberonCore https://forum.oberoncore.ru/ |
|
Standard Container Library https://forum.oberoncore.ru/viewtopic.php?f=47&t=6234 |
Страница 3 из 6 |
Автор: | Владимир Ситников [ Вторник, 13 Март, 2018 15:56 ] |
Заголовок сообщения: | Re: Standard Container Library |
Дмитрий Дагаев писал(а): Поэтому - вот есть данные, они получены в таких-то условиях. |
Автор: | Kemet [ Вторник, 13 Март, 2018 17:09 ] |
Заголовок сообщения: | Re: Standard Container Library |
Владимир Ситников писал(а): Kemet писал(а): А компилятор в ББ делает кое-какую оптимизацию. Вообще в данном случае про сравнение производительности вообще не стоит говорить Сравнение производительности делать стоит (чтобы убедиться, что оно не в 100500 раз медленнее простой программы на C++). Ну а так, думаю, для компилятора Активного Оберона в А2 появится оптимизация, но на уровне IR, без машинной специфики, ну и есть особенности языка и системы, препятствующие глобальной всепоглощающей оптимизации Владимир Ситников писал(а): Но вот говорить "SclVectors demonstrate 40% better results against 'std::vector without iterators', especially with array bounds check as a bonus." уж точно не стоит. Равно как и говорить "более простые решения более эффективны в плане быстродействия..." тоже не стоит. Так я именно об этом - сравнение явно было лишним, трудно написать одинаковый для сравнения код, и учесть все особенности. |
Автор: | Владимир Ситников [ Вторник, 13 Март, 2018 17:32 ] |
Заголовок сообщения: | Re: Standard Container Library |
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++ должен работать гораздо быстрее. |
Автор: | Kemet [ Вторник, 13 Март, 2018 17:57 ] |
Заголовок сообщения: | Re: Standard Container Library |
Владимир Ситников писал(а): 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++ порвёт всё как тузик грелку, может оказаться лишь предположением, потому что там куча кода и лишних телодвижений, оптимизирующий компилятор частично решает эту проблему, но, в общем случае, код на простом Си будет быстрее, и вполне может оказаться, что и код на каком-нибудь Обероне в итоге окажется быстрее. Но это имеет смысл только в теоретическом смысле, ради исследований, а не в контексте описания данного решения. |
Автор: | arlean1 [ Вторник, 13 Март, 2018 18:29 ] |
Заголовок сообщения: | Re: Standard Container Library |
Владимир Ситников писал(а): ... C++ должен работать гораздо быстрее. Kemet писал(а): Так я именно об этом - сравнение явно было лишним, трудно написать одинаковый для сравнения код, и учесть все особенности. Для тестирования лучше брать группу студентов, прошедших курс ВВ и курс С++, и + курс матметодов. Но не Гуру, который всю свою сознательную жизнь работал на С++. Несколько лучших результатов, например 3 из 10, будет показателем среднего уровня технологий, а не "трюков" с помощью С++. Сравнивать так же требуется время, которое потребовалось для написания кода. |
Автор: | Владимир Ситников [ Четверг, 15 Март, 2018 08:47 ] |
Заголовок сообщения: | Re: Standard Container Library |
arlean1 писал(а): Kemet писал(а): Так я именно об этом - сравнение явно было лишним, трудно написать одинаковый для сравнения код, и учесть все особенности. Для тестирования лучше брать группу студентов, прошедших курс ВВ и курс С++, и + курс матметодов. Но не Гуру, который всю свою сознательную жизнь работал на С++. Несколько лучших результатов, например 3 из 10, будет показателем среднего уровня технологий, а не "трюков" с помощью С++. Сравнивать так же требуется время, которое потребовалось для написания кода. По-вашему, замеры производительности вообще не нужны? И, да, сравнивать 'на студентах' имеет смысл только когда ваш проект пишут студенты, код которых напрямую идёт в эксплуатацию. У вас реально так? Всё, о чём я говорил относится к базовым знаниям C++. Речи о тонкой настройке C++ даже и не заходило. |
Автор: | Сергей Оборотов [ Четверг, 15 Март, 2018 09:23 ] |
Заголовок сообщения: | Re: Standard Container Library |
Владимир Ситников писал(а): По-вашему, замеры производительности вообще не нужны? Не помешают, попробуйте сами замерить.
|
Автор: | Владимир Ситников [ Четверг, 15 Март, 2018 10:02 ] |
Заголовок сообщения: | Re: Standard Container Library |
Сергей Оборотов писал(а): Не помешают По-моему, оно не просто "не помешает", а замеры нужны. Сергей Оборотов писал(а): попробуйте сами замерить. На текущий момент у меня нет ни потребности, ни желания, ни времени этим заниматься. |
Автор: | Сергей Оборотов [ Четверг, 15 Март, 2018 11:58 ] |
Заголовок сообщения: | Re: Standard Container Library |
Все изобретатели – великие лентяи. |
Автор: | arlean1 [ Четверг, 15 Март, 2018 17:10 ] |
Заголовок сообщения: | Re: Standard Container Library |
Владимир Ситников писал(а): Всё, о чём я говорил относится к базовым знаниям C++. Речи о тонкой настройке C++ даже и не заходило. Даже если Вы не заводили, заведёт какой-нибудь Си-шник. И именно этим всегда заканчивались споры о сравнении языков, которые я встречал. Владимир Ситников писал(а): И, да, сравнивать 'на студентах' имеет смысл только когда ваш проект пишут студенты, код которых напрямую идёт в эксплуатацию. У вас реально так? Судя по многим проектам по созданию новых языков, их часто пишут аспиранты. Студенты нужны чтобы понять как язык воспринимается - их легче собрать вместе, они слушают одни и те же курсы и пр. И ведь студентов часто привлекают к коммерческим проектам - именно они и являются носителями новых технологий. Но в любом случае это лучше спора двух состоявшихся фанатов каких языков программирования. Здесь скорее можно увидеть, что разница в скорости работы разработанных программ будет не так велика, а качество кода и скорость разработки будут сильно отличаться. Это и проявляется в коммерческих проектах. Почему Оберона нет на олимпиадах - это ещё вопрос продвижения Оберона. Паскаль уже не в моде. http://codeforces.com/blog/entry/1917 |
Автор: | Владимир Ситников [ Четверг, 15 Март, 2018 17:45 ] |
Заголовок сообщения: | Re: Standard Container Library |
arlean1 писал(а): Даже если Вы не заводили, заведёт какой-нибудь Си-шник. И именно этим всегда заканчивались споры о сравнении языков, которые я встречал. Вот когда заведёт этот самый Си-шник, с ним обсуждать и будете. Незачем за меня домысливать то, что я не говорил. И я тут не спор о языках развожу. Я протестую против косого сравнения библиотек. arlean1 писал(а): Владимир Ситников писал(а): И, да, сравнивать 'на студентах' имеет смысл только когда ваш проект пишут студенты, код которых напрямую идёт в эксплуатацию. У вас реально так? Судя по многим проектам по созданию новых языков, их часто пишут аспиранты. Студенты нужны чтобы понять как язык воспринимается - их легче собрать вместе, они слушают одни и те же курсы и пр. И ведь студентов часто привлекают к коммерческим проектам - именно они и являются носителями новых технологий. Но в любом случае это лучше спора двух состоявшихся фанатов каких языков программирования. Здесь скорее можно увидеть, что разница в скорости работы разработанных программ будет не так велика, а качество кода и скорость разработки будут сильно отличаться. Это и проявляется в коммерческих проектах. Я задал простой вопрос: у вас реально студенты пишут боевой код и этот код без какого-либо рецензирования попадает в эксплуатацию? Вы же отвечаете совсем мимо. По моему опыту, тормозящий код выходит даже из под пера опытных программистов. У студентов -- вообще на раз получается тормозной код. Так вот. Например, автор Scl написал C++ замер, в котором реально перемудрил. Вот зачем было делать "str.resize(256)"? Далее, замер делался в режиме "по умолчанию". Очевидно же, что замеры времени нужно делать в режиме "с оптимизациями". Разумеется, подобные ошибки запросто допустит студент. И задача его наставника как раз в том, чтобы заметить эти ошибки и скорректировать. Вы же пишете про исследование "сколько времени у студентов будет уходить на реализацию той или иной задачи", и это СОВСЕМ никак не связано с обсуждаемой "скоростью работы Scl". |
Автор: | Trurl [ Четверг, 15 Март, 2018 22:43 ] |
Заголовок сообщения: | Re: Standard Container Library |
Владимир Ситников писал(а): Очевидно же, что замеры времени нужно делать в режиме "с оптимизациями". Как правилоЮ ошибка скрывается за словами "очевидно, что". |
Автор: | Владимир Ситников [ Четверг, 15 Март, 2018 22:52 ] |
Заголовок сообщения: | Re: Standard Container Library |
Trurl писал(а): Владимир Ситников писал(а): Очевидно же, что замеры времени нужно делать в режиме "с оптимизациями". Как правилоЮ ошибка скрывается за словами "очевидно, что". И? Если видите ошибку -- говорите прямо. Если ничего не понимаете в производительности, то зачем пишете "как правило"? Если интересно меня затроллить -- вперёд и с песней. Только вряд ли получится, ведь я не адепт Оберона, не адепт C++, и не адепт C. |
Автор: | Иван Денисов [ Пятница, 16 Март, 2018 05:27 ] |
Заголовок сообщения: | Re: Standard Container Library |
Владимир Ситников писал(а): Очевидно же, что замеры времени нужно делать в режиме "с оптимизациями". Вот тут не соглашусь. Ведь задача сравнить реализации алгоритмов, а не реализации оптимизаторов. По дефолту ББ имеет такую же скорость как GCC без оптимизации. Вот и надо сравнивать дальше без оптимизации, если мы сравниваем алгоритмы, реализации библиотек и т.п. Иначе эксперимент получается не чистый. |
Автор: | Иван Денисов [ Пятница, 16 Март, 2018 07:48 ] |
Заголовок сообщения: | Re: Standard Container Library |
Мне Влад объяснил, что STL проектируется с учетом последующей оптимизации компилятором, иначе они не работают быстро. Так что невозможно получается сравнения с ББ проводить таким методом замеров. |
Автор: | Trurl [ Пятница, 16 Март, 2018 08:24 ] |
Заголовок сообщения: | Re: Standard Container Library |
Владимир Ситников писал(а): И? Ну, вот мне, например, неочевидно. Не могли бы Вы привести какие-то аргументы в подтвердение тезиса? |
Автор: | Владимир Ситников [ Пятница, 16 Март, 2018 16:08 ] |
Заголовок сообщения: | Re: Standard Container Library |
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 16:33 ] |
Заголовок сообщения: | Re: Standard Container Library |
Иван Денисов писал(а): Вот и надо сравнивать дальше без оптимизации, Надо зачем? Что вы получите из замера "C++ без оптимизаций"? В реальных проектах С++ будет с оптимизациями. Это как раз то, что упрощает работу программистам: пиши как хочешь, компилятор стерпит. Иван Денисов писал(а): если мы сравниваем алгоритмы, реализации библиотек и т.п В C++ операция std::list.sort() реализует алгоритм merge sort, т.к. в стандарте C++ класс list это неупорядоченный список. Вы же в Scl реализовали какую-то разновидность QuickSort. В итоге вы сравниваете *разные* алгоритмы сортировки на *разных* языках. Ну и, кстати, непонятно является ли Scl сортировка устойчивой или нет (stable). В стандарте C++ сортировка должна быть stable. Но, опять же, в реальных проектах глупо не использовать оптимизации компилятора, поэтому делать замеры "неоптимизированного C++" смысла нет. |
Автор: | Владимир Ситников [ Пятница, 16 Март, 2018 21:28 ] |
Заголовок сообщения: | Re: Standard Container Library |
Владимир Ситников писал(а): В C++ операция std::list.sort() реализует алгоритм merge sort, т.к. в стандарте C++ класс list это неупорядоченный список . Упорядоченный, конечно. Это же список. Хотел сказать "без быстрого доступа к произвольному элементу" |
Автор: | Trurl [ Суббота, 17 Март, 2018 19:15 ] |
Заголовок сообщения: | Re: Standard Container Library |
Вот, все оказалось не так очевидно. Чтобы убедитяся, что сложность составляет O(logN), сравнивать с другими программами не нужно и бесполезно. Много или мало 10 секунд? Это просто. Если у нас есть 10 секунд, то нормально, если нет - много. Ладно, пусть нам все же хочется сравнить. Допустим, C++ без оптимизации работает 15 секунд, а с оптимизацией 0.005сек, какой из этого сделать вывод? |
Страница 3 из 6 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |