kika

>Ну это таки неправда
Предположим у вас 4 ядра каждое с HyperThreading, один сложноделимый датасет размером примерно с RAM, и вы хотите в 8 потоков (шоб быстрее было) его как-то обрабатывать, при этом изменяя.

>Она не гарантирована
Вам шашечки или ехать?
>с dll она не работает
С DLL (особенно скомпилированными разными компиляторами) вообще очень много всего не работает, к примеру memory management и C++ exceptions. Вы будете поэтому утверждать, что в C++ нет динамической памяти или исключений?

From:

Вообще-то "не получится многопоточность" и "данные не лезут в память" это две разных проблемы.

From:

Лезут нормально, но только одна их копия + ещё немного.

From:

Ну и чем это отличается от мутабельных данных? Мы пишем, GC собирает старое, вопрос только в правильной организации структур. Может быть менее эффективно, т.к. нужно больше места для работы между сборками и невозможно заниматься выжиманием тактиков и битиков, но это же не для повышения производительности программистов, а не программ.

From:

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

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

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

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

From:

Я даже согласен. Но вот только фейсбук хаскель использует для связывания данных, Haxl называется. А проблема пользователей с тормозящими компьютерами традиционно решается не оптимизацией, а через lock-in.

Количество действительно performance-critical кода крайне невелико.

From:

>фейсбук хаскель использует для связывания данных
У самого фейсбука другая экономика.
Он ни у кого виртуалки не арендует, наоборот он свои железные сервера с нуля дизайнит, и RAM для них он всё равно покупает петабайтами, потому шо кеширование контента.
Когда у вас всё равно есть десятки петабайт RAM, конечно хаскель будет иметь смысл.

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

>Количество действительно performance-critical кода крайне невелико.
Это вам с вашей колокольни так кажется.
Ещё с прошлого года смартфонов/планшетов в интернетах уже больше, чем компов.
Весь мобильный софт performance-critical, потому шо там в среднем не особо быстрые ARM-камни, их охлаждать сложно, и технологии батареек как-то медленно прогрессируют.

From:

Vendor lock-in. Если пользователю геморнее конвертировать свои данные в формат конкурентов, чем страдать от тормозов, то будет страдать.

From:

Далеко не у всех есть такая возможность.

Например из клиентов, для которых я сейчас разрабатываю софт для windows/osx десктопов, один делает в основном плагин для adobe after effects (софт для киношников), второй работает с пачкой чужих форматов word/pdf/odf и всеми остальными, где люди держат тексты (софт для пейсателей и переводчиков).

From:

>Предположим у вас 4 ядра каждое с HyperThreading, один сложноделимый датасет размером примерно с RAM, и вы хотите в 8 потоков (шоб быстрее было) его как-то обрабатывать, при этом изменяя.

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

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

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

From:

>в большинстве случае задача ляжет на сложносочиненный fold
У вас значит такая выборка случаев.
У меня вот другая выборка случаев. В моём большинстве случаев датасет не имеет ничего общего ни с деревьями, ни со списками, а является например большим 2-3 мерным массивом небольших структур.

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

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

P.S. Недавно делал приложение для одного клиента. Сначала запилил алгоритм на C# с иммутабельностью, время работы 5 секунд, много. Потом переписал на C++/ATL, время работы 0.2 секунды, нормально. После JIT, вычисления примерно одинаково быстрые, там не было сложной математики, даже floating point не было, только немного целочисленной арифметики и ветвлений.
Основное отличие с точки зрения производительности — в C++ версии в обоих вложенных горячих циклах не было ни одного выделения памяти, потому шо все временные переменные мутабельные и куски памяти с ними переиспользовались между итерациями, мгновенно попали в кеш процессора, и там остались на время работы алгоритма.

From:

А почему, кстати, у вас исключения не работают с DLL? С .so они отлично работают, даже если один модуль собран gcc, а другой clang. Это же стандартный ABI, ничего особенного.

Edited Date: 2015-09-14 05:39 pm (UTC)

From:

>С .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 (http://llvm.org/docs/ExceptionHandling.html) where exception records are kept in side tables. DWARF (http://www.dwarfstd.org/) 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.

Копипаста вот отсюда (https://www.p6r.com/articles/2014/07/20/binary-compatible-c-interfaces/), почитайте — как видно, у C++ вообще практически нет стандартного ABI.
Кстати к исключениям ещё в полной мере относятся разделы той статьи “Object Layout” и “Memory Allocation”.

From:

ABI есть, вот даже документ имеется: https://mentorembedded.github.io/cxx-abi/. То, что MSVC в силу исторических и коммерческих причин ему не следует, это очень грустно, но что поделаешь, как говорят у красноглазиков, виндопроблемы.

From:

>в силу исторических и коммерческих причин ему не следует, это очень грустно
А мне норм.
На венде не нужен этот стандарт. Уже многие десятилетия есть прекрасный ABI, который называется COM.

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

Если бы в красноглазом мире было нечто подобное, я уверен, что им бы тоже не упёрся этот C++ ABI.
А так у них выбора в общем-то не было, кроме как стандартизировать C++ ABI, и программировать на 30-летней давности C++.

From:

>Уже многие десятилетия есть прекрасный ABI, который называется COM.
Это, гм, п-ц а не abi.

>Если бы в красноглазом мире было нечто подобное,
CORBA. Особой популярностью не пользуется.

From:

>п-ц а не abi
Не умеете его готовить.

>CORBA
Это никакой не ABI.
CORBA это стандарт взаимодействия распределённых систем.
В случае in-process COM, используемого из C++, накладные расходы — единственный виртуальный вызов. Так работают Direct3D, Media Foundation, и другие очень требовательные к производительности штуки.
В случае CORBA вы anyway попадаете на сериализацию\десериализацию, что очевидно ставит крест на производительности.

From:

>Не умеете его готовить.
Что характерно, никогда не стремился. С п-цом дел стараюсь не иметь.

>Это никакой не ABI.
>CORBA это стандарт взаимодействия распределённых систем.

И то, и другое - стандарт доступа к (возможно, удаленному) менеджеру/хранилищу объектов. Разумеется, ни то, ни другое стандартов ABI не являются.

>В случае in-process COM, используемого из C++, накладные расходы — единственный виртуальный вызов. Так работают Direct3D,

Чё-чё-чё?
С каких это пор DirectX стал работать через виртуальные вызовы?

From:

>С п-цом дел стараюсь не иметь.
Прекрасная проверенная временем технология.
Очень удачная.
Например весь новый WinAPI (который Windows Runtime) целиком построен на COM-интерфейсах.

>И то, и другое - стандарт доступа к (возможно, удаленному) менеджеру/хранилищу объектов.
На самом высоком уровне абстракции да.
Однако COM включает в себя и ABI тоже, который с определёнными оговорками можно использовать отдельно от его более высокоуровневых фич.

>С каких это пор DirectX стал работать через виртуальные вызовы?
DirectX работает через виртуальные вызовы всю свою историю.
Он весь построен на COM интерфейсах, наследующих от IUnknown (ID3D11Device, IXAudio2, etc).
С точки зрения языка C++, COM интерфейс это pure abstract class c таблицей виртуальных методов, которые можно вызывать.

From:

>Например весь новый WinAPI (который Windows Runtime) целиком построен на COM-интерфейсах.

Ничего хорошего в этом нет, в общем-то. ООП головного мозга теперь совсем зохавает мир.

>DirectX работает через виртуальные вызовы всю свою историю.

Мда. Я-то помню времена, когда это был чисто сишный АПИ, без всякого COM на поверхности. А тут вы рассказываете про ком.

Все-таки не зря винду считают гнилой платформой того же уровня, что и кофемолки.

From:

>ООП головного мозга теперь совсем зохавает мир
Ничего лучше человечество не придумало.
Интерфейс всех современных ОС задизайнен в ООП стиле, даже если он на чистом C с хэндлами, как в Win32 или линупсе.

>Я-то помню времена, когда это был чисто сишный АПИ, без всякого COM на поверхности
У вас значит с памятью что-то. Вот например статья эпохи DirectX 5, из текста которой видно, что COM на поверхности был ещё в DirectX 3:
https://www.microsoft.com/msj/0298/primitive.aspx

From:

>Интерфейс всех современных ОС задизайнен в ООП стиле, даже если он на чистом C с хэндлами, как в Win32 или линупсе.

Эээ, ненене. ООП там нет. Объекты - есть, ООП точно нет. И слава богу.

>У вас значит с памятью что-то.

*внимательно поглядел матчасть* Действительно. Ну, от майкрософта ничего хорошего ждать и не следовало...

From:

>У меня вот другая выборка случаев. В моём большинстве случаев датасет не имеет ничего общего ни с деревьями, ни со списками, а является например большим 2-3 мерным массивом небольших структур.

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

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

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

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

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

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

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

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

Edited Date: 2015-09-14 08:14 pm (UTC)

From: