?

Log in

No account? Create an account
Читая обсуждение http://ivan-gandhi.livejournal.com/3329246.html и… - Cyril Pertsev
September 13th, 2015
02:21 pm

[Link]

Previous Entry Share Next Entry

(91 comments | Leave a comment)

Comments
 
[User Picture]
From:soonts
Date:September 14th, 2015 03:36 pm (UTC)
(Link)
>Ну это таки неправда
Предположим у вас 4 ядра каждое с HyperThreading, один сложноделимый датасет размером примерно с RAM, и вы хотите в 8 потоков (шоб быстрее было) его как-то обрабатывать, при этом изменяя.

>Она не гарантирована
Вам шашечки или ехать?
>с dll она не работает
С DLL (особенно скомпилированными разными компиляторами) вообще очень много всего не работает, к примеру memory management и C++ exceptions. Вы будете поэтому утверждать, что в C++ нет динамической памяти или исключений?
[User Picture]
From:rblaze
Date:September 14th, 2015 04:27 pm (UTC)
(Link)
Вообще-то "не получится многопоточность" и "данные не лезут в память" это две разных проблемы.
[User Picture]
From:soonts
Date:September 14th, 2015 05:03 pm (UTC)
(Link)
Лезут нормально, но только одна их копия + ещё немного.
[User Picture]
From:rblaze
Date:September 14th, 2015 05:30 pm (UTC)
(Link)
Ну и чем это отличается от мутабельных данных? Мы пишем, GC собирает старое, вопрос только в правильной организации структур. Может быть менее эффективно, т.к. нужно больше места для работы между сборками и невозможно заниматься выжиманием тактиков и битиков, но это же не для повышения производительности программистов, а не программ.
[User Picture]
From:soonts
Date:September 14th, 2015 08:44 pm (UTC)
(Link)
>это же для повышения производительности программистов, а не программ.
Программисты далеко не всегда обходятся дороже компьютеров. Случаи разные.

Кто-то пишет не особо нагруженную корпоративную систему, которая будет работать на 16-ядерном сервере с 45MB L3 cache, генерируя отчоты. Для такого вполне выгодно пожертвовать производительностью, если это на пользу для программистам. Даже иногда выгодно докупить памяти, или поменять проц с 16 ядерного на 18 ядерный, если альтернатива этому переписывать software.

Кто-то другой программирует для простых вендопользователей, у некоторых из которых обязательно окажется самый популярный в мире современный нетбук с условным Atom Z3740 и 2GB RAM. Пользователям нужно, шоб у них не тормозило, а производительность программистов ваши личные сложности, будет тормозить у вас, пользователи свалят к конкурентам.

Кто-то третий программирует какой-нибудь high-load для облаков для всей аудитории фейсбука, и у него цена виртуального железа линейно зависит от числа работающих виртуалок, и экспоненциально от количества оперативы и ядер процессора в каждой из них.
[User Picture]
From:rblaze
Date:September 14th, 2015 08:47 pm (UTC)
(Link)
Я даже согласен. Но вот только фейсбук хаскель использует для связывания данных, Haxl называется. А проблема пользователей с тормозящими компьютерами традиционно решается не оптимизацией, а через lock-in.

Количество действительно performance-critical кода крайне невелико.
[User Picture]
From:soonts
Date:September 14th, 2015 09:13 pm (UTC)
(Link)
>фейсбук хаскель использует для связывания данных
У самого фейсбука другая экономика.
Он ни у кого виртуалки не арендует, наоборот он свои железные сервера с нуля дизайнит, и RAM для них он всё равно покупает петабайтами, потому шо кеширование контента.
Когда у вас всё равно есть десятки петабайт RAM, конечно хаскель будет иметь смысл.

>проблема пользователей с тормозящими компьютерами традиционно решается не оптимизацией, а через lock-in.
Какой lock-in?

>Количество действительно performance-critical кода крайне невелико.
Это вам с вашей колокольни так кажется.
Ещё с прошлого года смартфонов/планшетов в интернетах уже больше, чем компов.
Весь мобильный софт performance-critical, потому шо там в среднем не особо быстрые ARM-камни, их охлаждать сложно, и технологии батареек как-то медленно прогрессируют.
[User Picture]
From:permea_kra
Date:September 14th, 2015 04:47 pm (UTC)
(Link)
>Предположим у вас 4 ядра каждое с HyperThreading, один сложноделимый датасет размером примерно с RAM, и вы хотите в 8 потоков (шоб быстрее было) его как-то обрабатывать, при этом изменяя.

Примерно с RAM он быть не может, потому что может быть больше, может быть меньше.

Во вторых, если мы предполагаем, что он на 10% меньше, то в большинстве случае задача ляжет на сложносочиненный fold, в котором мутабельность может быть и будет, но вся окажется в довольно простом бойлерплейте.

>Вам шашечки или ехать?
В том-то и проблема, что тут нужно гарантированно ехать - иначе на фичу нальзя полагаться, что отражается в подходе к написанию кода, в частности написать разбор входящего файл как рекурсивную функцию уже нельзя.

[User Picture]
From:soonts
Date:September 14th, 2015 05:34 pm (UTC)
(Link)
>в большинстве случае задача ляжет на сложносочиненный fold
У вас значит такая выборка случаев.
У меня вот другая выборка случаев. В моём большинстве случаев датасет не имеет ничего общего ни с деревьями, ни со списками, а является например большим 2-3 мерным массивом небольших структур.

>в котором мутабельность может быть и будет, но вся окажется в довольно простом бойлерплейте.
Синхронизация доступа потоков к мутабельному датасету тоже в довольно простом бойлерплейте.

>тут нужно гарантированно ехать - иначе на фичу нальзя полагаться
Во-первых, в нашей индустрии 100% гарантии вам никто ни о чём не даёт, это ж не математика с теоремами, прочитайте EULA от чего угодно вообще. Из того, что в спецификации написаны какие-то буковки, ничего особенного не следует. Тестируйте в интересующих условиях, потом полагайтесь, если вам нужно.
Во-вторых, я вам уже приводил пример с C++ исключениями. Почему куча народу, включая афтаров стандартной библиотеки, на них полагается, хотя они тоже не работают с DLL?

P.S. Недавно делал приложение для одного клиента. Сначала запилил алгоритм на C# с иммутабельностью, время работы 5 секунд, много. Потом переписал на C++/ATL, время работы 0.2 секунды, нормально. После JIT, вычисления примерно одинаково быстрые, там не было сложной математики, даже floating point не было, только немного целочисленной арифметики и ветвлений.
Основное отличие с точки зрения производительности — в C++ версии в обоих вложенных горячих циклах не было ни одного выделения памяти, потому шо все временные переменные мутабельные и куски памяти с ними переиспользовались между итерациями, мгновенно попали в кеш процессора, и там остались на время работы алгоритма.
[User Picture]
From:rblaze
Date:September 14th, 2015 05:38 pm (UTC)
(Link)
А почему, кстати, у вас исключения не работают с DLL? С .so они отлично работают, даже если один модуль собран gcc, а другой clang. Это же стандартный ABI, ничего особенного.

Edited at 2015-09-14 05:39 pm (UTC)
[User Picture]
From:soonts
Date:September 14th, 2015 08:06 pm (UTC)
(Link)
>С .so они отлично работают, даже если один модуль собран gcc, а другой clang.
Короткий ответ — вам просто повезло.

>Это же стандартный ABI
By its nature, exception handling is very platform specific, and not surprisingly, different compilers use very different implementations. Some compilers use what is known as the Zero-Cost Strategy where exception records are kept in side tables. DWARF debugging information is then used to unwind the stack when an exception is thrown. The advantage here is that entering try/catch blocks are fast, but executing a throw is very slow. GCC and LLVM implement this strategy.

Microsoft’s compilers on the other hand use Structured Exception Handling (SEH) to implement C++ exceptions by managing a chain of EXCEPTION_REGISTRATION_RECORDs embedded on the stack and then calling the operating system RaiseException() function with “special” arguments. SEH is an operating system feature that Microsoft’s compilers use to implement C++ exception handing.

Given an executable compiled with GCC and a shared library compiled with MSVC, if the shared library were to throw a C++ exception that it did not handle, the different implementations would prevent it from working and the program would likely crash. This would happen even if the GCC compiled executable had the correct C++ exception handling to catch the exception.


Копипаста вот отсюда, почитайте — как видно, у C++ вообще практически нет стандартного ABI.
Кстати к исключениям ещё в полной мере относятся разделы той статьи “Object Layout” и “Memory Allocation”.
[User Picture]
From:rblaze
Date:September 14th, 2015 08:17 pm (UTC)
(Link)
ABI есть, вот даже документ имеется: https://mentorembedded.github.io/cxx-abi/. То, что MSVC в силу исторических и коммерческих причин ему не следует, это очень грустно, но что поделаешь, как говорят у красноглазиков, виндопроблемы.
[User Picture]
From:soonts
Date:September 14th, 2015 09:36 pm (UTC)
(Link)
>в силу исторических и коммерческих причин ему не следует, это очень грустно
А мне норм.
На венде не нужен этот стандарт. Уже многие десятилетия есть прекрасный ABI, который называется COM.

В отличие от того, что теоретически возможно со стандартным C++ ABI, COM позволяет использовать DLL из любого языка, из дот нета, из петона, и если приспичит, то можно даже из PHP. Там и многопоточность, и исключения, и ещё куча всего, и производительности хватает даже для очень performance critical штук (если оно in-process, конечно).

Если бы в красноглазом мире было нечто подобное, я уверен, что им бы тоже не упёрся этот C++ ABI.
А так у них выбора в общем-то не было, кроме как стандартизировать C++ ABI, и программировать на 30-летней давности C++.
[User Picture]
From:permea_kra
Date:September 14th, 2015 08:13 pm (UTC)
(Link)
>У меня вот другая выборка случаев. В моём большинстве случаев датасет не имеет ничего общего ни с деревьями, ни со списками, а является например большим 2-3 мерным массивом небольших структур.

фолд и тензорные операции?

>Синхронизация доступа потоков к мутабельному датасету тоже в довольно простом бойлерплейте.

Ииии? Баги и сложный код будет скорее всего не в этом месте.

>Во-первых, в нашей индустрии 100% гарантии вам никто ни о чём не даёт,

Языковой стандарт с тестами соответствия дают.

>Почему куча народу, включая афтаров стандартной библиотеки, на них полагается, хотя они тоже не работают с DLL

Потому что дураки. Механизм исключений вообще надо предать анафеме.

>Сначала запилил алгоритм на C# с иммутабельностью,
Этот язык не умеет толком иммутабельность. F# по слухам умеет, но уверенности нет.

Edited at 2015-09-14 08:14 pm (UTC)
[User Picture]
From:soonts
Date:September 14th, 2015 10:38 pm (UTC)
(Link)
>фолд и тензорные операции?
Не тензорные, просто сильно зависящие от соседних данных.

>Потому что дураки. Механизм исключений вообще надо предать анафеме.
Я с этим согласен, и я к этой куче народа не отношусь.
Это ж не отменяет того факта, что в языке С++ есть исключения, несмотря на то, что лично мне они не нравятся, и шо они не совместимы между компиляторами.

>язык не умеет толком иммутабельность
Readonly fields есть, шо вам ещё от языка нужно?
My Website Powered by LiveJournal.com