Здравствуйте, WolfHound, Вы писали:
R>>Второй момент, константность ("pureness") объекта определяется не статически, а динамически. Т.е. на одной итерации одна матрица pure, на другой — другая. Необходимость получения доступа на чтение к "предыдущей" матрице без всяких блокировок — критична. Копировать матрицы на каждой итерации тоже не вариант.
WH>В принципе если ввести аналог С++'ного const для методов uniqueness типа то можно сделать преобразование uniqueness -> pure при условии что у pure варианта можно будет трогать только const методы. WH>Обратная трансформация невозможна.
Мне кажется, что наличие только одного этого преобразования не добавляет много к языку, из-за... однобокости... и ограниченности. Т.е. хотелось бы чего-то более... как сказать... мощного. Можно ли ещё что-то добавить?
Хотя, возможно, и наличие только такого одного преобразования будет тоже полезным на практике. Мне сейчас сложно сказать. Что думаешь? Будет оно полезно?
Здравствуйте, remark, Вы писали:
R>Я поражаюсь как у тебя всё всегда просто
Ну что поделать если все действительно просто когда нет зависимостей по данным.
R>А компилятор в действительности сможет это сделать приемлемо? R>Ну хорошо, допустим даже, что сможет.
Думаю что если за эту часть компилятора посадить тебя предварительно объяснив философию работы с неизменяемыми данными то наверняка сможет.
R>А теперь допустим, что матрица — это у нас изображение. Которое мы обсчитываем путем ray-tracing'а.
Не вопрос.
R>Как компилятор побъет эту матрицу для независимой обработки потоками?
Как угодно.
Если сцена неизменяемая и расчет пикселея не завист от соседей то можно делать что угодно.
Ибо значение пикселя это функция от сцены, камеры и координат пикселя.
R>Бить её квадрантами или широкими горизонтальными или вертикальными линиями очень не хорошо. Т.к. при ray-tracing'е объем работы сильно зависит от изображения, соотв., если мы будем бить широкими горизонтальными полосами, мы получим, что объем работы для обработки верхней полосы, где небо, будет в 100 раз меньше, чем объем работы для нижней полосы, где несколько детализированных моделей деревьев. Соотв. бить надо в зависимости от задачи, например очень узкими горизонтальными полосами, и каждому потоку достается множество полос, удовлетворяющее (stripe_index % thread_count == thread_index).
fork/join + work stealing
В случае с перемножением матриц это вобще идеальный вариант.
В случае с ray-tracing поддерево с небом быстренько обсчитается и все ресурсы переползут на поддерево с лесом.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
WH>>В принципе если ввести аналог С++'ного const для методов uniqueness типа то можно сделать преобразование uniqueness -> pure при условии что у pure варианта можно будет трогать только const методы. WH>>Обратная трансформация невозможна. R>Мне кажется, что наличие только одного этого преобразования не добавляет много к языку, из-за... однобокости... и ограниченности.
Вобще да. Отдает некой костыльностью.
R>Т.е. хотелось бы чего-то более... как сказать... мощного.
Хотелось бы.
R>Можно ли ещё что-то добавить?
Может что-то еще придумаю.
R>Хотя, возможно, и наличие только такого одного преобразования будет тоже полезным на практике. Мне сейчас сложно сказать. Что думаешь? Будет оно полезно?
Думаю будет.
Иногда нужно кучерявым образом инициализаровать некий кучерявый объект который после инициализации никогда не будет меняться.
Например хештаблици таки заруливают деревья по скорости.
Хотя нужно еще подумать. Может из меня еще не доконца вышли императивные замашки.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
R>>Хотя, возможно, и наличие только такого одного преобразования будет тоже полезным на практике. Мне сейчас сложно сказать. Что думаешь? Будет оно полезно?
WH>Думаю будет. WH>Иногда нужно кучерявым образом инициализаровать некий кучерявый объект который после инициализации никогда не будет меняться. WH>Например хештаблици таки заруливают деревья по скорости.
Хороший пример. В одном императивном языке, не будем называть имён, часто делается так:
И тут действительно происходит неявное преобразование unique -> const. И оно действительно всегда безопасно. Хотя, конечно, ответственность, что объект был действительно unique тут лежит на программисте.
Здравствуйте, WolfHound, Вы писали:
R>>Как компилятор побъет эту матрицу для независимой обработки потоками?
WH>Как угодно. WH>Если сцена неизменяемая и расчет пикселея не завист от соседей то можно делать что угодно. WH>Ибо значение пикселя это функция от сцены, камеры и координат пикселя.
В том-то и дело, что можно. Можно, но не нужно.
R>>Бить её квадрантами или широкими горизонтальными или вертикальными линиями очень не хорошо. Т.к. при ray-tracing'е объем работы сильно зависит от изображения, соотв., если мы будем бить широкими горизонтальными полосами, мы получим, что объем работы для обработки верхней полосы, где небо, будет в 100 раз меньше, чем объем работы для нижней полосы, где несколько детализированных моделей деревьев. Соотв. бить надо в зависимости от задачи, например очень узкими горизонтальными полосами, и каждому потоку достается множество полос, удовлетворяющее (stripe_index % thread_count == thread_index).
WH>fork/join + work stealing
Т.е. ты просто предлагаешь ввести типы шедулинга, как в OpenMP — static, dynamic etc.
Ну в принципе для данной конкретной задачи это сработает.
Ну хорошо зайду с другой стороны — а зачем тогда вообще возможность явного тридинга и возможность передавать что-то между потоками? Видимо, что бы программист мог реализовать что-то сам, чего не умеет язык/ран-тайм. Раз так, значит должна быть соотв. поддержка. Какая например поддержка видно из вышеприведенного примера — например, указывать доступ к массиву на уровне элементов. Или давать доступ к объекту как к pure, а потом как к mutable, а потом опять как к pure.
WH>>В принципе если ввести аналог С++'ного const для методов uniqueness типа то можно сделать преобразование uniqueness -> pure при условии что у pure варианта можно будет трогать только const методы. WH>>Обратная трансформация невозможна.
R>Мне кажется, что наличие только одного этого преобразования не добавляет много к языку, из-за... однобокости... и ограниченности. Т.е. хотелось бы чего-то более... как сказать... мощного. Можно ли ещё что-то добавить? R>Хотя, возможно, и наличие только такого одного преобразования будет тоже полезным на практике. Мне сейчас сложно сказать. Что думаешь? Будет оно полезно?
Менее однобокий вариант: Lazy Functional State Threads.
В двух словах: описаны примитивы для работы с изменяемыми переменными/массивами (вида newVar, newArray, readVar, writeVar), и показано, как гарантировать, что выражение 'runImperative func' компилируется только в том случае, если изменяемые объекты не доступны снаружи func.
Здравствуйте, remark, Вы писали:
WH>>Как угодно. WH>>Если сцена неизменяемая и расчет пикселея не завист от соседей то можно делать что угодно. WH>>Ибо значение пикселя это функция от сцены, камеры и координат пикселя. R>В том-то и дело, что можно. Можно, но не нужно.
Почему не нужно?
R>Т.е. ты просто предлагаешь ввести типы шедулинга, как в OpenMP — static, dynamic etc. R>Ну в принципе для данной конкретной задачи это сработает.
Не предлагаю.
Пусть рантайм сам разбирается.
R>Ну хорошо зайду с другой стороны — а зачем тогда вообще возможность явного тридинга и возможность передавать что-то между потоками?
Есть разные задачи.
Например http сервер. Вот ему очень нужен явный трединг.
А числомолотилкам он вреден.
R>Видимо, что бы программист мог реализовать что-то сам, чего не умеет язык/ран-тайм. Раз так, значит должна быть соотв. поддержка. R>Какая например поддержка видно из вышеприведенного примера — например, указывать доступ к массиву на уровне элементов.
Все несколько не так.
Данная механика уневерсальна для любых pure данных.
Ибо в их случае всегда легко прослеживается зависимость по данным.
R>Или давать доступ к объекту как к pure, а потом как к mutable, а потом опять как к pure.
Вот этого небудет.
Ибо неверефицируемо.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, palm mute, Вы писали:
PM>Менее однобокий вариант: Lazy Functional State Threads.
Не-не-не. palm mute Не-не-не.
Это гораздо более однобокий вариант.
Например в их системе невозможен обмен между потоками. Все что они умеют это передать в поток кучу pure данных и дождаться пока он вернет другую кучу pure данных.
Для реальных применений этого недостаточно.
А всякие interleaveST разрушают все доказательства.
Что совсем приговор.
Мой подход этим не страдает.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Добавлю:
R>Интересно а какой производительности можно добиться для таких аппаратных примитивов синхронизации? Понятно, что можно сделать более специализировано, чем кэш, но фактор расстояния всё равно остаётся...
Кеш — это память, она не умеет делать простейших операций, типа декремента или проверки значения на 0, например. Поэтому дёргается АЛУ, со всеми прелестями типа доп. загрузки аппаратного шедуллера, срыва конвеера и т.д. Использовать сверхсложное АЛУ для обслуживания примитивов синхронизации — это из пушки по воробьям, т.к. для реализации аппаратного примитива синхронизации нужен лишь банальный аппаратный счётчик. Добавить десяток-другой тысяч их в современный проц ничего не стоит. Далее, было бы неплохо иметь довольно большой общий файл регистров, в котором можно было бы хранить состояния регистров конкретного потока с той целью, чтобы при вытеснении потока не копировать состояния регистров во внешнюю память, и не загружать оттуда сохранённое состояние. Все эти переключения потоков должны происходить аппаратно в течении одного такта (и то, аналогия "переключения" не совсем верна).
Насколько эффективна такая системы мы все давно знаем, за счёт увеличения внутреннего файла регистров и небольшого усложнения шедуллера, который завязан и на задержки (пока что лишь) доступа к памяти, интеловские процы умудряются из одного ядра делать практически два, за счёт исполнения 2-х потоков, и всего-навсего достаточно мгновенного переключение потоков для такого фокуса (повторюсь, "переключение" — это не совсем верно, для случая, когда два или более конвеера АЛУ работают одновременно). Ведь мы имеем более чем одно целочисленное АЛУ и обычно более чем одно для плавающей запятой, т.е. суть в том, что понятия "многоядрный" и "многопоточный" малость сливаются в одно.
Я себе так представляю действительно многоядерный/многопоточный процессор:
— несколько потоков исполнения, т.е. просто большой файл внутренних регистров
— приличное кол-во блоков АЛУ
— шедуллер, который управляет потоками и загрузками АЛУ
Т.е. схема принципиально не сильно будет отличаться от нынешней, где на одном ядре выполняется два потока. Если же добавить шедуллеру еще примитивы синхронизации (а не только те, которые отвечают за готовность линеек кеша), то он так же "мгновенно" будет распределять ресурсы, исходя из логики ожиданий этих доп. примитивов, на которых строится уже прикладная логика управления потоками.
Помимо этого в процах есть еще логика по дешифровке кодов команд, переименованию регистров, спекулятивное выполнение и т.д. Но мне кажется, что таких блоков может быть гораздо меньше, чем потоков, учитывая, что потоки могут приличную часть времени проводить в ожидании загрузки кеша, или же в ожидании сигналов от наших гипотетических доп. прикладных примитивов синхронизации.
Здравствуйте, remark, Вы писали:
R>А теперь допустим, что матрица — это у нас изображение. Которое мы обсчитываем путем ray-tracing'а.
Плохой пример. При рейтрейсинге обрабатываемые данные не меняются, и никакой синхронизации не нужно, а меняющийся выхлоп ничтожно мал по сравнению с перевариваемыми объемами.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, vdimas, Вы писали:
R>>Интересно а какой производительности можно добиться для таких аппаратных примитивов синхронизации? Понятно, что можно сделать более специализировано, чем кэш, но фактор расстояния всё равно остаётся... R>>Кстати, а как быть с многопроцессорными системами? Надо ещё какой-то отдельный канал между процессорами и специальный протокол для этих целей...
V>Никак, речь шла о многоядерных. Передавать поток с одного многоядерного процессора на другой — это моветон, ИМХО.
По крайней мере современные многоядерные процессоры Intel/AMD позволяют многопроцессорные конфигурации. И значительная часть серверов именно несколько-процессорная. Что-то не увязывается...
Здравствуйте, vdimas, Вы писали:
R>>Интересно а какой производительности можно добиться для таких аппаратных примитивов синхронизации? Понятно, что можно сделать более специализировано, чем кэш, но фактор расстояния всё равно остаётся...
V>Кеш — это память, она не умеет делать простейших операций, типа декремента или проверки значения на 0, например. Поэтому дёргается АЛУ
Не очень понятно, а в чём проблема дергать АЛУ? АЛУ — это ж самая быстродействующая и, зачастую, недозагруженная часть системы. Если считать, что АЛУ может выдавать 3 команды за такт, а на перемещение кэш-линии тратится 200 тактов, то доля АЛУ тут получается менее 1%. Плюс к этому, примерно в 50% случаев обращение к примитиву синхронизации связано с проверкой, т.е. это ветвление, т.е. конвеер в любом случае должен быть осведомлен об этой операции, выполнять её полностью в разрыве с АЛУ не видится возможным.
А вот сам специализированный и мелко-гранулярный счетчик не помешало бы иметь... Если бы его можно было реализовать значительно быстрее, чем протокол когерентности общего назначения. Я в этом не большой специалист, но я думаю, что с доступом к одному счетчику из раных ядер должны быть определенные проблемы (например, синхронизация частот). Ну и по прежнему не понятно, как быть с многопроцессорными конфигурациями.
V>Далее, было бы неплохо иметь довольно большой общий файл регистров, в котором можно было бы хранить состояния регистров конкретного потока с той целью, чтобы при вытеснении потока не копировать состояния регистров во внешнюю память, и не загружать оттуда сохранённое состояние. Все эти переключения потоков должны происходить аппаратно в течении одного такта (и то, аналогия "переключения" не совсем верна).
Ну так это ж вроже Sun Niagara/Rock. У них там сколько аппаратных потоков? Вроде 32 было на одном процессоре. И встроенный шедулер. У Intel пока дело дошло только до 2 аппаратных потоков на ядро, но я думаю, что в ближайшем будущем будет больше.
V>понятия "многоядрный" и "многопоточный" малость сливаются в одно.
Для такой схему применяются термины CMT (Chip MultiThreading), HWT (Hardware MultiThreading), HT (HyperThreading). А обобщенный поток исполнения называется Аппаратный Поток Исполнения (Hardware Thread), т.е. это может быть либо процессор, либо ядро, либо поток внутри ядра.
Здравствуйте, WolfHound, Вы писали:
WH>>>Как угодно. WH>>>Если сцена неизменяемая и расчет пикселея не завист от соседей то можно делать что угодно. WH>>>Ибо значение пикселя это функция от сцены, камеры и координат пикселя. R>>В том-то и дело, что можно. Можно, но не нужно. WH>Почему не нужно?
R>>Т.е. ты просто предлагаешь ввести типы шедулинга, как в OpenMP — static, dynamic etc. R>>Ну в принципе для данной конкретной задачи это сработает. WH>Не предлагаю. WH>Пусть рантайм сам разбирается.
Не нужно, потому что, я в это не верю, это, блин, какой-то rocket science.
Это должна быть монсторская система, которая на основе само-рефлексии занимается само-твикингом. Тут гарантированно есть 2 недетерминированных фактора — входные данные и загрузка системы сторонними приложениями. Т.е. помимо монсторского алгоритмы, тут нужна выборка репрезентативных приложений и пара лет ручного твикинга параметров. И даже если это будет сделано, сомнительно, что это имеет смысл перед ручным анализом и реализацией алгоритма, которая может занять порядка нескольких дней.
R>>Ну хорошо зайду с другой стороны — а зачем тогда вообще возможность явного тридинга и возможность передавать что-то между потоками?
WH>Есть разные задачи. WH>Например http сервер. Вот ему очень нужен явный трединг. WH>А числомолотилкам он вреден.
Т.е. тут твой тезис, что для "http сервера" будут не нужны такие вещи как контроль доступа на уровне элементов массива, и изменение pure/mutable в ран-тайм? Ну что ж, возможно, это вполне разумно... В любом случае примера-убийцы у меня нет...
R>>Видимо, что бы программист мог реализовать что-то сам, чего не умеет язык/ран-тайм. Раз так, значит должна быть соотв. поддержка. R>>Какая например поддержка видно из вышеприведенного примера — например, указывать доступ к массиву на уровне элементов.
WH>Все несколько не так. WH>Данная механика уневерсальна для любых pure данных. WH>Ибо в их случае всегда легко прослеживается зависимость по данным.
Но это НЕ достаточное условие для эффективной автоматической реализации. Это лишь необходимое условие!
Здравствуйте, remark, Вы писали:
R>Не нужно, потому что, я в это не верю, это, блин, какой-то rocket science.
Все проще. Нужно просто немного статистики собрать.
А на длинных расчетах статистика наберется уже после пары итераций.
R>Это должна быть монсторская система, которая на основе само-рефлексии занимается само-твикингом.
hotspot...
Только тут все еще проще и круче будет ибо жаба совсем не формализована, а тут куча теорем с доказательствами есть.
R>Тут гарантированно есть 2 недетерминированных фактора — входные данные и загрузка системы сторонними приложениями.
И с тем и с другим (особенно с загрузкой системы) можно разобраться только во время работы программы.
R>Т.е. помимо монсторского алгоритмы, тут нужна выборка репрезентативных приложений и пара лет ручного твикинга параметров. И даже если это будет сделано, сомнительно, что это имеет смысл перед ручным анализом и реализацией алгоритма, которая может занять порядка нескольких дней.
Если таки делать уневерсальный рантайм то несколько человеколет тюнинга многократно окупятся последующим применением.
R>>>Ну хорошо зайду с другой стороны — а зачем тогда вообще возможность явного тридинга и возможность передавать что-то между потоками? WH>>Есть разные задачи. WH>>Например http сервер. Вот ему очень нужен явный трединг. WH>>А числомолотилкам он вреден. R>Т.е. тут твой тезис, что для "http сервера" будут не нужны такие вещи как контроль доступа на уровне элементов массива, и изменение pure/mutable в ран-тайм? Ну что ж, возможно, это вполне разумно... В любом случае примера-убийцы у меня нет...
Нет тезис в том что явный трединг то же нужен.
В случае с http сервером у нас есть куча явных, независимых запросов.
И обрабатывать их удобно в отдельных потоках. Если во время обработки запроса будет удобно запустить еще потоки то так тому и быть.
А возиться с расчетом матрици который может на раз распаралелить рантайм смысла нет.
А если при запросе по http нам приспичило матрици отплющить то рантайм должен эту самую часть запроса сам распаралелить.
R>Но это НЕ достаточное условие для эффективной автоматической реализации. Это лишь необходимое условие!
Согласен.
Но достаточность это дело техники которую в условиях когда у нас все зависимости как на лодоне получить относительно просто.
Это тебе не С++ паралелить.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
R>>Не нужно, потому что, я в это не верю, это, блин, какой-то rocket science. WH>Все проще. Нужно просто немного статистики собрать. WH>А на длинных расчетах статистика наберется уже после пары итераций.
R>>Это должна быть монсторская система, которая на основе само-рефлексии занимается само-твикингом. WH>hotspot... WH>Только тут все еще проще и круче будет ибо жаба совсем не формализована, а тут куча теорем с доказательствами есть.
R>>Тут гарантированно есть 2 недетерминированных фактора — входные данные и загрузка системы сторонними приложениями. WH>И с тем и с другим (особенно с загрузкой системы) можно разобраться только во время работы программы.
R>>Т.е. помимо монсторского алгоритмы, тут нужна выборка репрезентативных приложений и пара лет ручного твикинга параметров. И даже если это будет сделано, сомнительно, что это имеет смысл перед ручным анализом и реализацией алгоритма, которая может занять порядка нескольких дней. WH>Если таки делать уневерсальный рантайм то несколько человеколет тюнинга многократно окупятся последующим применением.
Ну что я могу на всё это сказать... извести, когда это будет работать. Будет очень интересно посмотреть.
R>>>>Ну хорошо зайду с другой стороны — а зачем тогда вообще возможность явного тридинга и возможность передавать что-то между потоками? WH>>>Есть разные задачи. WH>>>Например http сервер. Вот ему очень нужен явный трединг. WH>>>А числомолотилкам он вреден. R>>Т.е. тут твой тезис, что для "http сервера" будут не нужны такие вещи как контроль доступа на уровне элементов массива, и изменение pure/mutable в ран-тайм? Ну что ж, возможно, это вполне разумно... В любом случае примера-убийцы у меня нет... WH>Нет тезис в том что явный трединг то же нужен. WH>В случае с http сервером у нас есть куча явных, независимых запросов. WH>И обрабатывать их удобно в отдельных потоках. Если во время обработки запроса будет удобно запустить еще потоки то так тому и быть. WH>А возиться с расчетом матрици который может на раз распаралелить рантайм смысла нет. WH>А если при запросе по http нам приспичило матрици отплющить то рантайм должен эту самую часть запроса сам распаралелить.
А вот за это по рукам его. Если у нас уже есть достаточный источник параллелизма (а во многих высокопроизводительных серверах "запросы" — это достаточный источник параллелизма, на то они и высокопроизводительные, что запросов у них *много*), то распараллеливать ещё дополнительно на более низком уровне — это исключительно дополнительные накладные расходы. Расходы на work-stealing (или что там выберет умный ран-тайм), и расходы на уменьшение локальности вычислений.
Так что это супер-умный ран-тайм тоже должен будет уметь автоматически определять. Иначе я его на С++ как тузик грелку
R>>Но это НЕ достаточное условие для эффективной автоматической реализации. Это лишь необходимое условие! WH>Согласен. WH>Но достаточность это дело техники которую в условиях когда у нас все зависимости как на лодоне получить относительно просто.
Так тут дело не только в определении зависимостей, и вообще не в зависимостях. Например смотри абзац выше.
WH>Это тебе не С++ паралелить.
А С++ программист и не надеятся на дядю со счётами, что бы он распараллелил; и на тётю с совком тоже не надеятся
Здравствуйте, remark, Вы писали:
R>Ну что я могу на всё это сказать... извести, когда это будет работать. Будет очень интересно посмотреть.
Будет.
R>А вот за это по рукам его.
Не надо.
R>Если у нас уже есть достаточный источник параллелизма
Уерен что достаточнй?
R>(а во многих высокопроизводительных серверах "запросы" — это достаточный источник параллелизма, на то они и высокопроизводительные, что запросов у них *много*),
Я такие системы и пишу.
R>то распараллеливать ещё дополнительно на более низком уровне — это исключительно дополнительные накладные расходы. Расходы на work-stealing (или что там выберет умный ран-тайм), и расходы на уменьшение локальности вычислений.
Так вот там где хватает там на низком уровне ничего не распаралелить.
А там где нет...
Я у себя давно хочу распаралелить интерпретатор (накладные расходы на интерпретацию в данном случае ничтожны) одного язычка нарисованного под задачу да только руки не доходят.
А вот еслиб оно само могло... то я бы изначально все написал так что бы рантайм сам все сделал.
R>Так что это супер-умный ран-тайм тоже должен будет уметь автоматически определять.
Вот он то это проделать сможет. В отличии от С++ника...
R>Иначе я его на С++ как тузик грелку
Ну-ну.
R>А С++ программист и не надеятся на дядю со счётами, что бы он распараллелил; и на тётю с совком тоже не надеятся
Ага. Он тупо воюет с ужасной моделью языка и тупейшим рантаймом... ядро линуха от любого не осторожного движения уходит в нирвану и перестает возвращать управление из сиколов... хорошо что оно иногда от туда возвращается.
С другими ОСями таже фигня.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
R>>Ну что я могу на всё это сказать... извести, когда это будет работать. Будет очень интересно посмотреть. WH>Будет.
Что "будет"? Будет работать? Или будет интересно посмотреть?
R>>А вот за это по рукам его. WH>Не надо.
А кого тогда, если не его?
R>>Если у нас уже есть достаточный источник параллелизма WH>Уерен что достаточнй?
Полностью. Для производительных/нагруженных OLTP или Web систем это будет так.
R>>(а во многих высокопроизводительных серверах "запросы" — это достаточный источник параллелизма, на то они и высокопроизводительные, что запросов у них *много*), WH>Я такие системы и пишу.
R>>то распараллеливать ещё дополнительно на более низком уровне — это исключительно дополнительные накладные расходы. Расходы на work-stealing (или что там выберет умный ран-тайм), и расходы на уменьшение локальности вычислений.
WH>Так вот там где хватает там на низком уровне ничего не распаралелить.
Как же ничего не распараллелить? Если применить анализ по данным/управлению, то мы везде найдём столько распараллелить, что мало не покажется.
WH>А там где нет...
Ну естественно есть приложения, где и на обоих уровнях имеет смысл распараллеливать. Например, OLAP. Но речь о тех приложениях, где достаточно.
WH>Я у себя давно хочу распаралелить интерпретатор (накладные расходы на интерпретацию в данном случае ничтожны) одного язычка нарисованного под задачу да только руки не доходят. WH>А вот еслиб оно само могло... то я бы изначально все написал так что бы рантайм сам все сделал.
Ну что ж, осталось только подождать выхода магического ран-тайма, и уж тогда никаких проблем не будет — "оно само там как-то магически всё будет".
R>>Так что это супер-умный ран-тайм тоже должен будет уметь автоматически определять. WH>Вот он то это проделать сможет. В отличии от С++ника...
Как бы он только не начал все запросы в одном потоке обрабатывать, а "мясо" запросов по другим потокам разбрасывать
R>>Иначе я его на С++ как тузик грелку WH>Ну-ну.
Ну я пока на кошках потренируюсь
R>>А С++ программист и не надеятся на дядю со счётами, что бы он распараллелил; и на тётю с совком тоже не надеятся WH>Ага. Он тупо воюет с ужасной моделью языка и тупейшим рантаймом...
R>По крайней мере современные многоядерные процессоры Intel/AMD позволяют многопроцессорные конфигурации. И значительная часть серверов именно несколько-процессорная. Что-то не увязывается...
Думаю, что шедуллер должен учитывать многоядерность, и передавать поток с проца на проц только при необходимости. Просто сейчас "многоядерность" какя-то маленькая, а мои рассуждения были для заметного кол-во ядер в процессоре, иначе и смысла в этих аппаратных примитивах будет не много.
Да и вообще, всяко лучше иметь некое кол-во ядер на одном кристелле, чем такое же их суммарное кол-во, раскиданное по разным процам.
Здравствуйте, remark, Вы писали:
V>>Кеш — это память, она не умеет делать простейших операций, типа декремента или проверки значения на 0, например. Поэтому дёргается АЛУ
R>Не очень понятно, а в чём проблема дергать АЛУ? АЛУ — это ж самая быстродействующая и, зачастую, недозагруженная часть системы. Если считать, что АЛУ может выдавать 3 команды за такт,
3 команды сложения за такт означают наличие 3-х сумматоров, например.
R>а на перемещение кэш-линии тратится 200 тактов, то доля АЛУ тут получается менее 1%.
В том-то и дело, что сейчас счётчики примитивов надо еще в кеш предварительно загружать.
R> Плюс к этому, примерно в 50% случаев обращение к примитиву синхронизации связано с проверкой, т.е. это ветвление,
Для встроенного примитива не должно быть ветвления, кроме случаев таймаута (т.е. постпроверки — по таймауту прошли примитив или нет). Для семафора/мьютекса/события должна быть просто некая команда wait #sync безо-всяких ветвлений. "Ветвление" должен делать шедуллер, путём распределения загрузок внутренних блоков. С предпросмотром тоже всё нормально — ведь шедуллер может посмотреть — будет в ближайшие несколько тактов изменяться данный примитив в других потоках, или нет (напомню, я считаю всю эту схему эффективной только при возможности хранить состояния приличного кол-ва потоков в процессоре). Если примитив в сигнальном состоянии, и шедуллер в видимой последовательности команд в других потоках не обнаруживает операций с этим примитивом, то на выполнение команды wait должно тратиться ровно 0 тактов.
R>А вот сам специализированный и мелко-гранулярный счетчик не помешало бы иметь... Если бы его можно было реализовать значительно быстрее, чем протокол когерентности общего назначения. Я в этом не большой специалист, но я думаю, что с доступом к одному счетчику из раных ядер должны быть определенные проблемы (например, синхронизация частот).
Как раз аппаратно логика атомарного управления строится легко. Какая может быть проблема с синхронизацией внутри проца? Там общая синхронизация для всех ядер. Если в течении одного гипотетического такта несколько команд пытаются _изменять_ примитив, то изменяет пусть только один, остальные задействованные пусть задерживаются на такт (и кстати, шедуллер заранее может спланировать потоки так, чтобы не пришлось иметь доступ в течении одного такта разным потокам). А вот параллельное чтение может проводиться одновременно несколькими потоками.
R>Ну и по прежнему не понятно, как быть с многопроцессорными конфигурациями.
Пусть остануться только для суперкомпьютеров. Как уже сказал рядом, всяко эффективней всё необходимое кол-во ядер иметь на одном проце.
V>>Далее, было бы неплохо иметь довольно большой общий файл регистров, в котором можно было бы хранить состояния регистров конкретного потока с той целью, чтобы при вытеснении потока не копировать состояния регистров во внешнюю память, и не загружать оттуда сохранённое состояние. Все эти переключения потоков должны происходить аппаратно в течении одного такта (и то, аналогия "переключения" не совсем верна).
R>Ну так это ж вроже Sun Niagara/Rock. У них там сколько аппаратных потоков? Вроде 32 было на одном процессоре. И встроенный шедулер. У Intel пока дело дошло только до 2 аппаратных потоков на ядро, но я думаю, что в ближайшем будущем будет больше.
Угу.
V>>понятия "многоядрный" и "многопоточный" малость сливаются в одно.
R>Для такой схему применяются термины CMT (Chip MultiThreading), HWT (Hardware MultiThreading), HT (HyperThreading). А обобщенный поток исполнения называется Аппаратный Поток Исполнения (Hardware Thread), т.е. это может быть либо процессор, либо ядро, либо поток внутри ядра.
Именно что логический поток внутри ядра. ИМХО, за этим будущее многоядерных процов, т.е. вместо выделенных ядер внутри проца будет просто большой внутренний файл регистров и приличное кол-во разделяемых выч. ресурсов, например, тот же АЛУ — это не монолит, сумматоры, умножители и делители — это физически разные исполняющие блоки. Простых блоков АЛУ (которые только суммируют и оперируют с битами) может быть вообще неограниченное кол-во, они очень примитивны. Ведь не думаешь ты, что для банального ветвления по знаку операции (например) надо результат операции грузить в выделенное устройство? Всё проще, после сумматора ветвление происходит по результату регистра сумматора, после умножения — по его выходному регистру и т.д.
Да, ты еще упоминал в предыдущих сообщениях проблему расстояний (внутри кристалла, правильно?) Эта проблема есть давно, обсуждалась еще на подходе к 200МГц и её обещают в конце концов решить многослойной структурой, т.е. будуще за 3D. В конце-концов, печатные платы несколько десятилетий оставались односторонними, потом еще несколько — двусторонними, а последние несколько — в основном многослойные.
Да и вообще, кеш второго уровня должен стать единственным (или даже превратиться в обычную ОП на кристалле), а первого — слиться в экстазе с общим файлом регистров (т.е. быть непосредственно доступен логике шедуллера поячеечно).
Здравствуйте, vdimas, Вы писали:
R>>По крайней мере современные многоядерные процессоры Intel/AMD позволяют многопроцессорные конфигурации. И значительная часть серверов именно несколько-процессорная. Что-то не увязывается...
V>Думаю, что шедуллер должен учитывать многоядерность, и передавать поток с проца на проц только при необходимости....
Может не быть никакой передачи вообще. Просто 2 потока изначально работают на разных процессорах и обращаются к одному примитиву синхронизации. Как тут быть?
V>Да и вообще, всяко лучше иметь некое кол-во ядер на одном кристелле, чем такое же их суммарное кол-во, раскиданное по разным процам.
Лучше-то может оно и лучше, только к жизни не имеет отношения...
