OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 07:27

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 18 ] 
Автор Сообщение
СообщениеДобавлено: Пятница, 24 Июнь, 2011 22:46 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
(модератор) выделено: viewtopic.php?p=63851#p63851
O.Nick писал(а):
менеджер памяти корректно с несколькими потоками работает или ,,,
Это (как и многое другое в "сфере ИТ") следует считать порочной идеей, пока не будет доказано обратное.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Active BlackBox
СообщениеДобавлено: Суббота, 25 Июнь, 2011 15:26 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Info21 писал(а):
O.Nick писал(а):
менеджер памяти корректно с несколькими потоками работает или ,,,
Это (как и многое другое в "сфере ИТ") следует считать порочной идеей, пока не будет доказано обратное.
Свеженький интерлагос (серверный вариант бульдозера) имеет 16 ядер и устанавливается, кажется, в количестве 4 штук, т.е. 64 ядра на сервер. Не очень свеженький ксеон в максимальной конфигурации имеет 10 ядер и устанавливается в количестве 8 штук на сервер. Итого 80 ядер в сервере. Каждое с гипертредингом, то есть 160 потоков. Есть несколько серверов. Рассмотрим два случая. 1) На каждом сервере запущена одна многопоточная программа. 2) На каждом сервере запущено под сотню однопоточных программ. Программы взаимодействуют друг с другом по TCP. А теперь подумайте сколько TCP соединений между ними должно быть установлено в каждом из этих двух случаев?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Active BlackBox
СообщениеДобавлено: Суббота, 25 Июнь, 2011 17:42 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Сергей Губанов писал(а):
А теперь подумайте сколько TCP соединений между ними должно быть установлено в каждом из этих двух случаев?
159.

Кроме того, TCP это заглушка только на первое время.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Active BlackBox
СообщениеДобавлено: Суббота, 25 Июнь, 2011 21:56 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Большинство суперкомпьютеров работает по TCP, поэтому нет ничего зазорного делать на нем распределенные системы вычислений.

Интересно было бы покопать в сторону привязки к библиотекам для Message_Passing_Interface или OpenMP.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Active BlackBox
СообщениеДобавлено: Суббота, 25 Июнь, 2011 22:23 

Зарегистрирован: Воскресенье, 03 Февраль, 2008 12:50
Сообщения: 249
Иван Денисов писал(а):
Большинство суперкомпьютеров работает по TCP, поэтому нет ничего зазорного делать на нем распределенные системы вычислений.

tcp - там протокол для бедных. Используется только при отсутствии альтернатив (infiniband, myrinet express).

Иван Денисов писал(а):
Интересно было бы покопать в сторону привязки к библиотекам для Message_Passing_Interface или OpenMP.

OpenMP - не библиотека. Это набор директив компилятора. Есть только в компиляторах для сишечки, плюсов и фортрана.
MPI вот библиотека, но даже при возможности сделать к ней привязки, лучше бы дать ей спокойно умереть.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Active BlackBox
СообщениеДобавлено: Суббота, 25 Июнь, 2011 22:38 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
to Info21: Я не понял Вашего ответа.

to Иван Денисов: Сетевыми картами (не важно по какому протоколу) связываются платы, а не отдельные ядра. На одной плате установлено под сотню ядер работающих с памятью этой платы. Вот на одной плате на этой "сотне" ядер и имеет смысл запустить всего одну многопоточную программу, а не "сто" однопоточных.

Есть же ещё другой момент: Большие Общие Данные. Одна многопоточная программа расходует меньше памяти чем несколько однопоточных программ если у них большой объём одинаковых общих данных.

Пример: копия базы данных абонентов телефонной станции для ускорения работы целиком всосанная в оперативку (для 100'000 абонентов примерно 0.5 Гб).

Кстати, когда я писал первое сообщение, то имел ввиду не суперкомьютеры, а обычные серверы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Active BlackBox
СообщениеДобавлено: Суббота, 25 Июнь, 2011 22:48 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
to info21 Раз уж суперкомпьютерные железячники ставят одну сетевую карту на одну плату с "сотней" ядер (а не к каждому ядру по сетевухе), то и нам, софтовикам, у них бы пример брать: Чем больше ядер сможешь окучить внутри одной программы тем лучше, и лишь остальное через сеть.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Active BlackBox
СообщениеДобавлено: Воскресенье, 26 Июнь, 2011 11:21 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Сергей Губанов писал(а):
to info21 Раз уж суперкомпьютерные железячники ставят одну сетевую карту на одну плату с "сотней" ядер (а не к каждому ядру по сетевухе), то и нам, софтовикам, у них бы пример брать: Чем больше ядер сможешь окучить внутри одной программы тем лучше, и лишь остальное через сеть.
Математика учит о важности теорем существования.

Возможно, это просто тупик.
Железячники ставят, потому что могут поставить.
А пипл хавает, надеясь, что с софтом уж как-нибудь -- мы же гении контуперные -- справимся.

Софтовикам не пример нужно брать у железячников, потому что это не пример вовсе, а думать головой.

"Одна программа" всё равно будет как-то структурирована под процессоры.
Элементарная процедура выполняется все-таки обычно на одном ядре.
Просто нужно, чтобы то, что сидело на одном ядре, было как можно легковесней -- как Оберон, а не как типичная ось.

И еще. Нужна, видимо, какая-то поддержка со стороны железа. Но какая -- можно выяснить только "сверху вниз", т.е. с уровня софта.

А TCP в суперкомпах по-особому реализованный. Так что...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Active BlackBox
СообщениеДобавлено: Понедельник, 27 Июнь, 2011 10:07 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Сергей Губанов писал(а):
Кстати, когда я писал первое сообщение, то имел ввиду не суперкомьютеры, а обычные серверы.

Если обычные серверы, то там многопоточность по большей части нужна для параллельной обработки нескольких запросов, а взаимодействие между ними фактически идёт через базу данных. Правда, многопоточную базу данных тоже кто-то должен написать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Active BlackBox
СообщениеДобавлено: Понедельник, 27 Июнь, 2011 11:21 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
to Info21 Понятно. Вы немного не в теме. Идеологически правильная многопоточная программа логически организуется точно так же как несколько взаимодействующих через очереди сообщений однопоточных программ. Каждая процедура разумеется выполняется в каком-то одном потоке. Разница состоит в том, что в очередь сообщений теперь кладётся не само сообщение, а указатель на него (что на порядки быстрее по скорости), а так же в том, что есть доступные всем для чтения по указателям Большие Общие Данные (что на порядки экономнее по памяти).

to Comdiv Под сервером я имел ввиду не "веб сервер", а многопроцессорный компьютер, железку. А программы выполняемые на нём разные бывают.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Active BlackBox
СообщениеДобавлено: Понедельник, 27 Июнь, 2011 23:45 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Сергей Губанов писал(а):
to Info21 Понятно. Вы немного не в теме.
Не понятно, как Вы это вывели. Вы не сказали ничего, что поразило бы меня новизной.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Active BlackBox
СообщениеДобавлено: Вторник, 28 Июнь, 2011 05:46 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Сергей Губанов писал(а):
Идеологически правильная многопоточная программа логически организуется точно так же как несколько взаимодействующих через очереди сообщений однопоточных программ. Каждая процедура разумеется выполняется в каком-то одном потоке.
Это определяется... точкой зрения. Одна и та же процедура (один и тот же код) может одновременно выполняться во многих потоках. Типичный пример, параллельная обработка массивов данных (или разных частей одного массива). Получается, что если смотреть с точки зрения ядра процессора, то он выполняет одну процедуру, а если смотреть с точки зрения процедуры, то она выполняется на многих ядрах процессоров, во многих потоках. Но, в принципе, Вы пишите совершенно верно.
Сергей Губанов писал(а):
Разница состоит в том, что в очередь сообщений теперь кладётся не само сообщение, а указатель на него (что на порядки быстрее по скорости), а так же в том, что есть доступные всем для чтения по указателям Большие Общие Данные (что на порядки экономнее по памяти).
Строго говоря, эти факторы не всегда дают положительный эффект, ни с точки зрения скорости, ни с точки зрения памяти. Если есть избыточные вычислительные ресурсы (дополнительные ядра), то они могут заниматься оптимизацией очереди и/или распределения памяти (не только для данных, но и памяти выделяемой под задачи/потоки), что позволяет достигать большей производительности и компактности. С другой стороны, размещение указателей вместо сообщений может нарушить изолированность исполнения, что создаст угрозу правильности работы, поскольку, как правило, данные, передаваемые по ссылке, не "обрамляются" "критическими секциями" и т.п. Такие ошибки трудно вылавливать. Другими словами, многопоточность не отменяет решение проблем, связанных с обеспечением изолированности и когерентности, а, следовательно, пользоваться указателями и глобальной памятью надо продуманно и очень аккуратно.

Хорошо, что Вы поднимаете эти вопросы. Для разработчиков, как правило, непривычно смотреть на свои программы со стороны... параллелизма. Одно дело писать алгоритмы, вызывая по мере необходимости подпрограммы, другое дело, писать и оценивать программу, как набор связей между разными частями, каждая из которых в значительной степени [должна быть] автономна по ресурсам. И здесь задача организации и оптимизации совместной и параллельной работы частей... становится труднопреодолимым препятствием для дальнейшего развития.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 28 Июнь, 2011 09:32 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Сергей Губанов, Info21, есть предположение, что ваша полемика основывается на примере слишком разных по техническим требованиям прикладных задач. Будет ли она иметь смысл?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 02 Июль, 2011 00:03 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
alexus писал(а):
Одна и та же процедура (один и тот же код) может одновременно выполняться во многих потоках. Типичный пример, параллельная обработка массивов данных (или разных частей одного массива)

...

Другими словами, многопоточность не отменяет решение проблем, связанных с обеспечением изолированности и когерентности, а, следовательно, пользоваться указателями и глобальной памятью надо продуманно и очень аккуратно

Именно этим я занимаюсь в своих расчётах.
Есть идеи по улучшению ситуации?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 02 Июль, 2011 18:59 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
GameHunter писал(а):
alexus писал(а):
Одна и та же процедура (один и тот же код) может одновременно выполняться во многих потоках. Типичный пример, параллельная обработка массивов данных (или разных частей одного массива)

...

Другими словами, многопоточность не отменяет решение проблем, связанных с обеспечением изолированности и когерентности, а, следовательно, пользоваться указателями и глобальной памятью надо продуманно и очень аккуратно

Именно этим я занимаюсь в своих расчётах.
Есть идеи по улучшению ситуации?
Новых идей нет... Вряд ли они возможны в рамках действующих парадигм. Если возможно (по условию задачи и доступным ресурсам, то можно использовать копии данных для каждого обработчика, работающего параллельно, если нет, то сериализуйте доступ к разделяемым данным на основе блокировок (критические секции, mutex, семафоры и пр.))


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 13 Июль, 2011 12:52 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Цитата:
Раз уж суперкомпьютерные железячники ставят одну сетевую карту на одну плату с "сотней" ядер (а не к каждому ядру по сетевухе), то и нам, софтовикам, у них бы пример брать: Чем больше ядер сможешь окучить внутри одной программы тем лучше, и лишь остальное через сеть.

На форуме oberon.talk4fun.net valexey дал ссылку на новость о новой OS Barrelfish, сделанной в ETH Zurich. Если верить тому, что о ней пишут, то для эффективного использования многопроцессорных систем вполне можно ставить по "сетевой карте" на ядро.
Цитата:
От других операционных систем Barrelfish отличается прежде всего тем, что использует совершенно новый подход к проектированию ОС, получивший имя multikernel (мультиядро). Смысл метода в том, чтобы превратить многопроцессорную/многоядерную машину в некое подобие кластера, каждое отдельное процессорное ядро которого будет управляться собственной операционной системой. Достигается это за счет расщепления ядра ОС на множество компактных экзоядер, каждое из которых исполняется на отдельном процессоре/ядре, следит за доступными ему ресурсами и сообщает об изменении своего состояния и готовности к исполнению кода приложений с помощью посылки сообщений другим ядрам. По мнению разработчиков такая архитектура позволит наиболее эффективно использовать ресурсы современных многопроцессорных систем, что довольно красноречиво подтверждается замерами производительности.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 13 Июль, 2011 13:37 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Всё это эксперименты; без реального "профилирования" под задачи трудно понять, во что всё это выльется...
Истерии про гипер-многоядерность много; но история развития техники приводит много примеров, когда восторги и технические возможности ни к чему не приводили; просто идти "более традиционно" оказывалось удобнее.

В принципе, обычные машины и обычное последовательное программирование справляется успешно с кучей задач; эти задачи никуда не денутся -и размерность их тоже не растёт. А те задачи, которые "на грани", размерность которых готова вырасти всегда, как только появится возможность, могут обычно быть отделены в замкнутые подсистемы и уже там решены особыми средствами. Вообще, например, генерацией в топологию ПЛИС. Стоит рядом с компом шкафчик дополнительный... А сам комп самый обычный.

Наконец, обычные машины будут существовать ровно потому, потому что огромное количество софта уже на них работает... Как до сих пор существует линейка мейнфреймов.
А поскольку программировать кучу задач на обычных машинах удобнее, чем на каких-то гипер-параллельных, то её и будут программировать под них... Т.е. они не вытеснятся в зону "обратной совместимости".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 14 Июль, 2011 01:11 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Comdiv писал(а):
для эффективного использования многопроцессорных систем вполне можно ставить по "сетевой карте" на ядро.
Для эффективного нужно одно адресное пространство и пулять объекты по указателям. По сетевухе - для наименее эффективного. "Сетевухи" вылазят как компромис в случае технической невозможности одного пространства.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 18 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB