BZ>>мне кажется, это станет ещё одним гвоздём в гроб нынешнего поколения языков (java/c#)
К>Не совсем понял — можешь пояснить почему? Транзакционную память нельзя "положить" на них чтоль? К>STM хаскелевский идёт несколько лесом из-за буквы S
скажем посмотри на поддержку исключений для хаскела и императивных языков. в последних это часть спецификации языка и если она сделана неудобно — это уже никак не исправить. в хаскеле вся поддержка идёт на уровне RTS, который выводит наружу одну функцию (catch#) на основе которой в бибилиотеках строятся какие угодно примитивы — хочешь тебе handle, хочешь try, хочешь handleJust. я не рассказывал, что в своей программе заменил стандартные обработчики (коих нашлось всего два типа — "выполнить при ошибке" и "выполнить в любом случае") на свои собственные, обрабатывающие также сигналы (^Break и т.п.)
то же будет с htm — языковая поддержка затянется на годы и будет сделана не лучшим образом. STM ведь появился именно в хаскеле, а не где-нибудь ещё, именно потому, что его там проще реализовать и удобнее использовать
BulatZiganshin wrote: > STM ведь появился именно в хаскеле, а не где-нибудь > ещё, именно потому, что его там проще реализовать и удобнее использовать
STM появился в середине 80-х в исследовательских работах. Там ведь особо
ничего такого нет.
STM вполне можно и в обычных императивных языках было бы использовать.
Даже особых изменений не надо — достаточно делать транзакции по границам
synchronized-блоков.
Здравствуйте, BulatZiganshin, Вы писали:
R>>Кроме выставления минусов, кто-нибудь может что-нибуть по существу сказать по поводу HTM, за исключением цитирования маркетингого очковтирательства?
BZ>наводящий вопрос: у тебя есть технология разработки программ для 80-ядерных процессоров с почти идеальным скалированием?
Такого магического решения сейчас нет и не будет. Масштабирование на 80-ядер, в любом случае, будет подразумевать, как одну из главных составляющих, активное вмешательство человека. Я очень не думаю, что HTM это обеспечит вот так вот прямо магически — вот была программа под одно ядро, в вот она же замасштабировалась линейно на 80 ядер.
Причём, HTM, насколько это мне сейчас видится, является одним из худших претендентов на решение проблемы вообще. Т.к. по производительности HTM, видимо, будет очень слабовата. И проблем она решает только часть, точнее то, решение, которое предлагает HTM не всегда подходит.
И при этом уж с ней-то вообще практически никто не умеет обращаться...
Поэтому я полностью не понимаю радости по поводу HTM.
BZ>>наводящий вопрос: у тебя есть технология разработки программ для 80-ядерных процессоров с почти идеальным скалированием?
R>Такого магического решения сейчас нет и не будет.
гм, лет 10-20 назад я думал то же самое про возможность генерить из С код не хуже написанного вручную
сейчас такого решения действительно нет, а задача эта — наиболее важная из стоящих перед солвременным программированием. поэтому любые попытки решить её, даже с небольшими шансами на успех — архиинтересны
далее, транзакционный подход оказался исключительно упсешен в сфере СУБД, где параллельность обращения клиентов к одной базе — давно уже правило, а не исключение. сейчас ни один человек в здравом уме не станет решать проблемы конкурентного доступа к БД вручную, как это делается в маинстриме конкурентного программирования
так что шансы на успех есть, и немалые. ты вообще с STM знаком, пробовал его использовать?
Здравствуйте, BulatZiganshin, Вы писали:
BZ>далее, транзакционный подход оказался исключительно упсешен в сфере СУБД, где параллельность обращения клиентов к одной базе — давно уже правило, а не исключение.
Вот по поводу успешности — еще вопрос...
Ни одно приложение при использовании СУБД не работает на SERIALIZABLE уровне изоляции, не смотря на то, что 100% гарантию от побочных эфектов при параллельной работе можно обеспечить только на это уровне. На вех уровнях ниже возможны те или иные побочные эффекты. Таким образом это всегда некий договор между СУБД и разработчиком "ты не делаешь этого и тогда у тебя изолированость", причем это "не делаешь этого" нигде и ни кем не контролируется.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>далее, транзакционный подход оказался исключительно упсешен в сфере СУБД, где параллельность обращения клиентов к одной базе — давно уже правило, а не исключение. IB>Вот по поводу успешности — еще вопрос...
IB>Ни одно приложение при использовании СУБД не работает на SERIALIZABLE уровне изоляции, не смотря на то, что 100% гарантию от побочных эфектов при параллельной работе можно обеспечить только на это уровне. На вех уровнях ниже возможны те или иные побочные эффекты. Таким образом это всегда некий договор между СУБД и разработчиком "ты не делаешь этого и тогда у тебя изолированость", причем это "не делаешь этого" нигде и ни кем не контролируется.
У меня такое ощущение, что с железом будет то же самое. Только отключить SERIALIZABLE судя по всему будет нельзя...
Т.е. будут получаться очень сильно засинхронизированные приложения с низкой производительностью.
А уж где словить deadlock новичок и с HTM я думаю найдёт
Плюс ограничения по обязательной возможности повторного выполнения...
Здравствуйте, BulatZiganshin, Вы писали:
BZ>>>наводящий вопрос: у тебя есть технология разработки программ для 80-ядерных процессоров с почти идеальным скалированием?
R>>Такого магического решения сейчас нет и не будет.
BZ>гм, лет 10-20 назад я думал то же самое про возможность генерить из С код не хуже написанного вручную
Ну, лет через 20 возможно и HTM будет хороша
BZ>сейчас такого решения действительно нет, а задача эта — наиболее важная из стоящих перед солвременным программированием. поэтому любые попытки решить её, даже с небольшими шансами на успех — архиинтересны
Ну надо хотя бы изначально быть уверенным, что это хорошее решение. А иначе. Делать любые попытки, причём в железе...
BZ>далее, транзакционный подход оказался исключительно упсешен в сфере СУБД, где параллельность обращения клиентов к одной базе — давно уже правило, а не исключение. сейчас ни один человек в здравом уме не станет решать проблемы конкурентного доступа к БД вручную, как это делается в маинстриме конкурентного программирования
Если на тразакцию в БД уходит 10 мс, то я готов это потратить. Я хотя бы вижу, за что плачу.
А если у меня тривиальная модификация разделяемой структуры занимает 1 мкс, то я не готов это платить.
BZ>так что шансы на успех есть, и немалые. ты вообще с STM знаком, пробовал его использовать?
Использовал, точнее изучал, STM by Keir Fraser. Но имхо даже она слишком тяжеловесная для применения в жизни...
С остальными HTM/HyTM и т.д. знаком чисто теоретически...
BZ>>так что шансы на успех есть, и немалые. ты вообще с STM знаком, пробовал его использовать?
R>Использовал, точнее изучал, STM by Keir Fraser. Но имхо даже она слишком тяжеловесная для применения в жизни...
тяжела в каком плане? скорости — это как раз должна рещить хардверная поддержка. неудоюно применять — ну так проблема в языках
Здравствуйте, BulatZiganshin, Вы писали:
BZ>>>так что шансы на успех есть, и немалые. ты вообще с STM знаком, пробовал его использовать?
R>>Использовал, точнее изучал, STM by Keir Fraser. Но имхо даже она слишком тяжеловесная для применения в жизни...
BZ>тяжела в каком плане? скорости — это как раз должна рещить хардверная поддержка.
Каким образом???
В любом случае, если HTM чудесным образом будет быстрой, то то, что сейчас быстрее HTM на порядок, так и останется быстрее на порядок...
R>В любом случае, если HTM чудесным образом будет быстрой, то то, что сейчас быстрее HTM на порядок, так и останется быстрее на порядок...
Ну-ну, советую ознакомиться побольше с предметом, к примеру на вот эти выкладки, котырые приводит Simon Peyton Jones, конкретно слайды 16 и 17. "Блокировочные" варианты очень плохо ведут себя с т.зр. масштабируемости.
TM, конечно, не "серебрянная пуля", но довольно удобная и полезная абстракция.
Здравствуйте, Курилка, Вы писали:
R>>В любом случае, если HTM чудесным образом будет быстрой, то то, что сейчас быстрее HTM на порядок, так и останется быстрее на порядок...
К>Ну-ну, советую ознакомиться побольше с предметом, к примеру на вот эти выкладки, котырые приводит Simon Peyton Jones, конкретно слайды 16 и 17. "Блокировочные" варианты очень плохо ведут себя с т.зр. масштабируемости.
Я могу привести ещё более медленные варианты. На их фоне STM будет выглядеть ещё более привлекательно.
Как это противоречит тому, что сказал я?
HTM *должна* полагаться на сильную модель памяти и синхронизацию между кэшами.
К>TM, конечно, не "серебрянная пуля", но довольно удобная и полезная абстракция.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Курилка, Вы писали:
К>>TM, конечно, не "серебрянная пуля", но довольно удобная и полезная абстракция.
R>Чем она полезна?
Тем что позволяет работать с разделяемыми данными более "высокоуровнево", не спускаясь до примитивов синхронизации.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, remark, Вы писали:
R>>Я могу привести ещё более медленные варианты. На их фоне STM будет выглядеть ещё более привлекательно.
К>Приведи более быстрые варианты, коль их, судя по твоей убеждённости, видимо, очень много...
Алгоритм полагается исключительно на расслабленную модель памяти и никак не форсирует синхронизацию кэшей.
Алгоритм предполагает выполнение только дешевого #LoadLoad барьера, на x86 и того не надо.
Любая TM *должна* предполагать синхронизацию между кэшами, иначе она не сможет проводить сильное разрешение конкуренции между потоками. Т.е. соотв. накладные расходы сразу возрастают на порядок. И плюс к этому шина протокола когерентности кэшей становится bottleneck'ом твоего приложения. На NUMA системах, к которым сейчас все идет, вообще страшно представить...
Мы уже победили, просто это еще не так заметно...
