?

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 07:26 am (UTC)
(Link)
>зато в ряде случаях из-за неё RAM перестаёт хватать,

Это уже сильно другой вопрос.

>многопоточность сложно сделать,

Ну это таки неправда.

>В 2008 уже оптимизировалось в обычных плюсах.

Она не гарантирована. Более того, насколько я помню, с dll она не работает.
[User Picture]
From:_slw
Date:September 14th, 2015 07:56 am (UTC)
(Link)
а что такое dll?
[User Picture]
From:permea_kra
Date:September 14th, 2015 08:24 am (UTC)
(Link)
cdecl и аналоги (caller cleanup) несовместима с TCO простыми средствами. А это афаик стандартная calling convention для c-компиляторов. читай - везде.
[User Picture]
From:_slw
Date:September 14th, 2015 08:49 am (UTC)
(Link)
а что такое cdecl? в моем компиляторое этого нет.
[User Picture]
From:permea_kra
Date:September 14th, 2015 11:12 am (UTC)
(Link)
Вообще говоря, в gcc это есть, если речь о нем. Скорее всего, есть и в clang. В VC++ точно есть.
[User Picture]
From:_slw
Date:September 14th, 2015 12:16 pm (UTC)
(Link)
я попробовал в своем clang и gcc -- нету.

int cdecl is_one(void)
{
        return 1;
}


t.c:1:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'is_one'
 int cdecl is_one(void) 
[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: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: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)
My Website Powered by LiveJournal.com