Многопроцессорность и с чем её едят.
Ну очень коротко и примерно.(Чувствую, не, получится.)
Данная вещь известна и реализована ещё во времена царя Гороха. (В СССР, гдеж ещё то, в начале 80-х.) ЭВМ называлась ПС-2000, разработчик- ИПУ, изготовитель- С-к. Использовалась понятно где и в геологии. Быстро американская разведка сработала- всего 25 лет прошло. Правда до наших ещё далековато- в максимальной конфигурации ПС-2000 имела 64 процессора.
Прикольная была машинка- в каждом процессоре своя собственная память, имея своё собственное центральное АЛУ, работать могла только под управлением ЭВМ СМ-2М( операции ввода-вывода),по формулярам в составе радиоэлектронных компонентов содержала 5кг AU.
У нас в конторе на ней пытались распараллелить обработку видеографической информации, САПРа. Была темка по системе управления базами данных (СУБД). Лично мне надо было оценить\сравнить в отчёте эффективность обработки СУБД на одно и многопроцессорных машинах. У меня получилось, что "многопроцессорность" эффективнее в 0,8-60 раз (на 64 процессорах). Уж больно сильно структура СУБД влияет на возможность распараллелить вычисления. Тормоза возникают при межпоцессорных пересылках, процессоры стоят в очереди, чтобы сдать свои вычисления центральному АЛУ. У меня "огромные" подозрения, что и в других "параллельных" задачах имеются подобные проблемы.
Цитата:
Примечание: Любая задача НЕ получает прирост от добавления ядер в систему, если она не умеет с ними работать.
Но прирост можно получить при запуске несколько таких задач параллельно.
Есть одна "тонкость": программы для "параллельных" машин должны быть написаны на "параллельном" языке программирования. Собственно, наш отдел долгие годы и "создавал" этот "параллельный" язык. Фортран-ПС назывался- язык высокого уровня для прикладных программистов. Человек 30 лет шесть писали, потом ещё до победного глюки ликвидировали.
Вы скажете, что в Микрософт 3000 программистов всё напишут за 1 месяц. Да нет, не напишут. Это не параллельная задача. Может оказаться, что 2999 спецов будут в течении месяца, ничего не делая, ждать окончания работ одного, и т.д.. Потом пойдут тормозные межпроц...межпрограммистные пересылки. Качество продукции Микрософт (особенно новой) всем хорошо известно.
Если по другим темам у меня мыслей не будет, сюда добавлю.
Многопроцессорность и с чем её едят.
Ну очень коротко и примерно.(Чувствую, не, получится.)
Данная вещь известна и реализована ещё во времена царя Гороха. (В СССР, гдеж ещё то, в начале 80-х.) ЭВМ называлась ПС-2000, разработчик- ИПУ, изготовитель- С-к. Использовалась понятно где и в геологии. Быстро американская разведка сработала- всего 25 лет прошло. Правда до наших ещё далековато- в максимальной конфигурации ПС-2000 имела 64 процессора.
Прикольная была машинка- в каждом процессоре своя собственная память, имея своё собственное центральное АЛУ, работать могла только под управлением ЭВМ СМ-2М( операции ввода-вывода),по формулярам в составе радиоэлектронных компонентов содержала 5кг AU.
У нас в конторе на ней пытались распараллелить обработку видеографической информации, САПРа. Была темка по системе управления базами данных (СУБД). Лично мне надо было оценить\сравнить в отчёте эффективность обработки СУБД на одно и многопроцессорных машинах. У меня получилось, что "многопроцессорность" эффективнее в 0,8-60 раз (на 64 процессорах). Уж больно сильно структура СУБД влияет на возможность распараллелить вычисления. Тормоза возникают при межпоцессорных пересылках, процессоры стоят в очереди, чтобы сдать свои вычисления центральному АЛУ. У меня "огромные" подозрения, что и в других "параллельных" задачах имеются подобные проблемы.
Цитата:
Примечание: Любая задача НЕ получает прирост от добавления ядер в систему, если она не умеет с ними работать.
Но прирост можно получить при запуске несколько таких задач параллельно.
Есть одна "тонкость": программы для "параллельных" машин должны быть написаны на "параллельном" языке программирования. Собственно, наш отдел долгие годы и "создавал" этот "параллельный" язык. Фортран-ПС назывался- язык высокого уровня для прикладных программистов. Человек 30 лет шесть писали, потом ещё до победного глюки ликвидировали.
Вы скажете, что в Микрософт 3000 программистов всё напишут за 1 месяц. Да нет, не напишут. Это не параллельная задача. Может оказаться, что 2999 спецов будут в течении месяца, ничего не делая, ждать окончания работ одного, и т.д.. Потом пойдут тормозные межпроц...межпрограммистные пересылки. Качество продукции Микрософт (особенно новой) всем хорошо известно.
Если по другим темам у меня мыслей не будет, сюда добавлю.