?

Log in

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

[Link]

Previous Entry Share Next Entry

(91 comments | Leave a comment)

Comments
 
[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 09:53 pm (UTC)
(Link)
>Уже многие десятилетия есть прекрасный ABI, который называется COM.
Это, гм, п-ц а не abi.

>Если бы в красноглазом мире было нечто подобное,
CORBA. Особой популярностью не пользуется.
[User Picture]
From:soonts
Date:September 14th, 2015 10:26 pm (UTC)
(Link)
>п-ц а не abi
Не умеете его готовить.

>CORBA
Это никакой не ABI.
CORBA это стандарт взаимодействия распределённых систем.
В случае in-process COM, используемого из C++, накладные расходы — единственный виртуальный вызов. Так работают Direct3D, Media Foundation, и другие очень требовательные к производительности штуки.
В случае CORBA вы anyway попадаете на сериализацию\десериализацию, что очевидно ставит крест на производительности.
[User Picture]
From:permea_kra
Date:September 16th, 2015 06:45 am (UTC)
(Link)
>Не умеете его готовить.
Что характерно, никогда не стремился. С п-цом дел стараюсь не иметь.

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

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

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

Чё-чё-чё?
С каких это пор DirectX стал работать через виртуальные вызовы?
[User Picture]
From:soonts
Date:September 16th, 2015 07:23 am (UTC)
(Link)
>С п-цом дел стараюсь не иметь.
Прекрасная проверенная временем технология.
Очень удачная.
Например весь новый WinAPI (который Windows Runtime) целиком построен на COM-интерфейсах.

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

>С каких это пор DirectX стал работать через виртуальные вызовы?
DirectX работает через виртуальные вызовы всю свою историю.
Он весь построен на COM интерфейсах, наследующих от IUnknown (ID3D11Device, IXAudio2, etc).
С точки зрения языка C++, COM интерфейс это pure abstract class c таблицей виртуальных методов, которые можно вызывать.
[User Picture]
From:permea_kra
Date:September 16th, 2015 08:54 am (UTC)
(Link)
>Например весь новый WinAPI (который Windows Runtime) целиком построен на COM-интерфейсах.

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

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

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

Все-таки не зря винду считают гнилой платформой того же уровня, что и кофемолки.
[User Picture]
From:soonts
Date:September 16th, 2015 11:01 am (UTC)
(Link)
>ООП головного мозга теперь совсем зохавает мир
Ничего лучше человечество не придумало.
Интерфейс всех современных ОС задизайнен в ООП стиле, даже если он на чистом C с хэндлами, как в Win32 или линупсе.

>Я-то помню времена, когда это был чисто сишный АПИ, без всякого COM на поверхности
У вас значит с памятью что-то. Вот например статья эпохи DirectX 5, из текста которой видно, что COM на поверхности был ещё в DirectX 3:
https://www.microsoft.com/msj/0298/primitive.aspx
[User Picture]
From:permea_kra
Date:September 16th, 2015 11:49 am (UTC)
(Link)
>Интерфейс всех современных ОС задизайнен в ООП стиле, даже если он на чистом C с хэндлами, как в Win32 или линупсе.


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


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

*внимательно поглядел матчасть* Действительно. Ну, от майкрософта ничего хорошего ждать и не следовало...
[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