Comments 69
"Slow net" на одной из схем прочиталось как
"Нет слов " :)
А вот что это за мусор по всей статье?
виртуальный объект это «связанный» набор данных [...] который изменяет свое состояние при взаимодействии с другими виртуальными объектами сообразно с законами функционирования
У вас не даны определения "состояния" и "законов функционирования".
Данные это и есть состояние объекта.
Давайте я скопирую часть переписки с пояснениями (общение на другом сайте)
Важный пункт, который не озвучен в вашей статье — для эквивалентности последовательных и параллельных реализаций схема должна строиться на трёх основных типах блоков: вычислитель с одним входом и одним выходом, демультиплексор и мультиплексор (в некоторых исследованиях используется термин «round robin»).
Он озвучен, просто этот подход настолько «экзотичен» для человека с мировоззрением программиста,
что гарантированно выпадает из восприятия.
Если описывать современное программирование, то можно сказать:
Если смотреть на команды на входе АЛУ, то программа это одномерный процесс (нить) с возможными альтернативами (команды ветвления). Но в итоге это просто одномерная нить, состоящая из исполненных команд. Что бы не было совсем уж грустно, придумали прерывания (параллельные нити). В базовой парадигме такого понятия нет (там один непрерывный поток команд), так что прерывания это «косттыль» изначально созданный для обслуживания аппаратуры (надо сказать, что создан с грубейшими нарушениями).
Если смотреть на создаваемую программистом «программу», то это клубок (который будет процессором раскручен в нить команд в процессе исполнения). От обычного клубка пряжи отличается только тем что нить иногда разделяется на части. Процесс исполнения (исполняемая команда) бегает внутри этого клубка.
Понятие времени по отношению к клубку целиком не применяется, ну разве что при переключении задач, есть понимание что задача изменила свое состояние.
Я предлагаю убрать из рассмотрения нить, последовательность команд и заменить ее на понятие изменения состояния программы (составляющих ее данных) от времени. Поскольку исполняемый код (последовательность команд) не изменяется, то таким состоянием будет только содержимое ячеек памяти. В исходной парадигме DataFlow тоже нет понятия последовательности команд впрямую, но оно появляется опосредованно, через неявную последовательность исполнения.
Время в моем варианте это цепочка изменений состояния (данных) программы. Пример: Вызывает программа процедуру, так вот вызов осуществляет одна программа (с одним набором данных), а результат получает совсем другая (с другим набором данных). Следующий вызов процедуры, будет вызывать не ту первую, а совсем другую (с другим набором данных).
Если для «обычного» программиста суммарная программа это основная + вызываемая процедура, то в моем случае
это потенциально бесконечная последовательность вызовов и возвратов. Да непосредственно команды будут в этой последовательности повторяться, но программа это не просто список команд а команды помноженные на данные.
И исполняемым графом будет именно эта бесконечная последовательность. Именно для нее производится сортировка данных по «уровням» и распределение по «ядрам». И только после этого будут получены отдельные последовательности команд, для каждого ядра, которые нужно «сжать» (распаковка в процессе исполнения).
Примерно так, но в голове среднего программиста это никак не укладывается.
Давайте я скопирую часть переписки с пояснениями (общение на другом сайте)
Важный пункт, который не озвучен в вашей статье — для эквивалентности последовательных и параллельных реализаций схема должна строиться на трёх основных типах блоков: вычислитель с одним входом и одним выходом, демультиплексор и мультиплексор (в некоторых исследованиях используется термин «round robin»).
Он озвучен, просто этот подход настолько «экзотичен» для человека с мировоззрением программиста,
что гарантированно выпадает из восприятия.
Если описывать современное программирование, то можно сказать:
Если смотреть на команды на входе АЛУ, то программа это одномерный процесс (нить) с возможными альтернативами (команды ветвления). Но в итоге это просто одномерная нить, состоящая из исполненных команд. Что бы не было совсем уж грустно, придумали прерывания (параллельные нити). В базовой парадигме такого понятия нет (там один непрерывный поток команд), так что прерывания это «косттыль» изначально созданный для обслуживания аппаратуры (надо сказать, что создан с грубейшими нарушениями).
Если смотреть на создаваемую программистом «программу», то это клубок (который будет процессором раскручен в нить команд в процессе исполнения). От обычного клубка пряжи отличается только тем что нить иногда разделяется на части. Процесс исполнения (исполняемая команда) бегает внутри этого клубка.
Понятие времени по отношению к клубку целиком не применяется, ну разве что при переключении задач, есть понимание что задача изменила свое состояние.
Я предлагаю убрать из рассмотрения нить, последовательность команд и заменить ее на понятие изменения состояния программы (составляющих ее данных) от времени. Поскольку исполняемый код (последовательность команд) не изменяется, то таким состоянием будет только содержимое ячеек памяти. В исходной парадигме DataFlow тоже нет понятия последовательности команд впрямую, но оно появляется опосредованно, через неявную последовательность исполнения.
Время в моем варианте это цепочка изменений состояния (данных) программы. Пример: Вызывает программа процедуру, так вот вызов осуществляет одна программа (с одним набором данных), а результат получает совсем другая (с другим набором данных). Следующий вызов процедуры, будет вызывать не ту первую, а совсем другую (с другим набором данных).
Если для «обычного» программиста суммарная программа это основная + вызываемая процедура, то в моем случае
это потенциально бесконечная последовательность вызовов и возвратов. Да непосредственно команды будут в этой последовательности повторяться, но программа это не просто список команд а команды помноженные на данные.
И исполняемым графом будет именно эта бесконечная последовательность. Именно для нее производится сортировка данных по «уровням» и распределение по «ядрам». И только после этого будут получены отдельные последовательности команд, для каждого ядра, которые нужно «сжать» (распаковка в процессе исполнения).
Примерно так, но в голове среднего программиста это никак не укладывается.
Архитектура фон-неймана
Джон фон Нейман — это человек такой.
Автор, как и большинство ему подобных, наметил стратегический прорыв, но не захотел думать о деталях.
Собственно, мысль о генерации решения на основании ограничений (законов, правил, как угодно) пришла в головы людей очень давно. И с появлением компьютеров эта мысль, разумеется, была реализована. И, в отличии от автора, реализация получилась качественной, потому что там думали о деталях. Правда вместе с размышлениями о деталях пришло и осознание сложности проблемы, да такой, которая никак не позволяет отказаться от программистов, как возмечтал автор текста.
Совет автору: читайте о логическом программировании, о программировании в ограничениях, учите, наконец, математику, и в частности формальную логику. Через несколько лет изучения вы в корне поменяете свои представления о прекрасном.
Да, и для справки: сочинять прекрасное без контакта с реальностью всегда занятно, но как только возвращаетесь в реальный мир, сразу становится больно. Поэтому и нужно сначала понять, что уже достигнуто, что бы не выглядеть идиотом. Хотя если мотивация есть, то после холодного душа автор наверняка пойдёт на поправку и в итоге сделает что-нибудь приличное. Ну а если душ отобьёт желание творить, значит туда и дорога, значит не было никогда настоящего творчества, а было лишь детское разлечение в дебрях сумрачного разума.
Собственно, мысль о генерации решения на основании ограничений (законов, правил, как угодно) пришла в головы людей очень давно. И с появлением компьютеров эта мысль, разумеется, была реализована. И, в отличии от автора, реализация получилась качественной, потому что там думали о деталях. Правда вместе с размышлениями о деталях пришло и осознание сложности проблемы, да такой, которая никак не позволяет отказаться от программистов, как возмечтал автор текста.
Совет автору: читайте о логическом программировании, о программировании в ограничениях, учите, наконец, математику, и в частности формальную логику. Через несколько лет изучения вы в корне поменяете свои представления о прекрасном.
Да, и для справки: сочинять прекрасное без контакта с реальностью всегда занятно, но как только возвращаетесь в реальный мир, сразу становится больно. Поэтому и нужно сначала понять, что уже достигнуто, что бы не выглядеть идиотом. Хотя если мотивация есть, то после холодного душа автор наверняка пойдёт на поправку и в итоге сделает что-нибудь приличное. Ну а если душ отобьёт желание творить, значит туда и дорога, значит не было никогда настоящего творчества, а было лишь детское разлечение в дебрях сумрачного разума.
Автор очень подумал о деталях.
Автор знает что такое автоматическое доказательство теорем,
знакомы слова теорема Геделя (не могу похвастаться полным пониманием),
знаю слова Prolog.
Но для данной статьи они излишни.
Здесь описывается система, которую можно запрограммировать с использованием обычного языка (СИ, Паскаль,Verilog) и является практически применимой dataflow системой.
Для понимания содержания статьи требуется минимум университетское образование в области вычислительной техники.
Автор знает что такое автоматическое доказательство теорем,
знакомы слова теорема Геделя (не могу похвастаться полным пониманием),
знаю слова Prolog.
Но для данной статьи они излишни.
Здесь описывается система, которую можно запрограммировать с использованием обычного языка (СИ, Паскаль,Verilog) и является практически применимой dataflow системой.
Для понимания содержания статьи требуется минимум университетское образование в области вычислительной техники.
Вы неправильно интерпретируете написанное.
Можно запрограммировать на языках высокого уровня, а вот исполняться эта программа будет на DataFlow системе (да не полностью используя предоставленные возможности).
Вы же можете исполнить (эмулировать) программу для калькулятора на современном компьютере, вот и здесь примерно так.
Я все эти цифры понимаю, в статье я не стал писать, что бы не «шокировать» окружающих, архитектура данной DataFlow вычислительной машины рассчитана на уровни производительности от 10E20 и не просто пиковой производительности (например в грид системах она никогда не достигается в реальности), а именно средней для задач молекулярного моделирования и моделирования мозга. Это конечно будет совсем уж крайностью (от интеллектуальной безнадеги), для моделирования мозга как совокупности 72Е25 молекул — (страшно много, но если нет мозгов приходится бегать)
По поводу моделировать синапс: Если не удастся понять как работает мозг (двигаясь сверху), то действительно придется двигаться от молекулярной биологии (снизу).
Я попробовал анализировать работу мозга сверху.
Если у Вас есть какие то вопросы, с удовольствием отвечу, в статье habr.com/ru/post/512652 описывается коммуникационная система которая позволяет создавать от 10Е16 соединений точка-точка в секунду, с задержками передачи данных определяемых скоростью света в среде передачи.
Можно запрограммировать на языках высокого уровня, а вот исполняться эта программа будет на DataFlow системе (да не полностью используя предоставленные возможности).
Вы же можете исполнить (эмулировать) программу для калькулятора на современном компьютере, вот и здесь примерно так.
Я все эти цифры понимаю, в статье я не стал писать, что бы не «шокировать» окружающих, архитектура данной DataFlow вычислительной машины рассчитана на уровни производительности от 10E20 и не просто пиковой производительности (например в грид системах она никогда не достигается в реальности), а именно средней для задач молекулярного моделирования и моделирования мозга. Это конечно будет совсем уж крайностью (от интеллектуальной безнадеги), для моделирования мозга как совокупности 72Е25 молекул — (страшно много, но если нет мозгов приходится бегать)
По поводу моделировать синапс: Если не удастся понять как работает мозг (двигаясь сверху), то действительно придется двигаться от молекулярной биологии (снизу).
Я попробовал анализировать работу мозга сверху.
Если у Вас есть какие то вопросы, с удовольствием отвечу, в статье habr.com/ru/post/512652 описывается коммуникационная система которая позволяет создавать от 10Е16 соединений точка-точка в секунду, с задержками передачи данных определяемых скоростью света в среде передачи.
habr.com/ru/post/556336 прочитайте данный текст.
как мне сейчас представляется, 5-е поколение вычислительной техники будет гибридом аналогового и цифрового вычислителя, где цифровому вычилителю будет отводиться роль очень быстрого перестроителя схемы аналоговой части и считывания данных с нее. а программирование будет осуществляться в терминах аналоговых вычислителей.
Примерно так выглядели вычисления в первых ракетах.
Мощных вычислительных машин не было и различные
уравнения, которые требовалось решать для обеспечения полета
делали в виде блоков из аналоговых элементов.
Главными особенностями машины пятого поколения должны быть
адаптивность ПО (возможность работать в реальном физическом мире),
параллельность, и распределенность.
Мощных вычислительных машин не было и различные
уравнения, которые требовалось решать для обеспечения полета
делали в виде блоков из аналоговых элементов.
Главными особенностями машины пятого поколения должны быть
адаптивность ПО (возможность работать в реальном физическом мире),
параллельность, и распределенность.
Главными особенностями машины пятого поколения должны быть
адаптивность ПО
В софте уже достаточно адаптивности. Может это пора уже выносить на уровень «железа»?
Когда понятие — обновление (означающее переписывание части кода) исчезнет из обихода, вот тогда и появится адаптивность ПО — В настоящее время ПО это «монолит», который не факт что будет работать даже с библиотеками следующих версий.
Когда понятие — обновление (означающее переписывание части кода) исчезнет из обихода, вот тогда и появится адаптивность ПО
Обновление — это и есть адаптация. Софт — чуть ли не по определению гораздо более адаптивный, чем железо.
сам по себе софт не обновляется — только посредством человека.
Основная идея тут озвучивается так:
идет робот по асфальту, асфальт закончился, пошел крупный щебень.
Робот должен через небольшое время адаптироваться и уже нормально передвигаться по щебню и все это он должен сделать без участия человека.
Таких изменений в реальном мире море — никаких программистов не напасешься для обновлений традиционным способом.
Основная идея тут озвучивается так:
идет робот по асфальту, асфальт закончился, пошел крупный щебень.
Робот должен через небольшое время адаптироваться и уже нормально передвигаться по щебню и все это он должен сделать без участия человека.
Таких изменений в реальном мире море — никаких программистов не напасешься для обновлений традиционным способом.
Тогда это будет "самостоятельная адаптация", а не "адаптация". В наше время обычно софт не имеет разума, и подразумевается, что есть субъект, его адаптирующий.
таракан разумом не обладает, но адаптируется прекрасно (или все же обладает)
Ни разу не слышал о тараканах, переписывающих свой код, или изобретающих продвинутые методы передвижения…
Не имею желания спорить. Просто указал на то, что "адаптировать" и "заложить бесконечную способность к самоадаптации" — разные вещи, разные "технические задания" с совершенно разными подходами к исполнению.
Что вы с мощностью делать будете? Сейчас у вас 1 вт на 10е8 вычислений/с, как в обычных системах с CPU? Или 1 вт на 10e9 вычислений/с как в GPU при существенном ограничении на виды инструкций, на скорость последовательного исполнения, и на независимость блоков друг от друга?
Вообще, посчитайте, что за утюг вы хотите сделать с производительностью >10e14 вычислений, и подумайте, как вы сможете плотнее упаковывать чипы чем сейчас в системах типа TPU и в GPU фермах при наличии ограничений на отведение тепла с единицы объёма. (самая большой чип вам в помощь: Cerebras Wafer, почитайте про теплоотведение и про объединение нескольких чипов вместе, всё уже продумано и изготовлено не хуже вашего).
И наконец, ответьте, чем это будет лучше существующих систем по логике работы? И сейчас везде программы как dataflow представляются, и сейчас в железе отдельные команды на отдельные вычислительные узлы идут, вот только закон Амдала это вам не поможет обойти: скорость программы ограничена самым непараллелизуемым местом. И для большинства программ этот лимит параллелизма уже достигнут на 8-ядерных процессорах, для почти всех редких оставшихся программ — на 10к CUDA-ядрах, для оставшейся части оставшейся части программ — на кластере из CUDA-ядер / TPU-ядер.
Вообще, посчитайте, что за утюг вы хотите сделать с производительностью >10e14 вычислений, и подумайте, как вы сможете плотнее упаковывать чипы чем сейчас в системах типа TPU и в GPU фермах при наличии ограничений на отведение тепла с единицы объёма. (самая большой чип вам в помощь: Cerebras Wafer, почитайте про теплоотведение и про объединение нескольких чипов вместе, всё уже продумано и изготовлено не хуже вашего).
И наконец, ответьте, чем это будет лучше существующих систем по логике работы? И сейчас везде программы как dataflow представляются, и сейчас в железе отдельные команды на отдельные вычислительные узлы идут, вот только закон Амдала это вам не поможет обойти: скорость программы ограничена самым непараллелизуемым местом. И для большинства программ этот лимит параллелизма уже достигнут на 8-ядерных процессорах, для почти всех редких оставшихся программ — на 10к CUDA-ядрах, для оставшейся части оставшейся части программ — на кластере из CUDA-ядер / TPU-ядер.
По поводу мощности: еще пару порядков относительно GPU надеюсь выиграть и вычислительная машина 10Е20 будет потреблять 100МВт. Понятно, что «дофига», но уже практически реализуемые цифры.(компьютер будет работать как система отопления в помещениях — платежки потребителям выставил и электричество бесплатно (шучу).
Как отводить такое тепло — жидкостные системы охлаждения много компактнее и производительнее чем воздушные (да и с кондиционерами возиться не придется).
Ограничение по теплу — сейчас проблема состоит не в отведении тепла как такового, а в отведении большой мощности с малого площади (вычислительная техника по удельному тепловыделению атомный реактор обгоняет). Проблема в том, что нельзя отвести много тепла с малой площади кристалла, но и нельзя сделать кристаллы большими или вообще процессор на нескольких кристаллах сделать. Решение этой проблемы я предложил — ограничений по теплу нет.
По поводу (лучше по логике): У современные процессоров есть проблема — только 20-30% исполняемых команд непосредственно участвуют в вычислениях, а все остальные это сервисные (mov,push,pop,call и тд). Если к этому приплюсовать различные методы ускорения вычислений (исполнение нескольких веток ветвления сразу, декодирование инструкций заранее, заполнение кеш памяти без непосредственной необходимости) тут сразу порядок по энергии или скорости можно выиграть. В моем случае исполняется только «полезные» команды, удалось избавиться от КЕШ памяти, удалось избавиться от очень тяжелого момента: синхронизации отдельный потоков команд.
Сейчас нет DataFlow — все что есть в «больших вычислениях» это векторные вычисления (GPU)
Закон Амдалла: Тут есть один интересный момент, чем более последовательно исполнение конкретной программы, тем больше не повторяющихся последовательностей команд она содержит, значит труднее ее писать, значит меньше размер этого участка, значит быстрее исполняется. (данное предположение требует доказательства). Кроме того, в основе предлагаемой вычислительной системе лежит понятие «объект», который обладает свойством вычисления любого элемента данных полностью параллельно. Иными словами, чем больше объект, там более параллельно его вычисление.
Параллелизм не имеет ограничений, главное не заставлять писать параллельные программы человека — МОЗГ ЧЕЛОВЕКА НЕ ПРЕДНАЗНАЧЕН ДЛЯ НАПИСАНИЯ ПАРАЛЛЕЛЬНЫХ ПРОГРАММ.
Как отводить такое тепло — жидкостные системы охлаждения много компактнее и производительнее чем воздушные (да и с кондиционерами возиться не придется).
Ограничение по теплу — сейчас проблема состоит не в отведении тепла как такового, а в отведении большой мощности с малого площади (вычислительная техника по удельному тепловыделению атомный реактор обгоняет). Проблема в том, что нельзя отвести много тепла с малой площади кристалла, но и нельзя сделать кристаллы большими или вообще процессор на нескольких кристаллах сделать. Решение этой проблемы я предложил — ограничений по теплу нет.
По поводу (лучше по логике): У современные процессоров есть проблема — только 20-30% исполняемых команд непосредственно участвуют в вычислениях, а все остальные это сервисные (mov,push,pop,call и тд). Если к этому приплюсовать различные методы ускорения вычислений (исполнение нескольких веток ветвления сразу, декодирование инструкций заранее, заполнение кеш памяти без непосредственной необходимости) тут сразу порядок по энергии или скорости можно выиграть. В моем случае исполняется только «полезные» команды, удалось избавиться от КЕШ памяти, удалось избавиться от очень тяжелого момента: синхронизации отдельный потоков команд.
Сейчас нет DataFlow — все что есть в «больших вычислениях» это векторные вычисления (GPU)
Закон Амдалла: Тут есть один интересный момент, чем более последовательно исполнение конкретной программы, тем больше не повторяющихся последовательностей команд она содержит, значит труднее ее писать, значит меньше размер этого участка, значит быстрее исполняется. (данное предположение требует доказательства). Кроме того, в основе предлагаемой вычислительной системе лежит понятие «объект», который обладает свойством вычисления любого элемента данных полностью параллельно. Иными словами, чем больше объект, там более параллельно его вычисление.
Параллелизм не имеет ограничений, главное не заставлять писать параллельные программы человека — МОЗГ ЧЕЛОВЕКА НЕ ПРЕДНАЗНАЧЕН ДЛЯ НАПИСАНИЯ ПАРАЛЛЕЛЬНЫХ ПРОГРАММ.
>По поводу мощности: еще пару порядков относительно GPU надеюсь выиграть
Ещё вам и по числу транзисторов надо оптимизироваться, потому что сейчас 20 млрд транзисторов на чип — это потолок.
Упаковать 10 чипов там, где был 1, и получить в 10 раз большую мощность, которую отвести жидкостью — это можно.
А вот увеличить хотя бы в 10 раз количество вычислений на транзистор по сравнению с GPU — мне кажется, нереально.
>Чем более последовательно исполнение конкретной программы, тем больше не повторяющихся последовательностей команд она содержит, значит труднее ее писать, значит меньше размер этого участка, значит быстрее исполняется.
Нет.
>Иными словами, чем больше объект, там более параллельно его вычисление.
Нет.
>Параллелизм не имеет ограничений, главное не заставлять писать параллельные программы человека — МОЗГ ЧЕЛОВЕКА НЕ ПРЕДНАЗНАЧЕН ДЛЯ НАПИСАНИЯ ПАРАЛЛЕЛЬНЫХ ПРОГРАММ
Ну тогда можно ещё проще поступить: мы создаём ИИ, а ИИ нам пишет программы. И заодно и правильный суперкомпьютер придумает, зачем этим тогда вам заниматься.
Ещё вам и по числу транзисторов надо оптимизироваться, потому что сейчас 20 млрд транзисторов на чип — это потолок.
Упаковать 10 чипов там, где был 1, и получить в 10 раз большую мощность, которую отвести жидкостью — это можно.
А вот увеличить хотя бы в 10 раз количество вычислений на транзистор по сравнению с GPU — мне кажется, нереально.
>Чем более последовательно исполнение конкретной программы, тем больше не повторяющихся последовательностей команд она содержит, значит труднее ее писать, значит меньше размер этого участка, значит быстрее исполняется.
Нет.
>Иными словами, чем больше объект, там более параллельно его вычисление.
Нет.
>Параллелизм не имеет ограничений, главное не заставлять писать параллельные программы человека — МОЗГ ЧЕЛОВЕКА НЕ ПРЕДНАЗНАЧЕН ДЛЯ НАПИСАНИЯ ПАРАЛЛЕЛЬНЫХ ПРОГРАММ
Ну тогда можно ещё проще поступить: мы создаём ИИ, а ИИ нам пишет программы. И заодно и правильный суперкомпьютер придумает, зачем этим тогда вам заниматься.
Ещё вам и по числу транзисторов надо оптимизироваться, потому что сейчас 20 млрд транзисторов на чип — это потолок.
этот вопрос решен, в предыдущей статье я опубликовал высокопроизводительную сеть, благодаря которой уже не придется все вычисления стягивать в один чип. Благодаря ориентированному графу (надеюсь) удастся раскрыть ее потенциал полностью.
А вот увеличить хотя бы в 10 раз количество вычислений на транзистор по сравнению с GPU — мне кажется, нереально.GPU это конечно векторная система с достаточно хорошим КПД (частично согласен с вашим скепсисом), но думаю есть еще за что побороться, например лучшие условия доступа к памяти, а значит большую загрузку вычислительных блоков. Правда тут упремся в потолок тепловыделения на единицу площади.
Чем более последовательно исполнение конкретной программы, тем больше не повторяющихся последовательностей команд она содержит, значит труднее ее писать
Тут я имел ввиду, что саму программу придется написать целиком «руками», она не имеет повторяющихся циклов, которые можно написать методом — «Вот это, повторить много раз». А написать в ручную — ну максимум 10 млн строк, не больше. Или есть другой вариант написать небольшой по размеру код, для исполнения которого потребуются очень много команд команд и при этом не будет повторов?
Ну тогда можно ещё проще поступить: мы создаём ИИ, а ИИ нам пишет программы.В следующей статье я и покажу такую систему, изначально это не ИИ, а просто постоянная коррекция ПО под изменяющиеся условия окружающей среды (без этого создавать программы для работы в реальном мире невозможно).
>Тут я имел ввиду, что саму программу придется написать целиком «руками», она не имеет повторяющихся циклов, которые можно написать методом — «Вот это, повторить много раз». А написать в ручную — ну максимум 10 млн строк, не больше. Или есть другой вариант написать небольшой по размеру код, для исполнения которого потребуются очень много команд команд и при этом не будет повторов?
А как связаны количество повторов в коде и скорость исполнения? Никак.
А как связаны количество повторов в коде и скорость исполнения? Никак.
А как связаны количество повторов в коде и скорость исполнения?
Почему никак — с точки зрения здравого смысла важно исполнить программу целиком и чем больше в ней повторов тем больше время исполнения.
Или другими словами, чем больше повторов кода, там больше размер трассы программы (список всех команд получившихся при исполнении программы).
Почему никак — с точки зрения здравого смысла важно исполнить программу целиком и чем больше в ней повторов тем больше время исполнения.
Или другими словами, чем больше повторов кода, там больше размер трассы программы (список всех команд получившихся при исполнении программы).
Почему никак — с точки зрения здравого смысла важно исполнить программу целиком и чем больше в ней повторов тем больше время исполнения.
… вы в курсе, что бывают программы, которые не выполняются "целиком"? И "время исполнения" их — это uptime, который "пока работает — не трогаем"?
Программы вида — написали 10 строчек исполнили одну это скорее показатель неэффективности работы программиста в сфере оптимизации.
Вот вам пример — средний размер программ не превышает 1Гб — даже если бы каждая команда кодировалась одним байтом и программа не содержала данных, то средняя программа исполнялась бы максимум за 1сек для абсолютного большинства вычислительных систем, но такого не происходит (понятно что пример не корректен для всех вариантов, но как среднее по палате работал всегда).
Вот вам пример — средний размер программ не превышает 1Гб — даже если бы каждая команда кодировалась одним байтом и программа не содержала данных, то средняя программа исполнялась бы максимум за 1сек для абсолютного большинства вычислительных систем, но такого не происходит (понятно что пример не корректен для всех вариантов, но как среднее по палате работал всегда).
Программы вида — написали 10 строчек исполнили одну
Вы не поняли, о чем я. Я говорю о ПО, которое исполняется без остановок (операционные системы, серверное ПО, демоны, и так далее, далее, далее).
Вот вам пример — средний размер программ не превышает 1Гб — даже если бы каждая команда кодировалась одним байтом и программа не содержала данных, то средняя программа исполнялась бы максимум за 1сек для абсолютного большинства вычислительных систем, но такого не происходит
… и почему же такого не происходит, как вы думаете? Не потому ли, что подавляющее большинство времени программа занимается не выполнением операций на процессоре?
Вы не поняли, о чем я. Я говорю о ПО, которое исполняется без остановок (операционные системы, серверное ПО, демоны, и так далее, далее, далее).
Это абсолютизированный цикл, я такие тоже писать умею
While (true)
{
a=b;
}
Второе даже комментировать не буду ))
Это абсолютизированный цикл, я такие тоже писать умею
While (true)
{
a=b;
}
Второе даже комментировать не буду ))
Это абсолютизированный цикл, я такие тоже писать умею
И тем не менее, ваше "важно исполнить программу целиком" к такому ПО неприменимо.
Второе даже комментировать не буду
Я не удивлен, это ваша типичная тактика.
Вы от компьютера чего хотите — что бы он гудел и потреблял электричество (можно использовать как нагреватель, но проще купить что то более приспособленное).
Вы ожидаете от компьютера решения задачи (выдачи полезного результата), все остальное никому не нужная фигня. А вот задача обязательно должна иметь конечное время исполнения (пусть даже это будет промежуточное решение).
Вообще любая задача обязана иметь конечное время исполнения (иначе она не имеет практического смысла), а вот повторный запуск исполнения это и есть цикл, для которого справедливо мое первоначальное утверждение.
Вы ожидаете от компьютера решения задачи (выдачи полезного результата), все остальное никому не нужная фигня. А вот задача обязательно должна иметь конечное время исполнения (пусть даже это будет промежуточное решение).
Вообще любая задача обязана иметь конечное время исполнения (иначе она не имеет практического смысла), а вот повторный запуск исполнения это и есть цикл, для которого справедливо мое первоначальное утверждение.
А вот задача обязательно должна иметь конечное время исполнения
Угу. Чем определяется конечное время исполнения задачи "покажи фильм"?
фильм сам по себе не программа, а вот повторяющаяся программа показывающая кадры этого фильма это и есть задача. Для нее показ одного кадра (или нескольких) и есть результат исполнения.
фильм сам по себе не программа
Мы же вроде про задачи, а не про программы уже?
Нам же нужно, чтобы компьютер "выдавал полезный результат"? Так вот полезный результат — это когда я сижу и смотрю фильм. Чем определяется время его получения?
Вы не поверите — в первую очередь, длиной фильма. Потому что короче, чем этот фильм, время выполнения быть не может.
Начальный посыл:
Те именно про программы.
А как связаны количество повторов в коде и скорость исполнения?
Те именно про программы.
А если про программы, а не про задачи, то есть программы, исполняющиеся "вечно", но при этом не имеющие повторов в коде. Примеры я уже приводил.
Магия, да и только.
программа вызывающая сама себя это и есть цикл, ее трасса будет содержать цикл.
Но повторов в ее коде — нет.
10 а=b
20 Goto 10
Повтора в коде нет?
20 Goto 10
Повтора в коде нет?
Нет. В коде есть цикл. Повтор в коде — это вот так:
10 а=b
20 а=b
30 а=bА как связаны количество повторов в коде и скорость исполнения? Никак
Вам не кажется, что вы доказали ошибочность исходного утверждения?
А уж как «рисовать цикл» развернутым или
в виде for… абсолютно неважно.
Вам не кажется, что вы доказали ошибочность исходного утверждения?
Какого?
Я пока придумал, только один вариант короткой (состоит из одной команды) и не повторяющейся программы с бесконечным временем исполнения.
JMP (0)
Если чтение памяти дает случайное число и при повторном чтении ячейки памяти с одинаковым адресом это число будет другим. (алу не прекращает исполнения для любой команды).
Вот только практического смысла в ней нет.
JMP (0)
Если чтение памяти дает случайное число и при повторном чтении ячейки памяти с одинаковым адресом это число будет другим. (алу не прекращает исполнения для любой команды).
Вот только практического смысла в ней нет.
… и?
… сферический конь в вакууме существует только в умах математиков и программистов, к практике имеет достаточно слабое отношение.
Придумайте программу не имеющую циклов, но имеющую длину трассы исполненных команд, больше размера кода?
Придумайте программу не имеющую циклов, но имеющую длину трассы исполненных команд, больше размера кода?
А, ну если вам про практику поговорить охота, то приведите примеры практической реализации вашей разработки.
Придумайте программу не имеющую циклов, но имеющую длину трассы исполненных команд, больше размера кода?
Пфф… Достаточно взять систему с зацикленным адресным пространством, и заполнить какими-нибудь операциями, не вызывающими сбоев (NOP подойдёт).
Вроде бы, даже можно зациклить виртуальное адресное пространство, заполнив линейным кодом одну страницу памяти, и отобразить эту страницу на на всё виртуальное адресное пространство.
А можно и не зацикливать, обойтись двумя виртуальными страницами, отображающими одну физическую страницу — пример подойдёт под ваши условия. Тут-то цикла точно нет.
Нет. С точки зрения здравого смысла, в программе есть не только код, который всегда исполняется один раз, но и код, который исполняется лишь при каких-то условиях (в том числе, ноль или очень много раз).
Трасса программы — это поток исполнения. А вы говорили про количество повторов *в коде* программы.
Вы сами запутались уже в своих половинчатых определениях.
Смотрите тривиальный пример:
1) В программе написано 100 раз «если а<100 то b=1». Это 100 повторов.
2) В программе написана процедура if_a: если а<100 то b=1 и потом она вызывается 100 раз в цикле.
1 повтор и 100 повторов — время выполнения одинаковое.
Если же вы говорили не про повторы *в коде*, а про повторы *в трассе*, то сначала объясните, как вы их измеряете, а во вторых, как это связано с вашим изначальным утверждением «Чем более последовательно исполнение конкретной программы, тем больше не повторяющихся последовательностей команд она содержит, значит труднее ее писать». В нём 3 (!) не связанных друг с другом вещи (причём, не связанных даже корреляцией!). Вот из моего примера программа (1) более последовательна, чем (2), при этом содержит больше повторяющихся команд, а писать (1) и (2) одинаково по сложности…
Трасса программы — это поток исполнения. А вы говорили про количество повторов *в коде* программы.
Вы сами запутались уже в своих половинчатых определениях.
Смотрите тривиальный пример:
1) В программе написано 100 раз «если а<100 то b=1». Это 100 повторов.
2) В программе написана процедура if_a: если а<100 то b=1 и потом она вызывается 100 раз в цикле.
1 повтор и 100 повторов — время выполнения одинаковое.
Если же вы говорили не про повторы *в коде*, а про повторы *в трассе*, то сначала объясните, как вы их измеряете, а во вторых, как это связано с вашим изначальным утверждением «Чем более последовательно исполнение конкретной программы, тем больше не повторяющихся последовательностей команд она содержит, значит труднее ее писать». В нём 3 (!) не связанных друг с другом вещи (причём, не связанных даже корреляцией!). Вот из моего примера программа (1) более последовательна, чем (2), при этом содержит больше повторяющихся команд, а писать (1) и (2) одинаково по сложности…
А "предел Ландауэра" ?
До этого предела еще очень далеко — оптимальная вычислительная машина достигшая этого предела позволит достигнуть производительности около 10Е20 в пределах одного кристалла.
Тут правильнее говорить о минимизации числа переключений отдельных транзисторов на единицу «вычислительной работы» и предлагаемая вычислительная парадигма (да и вообще вычислители DataFlow) достаточно оптимальна по этому параметру.
Если данных для вычисления нет, то логика вычислительного ядра «застывает» в состоянии чтения и не перезаряжает линии связи (не переключает транзисторы).
Тут правильнее говорить о минимизации числа переключений отдельных транзисторов на единицу «вычислительной работы» и предлагаемая вычислительная парадигма (да и вообще вычислители DataFlow) достаточно оптимальна по этому параметру.
Если данных для вычисления нет, то логика вычислительного ядра «застывает» в состоянии чтения и не перезаряжает линии связи (не переключает транзисторы).
Тезисно…
Схемы красиво нарисованы. Безпорно! Но 2021 год. Пора бы уже освоить графические редакторы.
«Вычислительная система пятого поколения» — это квантовый компьютер. Про транзисторы пора бы уже забывать. Надо искать новую элементную базу и алгоритмы.
Посмотреть хотя бы на биологию — громадная выч. мощность при низком потреблении. Выделение энергии при работе одного элемента является топливом для другого.
При всем уважении… это путь в никуда.
Схемы красиво нарисованы. Безпорно! Но 2021 год. Пора бы уже освоить графические редакторы.
«Вычислительная система пятого поколения» — это квантовый компьютер. Про транзисторы пора бы уже забывать. Надо искать новую элементную базу и алгоритмы.
Посмотреть хотя бы на биологию — громадная выч. мощность при низком потреблении. Выделение энергии при работе одного элемента является топливом для другого.
Все идеи и алгоритмы, описываемые в данной статье, являются результатом моей независимой и полностью самостоятельной интеллектуальной деятельности.Вы серьезно? Копипаст из учебников по электронике и очень слабое понимание принципов построения ПО вы называете «деятельностью»? Я вас умоляю!)
При всем уважении… это путь в никуда.
Схемы красиво нарисованы. — Винтаж ))
«Вычислительная система пятого поколения — это квантовый компьютер."
Вот когда его изготовят, тогда у всех откроются глаза и они воскликнут:
Rutel — гений, он изобрел квантовую вычислительную систему раньше чем смогли создать работающий квантовый компьютер.
Присмотритесь к понятию объект, он Вам ничего не напоминает?
«громадная выч. мощность при низком потреблении» — Думаю правильнее сказать, громадная эффективность использования энергии. Громадной вычислительной мощностью там и не пахнет, а данный миф появился из-за непонимания принципов работы мозга как вычислительной системы.
Вы серьезно? Копипаст из учебников по электронике — вот тут тема достаточно конкретная и вы можете доказать свою точку зрения конкретными ссылками.
Предыдущая статья, была про сетевую подсистему, я долго общался со связистами и никто мне так и не смог показать ничего похожего (да отдельные буквы и даже слова в «учебниках» встречаются).
«Вычислительная система пятого поколения — это квантовый компьютер."
Вот когда его изготовят, тогда у всех откроются глаза и они воскликнут:
Rutel — гений, он изобрел квантовую вычислительную систему раньше чем смогли создать работающий квантовый компьютер.
Присмотритесь к понятию объект, он Вам ничего не напоминает?
«громадная выч. мощность при низком потреблении» — Думаю правильнее сказать, громадная эффективность использования энергии. Громадной вычислительной мощностью там и не пахнет, а данный миф появился из-за непонимания принципов работы мозга как вычислительной системы.
Вы серьезно? Копипаст из учебников по электронике — вот тут тема достаточно конкретная и вы можете доказать свою точку зрения конкретными ссылками.
Предыдущая статья, была про сетевую подсистему, я долго общался со связистами и никто мне так и не смог показать ничего похожего (да отдельные буквы и даже слова в «учебниках» встречаются).
Вы серьезно? Копипаст из учебников по электронике и очень слабое понимание принципов построения ПО вы называете «деятельностью»? Я вас умоляю!)
Огромная просьба, если пишите про копипаст — прилагайте ссылку иначе это выглядит как общение в стиле: Дурак — Сам дурак.
Статья небезынтересная, но было неоднократно сказано в книгах по программированию: есть достаточная теория, чтобы поднять возможности техники минимум на 30-50% ценой смены архитектуры и отказа от обратной совместимости, но никто этого делать не будет именно из-за количества кода, который надо будет переписать. Так что все подобные системы мёртворождённые без полуавтоматического транслятора используемого ПО или эмулятора нынешней архитектуры, чтобы облегчить миграцию. GPU и FPGA выстрелили потому, что они не меняют парадигму разработки, а встраиваются в неё на правах «волшебной коробки сбоку в стандартном разъёме».
поднять возможности техники минимум на 30-50%Думаю правильнее говорить минимум про 10 раз.
По вопросу автоматической трансляции, в конце статьи я попробовал показать ее возможность и принципы ее построения для любого ассемблерного кода (по факту исполняемой программы).
Если найдется кто то заинтересованный в создании такого компилятора, то тут открываются очень больший перспективы. Для современных программ нет аналога «карт Карно».
Про универсальную трансляцию говорили неоднократно, минимум с БЭСМ: пролог, лисп, Эль-76, clang (когда он был диссертацией)… Но воз и ныне там. Хотя он коммерчески оправдан, чтобы избавиться от огромного количества легаси, нередко с утерянными исходниками.
Про смену архитектуры уже лет 30 никто всерьёз не заикается. Свежий Threadripper несколько обнадёживает, что будут явно переходить к модели NUMA, что уже большой шаг, посмотрим на политику AMD, смогут ли они сделать и продвинуть «новый С».
Про смену архитектуры уже лет 30 никто всерьёз не заикается. Свежий Threadripper несколько обнадёживает, что будут явно переходить к модели NUMA, что уже большой шаг, посмотрим на политику AMD, смогут ли они сделать и продвинуть «новый С».
В настоящее время вычислительная парадигма стагнирует по всем «фронтам» и внятной альтернативы нет, потому и не заикаются про новую архитектуру. Про всякие RISC процессоры, это от безысходности.
По поводу NUMA, предлагал одному из разработчиков процессоров (из первых по производительности) использовать символьную коммутацию, получались такие скорости передачи что даже КЭШ память может не справиться, задержки первые десятки ns.
В рамках виртуальной распределенной памяти в системе из 1000 процессоров (ядер еще больше) одновременный доступ всех процессоров (модификация содержимого ) к одному участку памяти (хоть к одному байту) всех 1000 процессорах занимает 200 нс И это время требуемое для обновления локальных копий на всей тысяче процессоров (запись в одну ячейку приводит к обновлению в 1000 и так для каждого процессора).
Цитирую неформальный ответ: Принято решение не выдавать никакого ответа на Ваше предложение.
У производителей процессоров интересы пользователей на последнем месте, все что их волнует не потерять свою долю рынка, даже в краткосрочной перспективе.
По поводу программирования — тут нужно менять все, у современной парадигмы программирования (выполни последовательность команд) нет никакого шанса.
По поводу NUMA, предлагал одному из разработчиков процессоров (из первых по производительности) использовать символьную коммутацию, получались такие скорости передачи что даже КЭШ память может не справиться, задержки первые десятки ns.
В рамках виртуальной распределенной памяти в системе из 1000 процессоров (ядер еще больше) одновременный доступ всех процессоров (модификация содержимого ) к одному участку памяти (хоть к одному байту) всех 1000 процессорах занимает 200 нс И это время требуемое для обновления локальных копий на всей тысяче процессоров (запись в одну ячейку приводит к обновлению в 1000 и так для каждого процессора).
Цитирую неформальный ответ: Принято решение не выдавать никакого ответа на Ваше предложение.
У производителей процессоров интересы пользователей на последнем месте, все что их волнует не потерять свою долю рынка, даже в краткосрочной перспективе.
По поводу программирования — тут нужно менять все, у современной парадигмы программирования (выполни последовательность команд) нет никакого шанса.
Я примерно про то и говорю: вопрос не в технической возможности и не в новизне идеи «всю систему менять», отказавшись от традиционной (сишной) модели вычислителя, а в рентабельности. Главный затык — в готовом софте (кто сказал «ЕС ЭВМ»?..) и отсутствии инструментов для «новой парадигмы», частично обкатанной на лисп-машинах и burroughs.
У производителей процессоров интересы пользователей на последнем месте, все что их волнует не потерять свою долю рынкаОчень наивное замечание. А как иначе? Кому интересна теория и нужды пользователей, идут на Opencores, qemu или хотя бы к risc-v.
Еще можно почитать про устройство системы связи: habr.com/ru/post/512652
Ничего похожего нет, производительность сети позволяет отделить от процессора оперативную память. С небольшими потерями, вообще разобрать монолитный процессор на отдельные составляющие и поместить их в отдельные кристаллы (для современного состояния дел вообще немыслимое).
Ничего похожего нет, производительность сети позволяет отделить от процессора оперативную память. С небольшими потерями, вообще разобрать монолитный процессор на отдельные составляющие и поместить их в отдельные кристаллы (для современного состояния дел вообще немыслимое).
Sign up to leave a comment.
Вычислительная система пятого поколения