OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 13 Декабрь, 2019 17:05

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




Начать новую тему Ответить на тему  [ Сообщений: 23 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 19 Ноябрь, 2016 17:17 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2481
Сегодня по приглашению Дмитрия Соломенникова сделал доклад по скайпу на III Республиканской IT конференции, которая проходила в Абакане.

Предлагаю вашему вниманию запись
https://www.youtube.com/watch?v=zntynaH0j60
и слайды
http://iadenisov.ru/reports/Abakan161119.pdf

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 19 Ноябрь, 2016 18:17 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 975
Откуда: Киев
Неплохо, но и тут упоминание о скорости уровня Си способно ввести в заблуждение. Конечно, если взять компилятор tcc, то в таком случае BB будет даже в выигрыше, но в сравнении с gcc и clang, сопоставимой скорости не будет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 19 Ноябрь, 2016 19:03 

Зарегистрирован: Воскресенье, 03 Февраль, 2008 12:50
Сообщения: 245
Comdiv писал(а):
Неплохо, но и тут упоминание о скорости уровня Си способно ввести в заблуждение. Конечно, если взять компилятор tcc, то в таком случае BB будет даже в выигрыше, но в сравнении с gcc и clang, сопоставимой скорости не будет.

В видео-записи об этом упомянуто, на самом деле. Другой вопрос, что, наверное, стоило и на слайдах быть чуть аккуратнее в формулировках. Лишний раз давать повод для обвинения в "клеветах" - себе дороже. Про лёгкую интеграция с библиотеками - опять же, заявление, что называется, на грани. И про Wine без "хаков" - туда же. Ну и вообще, по-честному, стоило, наверное, перечислить не только преимущества, но и недостатки.

P.S. "Поддержка русский идентификаторов" - epic fail прям. :P


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 19 Ноябрь, 2016 19:50 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2481
kemiisto писал(а):
P.S. "Поддержка русский идентификаторов" - epic fail прям. :P

Это психологический прием ;) чтобы лучше запомнили. Презентации без изъянов, это подозрительно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 19 Ноябрь, 2016 20:00 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2481
Comdiv писал(а):
Неплохо, но и тут упоминание о скорости уровня Си способно ввести в заблуждение. Конечно, если взять компилятор tcc, то в таком случае BB будет даже в выигрыше, но в сравнении с gcc и clang, сопоставимой скорости не будет.

Я делал пару тестов еще с фортраном, и Веселовский тоже делал несколько экспериментов, так что могу утверждать, что порядок скорости тот-же что у gcc без оптимизации.
А рассказывать про моделирование и не говорить про скорость вычислений было бы странно :) меня именно скорость и привлекла когда-то. Да я тогда на третьем курсе еще не знал про компилятор Intel...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 19 Ноябрь, 2016 23:16 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 975
Откуда: Киев
Мало кто собирает с помощью gcc без оптимизации, особенно из тех, кому может быть важно сообщение о скорости. Что было сказано на видео вполне разумно, но я его прослушал в пол уха, обратив внимание лишь на презентацию в pdf.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 20 Ноябрь, 2016 04:08 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2481
Comdiv писал(а):
Мало кто собирает с помощью gcc без оптимизации, особенно из тех, кому может быть важно сообщение о скорости. Что было сказано на видео вполне разумно, но я его прослушал в пол уха, обратив внимание лишь на презентацию в pdf.

Все равно оптимизация на реальных задачах увеличивает скорость не на порядок, так что порядок скорости сохраняется. Программы на Блэкбоксе, к сожалению, приходится оптимизировать вручную. Профилировщиком ищешь узкие места и размышляешь над алгоритмом. При такой оптимизации иногда приходит в голову использование более целесообразного численного метода, например :-) у меня там было с решением уравнения Шредингера, например. Я вручную увеличил скорость в 100 раз использованием другого частного алгоритма работы с матрицами.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 20 Ноябрь, 2016 17:52 

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

Типа, вот computer science для всех, циклы там, или даже, функции первого порядка, вы изучите, но знайте, что оно никому не нужно, настоящие компьютеры работают не так (почему, кстати).

А вот особый computer science для понимающих людей, там компилятор просто переписывает ваш код в правильный код, без всей этой обобщённой фигни, Циклов Дейкстры или Ленивости.

А чего, получается, нельзя сделать такой язык, чтобы сразу писать оптимальный код? Или нельзя сделать такой процессор, чтобы он выполнял обычный, привычный код, без суперкомпиляции и прочей магии?

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

Так вот в чём заключается double think: нужно писать правильно, потому что наука (computer science!), но не нужно писать правильно, потому что медленно (нормальные хакеры должны жертвовать правильностью ради скорости, циклы там разворачивать, и т.д. и т.п.).

А потом они на второй части противоречия спекулируют языком Си, который "намного" быстрее Оберона, в котором до сих пор стрёмные баги в компиляторе, которому между прочим уже 40+ лет (и это в прогрессивной индустрии ИТ), а на первой части противоречия спекулируют всяким очень правильным декларативным программированием, которое уделает ваш Оберон по формальности и верифицируемости (чего вы верифицировать будете после супер-компиляции от Intel, дятлы).

А полностью противоречие никто не показывает, это же самоубийство.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 20 Ноябрь, 2016 18:48 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8215
Откуда: Троицк, Москва
Иван Денисов писал(а):
Все равно оптимизация на реальных задачах увеличивает скорость не на порядок, так что порядок скорости сохраняется.
Программы на Блэкбоксе ... приходится оптимизировать вручную.
Профилировщиком ищешь узкие места и размышляешь над алгоритмом.
При такой оптимизации иногда приходит в голову использование более целесообразного численного метода, например :-) у меня там было с решением уравнения Шредингера, например. Я вручную увеличил скорость в 100 раз использованием другого частного алгоритма работы с матрицами.
Подписываюсь с заменой уравнения Шредингера на дифференциально-алгебраические алгоритмы имени себя.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 20 Ноябрь, 2016 18:55 

Зарегистрирован: Воскресенье, 03 Февраль, 2008 12:50
Сообщения: 245
Пётр Кушнир писал(а):
Типа, вот computer science для всех, циклы там, или даже, функции первого порядка, вы изучите, но знайте, что оно никому не нужно, настоящие компьютеры работают не так (почему, кстати).

Потому что циклы - концепция слишком высокоуровневая для кучки транзисторов? И кто сказал, что циклы не нужны, потому что транзисторы про них не знают? Настоящие компьютеры - они такие, какие есть. Из-за недостатков фон Неймановской архитектуры и дороговизны быстрой памяти (особенно в периоды становления отрасли) имеем то, что имеем: жутко сложную для эффективного использования подсистему "память-процессор" с очень малым количеством регистров, целой иерархией кешей и всякими там параллелизмами на уровне инструкций. Так исторически сложилось. Возможно, если бы основы проектирования компьютеров закладывались бы сейчас, то на текущем уровне развития технологий получилось бы что-то более простое... Но имеем то, что имеем.

Пётр Кушнир писал(а):
А вот особый computer science для понимающих людей, там компилятор просто переписывает ваш код в правильный код, без всей этой обобщённой фигни, Циклов Дейкстры или Ленивости.

Не в правильный, а в более эффективный же. Корректность, правда, при таком переписывании может пострадать, да. Это проблема. Кстати, возможно, отчасти поэтому доказательство корректности программ так и не популярно: ну докажешь корректность куска текста, а потом придёт оптимизатор и запросто выкинет все твои выкладки в мусорную корзину.

Пётр Кушнир писал(а):
А чего, получается, нельзя сделать такой язык, чтобы сразу писать оптимальный код?

Хм... Ассемблер? :) Хотя, да, там мягко скажем, на нём не сразу получиться. :lol: Ну а если нужен язык высокого уровня, то естественным образом встаёт вопрос об оптимальном отображения конструкций ЯВУ на набор инструкций машины, построенной в рамках физических, экономических и исторических ограничений.

Пётр Кушнир писал(а):
Или нельзя сделать такой процессор, чтобы он выполнял обычный, привычный код, без суперкомпиляции и прочей магии?

Эммм... А причём тут суперкомпиляция?

Пётр Кушнир писал(а):
И при этом, по последним данным, язык С++ уже настолько сложен, что даже с оптимизациями работает вполне обычно, а правильно спроектированные языки в той же нише, типа Rust, работают быстрее.

Rust и С++ всё таки в разных (хотя и отчасти пересекающихся) нишах. У первого на оф. сайте чёрным-по-белому написано systems programming language, а С++ таки отчаянно желают сделать general-purpose: чтоб и systems, и applications можно было писать. И я что-то не верю, что Rust быстрее С++. Пруф бы!

Пётр Кушнир писал(а):
Так вот в чём заключается double think: нужно писать правильно, потому что наука (computer science!), но не нужно писать правильно, потому что медленно (нормальные хакеры должны жертвовать правильностью ради скорости, циклы там разворачивать, и т.д. и т.п.).

Основная идея, что ни только писать, но и транслировать в машинный код нужно "правильно", где во втором случае "правильно" означает не только корректно, но и эффективно. А это сложно, потому что архитектура современных компьютеров сложная. Жертвовать правильностью ради скорости может только транслятор (и то только по команде), а не программист, конечно. Так для этого оптимизаторы и нужны: чтоб хакеры в прогрмамму на ЯВУ ручонками не лезли. В чём противоречие то?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Ноябрь, 2016 09:54 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 864
Откуда: Казань
Оптимизирующие компиляторы языков высокого уровня нужны по следующим причинам:
1) Языки высокого уровня содержат общие подвыражения, которые программист, не может выделить в отдельную инструкцию, например, здесь индекс умножается на размер элемента массива 3 раза:
Цитата:
VAR
i: INTEGER;
a: ARRAY 1000 OF INTEGER;
BEGIN
...
a[i] := b[i] + c[i]

Оптимизирующий компилятор может выделить такие общие инструкции автоматически.
2) Время_работы_программы = количество_инструкций * средняя_длительность_инструкции_в_тактах * длительность_одного_такта
Производители процессоров для повышения их производельности стараются наращивать частоту процессора и уменьшать количество тактов, которое требуется на одну инструкцию.
Вообще, обработка инстукции проходит несколько фаз:
- выборка инструкции
- декодирование
- выполнение
- завершение
- запись результата
Если, допустим, каждая из фаз занимает по одному такту, то среднее время выполнения одной инструкции было бы 5. Затем придумали конвейер, который позволяет выполнять, допустим, 5 инструкций на 5 фазах и в этом случае среднее время выполнения сокращается до 1 такта на инструкцию. Но при этом возможны коллизии и простои конвейера, если операндами следующей инструкции является результат предыдущей инструкции, который еще не записан в регистр.
Вот для того, чтобы уменьшить количество коллизий и простоев конвейера, оптимизирующие компиляторы переупорядочивают инструкции, при этом корректность программы должна сохраняться, так как оптимизирующий компилятор должен переупорядочивать инструкции таким образом, чтобы это не повлияло на окончательный результат.

P.S. Да, оптимизация не увеличивает производительность на порядок, но в зависимости от задачи может уменьшать время выполнения в 2-3 раза.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Ноябрь, 2016 18:19 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
Иван Денисов писал(а):
Все равно оптимизация на реальных задачах увеличивает скорость не на порядок, так что порядок скорости сохраняется.
Хе, ну медленнее она в 9 раз, но не порядок же, да


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Ноябрь, 2016 18:42 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1133
Откуда: СССР v2.0 rc 1
А я вот свои пять копеек подкину))
Оптимизация во FreePascal, PascalABC даёт прирост всего 10%. В С# прирост раза в три, только при release mode в многопоточном приложении (да, такова цена отладки в таких случаях!!!)
Написал я тест на PascalABC.Net. Мой любимый тест))) Бессмысленный и беспощадный.
Выдал он 114 млн. циклов в секунду (С# 104 млн debug и 2871 relise -- был свёрнут цикл). Смотрю в его аналог в ББ. Вижу там ошибку, исправляю, запускаю, и.... 91 млн. циклов в секунду!!
Прошу заметить: целочисленная и вещественная арифметика.
После втыкания инструкций OpenMP у PascalABC -- 406 млн. циклов в секунду, что явное снижение эффективности на 12% (вполне похоже на правду)
У FreePascal на этом тесте -- 97 млн. циклов.
У Си -- 163 млн. циклов.

Так что, отрыв оказался не настолько катастрофичным, как можно было бы предположить с самого начала ;-)

Дальше.
Имеем проблему ввода/вывода. И на рабочей машине -- это 80-110 МБ/с. И это всё))
Локальная сеть -- это 12 МБ/с.
Если говорить про какие-то специализированные расчёты -- да тупо подтащить стороннюю библиотеку и горя не знать.
Если совсем специализированные расчёты, то написать самому и пойти попить чайку. И это будет заведомо дешевле, чем заказать на стороне. А если надо сделать быстро, значит улучшаем алгоритм. Это лучшая оптимизация)
В одной из питонячих дискуссий был приведён такой диалог;
Я могу написать вам эту программу за 100 уе.
Пишите.
Другой программист:
Фу, как не кошерно! Я могу эту программу ускорить в 70 раз иработать она будет не 7 сек, а гораздо быстрее!!
Сколько?
2500 уе. С учётом кратности ускорения -- это выгодное предложение!
-Спасибо, мы решили купить новый сервер за 1000 уе.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Ноябрь, 2016 21:16 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
prospero78 писал(а):
...

Это компиляторы, а не интерпретаторы, поэтому на простых задачах сгенерить код, который будет на порядок медленнее, это надо постараться.
Однако, задачи бывают разные и оптимизация оптимизации рознь. Например, на А2 перемножение матрицы 6000х6000 (double) при использовании оптимизированного под SSE2 кода, выполняется примерно за 25 секунд на 32 битной винде и часа полтора если использовать оберонистый код ( И здесь разница даже не на порядок ;) ), а если использовать еще и простую реализацию, то явно можно отправляться спать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Ноябрь, 2016 22:24 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1133
Откуда: СССР v2.0 rc 1
60000 х 60000 (single) = 14,5 ГБ памяти. 25 сек? Ну-ну)))
C учётом того, что это не линейное чтение, а кусочное -- кэш повесится.
При объёме кэша 3 МБ только по матрице будет 1 млн 200 тыс. промахов.
Заполнение кэша по 3 МБ займёт 9 млрд 600 млн циклов.
Если взять задержку памяти на чтение 2 нс то потребуется 28,8 сек.
Это только на чтение. Ещё возьмём задержки на загрузку-выгрузку данных из сопроцессора, обратную запись и выйдет цифра не 25 сек, а 25 минут. Это если на борту есть 16-20 ГБ памяти (а если нет, то речь пойдёт уже 1,5-2 часах).


Ну ты и сказочник, Кемет. Ты хоть калькулятор себе заведи, штале.
Ну, и про Обероны с поспать я тут уже расписывать не буду)))

А теперь представим, что кэш всего 1 МБ, жёсткий диск с дикой фрагментацией, 2 ГБ ОЗУ с таймингом 4-6-4 и пару ядер, и это по определению не Ксеон 25 сек окажутся чем-то из разряда фантастики ;-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Ноябрь, 2016 22:43 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 975
Откуда: Киев
6000х6000 < 60000х60000


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Ноябрь, 2016 22:47 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1133
Откуда: СССР v2.0 rc 1
Хорошо. Посчитаем матрицу 6к на 6к))
Это 144 МБ. При скорости шины 3,6 ГБ/сек -- время на чтение 40 мс.
Если посчитать, что скорость перемножения в 100 раз меньше с SSE2 чем линейное чтение, то потребуется 4 сек.
Опять нескладуха с 25 сек)))


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Ноябрь, 2016 23:22 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 975
Откуда: Киев
Что-то не сходится. У меня на SSD столько данных записываются менее, чем за пол-секунды.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Ноябрь, 2016 23:35 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1133
Откуда: СССР v2.0 rc 1
Comdiv писал(а):
Что-то не сходится. У меня на SSD столько данных записываются менее, чем за пол-секунды.

1. Речь не идёт о SSD.
2. Менее полсекунды заведомо быстрее чем 4 сек примерно в 10 раз, и быстрее примерно в 125 раз, чем за 25 сек.

Кемет с любой стороны не прав.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Ноябрь, 2016 04:14 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
prospero78 писал(а):
Опять нескладуха с 25 сек)))

Та ладно, при таких вычислениях в А2 задействуются все ядря проца( у меня их 3 ). То есть это не наивная реализация - параллелятся вычисления.
Кстати, у valexey на более мощной 64 битной ( 4 ядра ) машине с AVX(регистры 256 бит, тогда как в SSE - 128 ) код на С++ делающий то же самое, выполняется за 15 секунд. И видимо, на этой же машине код на А2 выполнится еще быстрее чем код на цпп.


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

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


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

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


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

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