OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Суббота, 19 Январь, 2019 00:47

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




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

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

Потому, что цели ваши туманны, а мысли неясны.


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

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 1001
Интересно само по себе.


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

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

Как я доказал, сейчас в разделе Scl benchmarks приводятся ложные утверждения, что Scl, якобы, быстрее C++ STL:
Цитата:
SclVectors demonstrate 40% better results against 'std::vector without iterators', especially with array bounds check as a bonus.
...
SclLists demonstrate 26% better results for 8bit and 3% better for 16 bit.
...
SclMaps demonstrate 41% better results for 8bit and 55% better for 16 bit.


Конечно, Scl приводится на правах public domain, т.е. может оказаться, что новой версии документа вообще не возникнет. Нельзя исключать и того, что кто-то в новой версии вообще удалит раздел "Scl benchmarks".
Поэтому читателям стоит трезво оценивать скорость работы Scl (и/или делать свои замеры), и нужно с большой долей скепсиса относиться к тому, что пишет Дмитрий Дагаев по вопросам производительности. По факту, Дмитрий много раз написал, что ББ код быстрее C++ кода, и рука у него не дрогнула.

На всякий случай: указание того, что "результаты C++ получены в debug режиме" не спасут раздел "Scl benchmarks". Отладочный режим C++ нужен для отладки, а не для конечной эксплуатации, и всевозможные фразы типа
Дмитрий Дагаев писал(а):
более простые решения более эффективны в плане быстродействия, чем переопределяющие операции решения типа reference operator[]( size_type pos ), используемые в c++ stl.
разбиваются в дребезги самым обычным оптимизирующим C++ компилятором. Попросту говоря, С++ позволяет получить одновременно и удобство разработки и высокую скорость работы результирующего кода.

Обновление: как я и предполагал, в очередном обновлении Scl добавился фрагмент
Цитата:
Mingw32 compiler for windows was used with -std=c++11 options, no optimization...
2. Scl against C++ stl results can be really compared when we get highly optimized BlackBox compiler

Т.е. автор продолжает водить читателей по ложному следу и утверждать, что Scl работает на 6-19-40% быстрее.


Последний раз редактировалось Владимир Ситников Вторник, 20 Март, 2018 22:41, всего редактировалось 1 раз.

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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7947
Откуда: Троицк, Москва
Владимир Ситников писал(а):
С++ позволяет получить одновременно и удобство разработки и высокую скорость работы результирующего кода.
Как, однако, надоела эта лабуда.


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

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2546
Откуда: Россия, Ярославль
Владимир Ситников писал(а):
Попросту говоря, С++ позволяет получить одновременно и удобство разработки и высокую скорость работы результирующего кода.
Чем и в ч0м измеряется удобство?
Владимир Ситников писал(а):
разбиваются в дребезги самым обычным оптимизирующим C++ компилятором
Попросту говоря - в деньги.


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

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 746
Откуда: Казань
Владимир Ситников писал(а):
Отладочный режим C++ нужен для отладки, а не для конечной эксплуатации...

У нас на работе для конечной эксплуатации используются бинарники скомпилированные для Debug режима, а не для Release. И на это есть свои причины.


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

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 304
Откуда: Москва
Цитата:
Ну, какой смысл сравниваться с "отладочным режимом работы C++"? Как раз нужно взять нормальный режим (например, -O3)

Тем, кто считает, что режим с оптимизациями является ненормальным, предлагаю ознакомиться с The Pitfalls of Benchmarking with Applications.
Цитирую по тексту
Цитата:
Our absolute reference is a run on the x86 32-bit Linux
target compiled with GCC at -O0 optimization level. This
is by no means a value judgment. One configuration has to
be chosen for comparison purposes. The lowest optimization
level decreases the likelihood of compiler-introduced errors.

И далее результаты сравнения с Windows 7 (как у меня)
Вложение:
Optimization.png
Optimization.png [ 26.95 КБ | Просмотров: 1164 ]

Ну и выводы по анализу корректности
Цитата:
1) qsort: All configurations have positive runs, except the
Windows 7 platform which shows 100% negative.

По остальным тестам корректности есть и 40%, и 100% негативных прогонов.


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

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 1001
Дмитрий Дагаев писал(а):
... предлагаю ознакомиться с The Pitfalls of Benchmarking with Applications.
Вот что от вас хотят, Владимир.


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

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 64
Дмитрий Дагаев писал(а):
Тем, кто считает, что режим с оптимизациями является ненормальным

Вот вы это кому только что сказали?
Я как раз всегда говорил, что режим с оптимизациями является основным, и сравнивать нужно "с оптимизациями".

Дмитрий Дагаев писал(а):
1) qsort: All configurations have positive runs, except the
Windows 7 platform which shows 100% negative.


Читайте, пожалуйста, полностью. Или вы ссылаетесь на статью только ради того, чтобы сослаться?
Цитата:
Windows 7 platform which shows 100% negative. This is due
to the text output format and different end-of-line characters:
Windows uses CR+LF, while Linux uses only LF. When
using diff -b or diff --strip-trailing-cr 3
, or
dos2unix on output files, they show no difference with the
absolute reference. They should be considered false negatives
since the benchmark runs correctly, only the testing procedure
is inappropriate. A better testing framework should either use
different files for different platforms, or specify what utility is
to be used for comparison, with the appropriate set of flags.

Перевожу на русский: отрицательный результат для qsort теста оказалось лишь проблемой запускатора тестов. Сам код отработал верно. Проблема в том, что проверяющая система не ожидала, что в Windows строки будут разделяться символами CR+LF.

Иными словами, они прямо пишут, что проблемы вообще нет. Отсортировалось правильно во всех случаях.
И эта проблема "с форматом перевода строк" отмечена во многих Windows тестах. Наверняка, авторы исходного кода вообще никогда на Windows не запускались. Какое это отношение имеет к замерам? Да никакого. Какое это отношение имеет к оптимизациям? Тоже никакого.

Дмитрий Дагаев писал(а):
По остальным тестам корректности есть и 40%, и 100% негативных прогонов.

По факту, в предложенной вами работе сплошная вода.
Ну какой толк от того, что "из-за перевода строк бенчмарк показывает негативные результаты на Windows"?
Если бы они поправили очевидные огрехи в самом коде, тогда ещё можно было обсуждать.

Посмотрите же хотя бы на таблицу, которую вы доблестно процитировали.
Большинство "отрицательных значений" вообще не зависит от значения -O. О чём это говорит? О том, что исходный код в принципе не работал, и оптимизации на него никак не влияют.

Есть ровно 2 случая, когда от изменения -O "изменился" результат.
Это susan_c и rsynth.
Про susan_c сказано, что результат другой из-за "ошибок округления" (т.е. по-другому округлилось значение).
По rsynth снова разница в плавающей точке.

Какой вывод можно сделать?
Статья НЕ подтверждает того, что от -O1/O2/O3/Os что-то портится.
В статье авторы что-то там измерили, и таким образом установили, что:
1) На Windows перевод строки CR+LF, а на Linux это просто LF
2) Операции с плавающей точкой могут выдавать тот или иной ответ в зависимости от того какие команды процессора используются.
3) Использование неинициализированных переменных это плохо

Для кого-то эти пункты стали откровением?
Кто-то не знал, что нужно инициализировать переменные перед обращением?
Кто-то не знал, что вычисления с плавающей точкой не всегда гарантируют побитовый результат?


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2247
Владимир, статья и правда не идеальная, но там этот вопрос хотя бы рассмотрен. Может какую-то более подходящую найдете? А то всё равно кроме споров друг с другом было бы хорошо иметь представление о современном состоянии проблемы в мире. Но я не понимаю предмета, чего вы в целом нападаете? Для референса нормально использовать любой режим, если надо просто от чего отталкиваться. Я уверен, что Дмитрий Викторович не собирался как-то принижать С++, или как-то задеть людей, кто им пользуется. Для референса возможно выбрать и такой режим и другой. Главное указать, какой выбрал.

Ваши аргументы верные, но вот я специально заглянул в документацию Scl. Никто там не скрывает, что в С++ оптимизации были выключены. Это ведь для референса нужно, а не чтобы доказать кому-то. Для Вас это какой-то болезненный вопрос? Я совершенно согласен с выводами Дмитрия Викторовича, которые он сделал по результатам проверки. Реализация приемлемая, а правильное сравнение сейчас невозможно. Что-то вам еще хочется? Я не понимаю.


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

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1338
Я правильно понимаю, что пользователь библиотеки обязан знать про тип Elem и Iterator при работе со списками? и - наследовать свои классы от Elem, в предположении, что они будут храниться в списках?


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

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 304
Откуда: Москва
Wlad писал(а):
Я правильно понимаю, что пользователь библиотеки обязан знать про тип Elem и Iterator при работе со списками? и - наследовать свои классы от Elem, в предположении, что они будут храниться в списках?

Да, именно так


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

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

В статьях я не знаток.
Вот пример годного материала на тему: https://www.youtube.com/watch?v=8pMfUopQ9Es ( слайды: http://2014.jokerconf.com/presentations ... arking.pdf )

Если лень смотреть весь доклад, вот фрагмент, точно описывающий то, что проделал Дмитрий: https://www.youtube.com/watch?v=8pMfUop ... .be&t=2727 (ну и минута-полторы)

Иван Денисов писал(а):
Для референса нормально использовать любой режим, если надо просто от чего отталкиваться. Я уверен, что Дмитрий Викторович не собирался как-то принижать С++, или как-то задеть людей, кто им пользуется. Для референса возможно выбрать и такой режим и другой. Главное указать, какой выбрал.

А чего мелочиться? Давайте уж C++ запускать под valgrind'ом? "главное указать, какой выбрал" Шутка. Но она объясняет то, почему выбирать -O0 неграмотно.

Я вот тут всё детально разбирал уже: viewtopic.php?f=47&t=6234&start=40#p104028
Вопрос вовсе не в том, чтобы определить во сколько раз C++ быстрее.

Иван Денисов писал(а):
, а правильное сравнение сейчас невозможно

Правильное сравнение возможно.
Берём ББ код, измеряем.
Берём C++ код, измеряем (разумеется, -O2 или -O3).

Дальше анализируем результаты: ББ код работает в 15 раз медленнее, т.к. в ББ нет такой-то и такой-то оптимизации.

Как вариант, можно для C++ взять несколько режимов (O0 и O3). Но это делать сложнее, т.к. больше времени уйдёт на замеры, их анализ и т.п.
Поэтому, если делать только 1 вид C++, то остановиться стоит на -O3 (обоснование по ссылке выше)


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2247
-O3 использовать возможно, однако помимо подстановок такой режим использует другие оптимизирующие алгоритмы, которые на ряде тестовых задач могут показать аномальное ускорение. И покажется, что библиотека работает плохо, что не соответствует действительности. А непрофессионал тоже будет толковать такое ускорение превратно, и получится, что люди будут введены в заблуждение.

Я вот как-то уже обжегся на этих сравнениях, когда нерепрезентативный тест подсунул компилятору ifort и получил ускорение в 50 раз. Реальные цифры, если ускорение в 2-3 раза. В 50 раз бывает на очень и очень редких задачах.

Сейчас экспериментирую с компилятором icc, транслирую Компонентный Паскаль в Си с помощью CPfront и подсовываю интеловскому компилятору. Но об этом потом отчет напишу.


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

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 64
Иван Денисов писал(а):
-O3 использовать возможно, однако помимо подстановок такой режим использует другие оптимизирующие алгоритмы, которые на ряде тестовых задач могут показать аномальное ускорение. И покажется, что библиотека работает плохо, что не соответствует действительности. А непрофессионал тоже будет толковать такое ускорение превратно

Вы всё правильно говорите, но к чему это?
Эти слова как-нибудь подтверждают, что нужно использовать режим "без оптимизаций"? нет.


Иван Денисов писал(а):
Я вот как-то уже обжегся на этих сравнениях

Ну, да, "А непрофессионал тоже будет толковать".
Разумеется, нужно применять мозг при составлении кода и при анализе результатов.


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

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2546
Откуда: Россия, Ярославль
Дмитрий Дагаев писал(а):
Wlad писал(а):
Я правильно понимаю, что пользователь библиотеки обязан знать про тип Elem и Iterator при работе со списками? и - наследовать свои классы от Elem, в предположении, что они будут храниться в списках?

Да, именно так

Зачем, блин, зачем...


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

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1338
Дмитрий Дагаев писал(а):
Wlad писал(а):
Я правильно понимаю, что пользователь библиотеки обязан знать про тип Elem и Iterator при работе со списками? и - наследовать свои классы от Elem, в предположении, что они будут храниться в списках?
Да, именно так

Это - плохо.
Классы предметки (их разработчики) не должны (в общем случае), строить какие-либо предположения о факте и способах включения в какие-либо, явно выраженные в проектируемом приложении, множества(отношений, признаков) (списки)...
В общем случае сущность НЕ ДОЛЖНА иметь свойства "быть элементом списка".
А вот произвол (со стороны разработчика системы/приложения) включения этой сущности в ЛЮБОЙ список(множество) - ДОЛЖЕН БЫТЬ.
Поэтому, мы должны обеспечить возможность и механизмы организации таких множеств, но это никоим образом не должно быть отражено в проектируемых сущностях.
Лучше исходить из таких требований.
Тогда (при некотором снижении производительности), возрастает показатель гибкости и общности решения.
К тому же, что я считаю более важным, уровень семантики прикладной системы не засоряется лишними знаниями о способах реализации множеств.


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

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2546
Откуда: Россия, Ярославль
А потом всякие там профессионалы кладут в виртуальные составы по пять тысяч вагонов, просто потому что так "удобнее" (измеряется в удобах, видимо, да), а этот состав потом в отчёт официальный попадает. Задумаешься тут, может, лучше бы они отразили природу "элемента списка" в списке и в сущности. Но не прямым наследованием, конечно, тут скорее mixin-подход должен применяться, вот я о чём.


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

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 304
Откуда: Москва
Wlad писал(а):
В общем случае сущность НЕ ДОЛЖНА иметь свойства "быть элементом списка".
А вот произвол (со стороны разработчика системы/приложения) включения этой сущности в ЛЮБОЙ список(множество) - ДОЛЖЕН БЫТЬ.
Поэтому, мы должны обеспечить возможность и механизмы организации таких множеств, но это никоим образом не должно быть отражено в проектируемых сущностях.
Лучше исходить из таких требований.

Да, я рассматривал эту проблему. Элемент списка Elem имеет естественные поля next, prev.
Включение любой сущности в любой список(множество) делаем по схеме инкапсуляции
Код:
Entity = RECORD (BaseEntity)
    user_data: INTEGER;
END;
Elem = RECORD (Lists.Elem)
   e: Entity;
END;

На сущность Entity не накладывается никаких ограничений, она, например, может наследоваться от BaseEntity или вставляться как элемент дерева в Map.

P.S.
А вот индексы внутри Entity пока не получится вставить. Спасибо за вопрос, доделаю, когда будет время.


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

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1338
Реализациям коллекций не нужно быть "полиморфными" (под тем или иным соусом).
Безопасность типа достигается в агрегирующих их классах.
На уровне модели прикладной области нет необходимости знать о том, вектором или списком реализовано ЧТО-ТО внутри множества-сущности из прикладной области.
Безопасность как раз и будет достигнута приведением типа во время работы методов-оберток (от сеттеров и геттеров и - до каких-то сложных методов).
Например, множество процессов-"серверов", ожидающих каких-либо внешних сигналов, не есть "просто список" с традиционным набором операций над списком. Скорее всего, интерфейсные функции этого "множества" будут включать в себя довольно нетривиальные действия. Но работать они будут именно с сущностями-процессами. Внутри этого класса мы гарантированно работаем ИМЕННО с "процессами" (нашего уровня предметки) и - НИ С ЧЕМ ДРУГИМ (ну - просто по логике работы этого класса-"множества процессов"), а прохождение "границы" между внутренностями этого класса-"множества" и "внешним миром" будет обеспечиваться высокоуровневыми проверками при обеспечении выполнения контрактов.
Поэтому, на уровне "чуть ниже" проектируемой системы, не будет никакого другого класса "список" (как примера контейнера для хранения "процессов"), кроме одного, элементы которого - ANY/void*/OBJECT (в зависимости от языка).
Поэтому и шаблонные "инстанцируемые" типы - особо не нужны.
Знаменитого (в библиотеках шаблонных классов коллекций) дублирования кода не происходит, а высокоуровневая проверка ("обеспечение типовой безопасности") - и так будет осуществляться в методах объектов уровня предметной области.

П.Н. Пересмотр подходов к проектированию - да - нужен.


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

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


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

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


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

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