Здравствуйте, AVM, Вы писали:
AVM>Ну а если уж сваливаться на философию, то мое мнение начинает сдвигаться в сторону что развитие современных кремниевых процессоров — тупиковая ветвь. Какая разница 4 или 80 или 8000 ядер. Качественный скачек это не дает, просто порождает кучу проблем и обсуждений на форумах. AVM>С другой стороны у каждого из нас в голове содержится нехреновый такой вычислительный центр додключенный к обалденным устройствам ввода/вывода
Вобще говоря эти машинки обладают принципиально разными свойствами и ИМХО то что хорошо делает одна другая будет делать плохо. Обратоное тоже верно.
Те они не будут заменять друг друга. Они будут друг друга дополнять.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
R>Но основная беда даже не в этом.
R>(опустим пока такие тривиальные вещи как сериализация на мьютексах)
R>Передача кэш-линии занимает порядка 150-350 тактов. Даже без всяких атомарных операций и пр. R>Т.е. скорость работы снижается до 100 (!) раз. Т.о. тривиальный producer-consumer может стать ботлнеком, если данные просто переходят из одного кэша в другой (без всяких atomic, мьютексов, евентов, вызовов я ядро для пробуждения consumer). R>Плюс шина межпроцессорного/межядерного взаимодействия может стать боттлнеком, так что приложение просто не будет масштабироваться вообще при добавлении ядер, даже если потоков/работы достаточно, и нет сериализации на мьютексах, ядра не загружены и шина памяти не загружена.
Получается, что нужно сосредоточиться не только на стычках потоков вокруг общих данных (что всегда было предметом уважения), но и на стычках ядер вокруг линеек кеша.
Это означает, что
— чем больше взаимодействие между потоками основано на пакетной обработке, тем лучше (впрочем, это и для одноядерных справедливо — в том плане, чтоб минимизировать переключения потоков)
— для очередей, не предполагающих пакетную обработку — нужно разбрасывать элементы по разным линейкам
Правильно?
На моей памяти это уже второй виток хардверно-специфических оптимизаций. Первый был, когда стали очень уважать попадание/промахивание в кэш своего ядра
Здравствуйте, AVM, Вы писали:
AVM>Ну а если уж сваливаться на философию, то мое мнение начинает сдвигаться в сторону что развитие современных кремниевых процессоров — тупиковая ветвь. Какая разница 4 или 80 или 8000 ядер. Качественный скачек это не дает,
А качественного скачка и раньше никогда в истории не было. Было 10МГц, потом 20МГц, потом 50МГц, потом 100МГц, потом 200МГц, потом 500МГц, потом 1ГГц.
Просто умножается на 2. И это всех устраивало. И будет устраивать.
R>> AVM>
R>>С использованием std::atomic я показал, как должна была бы выглядеть программа для сферического компьютера в вакууме. Т.е. где должны быть какие типы барьеров. R>>Потом я сказал, что те типы барьеров, которые тут должны быть на сферическом компьютере, на x86 не нужны, т.к. всегда присутствуют неявно. R>>Т.е., если я пишу под x86, то я ничего не использую.
КЛ>
КЛ>Т.е. ты хочешь сказать, что Interlocked _вообще_ никогда не нужен и все само собой синхронизируется?
Здравствуйте, Константин Л., Вы писали:
КЛ>Ну, честно признаюсь, дальше этого я не ходил:
КЛ>
КЛ>Without a garbage collector, things get harder. Much harder, actually, and it turns out that deterministic memory freeing is quite a fundamental problem in lock-free data structures.
Тогда было проблемой. Но развитие не стоит на месте
Здравствуйте, eao197, Вы писали:
C>>А почему тут происходят переключения контекстов? E>Если нить ввода-вывода и нить обработки находятся на разных ядрах, то передача сообщений между ними оказывается дороже, чем при работе обоих нитей на одном ядре. По крайней мере, по моим впечатлениям.
У меня впечатления обратные — передача данных через неблокирующуюся очередь (java.util.concurrent.ConcurrentNavigableMap, если кому интересно) у меня работает абсолютно с одинаковой скоростью на любом количестве процессоров (масштабируется почти линейно).
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, remark, Вы писали:
R>>??? достаточно *либо* GC, *либо* RCU, иметь их вместе бессмысленно. WH>Главная идея RCU (http://en.wikipedia.org/wiki/Read-copy-update оно?) это неизменение разделяемых данных, а изменеие ссылки по которой эти данные получают на ссылку на обновленные данные. WH>Те GC не отменяет RCU. Но делает реализацию данного паттерна тривиальной.
Я бы так не сказал. "неизменение разделяемых данных" это основа практически всех lock-free алгоритмов.
RCU тут как раз решает задачу отложенного выполнения действий. Т.н. PDR, partial-copy-on-write deferred reclamation.
И в принципе теоретически можно произвольно выбрать какой-либо алгоритм, основанный на partial-copy-on-write. И произвольную технику deferred reclamation (GC, RCU, SMP/ROP, DRC, vZOOM). И соединить их воедино. И это будет работать. Т.е. они независимы.
И RCU это фактически понятие того же порядка, что и GC.
Здравствуйте, alpha21264, Вы писали:
iZEN>>>Вы сами проверяли? iZEN>>>А я проверял. Двухъядерный процессор рвёт одноядерный на одной и той же частоте (Athlon64 X2 2ГГц vs. AthlonXP 1,8ГГц) в компиляции исходников C/C++ компилятором GCC более чем в 2,5 раза (двадцать пять минут против полутора часов) -- масштабируемость фактически линейная при одинаковой латентности подсистмы памяти и кэша L2). GZ>>2,5 — не очень то линейно. GZ>>С GCС не работал. А он действительно компилирует многопоточно, или как VS2005 загружает по проекту на каждый проц?
A>Кха... Юниксовый make много... параллельный короче. A>Пишешь make -j 2 и он компилирует в два раза быстрее. A>Даже если в машине ОДИН процессор. A>А если в машине два процессора, то надо писать make -j 4. A>Во как. A>Разгадка простая — пока один экземпляр gcc занимает процессор, второй читает/пишет данные с диска.
Я раньше тоже так думал, но разгадка оказалась не так проста.
На двуядерном процессоре команда make -j4 ровным счётом ничего не дала в плане уменьшения времени компиляции -- времени затратилось ровно столько же (с точностью до 5 минут), как-будто компиляция проводилась в однопоточном режиме на одном ядре.
А вот команда make -j2 действительно увеличила скорость компиляции 2,5 раза.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Константин Л., Вы писали:
R>>>С использованием std::atomic я показал, как должна была бы выглядеть программа для сферического компьютера в вакууме. Т.е. где должны быть какие типы барьеров. R>>>Потом я сказал, что те типы барьеров, которые тут должны быть на сферическом компьютере, на x86 не нужны, т.к. всегда присутствуют неявно. R>>>Т.е., если я пишу под x86, то я ничего не использую.
КЛ>>
КЛ>>Т.е. ты хочешь сказать, что Interlocked _вообще_ никогда не нужен и все само собой синхронизируется?
R>Где я это сказал?!
1. Привели пример, когда значение поинтеров меняется из разных тредов без-каких либо Interlocked/atomic. Будем считать что каждый тред сразу должен увидеть эти изменения (актуально для refcounting, не правда-ли?)
2. Ты говоришь —
На x86 да, а почему бы и нет? Это экстремально быстро.
3. Тебе говорят — тут нужен memory barrier.
4. Ты в ответ — "Не нужен, на x86 все и так путем. Они там присутствуют неявно".
5. Тебя спрашивают — "За каким хреном нам тогда вообще Interlocked на x86"
6. Ты — "Где я это сказал"?
Здравствуйте, Константин Л., Вы писали:
КЛ>1. Привели пример, когда значение поинтеров меняется из разных тредов без-каких либо Interlocked/atomic. Будем считать что каждый тред сразу должен увидеть эти изменения (актуально для refcounting, не правда-ли?)
Не путай запись из регистра в память (это одна атомарная операция) и чтение из памяти в регистр, изменение регистра, запись из регистра в память (это 3 атомарные операции) но вся последовательность не атомарна.
Интерлокеды нужны для того чтобы выполнять подобные последовательности атомарно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Стэн, Вы писали:
С>Здравствуйте, AVM, Вы писали:
AVM>>С другой стороны у каждого из нас в голове содержится нехреновый такой вычислительный центр подключенный к обалденным устройствам ввода/вывода С>А с какой скоростью и с какой точностью сможешь перемножить две матрицы 100x100 действительных чисел в уме?
Это вопрос к Человеку дождя, если ты догадываешься о чем я — Мы не знаем всех возможностей мозга.
Можно задать и встречный вопрос? — с какой скоростью японский робот-пылесос сможет найти (если вообще сможет) грязные носки в углу? Да ладно носки — с какой скоростью он сможет найти угол
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, AVM, Вы писали:
AVM>>Ну а если уж сваливаться на философию, то мое мнение начинает сдвигаться в сторону что развитие современных кремниевых процессоров — тупиковая ветвь. Какая разница 4 или 80 или 8000 ядер. Качественный скачек это не дает, просто порождает кучу проблем и обсуждений на форумах. AVM>>С другой стороны у каждого из нас в голове содержится нехреновый такой вычислительный центр додключенный к обалденным устройствам ввода/вывода WH>Вобще говоря эти машинки обладают принципиально разными свойствами и ИМХО то что хорошо делает одна другая будет делать плохо. Обратоное тоже верно. WH>Те они не будут заменять друг друга. Они будут друг друга дополнять.
Отчасти согласен, но думаю что со временем биомасса вытеснит кремний.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, AVM, Вы писали:
AVM>>Ну а если уж сваливаться на философию, то мое мнение начинает сдвигаться в сторону что развитие современных кремниевых процессоров — тупиковая ветвь. Какая разница 4 или 80 или 8000 ядер. Качественный скачек это не дает,
R>А качественного скачка и раньше никогда в истории не было. Было 10МГц, потом 20МГц, потом 50МГц, потом 100МГц, потом 200МГц, потом 500МГц, потом 1ГГц. R>Просто умножается на 2. И это всех устраивало. И будет устраивать.
Был, переход от механики к электричеству.
R>>> AVM>> R>
Здравствуйте, remark, Вы писали:
R>Скорее всего ты говоришь о какой-то очень ограниченной области применения, либо вообще о HPC.
Нет, я говорю о языках общего назначения. Общеизвестный пример: на К написала большая часть kdb (говорят лидер рынка БД по производительности), набор трейдерских (то бишь зачастую очень real-time-овских) и других околофинансовых приложений (kx.com). Порылся на форумах JSoftware — нет, к сожалению текущая реализация J 601 никак не использует многоядерность, но принципиальных проблем с её использованием нет (ввиду implicit parallelism).
Просто эти языки и платформы предлагают иную (векторную сиречь _параллельную_) парадигму программирования (что не означает кстати, что они подходят лишь для перемножения матриц — обычные повседневные задачи тоже зачастую легко "векторизуются").
Это был всего лишь мой пример существующего решения проблемы означенной в заглавии этой дискуссии. Продолжайте ломать копия о memory barrier-ы и прочие низкоуровневые детали реализации взгромождаемые традиционными постфортрановскими средствами разработки на плечи прикладного программиста
Здравствуйте, AVM, Вы писали: AVM>Отчасти согласен, но думаю что со временем биомасса вытеснит кремний.
Там проблема не в структуре кристалла. Если мы хакнем алгоритмическую базу, то прошить ее можно будет хоть в кремнии, хоть в германии. См.тж. Тезис Черча.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
E>Что-то разговоры о проблемах программирования в условиях многоядерности напоминают мне шумиху вокруг перехода на Win32. Тогда так же было много шума. Многие выгоды сулили. Мол не будет для ваших данных барьеров в 64K, будут доступны файлы объемом свыше 2Gb и пр.
E>А в итоге -- многих ли этот переход действительно серьезно затронул?
Вообще-то этот переход серъезно затронул практически всех.
Проблема-то не в перекомпиляции приложения. Эти приложения к 2005 году практически вымерли совсем.
Проблема в том, что требования пользователя изменились. На win16 не было принято писать многопоточные приложения. У всех вся работа делалась прямо в цикле выборки сообщений.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AVM, Вы писали:
С>>А с какой скоростью и с какой точностью сможешь перемножить две матрицы 100x100 действительных чисел в уме? AVM>Это вопрос к Человеку дождя, если ты догадываешься о чем я — Мы не знаем всех возможностей мозга.
Зато я читал о парочке случаев, из клинической психологии, когда человек мог запомнить и процетировать дословно несколько десятков страниц книжного текста, но при этом совершенно не мог объяснить о чем текст.
На самом деле мы знаем о возможностях мозга гораздо больше чем думают многие, и известно, что чудес не бывает, просто хочется в это верить...
AVM>Можно задать и встречный вопрос? — с какой скоростью японский робот-пылесос сможет найти (если вообще сможет) грязные носки в углу? Да ладно носки — с какой скоростью он сможет найти угол
Хороший вопрос. Вообщем-то о том и речь, что если задача искать носки, то забудь о перемножении матриц, если матрицы, то стоит забыть о носках...
Возьми какую-нибудь программную реализацию нейросетевого алгоритма. Нейронную сеть на его основе можно научить перемножать два числа, но для этого "умножения" ему придется несколько десятков тысяч внутренних коэффициентов перемножить! Спрашивается: а зачем такие сложности?
Сразу предвижу утверждение, что компьютер одной частью своего "мозга" может быстро искать носки, а другой быстро перемножать матрицы... Компьютер (ИИ), который пользуется компьютером... Вернемся тудаже откуда начали.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AVM, Вы писали: AVM>>Отчасти согласен, но думаю что со временем биомасса вытеснит кремний. S>Там проблема не в структуре кристалла. Если мы хакнем алгоритмическую базу, то прошить ее можно будет хоть в кремнии, хоть в германии. См.тж. Тезис Черча.
IMHO хакнуть — это только пол дела, потом его надо заимплементить. Ну хакнул ты алгоритм генерации запаха. Как ты имплементируешь скунса в игрушках на железе которое сделано по сути песка? На кремнии в рантайме химии нет, там голая физика.
Тут задавали вопрос про скорость перемножения матриц. А какая скорость принятия решения у хищной птицы, который в пикировании ловит добычу? И сколько фотодиодов должна иметь каменная оптика, чтобы различить мышь в траве c высоты птичьего полета?
Сейчас бьются над распознаванием образов, используя супер-пупер многоядерные кремниевые процессора и сенсоры запахов, чтобы найти террориста в потоке людей в аэропорту, а обычная собака в толпе за доли секунды определяет субъекта представляющего для нее опасность.
Пишут супер навигационные системы, запускают спутники, создают GPS и ГЛОНАС, чтобы самолеты и корабли не заблудились. А птицы просто летят на зимовку и возвращаются с нее. Гарбуша просто идет на нерест.
Бъемся над распознаванием голоса, наворотили кучу железа и софта, защитили кучу диссертаций и получили вагон премий, а кутенок уже через пол часа уже узнает колос хозяина.
Таких примеров вагон и маленькая тележка. Не верю я что все это можно реализовать из мертвого камня на одной только физике.
Здравствуйте, Стэн, Вы писали:
С>Хороший вопрос. Вообщем-то о том и речь, что если задача искать носки, то забудь о перемножении матриц, если матрицы, то стоит забыть о носках...
Можно еще один хороший вопрос? Зачем нам вообще перемножать матрицы? Может быть только для того, чтобы сделать компьютер умеющий их перемножать?
Здравствуйте, AVM, Вы писали: С>>Хороший вопрос. Вообщем-то о том и речь, что если задача искать носки, то забудь о перемножении матриц, если матрицы, то стоит забыть о носках... AVM>Можно еще один хороший вопрос?
Ничего хорошего в этом вопросе нету. AVM>Зачем нам вообще перемножать матрицы? AVM>Может быть только для того, чтобы сделать компьютер умеющий их перемножать?
Перемножение матриц имеет невероятно широкий спектр прикладных применений.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Перекуём баги на фичи!
