OSDev

для всех
Текущее время: 28 мар 2024, 13:02

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




Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: 01 дек 2014, 23:58 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 970
Откуда: Дагоба
SII писал(а):
Лично я вообще не вижу возможности создать универсальную архитектуру "на все случаи жизни". Думается, любая архитектура, подходящая для любых задач, будет более-менее одинаково плохо подходить для этих самых "любых задач".

Тут я, пожалуй, не соглашусь, но это из категории тех идеологических разногласий, которые может разрешить только практика.

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

Удивительная степень совпадения взглядов на эту тему, доходящая порой до совпадения формулировок :mrgreen:.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 02 дек 2014, 01:20 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 970
Откуда: Дагоба
Zealint писал(а):
Вот я и предлагаю задачи общего назначения (офис, видеопроигрыватель) решать на обычном процессоре, а специфические задачи - на специальном дополнительно модуле. То есть когда появляется новая сложная задача, требующая новой архитектуры, мы делаем не весь процессор, а только модуль к нему.

Давайте так порассуждаем. Моё [сильное] утверждение состоит в том, что [почти] все рассматриваемые вами задачи на самом деле не требуют специализированной архитектуры и могут быть эффективно реализованы на ЦП общего применения (не обязательно существующих, к ним у меня тоже серьёзные претензии). Предлагаю взять любую задачу и детально проанализировать её.

Zealint писал(а):
Автоматическое распараллеливание никогда не было и не будет эффективнее ручного, поскольку в ручном можно переписать алгоритм, заведомо заложив в него возможность работать параллельно. Поэтому в моей концепции модули будущей СКА уже будут спроектированы как параллельные, поэтому пользователь, вызывая функции СКА, сразу будет получать параллельную реализацию. ОС же должна грамотно раскидывать уже параллельные модули по нужному числу ядер. То есть в моём понимании задача автоматического распараллеливания должна сводиться к тому, как уже параллельные модули программы грамотно распределить по всей системе: кому-то вот эти 10 ядер, а кому-то вот эти 20 и т. д.

Ааа, вон оно что. Я полагал, у вас есть идея распараллеливания алгоритмов, а не процессов по ядрам. По моей практике, только ручное распараллеливание алгоритма даёт хороший результат.

Zealint писал(а):
В моей практике есть случаи, когда замена алгоритма позволяла увеличить эффективность распараллеливания на десятки тысяч процентов.

Отличный результат!

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


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

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Yoda, Спасибо за столь подробное описание своего видения моих проблем и свою поучительную историю. Приятно, что есть в некоторой степени общее понимание ситуации. В целом, всё понятно, однако некоторые Ваши замечания мне кажутся не до конца аргументированными по отношению ко мне.

Вы пишите, что не будет выигрыша от уменьшения числа операций в архитектуре. Я неявно предполагал, что уменьшение числа операций как раз позволит освободить место и сделать больше регистров, больше схем для независимых арифметических действий. Представьте, что если убрать весь мусор из x86, то на уровне микроархитектуры в тот же объём, наверное, можно будет всунуть ещё пару десятков регистров, увеличить кэш в разы и тогда одна из самых частых операций в моих программах (сумма чисел) будет работать быстрее именно за счёт того, что очень много регистров будут складываться параллельно.

Не совсем понятно замечание по поводу модулярной арифметики. Если мы объединим в одну инструкцию сложение и взятие остатка, то разве не уменьшит это размер самой операции? Разве не станет от этого более эффективно работать кэш команд? И разве не сможет процессор исполнять больше таких независимых команд за одно действие? Я помню Вашу оговорку, что здесь есть смысл только когда количество таких операций большое и находятся не в цикле, иначе ясно, что кэш сразу возьмёт весь цикл и всё влезет. Но есть практика разворачивания циклов. Например, 4 операции в цикле, разворачиваем раза 4, получаем уже 16. В некоторых задачах удаётся разворачивать 8 раз. Хотелось бы и больше, но регистров не хватает, а обращаться к памяти внутри самого жёсткого цикла – это значит убить смысл разворачивания цикла. Да, я знаю, что разворачивать 100 раз нет смысла, но золотую середину можно сдвинуть гораздо дальше её нынешнего положения, если уменьшить размер инструкции и увеличить число регистров.

По поводу генератора простых чисел там не описка. Чтобы выполнить расчёты по модулю, нужны, как правило, простые числа (иногда хватает более слабых ограничений – попарно взаимно простых чисел, но простые более удобны по ряду причин). Почему бы не генерировать их аппаратно? Там я говорил про то, чтобы увеличить размер регистра. Для регистра в 128 бит, например, сгенерировать простое число, затем получить следующее за ним или предыдущее – очень удобно. Как правило, вычисления начинают от максимального большого простого числа, умещающегося в регистр, а затем берут предыдущее, снова предыдущее и т. д., пока число модулей не окажется достаточным. В моих задачах было до десяти тысяч простых чисел. Здесь уже смысл не в скорости, а в удобстве. Программно-то генерируются они и так мгновенно.

Мне почему-то этот стереотип по поводу быстроты аппаратной реализации над программной не кажется столь уж необоснованным. Я вижу это так, действуя по аналогии. Допустим, мы программируем алгоритм, состоящий из нескольких независимых операций А, Б и С. И вдруг оказывается, что у них есть что-то общее (хотя бы даже взятие операторов из памяти), мы это общее «выносим за скобки» - и упрощаем набор действий. Теперь, допустим, есть электронная схема, «зашитая» в процессор. Допустим, есть операции А и Б. Есть отдельная схема для А, есть отдельная схема для Б. Вот, мы решили, что нам нужна операция АБ (сумма + взятие остатка, например). Разве у них совсем нет общих элементов на уровне микроархитектуры? Я не знаю, как в процессоре устроены эти операции, но разве нельзя, посмотрев на схемы внимательно, объединить их в одну? С точки зрения математики, я не вижу такого способа, а с точки зрения электроники? Например, после операции сложения, не помещать промежуточные данные в регистр, чтобы потом вызвать операцию взятия по модулю для этого регистра, а сразу подсоединить выводы сумматора к блоку взятия модуля? Если бы я разбирался в этих схемах, то, может, нашёл бы возможность что-нибудь там упростить при таком объединении двух операций. Знаете, всё-таки я не верю, что эти операции совсем-совсем разные, что у них нет ничего общего. Мой второй аргумент в пользу объединения операций в одну состоит в следующем. Допустим, мы хотим сложить два числа, размером 64 бита. Мы можем вызвать одну команду add на 64-битовыми регистрами, а можем две add / adc над 32-битовыми. Первый способ будет быстрее, но второй, который, как Вы говорите, является комбинацией уже реализованных блоков, будет всё-таки медленнее.

Ещё не до конца ясен момент с размером регистров. Я не понял, каков предел размера регистра для суммы и для умножения (они ведь должны быть разными). С какого размера операция сложения начинает тормозить? А умножения и деления? Здесь тоже есть аналогия с параллельными алгоритмами: часто при сильном увеличении числа ядер алгоритм начинает тормозить из-за квадратичного роста побочных эффектов взаимодействия, потому часто алгоритмист пытается разбить алгоритм на как можно большее число независимых кусочков (пусть даже теряя эффективность алгоритма), так как сумма квадратов меньше чем квадрат суммы (для положительных чисел). Аналогично, операция умножения может иметь квадратичный рост по числу бит. Но можно, например, выполнить один-два шага метода Карацубы, когда оба регистра разбиваются пополам, далее вместо 4-х умножений и сложений этих половинок выполняется только 3 умножения и чуть больше сложений/вычитаний. И вместо квадратичного роста (n^2) мы получаем n^(log_2(3)). То есть вместо квадратичного роста получаем значительно более медленный, что может позволить отодвинуть «тормоза» умножения подальше.

Я понимаю, что Вы имеете в виду, когда говорите, что мой ПМ (процессорный модуль) будет медленно взаимодействовать с ЦП, ведь они будут передавать друг другу данные по медленной шине. Но я предполагаю, что есть способ как-то «близко» подключить ПМ к ЦП, чтобы взаимодействие стало быстрым. Или это невозможно никак? Насколько я понимаю, раньше кэш L3 на многих процессорах был на отдельном кристалле, но он же не тормозил из-за этого. Или я не о том думаю?

Далее буду цитировать.

Цитата:
Компромисс может заключаться в том, что компиляция сейчас - довольно быстрый процесс, а интеграцией компиляции и интерпретации является работа с командной строки, - командный процессор является интерпретатором, но запускает скомпилированную программу.

Собственно, я это и сказал : )

Цитата:
То, что вы сейчас написали, в общем-то и является отличительными чертами хорошей ОС, а никак не отсутствия ОС.< . . . >. Другое дело, что настольные ОС больше ориентированы на обилие свистоперделок, а не на HPC (high performance computing).

Я могу согласиться. Однако вот Вы сами пишите, что современные ОС не ориентированы на HPC. Вот я и думаю, почему бы не сделать сразу ОС и СКА одновременно, чтобы СКА была бы неотъемлемой частью ОС и диктовала бы её развитие. Развивая СКА, мы будем вынуждены развивать ОС, подчиняя её развитие потребностям HCP. Это не обязательно значит, что СКА будет зашита в ОС, а это значит, что развиваться они будут «когерентно». А если я возьму чью-то готовую систему, то кто мне даст гарантии, что наши пути не станут настолько ортогональным, что сила нашего взаимодействия будет разрывать точку её приложения на части? Либо систему должен разрабатывать профессиональный учёный. Что-то такое можно было наблюдать в ОС/2, как мне сказали современники тех событий.

Цитата:
Судя по конфигурации, 80-ядерный кластер не первой свежести. Я могу сказать, что выбор конфигурации - ответственный момент и стоит его учитывать до запуска расчётов.

Да, свежесть была не первой. Но я и сам удивился, ведь наш «научный» центр заказал этот кластер в 2009 году. Сказать, что уже тогда это было ведро с гвоздями – это ничего не сказать. Более того, недавно, буквально год-два назад, наш университет тоже купил ведро с гвоздями, причём подержанное из 90-х! И, что самое безответственное с их стороны, они даже не проконсультировались со мной, как с единственным на тот момент человеком, который мог бы что-то подсказать из своего опыта, хотя именно мою команду собирались на этот кластер посадить. Потом меня выбросили, а ведро с гвоздями теперь ржавеет. Я пытался понять, зачем его купили, и выяснил, что оказывается, в рейтинге вузов есть такой пункт «наличие кластера». Вот руководство и решило выполнить этот пункт. Бестолочи : )

Цитата:
Как, например, поступать в следующей ситуации: мы одной инструкцией складываем два миллионобитных числа и вдруг оказывается, что последняя тысяча бит отсвоплена на диск? Откатывать миллион бит обратно и выкидывать промежуточные результаты? А где хранить почти миллион бит промежуточного результата, если есть вероятность отката операции? Останавливать процессорное ядро, пока другое ядро занимается вводом-выводом? А если во втором ядре при этом тоже случился page fault? В общем, поверьте, предполагаемая гибкость порождает больше проблем, нежели сулит выгоды.

Такой ситуации не может быть, если у нас миллионбитные регистры, значит они сначала полностью загружаются слагаемыми, а затем складываются без проблем. Кроме того, я никогда не пишу программы, которые уходят в своп, вернее, пишу, но стараюсь, чтобы так не происходило. Мне проще получить ошибку «нет памяти» с потерей всех промежуточных данных, что были в ОЗУ, чем останавливать процесс самому. Сама концепция свопа мне как-то не очень нравится. Нужна возможность выделять память так, чтобы помечать её как запрещённую к сбросу на диск и пусть лучше ОС даёт отказ в выделении памяти в таких случаях. В моих задачах своп был всегда равносилен потере времени, так как в этом случае, если программа и так считает месяц, увеличивать это время раз в 40 нет возможности.

По поводу гибкости я могу согласиться. «Резиновый» регистр заводить не обязательно и даже слишком большой тоже, но хотелось бы иметь что-то побольше, чем 64 бита.

Цитата:
А вам продавец в ответ - а какая частота шины? а в каком корпусе нужен модуль, LGA1234 или LBGA4321? А на какое напряжение питания? А для какого поколения ЦП? С вас 3000$ (по тыще за каждый модуль). А когда вы приходите домой, то оказывается, что они не совместимы с вашей материнской платой (хотя исправны) и возврату не подлежат как "технически сложные изделия", тогда вы бежите искать совместимую материнку . Нет уж, увольте, никаких модулей IMHO быть не должно. Надо делать ЦП изначально таким, чтобы задачи любого класса работали на нём хорошо.

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

Допустим, Вы против модулей, а имеет ли смысл создавать тогда мощный процессор, в котором есть «научный сопроцессор», содержащий наборы базовых алгоритмов математики, если эти алгоритмы удастся реализовать более эффективно, чем программно?

Цитата:
Берём отладочную карту с мощным FPGA и PCI-E слотом, устанавливаем в комп и программируем наши функции непосредственно в железе.

Можете ли Вы подробнее описать этот процесс? Где берём и что конкретно делать? Какую дисциплину для повышения квалификации изучать?

Цитата:
Цитата:
Неплохо было бы иметь строковые команды (префикс rep в x86), которые бегут по двум массивам чисел и складывают их с переносом.

Так это уже есть.

Правда? Я гляну в руководство по командам. Не знал, что rep можно использовать в таких случаях.

Цитата:
Вы совсем не правы. 2-3 докторские диссертации - мизерная плата за такую важную работу. Подумайте, например, о том, что счёт за электроэнергию для суперкомпьютера "Ломоносов" составляет порядка миллиона рублей в месяц по оптовым ценам (я даже не беру прочие эксплуатационные расходы) и вы поймёте, что даже 10% экономия - это огромный успех! Небольшие кластеры - совсем не тот рынок, на котором стоит акцентировать своё внимание.

Это вопрос дискуссионный. Дело в том, что более оптимальная программа в нашей научной среде как раз может сожрать ещё больше электроэнергии, и вот почему. Допустим, неопытный исследователь написал программу, которая вычисляет число расстановок N не бьющих друг друга ферзей на доске NxN (последовательность OEIS:A000170) и она с горем пополам работает для N=20 на домашней машине. Исследователь погонял-погонял её неделю на кластере, дошёл, быть может, до N=21 или N=22 и сказал «хватит», пошёл писать магистерскую диссертацию. Более опытный исследователь сделает что-то похожее, тоже погоняет для N=21,22, затем найдет слабое место, перепишет код, будет гонять для N=23,24, устраивая баню в подвале, где стоит «Ломоносов», затем в силу своих способностей разработает алгоритм для N=25,26 (это уже докторская, без шуток), загрузит кластер на полгода (примерно столько и понадобилось для решения этой задачи, правда, на видеокартах, но не суть). В результате, выходит, что способность разрабатывать более эффективные алгоритмы приводит к тому, что электричества тратится гораздо больше : )

Даже экономия на 10% приведёт к тому, что просто будет решаться больше задач в единицу времени, а энергии будет столько же.

Я знаю одну принципиальную схему экономии электроэнергии, которая никогда не будет воплощена руководством ни одного кластера какого-либо российского университета. Схема очень простая и состоит всего лишь из двух пунктов. Руководству следует:
  • перестать заниматься фаллометрией, наращивая мощность только для того, чтобы поддерживать свою позицию в top500 и высокий рейтинг в стране.
  • выгнать нафиг бездельников и тунеядцев, которые, во-первых, изображают видимость научной деятельности, а, во-вторых, многие их задачи легко решаются на ПК.
Поясню свою позицию: некоторое время назад я более-менее регулярно посещал конференции по HPC в России (их тогда было всего 3 ежегодных). Там всегда были представители из МГУ и всегда рассказывали, как они в очередной раз увеличили мощность или что они в очередной раз собираются присобачить туда. Так вот, по их докладам у меня сложилось впечатление, что это и является самым главным научным достижением из года в год. По тем же докладам я сделал вывод, что кластер многим не особо нужен, ряд задач решается обычными руками из плеч на обычном ПК, если не на карманном.

Цитата:
Цитата:
Либо изобретать принципиально другую архитектуру ЭВМ или даже другую математику.


Есть конкретные идеи?

Нет вообще. Но есть некоторая критика. Современная математика не всегда хорошо подходит для некоторых задач. Не хватает каких-то её расширений на те области, которыми я занимался. Там почти ни одна задача не может быть по-человечески решена математическими методами. Могу привести пример, в котором на протяжении лет 40 вроде бы считалось, что задача решена, однако впоследствии были показаны две причины, по которым полученная формула, читать и понимать которую довольно трудно, оказалась неподходящей для правильных выводов и давала неправильную асимптотику. Одна причина была показана из физических соображений лет 15 назад, а вторая, более «математичная», – в моей диссертации (в одной из глав). Но не знаю, надо ли печатать здесь эту чудовищную штуковину из многократный интегралов, которую вряд ли кто-то будет серьёзно разбирать : )

А так, идей нет, как можно расширить математику на те случаи, когда не существует никаких способов записать аналитическую формулу правильно.

Цитата:
Давайте так порассуждаем. Моё [сильное] утверждение состоит в том, что [почти] все рассматриваемые вами задачи на самом деле не требуют специализированной архитектуры и могут быть эффективно реализованы на ЦП общего применения (не обязательно существующих, к ним у меня тоже серьёзные претензии). Предлагаю взять любую задачу и детально проанализировать её.

Так видите ли, в чём дело, я согласен, что решить можно эффективно, но вопрос в том, что подразумевать под эффективностью. Я просто уверен, что если бы, с кажем, в процессоре было бы раз в 10 больше регистров и сумматоров, было бы ещё эффективнее. А если бы (если) аппаратная реализация суммы по модулю оказалась быстрее пары команд, то эффективность возросла бы ещё.

Не обязательно брать мою задачу, чтобы получился пример. Возьмите задачу подсчёта числа единичных бит в байте, слове, двойном слове и т. д. Эта процедура распадается на несколько более простых базовых команд. Однако же в SSE 4.2 всё-таки затем ввели аппаратную инструкцию, которая выполняет данное действие. Вряд ли они ввели бы её, не будь она более эффективной.

Цитата:
Ааа, вон оно что. Я полагал, у вас есть идея распараллеливания алгоритмов, а не процессов по ядрам. По моей практике, только ручное распараллеливание алгоритма даёт хороший результат.

Да, но и тут не всё так просто, как может показаться сначала. Допустим, пользователь ввёл команду, которая распадается на ряд других команд. Причём для каждой из них известно, на скольких ядрах она эффективно работает (кто-то только на 2, кто-то на 200). Задача в том, чтобы правильно распределить команды по ядрам, чтобы самая медленная программа выполнилась бы как можно быстрее. Причём некоторые команды могут хорошо исполняться только на одном узле кластера (процессоры близко), а некоторые другие могут исполняться хоть в разных странах. Особенно трудно что-то сказать, когда нельзя однозначно определить заранее время работы команды. Тут нужны какие-то эвристики и какой-то способ запоминания. Система запоминает, как долго та или иная команда с теми или иными параметрами работает на том или ином числе ядер и как как бы обучается, чтобы в следующий раз эту информацию использовать. Это не совсем самообучающийся ИИ, а просто таблица данных для задачи сетевого планирования, чем полнее таблица, тем более оптимальным будет план. Других идей пока нет.


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

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Himik писал(а):
Ну при чём здесь GCC, он ведь работает только во время компиляции.

Так а кто будет компилировать мою СКА?

Цитата:
И что за мощные сервера такие, что на GCC не хватает памяти, требуется всего 256МБ.

Не сервера мощные, а программы такие. Есть программы, пытаясь скомпилировать которые GCC сжирала 4 Гб оперативки, уходила в своп и там тихо умирала. Программы очень сложные: там были циклы, вложенные друг в друга до 6 раз, внутри которых несколько тысяч строк сложных инструкций, каждая из которых состояла из полутора десятков умножений.

Цитата:
2. Я полагаю, гарантии качества вам могут дать только производители ОС.

Казалось бы, гарантии качества того же Maple, должны давать разработчики Maplesoft. Однако, сколько бы раз я не заходил на сайт ошибок Maple, их там как было пять с половиной тысяч, так и осталось. Аналогично, я с трудом поверю, что разработчики ОС, которые ещё дальше от науки, будут поддерживать нужное именно мне качество. Я могу ошибаться, потому и продолжаю искать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 02 дек 2014, 23:52 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1126
Цитата:
Мне почему-то этот стереотип по поводу быстроты аппаратной реализации над программной не кажется столь уж необоснованным. Я вижу это так, действуя по аналогии. Допустим, мы программируем алгоритм, состоящий из нескольких независимых операций А, Б и С. И вдруг оказывается, что у них есть что-то общее (хотя бы даже взятие операторов из памяти), мы это общее «выносим за скобки» - и упрощаем набор действий. Теперь, допустим, есть электронная схема, «зашитая» в процессор. Допустим, есть операции А и Б. Есть отдельная схема для А, есть отдельная схема для Б. Вот, мы решили, что нам нужна операция АБ (сумма + взятие остатка, например). Разве у них совсем нет общих элементов на уровне микроархитектуры? Я не знаю, как в процессоре устроены эти операции, но разве нельзя, посмотрев на схемы внимательно, объединить их в одну? С точки зрения математики, я не вижу такого способа, а с точки зрения электроники? Например, после операции сложения, не помещать промежуточные данные в регистр, чтобы потом вызвать операцию взятия по модулю для этого регистра, а сразу подсоединить выводы сумматора к блоку взятия модуля? Если бы я разбирался в этих схемах, то, может, нашёл бы возможность что-нибудь там упростить при таком объединении двух операций. Знаете, всё-таки я не верю, что эти операции совсем-совсем разные, что у них нет ничего общего. Мой второй аргумент в пользу объединения операций в одну состоит в следующем. Допустим, мы хотим сложить два числа, размером 64 бита. Мы можем вызвать одну команду add на 64-битовыми регистрами, а можем две add / adc над 32-битовыми. Первый способ будет быстрее, но второй, который, как Вы говорите, является комбинацией уже реализованных блоков, будет всё-таки медленнее.

Объединить можно, но согласно математики |A+B|<=|A|+|B|
Т.е если вы объедините то не факт что скорость повысится.
Во вторых операции зависимые. Поэтому вычисления второй части будут по завершению первой. ||A|+B|<=|A|+|B|
Так что ускорения получить трудно.
В третьих вычисления не идут мгновенно. Всякие электрические элементы обладают емкостью. Т.е имеет задержку срабатывания подобно конденсатору.
Для единичного транзистора при своевременных технологиях можете считать 300 ГГц. Теперь возьмем And-Or-Xor, Not - уже около 100 ГГц а потом возьмем сложение. Допустим это сумматор допустим тривиальный алгоритм с переносом. В таком сумматоре задержка распростроняется от разряда к разряду и требуется 2 логических операции для вычисления. Для регистра в 32 имеем частоту процессора 1.56 ГГц Для 64 соотвественно частота 0.78 ГГц для 128 ещё меньше.
Конечно тривиальный алгоритм с переносом никто не использует а используют параллельные операции
Для 64 бит имеем 6-8 ГГц* Плюс флаги надо вычислять и другие заморочки.
А вот 128 бит регистры неудобны так как паралелить двойками нельзя только четвёрками.
Это так на пальцах не судите строго если в цифрах ошибся не очень хорошо помню все схемы.


Цитата:
Я понимаю, что Вы имеете в виду, когда говорите, что мой ПМ (процессорный модуль) будет медленно взаимодействовать с ЦП, ведь они будут передавать друг другу данные по медленной шине. Но я предполагаю, что есть способ как-то «близко» подключить ПМ к ЦП, чтобы взаимодействие стало быстрым. Или это невозможно никак? Насколько я понимаю, раньше кэш L3 на многих процессорах был на отдельном кристалле, но он же не тормозил из-за этого. Или я не о том думаю?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 03 дек 2014, 00:56 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1088
Откуда: Балаково
Zealint писал(а):
Так а кто будет компилировать мою СКА?

Ну допустим секретарша на своей пишущей машинке с 32ГБ памяти. Обязательно на сервере что ли? Ну а если серьёзно, программу лучше разбить на части, т.к. компиляторы на сложных конструкциях не могут эффективно распределять регистры под переменные. Распределите свои циклы по отдельным процедурам, а процедуры по отдельным файлам. Тогда каждый по отдельности скомпилируется на нескольких мегабайтах памяти и будет хорошо оптимизирован.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 03 дек 2014, 11:06 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
Zealint писал(а):
Я неявно предполагал, что уменьшение числа операций как раз позволит освободить место и сделать больше регистров, больше схем для независимых арифметических действий. Представьте, что если убрать весь мусор из x86, то на уровне микроархитектуры в тот же объём, наверное, можно будет всунуть ещё пару десятков регистров, увеличить кэш в разы и тогда одна из самых частых операций в моих программах (сумма чисел) будет работать быстрее именно за счёт того, что очень много регистров будут складываться параллельно.


Вы заблуждаетесь просто глубочайшим образом. Львиную долю площади кристалла современных мощных процессоров занимает именно кэш, поэтому сколько-нибудь значительно его нарастить не удастся. Поддержка же всякого мусора архитектуры IA-32 (а эта архитектура -- действительно одна из самых ужасных) требует лишь мизерных дополнительных затрат аппаратуры по сравнению с общим объёмом последней. Соответственно, ни о каком сколько-нибудь значительном выигрыше в производительности из-за отказа от неё говорить не приходится. (Собственно, именно поэтому среди процессоров общего назначения интеловские являются лидерами по производительности, несмотря на идиотскую систему команд -- наличие всякой дури усложняет их разработку и т.д., но не налагает принципиальных препятствий в достижении высокой производительности).

Цитата:
Не совсем понятно замечание по поводу модулярной арифметики. Если мы объединим в одну инструкцию сложение и взятие остатка, то разве не уменьшит это размер самой операции? Разве не станет от этого более эффективно работать кэш команд? И разве не сможет процессор исполнять больше таких независимых команд за одно действие?


Я не математик и не знаю, что такое модулярная арифметика, поэтому конкретно о ней сказать ничего не могу. Что же касается объединения нескольких операций в одну команду, то да, это позволяет поднять производительность -- и это одна из причин, почему CISC-процессоры архитектуры IA-32 (причём плохой CISC-архитектуры) оказываются в общем случае существенно быстрей, чем RISC-процессоры -- правда, ценой усложнения самого процессора. По этой же причине в 1980-х -- начале 1990-х быстрей были RISC-процессоры -- тогдашний технологический уровень не позволял впихнуть сложные схемы, связанные с декодированием сложных команд и их суперскалярным исполнением на один кристалл, поэтому, пока CISC медленно и печально (из-за ограничений по количеству транзисторов) выполнял одну сложную команду, RISC действительно успевал выполнить несколько простых. Сейчас ситуация поменялась: хотя RISC, конечно, тоже можно усложнить и заставить выполнять несколько команд параллельно (это давно сделано, кстати), но они упираются в пропускную способность памяти и ёмкость кэша -- а эти вещи, в отличие от логической сложности управляющих или исполнительных блоков процессора, нарастить куда сложней, а иногда и невозможно.

Другое дело, что не всякое объединение нескольких операций в одну оказывается реально полезным на широком круге задач. К примеру, меня на ARMе сильно напрягает его единственная имеющая место быть RISC-особенность -- выполнение операций только и исключительно в регистрах. Из-за этого мне постоянно писать три команды там, где на CISC обычно достаточно одной -- например, для инкремента/декремента счётчика использования некоего объекта. Здесь наличие команд, работающих с операндами прямо в памяти, было бы очень полезным и для ручного программирования на ассемблере, и (потенциально) в плане повышения производительности. Однако вводить в процессор команду, которая нужна 0,0001% приложений, выполняемых на данном процессоре, обычно неразумно, особенно если она требует для своей реализации каких-то особых исполнительных блоков.

Цитата:
По поводу генератора простых чисел там не описка. Чтобы выполнить расчёты по модулю, нужны, как правило, простые числа (иногда хватает более слабых ограничений – попарно взаимно простых чисел, но простые более удобны по ряду причин). Почему бы не генерировать их аппаратно?


Повторюсь, я не математик, но, насколько понимаю, простые числа известны заранее? Это ж вроде 1, 3, 5, 7, 11, 13, 17 и т.д. (которые ни на что не делятся нацело, кроме как на 1 и на самого себя)? Но зачем нужен генератор этих чисел? Понадобилось такое число -- возьмите да загрузите его из памяти в регистр и не тратьте в процессоре место на хранение констант, тем более нужных для очень узкого класса задач!

Цитата:
Мне почему-то этот стереотип по поводу быстроты аппаратной реализации над программной не кажется столь уж необоснованным. Я вижу это так, действуя по аналогии. Допустим, мы программируем алгоритм, состоящий из нескольких независимых операций А, Б и С. И вдруг оказывается, что у них есть что-то общее (хотя бы даже взятие операторов из памяти), мы это общее «выносим за скобки» - и упрощаем набор действий. Теперь, допустим, есть электронная схема, «зашитая» в процессор. Допустим, есть операции А и Б. Есть отдельная схема для А, есть отдельная схема для Б. Вот, мы решили, что нам нужна операция АБ (сумма + взятие остатка, например). Разве у них совсем нет общих элементов на уровне микроархитектуры? Я не знаю, как в процессоре устроены эти операции, но разве нельзя, посмотрев на схемы внимательно, объединить их в одну? С точки зрения математики, я не вижу такого способа, а с точки зрения электроники? Например, после операции сложения, не помещать промежуточные данные в регистр, чтобы потом вызвать операцию взятия по модулю для этого регистра, а сразу подсоединить выводы сумматора к блоку взятия модуля?


Можно, только скорость выполнения операций при этом соответствующим образом упадёт. Причём любых операций. Поэтому последовательное соединение нескольких блоков давным-давно никто не использует. Мощный процессор выполняет несколько разных (или не очень разных) операций параллельно, а его управляющая логика следит за тем, чтобы при этом не нарушалась концептуальная последовательность действий, определённая в программе. Более того, процессор может выполнять операции, следующие в программе после некоторой, до того, как эта некоторая операция закончится -- но, естественно, при условии, что они не пользуются данными, вырабатываемыми этой некоторой командой. Всё это называется внеочередным (out-of-order) исполнением и появилось ещё в конце 1960-х, но тогда, понятно, лишь на самых мощных машинах. Сейчас это есть в любом процессоре Intel Core, хотя отсутствует, например, в Атомах -- это одна из причин, почему они жрут намного меньше энергии, но при этом и работают существенно медленней.

В общем, хорошо построенный высокопроизводительный процессор сам сможет "спарить" те операции, которые реально можно выполнить параллельно, и не будет, например, лишний раз обращаться за операндами в памяти, если они уже оттуда были загружены. Так что только из-за этого вводить дополнительные инструкции смысла нет; это надо делать лишь тогда, когда за счёт введения новых инструкций удастся серьёзно увеличить плотность операций в программе (т.е. число элементарных операций, кодируемых в одном и том же объёме памяти) -- чтобы процессор как можно меньше простаивал из-за того, что нужных команд в кэше не оказалось (а кэш не резиновый и многократно увеличить его объём невозможно; повысить производительность подсистемы памяти также нельзя, иначе б это давно сделали).

Цитата:
Если бы я разбирался в этих схемах, то, может, нашёл бы возможность что-нибудь там упростить при таком объединении двух операций. Знаете, всё-таки я не верю, что эти операции совсем-совсем разные, что у них нет ничего общего


Знаете, на одном форуме по электронике некий человек никак не хотел поверить другим в то, что наличие в процессорных ядрах Cortex-M4 сопроцессора для операций с плавающей запятой одинарной точности (32 бита на число) абсолютно никак не может быть использовано для повышения производительности при обработке чисел с плавающей запятой двойной точности (64 бита). Дело как раз в том, что он понятия не имел, как числа представляются в двоичном виде и как они обрабатываются -- и при этом упорно не желал верить тем, кто эти вещи знает. (Это не в обиду Вам говорю, а как иллюстрацию заблуждений, связанных с незнанием предметной области).

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

Цитата:
Мой второй аргумент в пользу объединения операций в одну состоит в следующем. Допустим, мы хотим сложить два числа, размером 64 бита. Мы можем вызвать одну команду add на 64-битовыми регистрами, а можем две add / adc над 32-битовыми. Первый способ будет быстрее, но второй, который, как Вы говорите, является комбинацией уже реализованных блоков, будет всё-таки медленнее.


В теории -- да, на практике -- не всегда. Более того, поддержка 64-разрядных операций может сделать процессор более медленным. Например, первые интеловские 64-разрядные процессоры архитектуры IA-32 (ядра Core 2) в 64-битном режиме работали медленнее, чем в 32-битном. Этому явлению может быть несколько причин. Принципиальной проблемой является одна: в логических операциях (AND, OR, NOT, XOR) пары битов операндов действительно обрабатываются параллельно и независимо от других пар, поэтому результат что для 1-разрядной операции, что для 100500-битной операции будет получен за одно и то же время, лишь бы у нас было 100500 однобитных устройств, выполняющих эту операцию и работающих параллельно. В вот в сложении и вычитании есть такая вещь, как перенос/заём, т.е. реально отдельные пары битов не могут быть обработаны независимо и подлинно параллельно друг от друга: приходится передавать перенос/заём от младших битов к старшим. Вычисление этого переноса/заёма, передача его наверх, учёт его там требуют определённого времени. Поэтому, чем более широкой является операция сложения или вычитания, тем медленнее она работает. Поэтому концептуально 64-разрядный сумматор будет в 2 раза медленнее 32-разрядного.

На практике используют так называемый ускоренный перенос, когда значения межразрядных переносов формируются и учитываются специальными схемами не последовательно, а параллельно. Но это требует очень большого объёма аппаратуры. Вот пример реальной схемы:

Изображение

Эта схема микросхемы К1804ВР1, содранной в своё время с какой-то буржуйской из комплекта Am29xx. Одна изначально предназначена для соединения четырёх 4-битовых микропроцессорных секций для создания 16-разрядного вычислительного устройства, т.е. обеспечивает параллельную генерацию переносов для входов переноса каждой из трёх секций (кроме младшей, в которую перенос подаётся откуда-то снаружи). Выходами переносов здесь являются CX, CY и CZ. Легко заметить, что сложность схем нарастает: CX генерируется логическим элементом 2,2И-2ИЛИ-НЕ, CY -- 3,3,2И-3ИЛИ-НЕ, CZ -- 4,4,3,2И-4ИЛИ-НЕ. Точно такие же схемы потребуются для организации быстрых межбитных переносов, хотя в реальности часто делался последовательный перенос внутри секции (2-битовой К589ИК02, 4-битовых К1800ВС1, К1804ВС1 и ВС2, 8-битовой К1802ВС1) и параллельный ускоренный между секциями. Понятно, что сейчас транзисторы -- не столь дефицитный ресурс, как раньше, и параллельный перенос можно использовать более широко, но по-любому приходится считаться с тем, что при увеличении разрядности в 2 раза объём аппаратуры возрастает куда более существенно, а отнюдь не тоже в 2 раза. Более того, с увеличением разрядности растут, понятное дело, геометрические размеры схемы, а значит, возрастает время распространения сигнала (он же не мгновенно передаётся). Всё это и приводит в итоге к тому, что наращивание разрядности элементарной операции далеко не всегда способствует реальному повышению производительности даже при обработке данных большой разрядности. Что же касается более частых случаев обработки данных малой разрядности, то с ними ситуация будет как раз хуже, и в результате итоговая производительность может оказаться ниже.

Цитата:
С какого размера операция сложения начинает тормозить?


С любого; вопрос лишь в том, до какого предела можно эффективно использовать схемы ускоренного переноса.

Цитата:
А умножения и деления?


Умножение в теории может выполняться параллельно: частичные произведения никак не зависят друг от друга и могут быть сформированы параллельно, а затем их надо всего лишь сложить. Формирование частичных произведений в двоичной системе элементарно: это либо 0, либо значение множимого в зависимости от значения текущего бита множителя. А вот сложение приходится выполнять уже не двух чисел, а стольки, какова разрядность сомножителей. 32-входовый сумматор -- вещь, допускаемая теоретически, но не практически. Поэтому реально умножение выполняется в той или иной степени последовательно. Например, в такте 1 производится формирование всех частных произведений (скажем, их 32 -- для 32-разрядного умножения), в такте 2 они складываются попарно и получается 16, в такте 3 -- опять попарно и получается 8... Ну, Вы поняли :) Для повышения производительности это выполняется конвейерным образом: хотя одно умножение длится достаточно долго (пока не пройдёт через весь конвейер), каждый такт можно запускать новое умножение, поскольку в каждом такте используется лишь один набор сумматоров. В результате, хотя латентность операции велика (несколько тактов, и тем больше, чем выше разрядность), при следовании нескольких умножений подряд создаётся впечатление, что каждое выполняется за один такт. (Но понятно, что, если результат умножения требуется прямо в следующей операции, она вынуждена будет ждать, пока умножение не закончится, поэтому оптимизация кода программы здесь может оказаться очень полезной).

Что же до деления, то оно принципиально не может быть выполнено параллельно, ведь результат каждой следующей стадии операции зависит от результата предыдущей. Вспомните деление на бумажке в столбик: мы постепенно вычисляем цифры частного, каждый раз получая промежуточный остаток, чтобы на следующей итерации опять вычислить ещё одну цифру частного, и так до тех пор, пока остаток не станет меньше делителя. Точно так же вынуждена работать и машина -- это принципиальное ограничение. Разница лишь в том, что в слабых машинах (но где деление в виде отдельной команды таки было -- а ведь во многих деления нет вообще) деление выполняется с формированием лишь одного бита частного за такт, а в более мощных может формироваться несколько битов. Это достигается тем, что деление может выполняться не в двоичной, а в четверичной, восьмеричной, шестнадцатеричной системе... Но, понятно, всё это резко увеличивает объём аппаратуры. Так, для деления в двоичном виде достаточно сравнить текущие старшие разряды делимого с делителем, чтобы понять, нужно ли записать в частное 0 или 1; после этого выполняется либо вычитание и сдвиг, либо просто сдвиг (всё деление -- это последовательность сравнений, сдвигов и вычитаний). А в шестнадцатеричном виде надо провести одновременно 16 сравнений -- а значит, одних компараторов нужно 16 штук. По этой причине в большинстве ARMов, даже суперсовременных, команды деления нет: программная её реализация будет работать ненамного медленней простой аппаратной, а на сложную аппаратную требуется слишком много ресурсов, что больно бьёт и по цене процессора, и по его энергопотреблению (а одна из основных сфер применения ARMов -- мобильные штучки вроде телефонов и планшетов).

Цитата:
Я понимаю, что Вы имеете в виду, когда говорите, что мой ПМ (процессорный модуль) будет медленно взаимодействовать с ЦП, ведь они будут передавать друг другу данные по медленной шине. Но я предполагаю, что есть способ как-то «близко» подключить ПМ к ЦП, чтобы взаимодействие стало быстрым. Или это невозможно никак? Насколько я понимаю, раньше кэш L3 на многих процессорах был на отдельном кристалле, но он же не тормозил из-за этого. Или я не о том думаю?


В "древности" кэш выполнялся на отдельных микросхемах снаружи и всё равно давал прирост быстродействия. Но надо не забывать, что и сами процессоры тогда работали много медленней. Например, самые быстрые процессоры эпохи Intel 80486 имели тактовую частоту 133 МГц (это были AMD 586, насколько помню) -- ну а у современных процессоров той же архитектуры она превышает 3,5 ГГц (а, например, у мэйнфреймов IBM составляет 5,2 ГГц -- правда, там архитектура совсем другая, но в данном случае это не важно). Ну а чем выше частота, тем большую роль в качестве ограничителя быстродействия играет время распространения сигнала между двумя схемами. Кроме того, длинные связи означают наличие большого числа помех (ведь дорожки работают как антенны, собирая всевозможный радиошум). Именно эти два фактора и определяют весьма малую скорость передачи данных по любым внешним шинам по сравнению с внутрипроцессорными. Единственный способ заметно снизить время передачи -- объединить несколько устройств на одном кристалле, что и делается по мере возможности. Однако здесь мы упираемся и в допустимое число элементов на одном кристалле с точки зрения их физической вмещаемости (уже сейчас размер транзистора составляет всего несколько сотен атомов), и в проблемы с отводом тепла. Последняя, кстати, крайне важна. Именно из-за неё все современные процессоры делаются на КМОП-транзисторах, хотя сама по себе КМОП логика крайне медленная. Это хорошо видно на микросхемах 70-х годов, где число транзисторов на кристалле было мало, а поэтому не было особых проблем с теплоотводом: выполненные по одинаковым технологическим нормам, т.е. имеющие близкий размер транзистора, логические элементы на КМОП-транзисторах имели задержки в 100-300 наносекунд, а на биполярных -- от нескольких десятков (ТТЛ) до нескольких (ЭСЛ) наносекунд. Это соотношение сохраняется и сегодня: ЭСЛ-логика по-прежнему самая быстрая, на втором месте идёт ТТЛ (точней, её вариант ТТЛШ -- на биполярных транзисторах Шоттки, а не на обычных, но сие для нас не играет особой роли), а в хвосте плетётся КМОП. Но при этом ЭСЛ жрёт очень много энергии, ТТЛ -- поменьше, но тоже много, а КМОП -- мизер (идеальный КМОП-транзистор вообще энергии не потребляет; реальные, естественно, её тратят, но в сотни или тысячи раз меньше, чем биполярные).

Цитата:
Вот я и думаю, почему бы не сделать сразу ОС и СКА одновременно, чтобы СКА была бы неотъемлемой частью ОС и диктовала бы её развитие


ОС и СКА -- это абсолютно разные задачи, не связанные между собой. Сваливая их в одну кучу, вы получите... Ну, получите в итоге кучу дерьма, не годящуюся вообще ни для чего. Ведь всё это дело придётся развивать, а развивать одну большую систему куда сложней, чем 2-3-5-10 систем поменьше, хотя в совокупности функционал последних может быть больше, чем одной большой. В общем, не надо валить совершенно разные задачи в одну кучу.

Цитата:
Либо систему должен разрабатывать профессиональный учёный


Знаете, с моей точки зрения, одна из причин отставания советской вычислительной техники от американской была связана как раз с тем, что у нас её разрабатывали учёные, а у них -- бизнесмены. В результате, когда академик Глушко, если мне не изменяет памяти, в середине 1960-х предложил озаботиться тотальным "асучиванием" (т.е. внедрением АСУ -- автоматизированных систем управления) народного хозяйства, чтобы кардинально повысить качество управления, неожиданно выяснилось, что аппаратной базы для этого у нас нет вообще. Именно вообще: те машины, что были, годились лишь для научно-технических расчётов, да и то со сравнительно небольшими объёмами данных. В итоге это вылилось в копирование передовых на тот момент американских архитектур (IBM System/360, DEC PDP-11 и ещё парочки) -- но решение об этом тоже было принято с большим опозданием, в конце 1960-х. Ещё хуже было с элементной базой: наши гениальные учёные витали в облаках, а инженерам, которые реально что-то воплощали в жизнь, приходилось иметь дело со всяким дерьмом (ведь доступа в Политбюро у них не было, туда были вхожи лишь академики -- а эти академики совершенно не понимали реальных потребностей). У нас жутко нахваливают нашу БЭСМ-6 -- дескать, аж целый миллион операций в секунду! Но она пошла в серию в 1967 году и была сделана на дискретных транзисторах, а у американцев уже вовсю выпускались мэйнфреймы на микросхемах, делающие 6-7 миллионов операций в секунду. Про архитектуру я вообще промолчу: у нас она была попросту ужасна (хотя, естественно, и иностранные не без изъянов -- идеальной архитектуры пока что никто не придумал).

В общем, академическая братия, за редким исключением, не видит дальше собственного носа и очень плохо представляет себе всякие низменные материи вроде тех же транзисторов и их энергопотребления. Кроме того, для любого человека свойственно считать свою работу самой важной и т.д., но в реальной-то жизни это не так. Лично Вам и Вашим коллегам по науке "гигаразрядные" операции, наверное, действительно важны -- но подавляющему большинству народа приходится решать совершенно другие задачи, где и требования совершенно другие. Возможно, Вы бы (ну, не лично Вы, а инженеры по Вашему техническому заданию) смогли бы сделать машину, которая удовлетворяет Вашим требованиям -- но она, по всей вероятности, оказалась бы абсолютно бесполезной для 99,99% других людей. Ну а отвратительная архитектура IA-32, несмотря на всю свою кривизну, всё ж в состоянии удовлетворить требования пускай не 99,99% людей, но хотя бы 70-80% -- т.е. на практике она оказывается целесообразней Вашей архитектуры.

Цитата:
Да, свежесть была не первой. Но я и сам удивился, ведь наш «научный» центр заказал этот кластер в 2009 году. Сказать, что уже тогда это было ведро с гвоздями – это ничего не сказать. Более того, недавно, буквально год-два назад, наш университет тоже купил ведро с гвоздями, причём подержанное из 90-х! И, что самое безответственное с их стороны, они даже не проконсультировались со мной, как с единственным на тот момент человеком, который мог бы что-то подсказать из своего опыта, хотя именно мою команду собирались на этот кластер посадить. Потом меня выбросили, а ведро с гвоздями теперь ржавеет. Я пытался понять, зачем его купили, и выяснил, что оказывается, в рейтинге вузов есть такой пункт «наличие кластера». Вот руководство и решило выполнить этот пункт. Бестолочи : )


Они не бестолочи -- они выполняют свои личные задачи. Просто их задачи (повыситься в рейтинге и распилить бабло) отличаются от Ваших задач :)

Цитата:
Такой ситуации не может быть, если у нас миллионбитные регистры, значит они сначала полностью загружаются слагаемыми, а затем складываются без проблем


Как я уже говорил (а если не верите мне, то можете поискать информацию сами), кэш сейчас занимает основную часть площади кристалла. Суммарная ёмкость кэшей всех уровней во всех ядрах, а также внутренних регистров процессора (их отнюдь не 8 или 16, как то видит программист -- их в высокопроизводительных процессорах сотни или тысячи) составляет порядка 20 Мбайт, т.е., грубо говоря, порядка 100 млн. бит. Соответственно, если у Вас в процессоре регистры имеют размер миллион бит, то Вы сможете впихнуть в процессор порядка сотни таких регистров -- при этом не останется места под кэши. Какая у Вас будет производительность, а?

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

Цитата:
Сама концепция свопа мне как-то не очень нравится. Нужна возможность выделять память так, чтобы помечать её как запрещённую к сбросу на диск и пусть лучше ОС даёт отказ в выделении памяти в таких случаях


Концепция очень правильная и полезная в большинстве случаев. Другое дело, что не всегда она хороша. Не знаю, как Винда и Линух (не интересовался), а в OS/360 была возможность на уровне прикладного кода закрепить страницы в физической памяти. Реализовать это можно в любой системе, если там этого ещё нет. Например, в Винде можно написать свой типа драйвер, который будет заниматься не вводом-выводом, а лишь закрепит страницы задачи. В общем, принципиальной эта проблема не является.

Цитата:
«Резиновый» регистр заводить не обязательно и даже слишком большой тоже, но хотелось бы иметь что-то побольше, чем 64 бита.


А зачем? Вам это нужно, но 99,99% пользователей -- нет. Но, если сделать большие регистры (и, естественно, обрабатывающие блоки -- иначе зачем большие регистры), окажется, что изрядная их часть не используется. Точней, используется, но "механически" -- тупо хранит/складывает нули или единицы, а не реальную информацию, поскольку подавляющее большинство задач успешно обходится 32-разрядными данными, и даже адреса в 64 бита далеко не всегда востребованы. (Даже на современных мэйнфреймах объём физически установленной ОЗУ составляет, если не изменяет память, всего лишь 2 Тбайта).

Цитата:
Но там я подразумевал, что вся архитектура вычислительной машины будет выполнена по единому стандарту, то есть нужно делать что-то одно, что всегда со всем совместимо. Кроме того, я предполагал, что стоимость их не будет уж слишком высокой.


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

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

Цитата:
Цитата:
Берём отладочную карту с мощным FPGA и PCI-E слотом, устанавливаем в комп и программируем наши функции непосредственно в железе.

Можете ли Вы подробнее описать этот процесс? Где берём и что конкретно делать? Какую дисциплину для повышения квалификации изучать?


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

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

Цитата:
Правда? Я гляну в руководство по командам. Не знал, что rep можно использовать в таких случаях.


Мне кажется, что нельзя использовать...

------------

В общем, возможно, Вы -- очень хороший математик (а может, даже гений -- говорю без всякой иронии; сам-то я математической подготовки не имею, так что и судить хоть сколько-нибудь объективно не могу -- это дурака, знающего несколько "умных" слов, довольно легко определить, просто послушав некоторое время). Однако во всяких более "призимлённых" материях вроде реальной электроники Вы не разбираетесь, отсюда и нереальные предложения, и непонимание (не)осуществимости или цены тех или иных решений. Так что либо миритесь с тем, что есть, либо серьёзно углубляйтесь в изучение совсем нематематических аспектов нашего бытия, чтобы попробовать создать-таки что-то своё, лучше подходящее для Вашей задачи :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 03 дек 2014, 15:21 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 970
Откуда: Дагоба
Zealint писал(а):
Вы пишите, что не будет выигрыша от уменьшения числа операций в архитектуре. Я неявно предполагал, что уменьшение числа операций как раз позволит освободить место и сделать больше регистров, больше схем для независимых арифметических действий. Представьте, что если убрать весь мусор из x86, то на уровне микроархитектуры в тот же объём, наверное, можно будет всунуть ещё пару десятков регистров, увеличить кэш в разы и тогда одна из самых частых операций в моих программах (сумма чисел) будет работать быстрее именно за счёт того, что очень много регистров будут складываться параллельно.

Мне кажется, вы тоже не поняли мою позицию. Я не утверждаю, что в x86 всё замечательно, это крайне неудачная архитектура. Я рассматриваю эффективность некоторой гипотетической архитектуры, пытаясь понять, какие действия должны кодироваться одной инструкцией, а для каких этого делать не стоит - вот ключевой момент моих рассуждений.

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

Если каждая из двух последовательных операций выполняется за большее время, чем выборка и декодирование инструкции, то объединение лишено большого смысла. Забота о кэше имеет смысл, если количество инструкции в коде достаточно значительно, скажем, больше 5% от объёма, превышающего размер кэша первого уровня. Обратная сторона медали кодирования всего и вся заключается в том, что кодовое пространство не резиновое и при добавлении новых инструкций возрастёт средняя длина кодов, что также негативно скажется на эффективности.

Zealint писал(а):
По поводу генератора простых чисел там не описка. Чтобы выполнить расчёты по модулю, нужны, как правило, простые числа (иногда хватает более слабых ограничений – попарно взаимно простых чисел, но простые более удобны по ряду причин). Почему бы не генерировать их аппаратно?

Как вы себе это представляете?

Zealint писал(а):
Там я говорил про то, чтобы увеличить размер регистра. Для регистра в 128 бит...

Основным способом увеличения разрядности в процессорах является поддержка векторных операций. Этот способ позволяет эффективно реализовать арифметику с неограниченной разрядностью без использования специализированных инструкций.

Zealint писал(а):
В моих задачах было до десяти тысяч простых чисел. Здесь уже смысл не в скорости, а в удобстве. Программно-то генерируются они и так мгновенно.

Вот видите, если они и так нормально генерируются программно, то какой смысл в аппаратной реализации? Удобство - это не тот фактор, который нужно рассматривать в данном случае. Тем более, я до сих пор не понимаю, каким образом их можно было бы генерировать аппаратно.

Zealint писал(а):
Допустим, мы программируем алгоритм, состоящий из нескольких независимых операций А, Б и С. И вдруг оказывается, что у них есть что-то общее (хотя бы даже взятие операторов из памяти), мы это общее «выносим за скобки» - и упрощаем набор действий. Теперь, допустим, есть электронная схема, «зашитая» в процессор. Допустим, есть операции А и Б. Есть отдельная схема для А, есть отдельная схема для Б. Вот, мы решили, что нам нужна операция АБ (сумма + взятие остатка, например). Разве у них совсем нет общих элементов на уровне микроархитектуры?

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

Zealint писал(а):
Я не знаю, как в процессоре устроены эти операции, но разве нельзя, посмотрев на схемы внимательно, объединить их в одну? С точки зрения математики, я не вижу такого способа, а с точки зрения электроники?

Вся электроника основана на математике. Она не способна творить чудеса, опровергая математические законы.

Zealint писал(а):
Например, после операции сложения, не помещать промежуточные данные в регистр, чтобы потом вызвать операцию взятия по модулю для этого регистра, а сразу подсоединить выводы сумматора к блоку взятия модуля?

Синхронизация работы двух блоков по-любому требует наличия регистра между ними.

Zealint писал(а):
Допустим, мы хотим сложить два числа, размером 64 бита. Мы можем вызвать одну команду add на 64-битовыми регистрами, а можем две add / adc над 32-битовыми. Первый способ будет быстрее, но второй, который, как Вы говорите, является комбинацией уже реализованных блоков, будет всё-таки медленнее.

Нет, посмотрите внимательней, там стоит "или" (...или параллельное выполнение однородных операций). В данном случае сумматоры выполняют однородные действия, что достаточно эффективно кодируется в векторной арифметике.

Zealint писал(а):
Ещё не до конца ясен момент с размером регистров. Я не понял, каков предел размера регистра для суммы и для умножения (они ведь должны быть разными). С какого размера операция сложения начинает тормозить? А умножения и деления?

Сложение начинает тормозить с возникновением переносов. При отсутствии переносов с пропускной спосбностью памяти. Умножение и деление начинают тормозить сразу же.

Zealint писал(а):
Здесь тоже есть аналогия с параллельными алгоритмами: часто при сильном увеличении числа ядер алгоритм начинает тормозить из-за квадратичного роста побочных эффектов взаимодействия, потому часто алгоритмист пытается разбить алгоритм на как можно большее число независимых кусочков (пусть даже теряя эффективность алгоритма), так как сумма квадратов меньше чем квадрат суммы (для положительных чисел). Аналогично, операция умножения может иметь квадратичный рост по числу бит. Но можно, например, выполнить один-два шага метода Карацубы, когда оба регистра разбиваются пополам, далее вместо 4-х умножений и сложений этих половинок выполняется только 3 умножения и чуть больше сложений/вычитаний. И вместо квадратичного роста (n^2) мы получаем n^(log_2(3)). То есть вместо квадратичного роста получаем значительно более медленный, что может позволить отодвинуть «тормоза» умножения подальше.

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

Zealint писал(а):
Я понимаю, что Вы имеете в виду, когда говорите, что мой ПМ (процессорный модуль) будет медленно взаимодействовать с ЦП, ведь они будут передавать друг другу данные по медленной шине. Но я предполагаю, что есть способ как-то «близко» подключить ПМ к ЦП, чтобы взаимодействие стало быстрым. Или это невозможно никак? Насколько я понимаю, раньше кэш L3 на многих процессорах был на отдельном кристалле, но он же не тормозил из-за этого. Или я не о том думаю?

Локальность означает максимальную близость к функциональному блоку даже в пределах одного кристалла! Посмотрите - на процессорах все три уровня кэш-памяти находятся на одной микросхеме, но значительно отличаются по объёму и по скорости. Почему нельзя было сделать кэш-память третьего уровня столь же быстрой, как и первого уровня? Потому что размер мешает. Чем больше размер, тем больше площадь. Больше площадь - дальше от функционального блока. А чем дальше, тем больше задержки распространения сигнала. Что-то, находящееся физически за пределами ЦП вы не сделаете более быстродействующим, чем кэш третьего уровня, а это десятки тактов задержки на каждую операцию. Отсюда, кстати, напрямую следует, что вы не сделаете быстрый миллионобитный регистр, он будет работать крайне медленно.

Zealint писал(а):
Однако вот Вы сами пишите, что современные ОС не ориентированы на HPC. Вот я и думаю, почему бы не сделать сразу ОС и СКА одновременно, чтобы СКА была бы неотъемлемой частью ОС и диктовала бы её развитие.

Просто по той причине, что они выполняют совершенно разные функции. Нужно не объединение ОС и СКА, а создание ОС, подходящей под нужды СКА.

Zealint писал(а):
Такой ситуации не может быть, если у нас миллионбитные регистры, значит они сначала полностью загружаются слагаемыми, а затем складываются без проблем.

Регистр - это вид памяти. Миллионобитный регистр по быстродействию примерно сравнится с кэш-памятью второго-третьего уровня. Значит, если брать операнды из памяти и они попадут в кэш-память соответствующих уровней, то скорость работы будет примерно такой же. А значит регистры таких больших размеров лишены всякого смысла.

Zealint писал(а):
Кроме того, я никогда не пишу программы, которые уходят в своп, вернее, пишу, но стараюсь, чтобы так не происходило. Мне проще получить ошибку «нет памяти» с потерей всех промежуточных данных, что были в ОЗУ, чем останавливать процесс самому. Сама концепция свопа мне как-то не очень нравится.

Вы не поняли важного момента. Своп - это только частный случай, я бы вообще запретил свопирование на диск, как источник невероятных тормозов. Page fault в общем случае не привязан к свопированию. Основной источник PF - промах при записи в страницу, которая выделена приложению логически, но ещё не выделена физически.

Zealint писал(а):
По поводу гибкости я могу согласиться. «Резиновый» регистр заводить не обязательно и даже слишком большой тоже, но хотелось бы иметь что-то побольше, чем 64 бита.

Да. И это "больше, чем 64 бита" - векторные регистры, т.е. группы операндов, над которыми за один машинный цикл можно одновременно выполнять одинаковые операции.

Zealint писал(а):
Но там я подразумевал, что вся архитектура вычислительной машины будет выполнена по единому стандарту, то есть нужно делать что-то одно, что всегда со всем совместимо. Кроме того, я предполагал, что стоимость их не будет уж слишком высокой.

Вот для этого и стоит использовать уже существующую высоко стандартизированную шину - PCI-E.

Zealint писал(а):
Допустим, Вы против модулей, а имеет ли смысл создавать тогда мощный процессор, в котором есть «научный сопроцессор», содержащий наборы базовых алгоритмов математики, если эти алгоритмы удастся реализовать более эффективно, чем программно?

Ключевой момент - если эти алгоритмы удастся реализовать более эффективно, чем программно. Поскольку я полагаю, таких алгоритмов практически нет, то не вижу смысла в создании "научного сопроцессора", а точнее, любой ЦП должен изначально быть "научным". Более того, я не вижу разницы между научными приложениями и пользовательскими. Разница только в целях использования, но не в применяемых методах. Например, криптография с открытым ключом также базируется на операциях с большими числами (тысячи бит) и модульной арифметике, но вполне себе пользовательская.

Zealint писал(а):
Цитата:
Берём отладочную карту с мощным FPGA и PCI-E слотом, устанавливаем в комп и программируем наши функции непосредственно в железе.

Можете ли Вы подробнее описать этот процесс? Где берём и что конкретно делать? Какую дисциплину для повышения квалификации изучать?

Честно говоря, это весьма серьёзная во всех отношениях тема. Затраты времени на погружение в тему могут составить от нескольких месяцев до года и больше, затраты по деньгам выльются в десятки и соти тысяч рублей (если речь идёт о серьёзном изделии). Тем не менее, я действительно знаю предельно дешёвый способ изучить тему, как в теории, так и на практике.
1. Сначала посмотрите в википедии материалы на тему FPGA (ПЛИС), языки HDL (основные - Verilog и VHDL). Цифровые цепи по старинке, рисуя логические элементы ручками и соединяя их проводами, сейчас уже не делают, хотя это возможно. Вместо этого используют языки описания схемы (HDL).
2. Изучите один из основных языков (или оба) - Verilog и VHDL. Я после знакомства с ними остановился на Verilog, доступный учебник, например, здесь - http://irs.nntu.ru/globals/files/bukvarev/verilog.pdf. По VHDL лучше проконсультирует SII.
3. Дальше можно написать что-нибудь на верилоге и смоделировать без использования реальной ПЛИС, это делается при помощи программных симуляторов, например, Icarus Verilog. Этот симулятор работает как под виндой, так и под линуксом. Однако, следует быть осторожным, - программный симулятор позволяет сделать почти всё, что душе угодно, включая физически нереализуемые схемы. Реальные компиляторы накладывают массу ограничений.
4. Если в тему вникли, покупаем настоящую ПЛИС и реализуем первые цифровые цепи, действительно работающие 100% аппаратно. Самая доступная (но при этом далеко не самая плохая) плата - DE0-Nano. Их продают, например, в Чипе-и-Дипе, но дорого, по 7540 рублей. На eBay их можно купить примерно по 70$. Возможности DE0-Nano достаточны, чтобы на ней реализовать процессор уровня ARM или лучше. Недостатком является небольшая скорость, скажем, процессор будет работать на частоте около 50МГц (реальная величина зависит от вашего проекта).
5. Если вы сделали простой процессор на DE0-Nano, то без сомнения, будете настолько погружены в тему, что дальнейший путь вы сможете определять самостоятельно.

Zealint писал(а):
Цитата:
Цитата:
Неплохо было бы иметь строковые команды (префикс rep в x86), которые бегут по двум массивам чисел и складывают их с переносом.

Так это уже есть.

Правда? Я гляну в руководство по командам. Не знал, что rep можно использовать в таких случаях.

Простите, невнимательно прочёл. Нет, префиксы нельзя использовать с операциями сложения, только со строковыми операциями.

Zealint писал(а):
Это вопрос дискуссионный. Дело в том, что более оптимальная программа в нашей научной среде как раз может сожрать ещё больше электроэнергии, и вот почему. Допустим, неопытный исследователь написал программу, которая вычисляет число расстановок N не бьющих друг друга ферзей на доске NxN (последовательность OEIS:A000170) и она с горем пополам работает для N=20 на домашней машине. Исследователь погонял-погонял её неделю на кластере, дошёл, быть может, до N=21 или N=22 и сказал «хватит», пошёл писать магистерскую диссертацию. Более опытный исследователь сделает что-то похожее, тоже погоняет для N=21,22, затем найдет слабое место, перепишет код, будет гонять для N=23,24, устраивая баню в подвале, где стоит «Ломоносов», затем в силу своих способностей разработает алгоритм для N=25,26 (это уже докторская, без шуток), загрузит кластер на полгода (примерно столько и понадобилось для решения этой задачи, правда, на видеокартах, но не суть). В результате, выходит, что способность разрабатывать более эффективные алгоритмы приводит к тому, что электричества тратится гораздо больше :)

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

Zealint писал(а):
Даже экономия на 10% приведёт к тому, что просто будет решаться больше задач в единицу времени, а энергии будет столько же.

Нет, не так. Задача может быть либо решена, либо не решена. Если она решена, то затраты составят на 10% меньше. Если возможности компьютера возрасли настолько, что стало возможным решить другую задачу, то это - тоже победа. Ломоносов сейчас перегружен, там очередь задач практически не опускается ниже двух сотен.

Zealint писал(а):
Я знаю одну принципиальную схему экономии электроэнергии...
* перестать заниматься фаллометрией...

Я тоже полагал, что наши академические СК нужны только для прикладой фаллометрии. Меня убедили, что я ошибаюсь и бОльшая часть задач имеет прямое практическое значение. Другими словами, чтобы влезть в очередь из 200 задач нужно убедить, что твоя там не будет лишней. В конце концов, научные задачи - тоже задачи, и хорошо, если они решаются. Другое дело, что конечно же их надо решать правильно, именно здесь и нужны правильные языки высокого уровня, библиотеки и СКА. А аспиранты и доктора просто не могут быть специалистами во всех областях, поэтому вынуждены пользоваться тем, что есть, и решать задачи так, как умеют. Если кто-то сумел при помощи ПК забить СК, что ж, трижды хвала ему.

Zealint писал(а):
Цитата:
Цитата:
Либо изобретать принципиально другую архитектуру ЭВМ или даже другую математику.

Есть конкретные идеи?

Нет вообще. Но есть некоторая критика.

Критиковать - просто. Но если не существует способа решения, критика бесполезна.

Zealint писал(а):
Современная математика не всегда хорошо подходит для некоторых задач. Не хватает каких-то её расширений на те области, которыми я занимался. Там почти ни одна задача не может быть по-человечески решена математическими методами...

...а значит, как следствие, и компьютерными методами, поскольку работа компьютера целиком основана на математике.

Zealint писал(а):
Так видите ли, в чём дело, я согласен, что решить можно эффективно, но вопрос в том, что подразумевать под эффективностью. Я просто уверен, что если бы, с кажем, в процессоре было бы раз в 10 больше регистров и сумматоров, было бы ещё эффективнее.

10 сумматоров - пожалуйста, это векторные расчёты. 10 регистров - тоже. Но вот 100 регистров уже будут медленней 10, миллион будут в 10 раз медленней, а миллиарды - в 100 раз. Это и есть "иерархия памяти", и её центральная проблема - чем больше, тем медленней.

Zealint писал(а):
А если бы (если) аппаратная реализация суммы по модулю оказалась быстрее пары команд, то эффективность возросла бы ещё.

Так суть в том, что быстрей не оказывается и на то есть веские причины.

Zealint писал(а):
Не обязательно брать мою задачу, чтобы получился пример. Возьмите задачу подсчёта числа единичных бит в байте, слове, двойном слове и т. д. Эта процедура распадается на несколько более простых базовых команд. Однако же в SSE 4.2 всё-таки затем ввели аппаратную инструкцию, которая выполняет данное действие. Вряд ли они ввели бы её, не будь она более эффективной.

Правильно! И это - хороший пример того, когда аппаратная реализация имеет смысл в рамках данной архитектуры, т.к. операция по сути хорошо параллелизуема, но любая программная реализация на этом процессоре будет работать последовательно, т.е. в цикле. Однако, подсчёт числа единичных бит по сути своей является векторной операцией, представляющей собой свёртку - сумму массива. Ничего специфического касательно математики в данной операции нет, она довольно часто используется и в другой [векторной] архитектуре могла бы быть реализована без использования специальной инструкции.

Zealint писал(а):
Не сервера мощные, а программы такие. Есть программы, пытаясь скомпилировать которые GCC сжирала 4 Гб оперативки, уходила в своп и там тихо умирала.

Хмммм. Чрезвычайно интересный случай! У вас не осталось ли этого кода? Если есть, пришлите мне, пожалуйста, на исследование. Или если в будущем с таким столкнётесь, не забудьте про меня, пожалуйста.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 03 дек 2014, 15:34 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Ух ты : ) Спасибо, SII, за столь подробный ответ. Мне понадобится некоторое немалое время, чтобы его полностью осмыслить.

Что касается Вашей догадки, что я математик - это не совсем верно. У меня математическое образование, но скорее алгоритмист-практик. Сам очень не люблю "чистых" математиков. Среди наших "учёных" этого класса мало кто видел реальные задачи и что-то делал своими руками. Это часто было у них предметом споров и обид в мой адрес, когда я называл глупостями их "теоремы", в которых говорится, что вот, мы показали, как нечто сделать для N=1,2,3, аналогично можно и для остальных N. Я всегда отвечал, что как раз на практике на N=3 всё и закончится, если делать так, как они говорят. Поэтому я скорее практик, но, конечно, не архитектор. Моя задача всегда состояла в том, чтобы либо придумать алгоритм, работающий на практике быстро, либо оптимизировать уже известный подход, чтобы минимизировать число операций или их суммарное время выполнения. Меня чаще всего интересуют вопросы типа таких, как выжать из процессора максимум в той или иной программе. Вот, я выжимал, выжимал, и выразил свои пожелания разработчикам архитектуры. Очень хорошо, что нашлись люди, которые аргументированно протестуют, ведь одна из целей этой беседы для меня - больше узнать о железе, ведь я с ним работаю, а также понять, что можно, а чего нельзя поправить, лежат ли причины медленной работы в криворукости архитекторов, или же это физическое ограничение. Постепенно что-то проясняется.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 03 дек 2014, 16:41 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Спасибо подробный за ответ, Yoda. Теперь Ваши аргументы мне понятны, кроме пары.

Как Вы предлагаете реализовать длинную арифметику (хотя бы сложение) векторными командами? Я не придумал способа, как с помощью SSE сделать это хоть сколько-нибудь эффективно. Эти переносы портят всю картину, поэтому просто так сложить сразу несколько цифр не получается, нужны дополнительные действия, что сразу убивает весь смысл векторных команд.

По поводу реализации генератора простых чисел - это лишь мечты : ) В вопросах генерации основная сложность для программиста - сгенерировать большое простое число. Далеко не все знают, как получить, например, ближайшее снизу к 2^128 простое число. Для этого в общем случае есть алгоритмы, базирующиеся, обычно, на различных схемах определения псевдопростоты и не всегда, правда, они дают на 100% простое число. Раз есть алгоритмы, то я предположил, что можно зашить их аппаратно. Но не только потому, что "хочется", а для полноты картины. Я же, как Вы помните, предлагал концепцию процессорных модулей, которая оказалась глупой. Но в ней был пункт достаточной полноты операций, то есть если делаем процессор для теории чисел, то реализуем в нём основные операции из теории чисел. Сейчас-то я понимаю, что не нужно, в частности из-за того, что нельзя просто так занимать место, которого и так не хватает.

Цитата:
Другими словами, чтобы влезть в очередь из 200 задач нужно убедить, что твоя там не будет лишней.

Вращаясь в этих кругах, могу сказать, что чиновники "лишнесть" или "нелишнесть" задачи определяют только (даже нет, ТОЛЬКО) исходят из размера внешних показателей, которые они приобретут в результате допуска человека на кластер. Если либо чиновник не видит на заявлении подписи какого-нибудь супер-доктора, либо эта задача ему незнакома (а, следовательно, её смысл непонятен), доступ на мощный кластер человек не получит - это я утверждаю на 120% (а ещё можно быть родственником чиновника, тогда не важно, в чём задача). Можно попасть только на какой-нибудь провинциальный, где людям как раз не хватает пользователей. Значительная часть провинциальных кластеров простаивает процентов на 50-90. В качестве примера могу дополнить свою историю рассказом о нашем 80-ядерном кластере в "научном" центре. Когда его только поставили, никто не знал, что с ним делать. Он работал, и за электричество платить нужно было. В течении года я был единственным его пользователем, который умел загружать систему больше чем на 90%. В результате, по сути я и спасал их первый год, хотя этот калькулятор был мне не очень интересен. Потом они и сами научились чему-то. Время простоя у них теперь меньше 70% : ) Также я был в других небольших городах - та же картина.

Вы знаете, на сколько процентов обычно загружен "Ломоносов"? Я вот не знаю, но не верю, что больше чем на треть. И не верю, что официальная статистика, если она есть, написана честно. Я знаю, как можно "законно" в отчёте увеличить / уменьшить почти любую цифру в некотором диапазоне, чтобы никто не смог определить ошибку - чиновники пытались учить меня эту годами, - поэтому я давно не верю громким словам.

Программу, которая Вам нужна, я поищу позже. Это было 4 года назад, нужно покопаться в архиве.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

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


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

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


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

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB