Поговорим о том, в чем слабо разбираемся - технологиях и скоростях в микросхемах/контроллерах

[_KROL]

Странно... Но есть один вариант
Изначально если у тебя путь "C:\", а ты дописываешь "tasm\tasm l2.asm", то он конечно-же не найдёт "l2.asm", ведь будет искать "C:\l2.asm".
P.s. Aether, с какими ключами ассемблируешь? (а то у меня куча ошибок... у меня TASM 4.1)
P.p.s. Я просто под Windows пока ещё не программировал на ассемблере.

[Aether]

P.s. Aether, с какими ключами ассемблируешь? (а то у меня куча ошибок... у меня TASM 4.1)

make.bat

@nasm -fwin32 1.asm

@golink /console 1.obj kernel32.dll user32.dll

@1.exe

@pause

Версии:

NASM version 2.14rc0 compiled on May  1 2017

GoLink.Exe Version 0.26.14 - Copyright Jeremy Gordon 2002/9 - JG@JGnet.co.uk

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

P.p.s. Я просто под Windows пока ещё не программировал на ассемблере.

Под Windows вполне можно писать на ассемблере, однако главная трудность - это уследить за вносимыми разработчиками ОС нововведениями. Тот же DirectX обернётся далеко не только подключением dll.

[_KROL]

Понятно. Я просто не знал что это уже NASM, компилировал TASMом... А вообще я пишу Форт под DOS.

[Aether]

Понятно. Я просто не знал что это уже NASM, компилировал TASMом... А вообще я пишу Форт под DOS.

Что это?

Можешь в FASM переработать, но придётся подключать библиотеку с определениями под Windows и писать секцию импорта dll.

[_KROL]

Понятно. Я просто не знал что это уже NASM, компилировал TASMом... А вообще я пишу Форт под DOS.

Что это?

Можешь в FASM переработать, но придётся подключать библиотеку с определениями под Windows и писать секцию импорта dll.

Простите, только недавно заметил...
Форт - функциональный язык программирования. Появился во времена Лиспа, однако по своему своеобразен и неповторим. К примеру, он бесконечно расширяем...
Форт не так сильно распространён как Си, к тому же под него современной понятной документации вряд ли найдёшь. Тем не менее он не является сложным для понимания.
Синтаксис Форта весьма прост. Каждое слово Форта состоит из любых символов "выше" пробела. Всё остальное он воспринимает как разделители(как удобно, ни правда ли?).
Программа на Форте представляет собой последовательность слов(подпрограмм) связаных между собой шитым кодом(посмотрите в Wikepedia хотя бы). Слова делятся на высокоуровневые(на Форте) и низкоуровневые (на целевом языке [ну есть же термин "целевой компилятор"!]).
Целевым языком для меня сейчас ассемблер x86, поэтому всё написанное далее будет касаться этой архитектуры.
Последовательность слов образуют список(словарь)...
Ладно, я же не статью пишу
В заключении хочу отметить его runtime-ность. Дело в том, что у Форта 2 режима работы системы: интерпретация и компиляция. В зависимости от режима система интерпретирует или исполняет слово после считывания(если оно есть в словаре).
Компилирует новые слова она в "конец словаря". Также у Форта обычно есть специальные слова "немедленного исполнения"(IMMEDIATE), чьё исполнение не зависит от текущего режима системы. В них гибкость форта. Они позволяют пользователю изменять компиляцию...

P.s. Если хотите поговорить о Форте, то я могу создать для этого тему.
P.p.s. Я хоть теперь понятнее написал?

Добавлено через 22 минуты и 34 секунды:
Забыл про пару примеров кода на Форте!

Код:

: Hello ." Hello World!" ;
\ строчный комментарий
( комментарий)

: - начать определение слова
Hello - имя нового слова
." - взять строку до " и скомпилировать с процедурой вывода (IMMEDIATE)
; - законцить
Т.е. если после ввода вышенаписанной строки ввести Hello, то она должна вывести Hello World!

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

Код:

1 1 + . \ . - вывести число со знаком; U. - без знака

2

Ну и... напоследок)
Будте осторожнее перед использованием любого незнакомого слова в системе, потому-что неправильное его использование случайно может привести к плохим последствиям!
Однако, максимум что я наблюдал, так это окно "ошибка NTVDM" в моей Windows XP(но это только у меня).

[Aether]

Забыл также сказать, что особенностью Форта является приутствие как минимум 2-х стеков: стека данных и стека возвратов.

В чём состоит необходимость имитации двух и более стеков?

Каково предназначение языка?

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

[RXL]

Aether, почему имитации? Стек - это структура данных. Хранение данных в стеке возврата - частный случай реализации, а не правило. Т.ч. стеков может быть сколько угодно.

[Aether]

Aether, почему имитации? Стек - это структура данных. Хранение данных в стеке возврата - частный случай реализации, а не правило. Т.ч. стеков может быть сколько угодно.

Предположим, у нас два стека, и идёт вызов функции. Что мы ей передаём? По сути, мы ей сообщаем esp и она знает, что там лежит адрес возврата и следом необходимые ей данные. Как реализовать второй стек? Нужно либо использовать глобальную переменную с фиксированным адресом, либо занимать ещё один регистр, и использовать их как указатель на первый стек. Само собой, ситуация не штатная для архитектуры x86. И медленная. Плюс нужно следить за этими стеками, чтобы не произошло случайной их встречи. Собственно вся суть стека - это его линейность, которая исключает возможную фрагментацию, но ограничивает применение. Для меня стек привязан к аппаратной реализации. Есть МК, в которых стек возврата реализован в виде набора выделенных ячеек памяти, обычно от одной до тридцати двух, но тут суть принципиально другая.

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

[Dale]

Форт - функциональный язык программирования.

Это недавние стандарты так сильно изменились?

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

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

Интересно, как они реализовали определение лямбда-функции (синтаксис)?

Для меня стек привязан к аппаратной реализации.

Обычная абстракция, вроде очереди, только дисциплина доступа не LIFO, а FIFO. Возможность организации множества независимых очередей допускаете? Со стеками то же самое.

[RXL]

Aether, вспомни ассемблерные команды x86: enter и leave. Сохранение и восстановление контекста ESP/EBP для функций.

Теперь примерно тоже самое со стеком данных: в стеке возврата сохраняется не просто адрес, а контекст вызова. Контекст может содержать указатель на позицию в стеке данных, означающую условное для данного вызова дно стека. Т.е. вызванной процедуре доступен не весь стек, а его фрагмент. Если процедура хочет вызвать другую, то она должна подготовить новый контекст вызова: задать новое дно стека (можно указать, к примеру, дно из своего контекса, тем самым передав свои аргументы дальше), загрузить в стек аргументы, адрес возврата и выполнить вызов. При возврате восстанавливается дно стека вызывавшей процедуры и удаляются временные данные.

Если тебе машинные коды роднее высокоуровневых языков, считай, что стек данных задан двумя значениями: дно и вершина. Хранятся в контексе, временно могут быть загружены в регистры. Со своим кадром процедура может делать все, что угодно: менять значения, удалять из стека данные, добавлять новые. Добавлю в контекст еще третье значение: указатель на вершину стека при возврате.

Насчет аппаратной множественности стеков. Архитектура 68k: по 8 регистров данных и адреса. Каждый регистр адреса поддерживает операции, аналогичные push и pop: (An)+ и -(An). Причем A7 это аналог ESP.

[Aether]

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

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

[_KROL]

Форт - функциональный язык программирования.

Да, спасибо! И где это я вообще видел?

Предположим, у нас два стека, и идёт вызов функции. Что мы ей передаём? По сути, мы ей сообщаем esp и она знает, что там лежит адрес возврата и следом необходимые ей данные. Как реализовать второй стек?

Всегда можно задействовать второй регистр - ebp/bp. Правда обращение к стекам тут идёт по драгому, нежели в Си/Паскаль...
Лучше дам ссылки для ознакомления:
https://ru.wikipedia.org/wiki/Шитый_код или http://dic.academic.ru/dic.nsf/ruwiki/702586
http://dic.academic.ru/dic.nsf/ruwiki/726703
http://www.netlib.narod.ru/library/book0001/
Кое-что для скачивания тут http://fforum.winglion.ru/viewtopic.php?f=37&t=2895 и тут http://wiki.forth.org.ru/УчебникиФорта#0

[Dale]

Если хотите поговорить о Форте, то я могу создать для этого тему.

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

То, что было упомянуто как его основные черты и показано в примерах, Forth умел еще 40 лет назад. Что еще он приобрел хорошего за эти 40 лет?

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

[RXL]

Aether, используя один стек для данных и обслуживания вызовов ты не сможешь:
1. вернуть из вызова более одного значения;
2. использовать одни и те же данные без копирования в нескольких последовательных вызовах;
3. вернуть несколько значений из последовательных вызовов без копирования.
Также традиционные соглашения о вызовах не позволяют контролировать переменное количество параметров.

[Aether]

1. вернуть из вызова более одного значения;

Есть обход: функция выделяет необходимую ей область памяти, заполняет её данными, и возвращает указатель. Можно вернуть даже гигабайт. А вот как контролировать рост двух стеков в одном адресном пространстве мне не очень ясно.

2. использовать одни и те же данные без копирования в нескольких последовательных вызовах;

cdecl предписывает удалять из стека аргументы вызывающей программе. Поэтому можно подряд вызывать несколько функций с одними и теми же параметрами не заполняя стек каждый раз. Но это редкий случай.

Интересно следующее: когда мне необходимо выделить память под данные, то приходится обращаться к ОС. А как выглядит в современном виде механизм выделения памяти под стек? И в каком её месте будет располагаться второй стек?

[darkelf]

Интересно следующее: когда мне необходимо выделить память под данные, то приходится обращаться к ОС. А как выглядит в современном виде механизм выделения памяти под стек? И в каком её месте будет располагаться второй стек?

Имхо, это обычная область памяти, просто средствами ОС она специальным образом помечена, например, через MAP_GROWSDOWN.

[RXL]

Aether, в чем проблема? В программах много объектов переменной длины. Например, кучу и мапированный файл можно изменять по размеру. Не надо приписывать структурам данных какие-то магические свойства. Стек возврата, да, особенный, мы должны иметь возможность писать в него всегда, иначе процессу будет плохо. Все остальные стеки — просто структуры данных, поддерживать их емкость не сложно. Если в 32-битных системах жручие программы должны были планировать использование своего адресного пространства, то в 64-битных системах место дохрена.

И эта... Стек не обязан расти вниз, это стереотип.

Последовательные вызовы: наверно я непонятно выразился — вложенные вызовы.

[Aether]

Aether, в чем проблема?

Забыл также сказать, что особенностью Форта является приутствие как минимум 2-х стеков: стека данных и стека возвратов. В обычных языках адреса возвратов и параметры к процедурам находятся все в одном стеке, а тут раздельно.

Проблема в смешении понятий.

Стек, как аппаратное решение, не зависит от языков программирования. И на этом поле имеет преимущество тот язык, который взаимодействует с ним с минимальным числом посредников. К этому относятся, например, и "С" и ассемблер.

Стек, как организованная определённым образом структура данных, доступна наверное всем языкам. Поэтому я и написал: каков смысл в имитации?

[Gudleifr]

Извините, мимо проходил.

Поэтому я и написал: каков смысл в имитации [стека]?

Ответ содержится в статье Дейкстры - An attempt to unify the constituent concepts of serial program execution. 1962.
Можете посмотреть (а заодно, и "что такое FORTH") там - http://gudleifr.forum2x2.ru/t38-topic

[Dale]

По поводу упомянутой статьи Дейкстры: мне какое-то время назад попадалась анекдотичная версия, что якобы именно Дейкстра придумал FORTH, а Мур лишь реализовал готовую идею. Хотел процитировать, но сразу не нашел.

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

[RXL]

Aether, видимо ты не понял разницы. Никакой имитации.

Про языки высокого уровня я писал, конкретно упоминал Perl. И Dale писал о Forth. Для ассемблера и Си это реализовать можно, но как минимум будет неудобно. Я пишу сишные модули для Perl и приходится вручную общаться со стеком и управляемыми интерпретатором объектами — это громоздко, требует высокой аккуратности и покрытия тестами. Т.е. реально, но неудобно. А под интерпретатором все наоборот: удобно и не напрягает.

[Dale]

И Dale писал о Forth.

Не, это не я был. Я лишь спросил, куда его полувековая эволюция привела, если можно вкратце сформулировать. Сам я о Forth'е напрочь забыл с середины 80-х, причем и тогда он меня особо не торкнул, в самый пик моды. Полюбопытствовал в рамках приличий, поучаствовал немного в общем движении и тихо отошел. Что уж теперь старое ворошить...

Что касается альтернативных стеков (помимо "главного", куда по умолчанию валятся адреса возвратов при вызовах и прерываниях, параметры вызова и локальные объекты, контексты и много прочего барахла), я бы еще упомянул "регистровый стек" наподобие того, который заменял пул регистров общего назначения у мэйнфреймов Burroughs. У этих довольно производительных для своего времени компьютеров была безадресная система команд: операнды снимались с верхушки стека, выполнялась операция, и результат помещался на верхушку стека. Вроде бы это давало хороший прирост производительности в сравнении с операциями на регистрах общего назначения. К сожалению, я об этом знаю лишь по литературе, поскольку это семейство не было популярно у нас, покупали/клонировали в основном IBM/360/370/380, и живого "Берроуза" я даже не видел, не то чтобы поработать на нем. Хотя ходят слухи, что наши легендарные "Эльбрусы" на самом деле скопированы с "Берроузов", но тут я не в теме, ибо их не видел тоже.

<offtop>А если еще добавить факт, что Дейкстра долгое время был почетным сотрудником в фирме Burroughs, становится понятно, для кого на самом деле была написана упомянутая выше статья о стековых вычислениях. Ну а народная молва быстро дополнила недостающие детали, и вот вам - Товарищ   Сталин   разработал  положение о постоянно действующих факторах товарищ Дейкстра придумал столь нужный народу Forth.</offtop>

[Aether]

Про языки высокого уровня я писал, конкретно упоминал Perl.

Perl не знаю. Просто я пытаюсь разделить разные значения одного слова, чтобы понять суть.

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

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

[Dale]

сумматор работает намного дольше пересылки данных

В ЭВМ 3-го поколения (которые давали последний шанс реально заглянуть внутрь компьютера и увидеть своими глазами, что там происходит) это было совсем не так. Это хорошо видно на диаграммах микрокоманд (из которых посредством микропрограмм составляются те самые машинные команды, которые представляются ассемблерным программистам атомарными, но на самом деле это далеко не так). Значительную часть микропрограммы составляют вычисление фактического адреса операнда (если есть), операции с шиной для извлечения операнда из памяти (если есть), транспортировка данных в АЛУ и затем обратная доставка результата по месту назначения. Поскольку АЛУ - довольно простая комбинационная схема без состояний, его вклад в общие затраты времени невелик.

В архитектурах RISC, конечно, обработка данных более эффективна, но и пересылки данных при этом весьма урезаны. По сравнению с CISC они, можно сказать, рудиментарны.

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

В 3-м поколении ЭВМ регистры общего назначения обычно делались на быстродействующих (по тем временам) микросхемах памяти небольшой емкости (16/32 ячейки). Весь блок регистров представлял одну матрицу.

В предыдущих поколениях РОН делались вообще из всякого подручного хлама (конденсаторы, ЭЛТ с длительным послесвечением, закольцованные линии задержки, ферритовые кольца...), у кого что находилось в ближайшей мусорной корзине.

В 4-м поколении РОН перекочевали сначала в секции, а потом и в монолитный ЦП, увидеть их отдельно стало невозможно.

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

IMHO странный подход. Я в таких случаях реализую кольцевую очередь FIFO, когда самые старые данные перетираются новыми.

[RXL]

Любой контекст нужно сохранять при переключении задач, независимо от принципов работы. Для x86 FPU даже есть оптимизация с отложенным сохранением состояния.

Самописцы: стек — это LIFO. То, что ты описал — это называется лог. Можно использовать и FIFO, как предлагает Dale. Работа с логом отчасти похожа на FIFO. Лог подразумевает непрерывную последовательную запись с возможной сменой хранилища (переключением лога).

[Aether]

Поскольку АЛУ - довольно простая комбинационная схема без состояний, его вклад в общие затраты времени невелик.

Я такую вещь наблюдаю: простейшие сумматоры с последовательным переносом работают медленнее всех, но в своём составе имеют минимальное число элементов, поэтому затраты энергии Дж/вычисление имеют низкие. Сложные схемы увеличивают численность элементов в тысячи раз, имеют большее энергопотребление, но задержка при вычислении переносов всё равно имеет место быть. Если сравнивать транзит регистр-регистр и само вычисление суммы, думаю всё-таки считает он дольше. Хотя в программе, именно вычислительная нагрузка может померкнуть в сравнении с работой по пересылке память-память.

В архитектурах RISC, конечно, обработка данных более эффективна, но и пересылки данных при этом весьма урезаны. По сравнению с CISC они, можно сказать, рудиментарны.

Мне интересно: как правильно сравнивать эффективность? В пользовательских ПК обычно есть одна тяжёлая задача и сотня маленьких. В этом режиме более эффективен процессор с одним или двумя ядрами, но с высокой частотой и скоростью работы. С повышением частоты растут расходы на вычисления, причём нелинейно. Для задач по обслуживанию десятков тысяч потоков более эффективным будет многоядерный процессор с низкой частотой. Обычно пытаются сравнивать ARM с x86, первый работает на 400 МГц, условно, а второй на 3 ГГц. Полагаю, что если сравнивать в условии равных частот, равного, хотя бы условно, ПО, то преимущества RISC будут не такими уж и значимыми. Мало того, станут видимы недостатки, например, увеличится объём кода из-за того, что все инструкции в ARM имеют ширину 32 бита (Thumb - отдельная песня).

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

Любой контекст нужно сохранять при переключении задач, независимо от принципов работы. Для x86 FPU даже есть оптимизация с отложенным сохранением состояния.

Я о чём: если бы FPU использовал обычный РОН, а не свой стек, то это было бы выгоднее. Исторический ход, когда 8086 и 8087, и некоторые следующие МП выпускались в отдельном с сопроцессором корпусах, даёт и поныне своё эхо.

Самописцы: стек — это LIFO. То, что ты описал — это называется лог.

Я по сути: есть указатель адреса, который растёт с каждой новой записью, и есть список данных. А организовывать работу можно и так и так.

[Dale]

Если сравнивать транзит регистр-регистр и само вычисление суммы, думаю всё-таки считает он дольше.

Типичный 64-разрядный сумматор с параллельным переносом имеет задержку порядка 5td (т.е. в 5 раз превышает задержку на стандартном вентиле). Для того, чтобы доставить на его входы данные из РОН, необходимо подать адрес регистра на шину памяти, произвести цикл чтения, зафиксировать содержимое выборки в буфере, произвести суммирование. Затем нужно еще сохранить результат в РОН (т.е. опять подать его адрес на шину адреса и провести цикл записи). Сомневаюсь, что все это в сумме окажется меньше 5td. Если операнды/результат хранятся не в РОН, а в ОЗУ, все будет еще гораздо мрачнее.

Мне интересно: как правильно сравнивать эффективность?

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

Если серьезно, вот Вам пример из практики. На излете СССР у меня было два основных инструмента для работы: 16-разрядная СМ-1420 и 32-разрядная СМ-1700. СМ-1420 превосходила СМ-1700 приблизительно в 4 раза на коротких операциях (типа регистровых сложений/пересылок и т.п.), если закрыть глаза на разницу в длине слова. А вот на относительно большой (не на пару секунд) вычислительной задаче СМ-1700 опережала СМ-1420 приблизительно в 7 раз. Вопрос: кто из них эффективнее? Правильный ответ: а смотря что нужно сделать.

Еще вариант (из 8-битного мира). Нужно сложить 2 байта. На i8080: пересылаем операнд в аккумулятор; выполняем сложение со вторым операндом (в одном из регистров); пересылаем результат из аккумулятора по месту назначения. На ATmega: складываем два регистра. То есть на одной архитектуре может понадобиться выполнить множество операций (например, гонять данные с места не место, потому что только специализированный регистр может выполнить некое действие), которые на другой просто не потребуются.

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

Вот у меня в системе сейчас выполняются 240 процессов и 2516 потоков, хотя нет серьезной нагрузки. Они просто порвут в клочья единственное ядро, которое постоянно будет переключать контекст.

С повышением частоты растут расходы на вычисления, причём нелинейно.

Почему? Я считаю, что чем больше работы выполняется на один тик, тем меньше накладные расходы на мультизадачность (каждое переключение что-то стоит).

Обычно пытаются сравнивать ARM с x86, первый работает на 400 МГц, условно, а второй на 3 ГГц. Полагаю, что если сравнивать в условии равных частот, равного, хотя бы условно, ПО, то преимущества RISC будут не такими уж и значимыми.

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

[Aether]

Вот у меня в системе сейчас выполняются 240 процессов и 2516 потоков, хотя нет серьезной нагрузки. Они просто порвут в клочья единственное ядро, которое постоянно будет переключать контекст.

Не порвут. Даже если будет десять ядер, то критическое число задач можно оттянуть, но не разрешить ситуацию принципиально. Вот пример: пользователь запускает интерактивное приложение, которое представляет собой один процесс, который "потребляет" 2 ГГц, а у Вас десять ядер по 200 МГц. Что будет? Разделить один поток на разные ядра не выйдет, поэтому либо дикие тормоза (одно ядро тянет, остальные отдыхают), либо покупка другого процессора. Одноядерный процессор ПК с 3 ГГц этот поток осилит, и оставшиеся 1 ГГц запросто съедят 2516 микропотоков, многие из которых в полусонном состоянии. А теперь обратная задача: 10000 потоков по 1 МГц, получается одно ядро потребуется в виде 10 ГГц, и тут лучше иметь сервер с 50 ядрами по 200 МГц, так как суммарное потребление энергии окажется ниже, но есть и другие плюсы.

С повышением частоты растут расходы на вычисления, причём нелинейно.

Почему? Я считаю, что чем больше работы выполняется на один тик, тем меньше накладные расходы на мультизадачность (каждое переключение что-то стоит).

Я имел ввиду характеристику потребления электроэнергии логическим элементом, в данном случае КМОП образным. То есть, тут как у реактивного самолёта - с одной стороны летим мы как бы быстрее, но при этом запас топлива закончится ещё быстрее, и суммарный пролёт в сверх звуке окажется короче. Исторически принимались схемотехнические решения в виде ЭСЛ, и технологические в виде перехода на арсенид-галлиевые кристаллы, но цена за скорость остаётся прежней.

К чему собственно я говорил о свободном ПО: пользователь, заинтересованный в полезности работы своего ПК, будет стремиться не допустить к исполнению мусорные задачи, и только при полном доступе к ресурсам он имеет шанс это сделать. А без этого будут со временем и стоядерные по 10 ГГц аппараты, которые будут успешно тормозить при загрузке Word 5000. К сожалению, это одна из теней современной экономики, когда есть куча товаров, в каждом из которых отсутствует эксплуатационное качество лишь для обеспечения экономического тока.

[Dale]

Вот пример: пользователь запускает интерактивное приложение, которое представляет собой один процесс, который "потребляет" 2 ГГц, а у Вас десять ядер по 200 МГц. Что будет?

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

Потоков должно быть больше, чем ядер, благо у ширпотребных процессоров ядер пока не слишком много.

А теперь обратная задача: 10000 потоков по 1 МГц, получается одно ядро потребуется в виде 10 ГГц

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

С повышением частоты растут расходы на вычисления, причём нелинейно.
...
Я имел ввиду характеристику потребления электроэнергии логическим элементом, в данном случае КМОП образным.

Для КМОП как раз характеристика достаточно линейна. До такой степени, что производители приводят такой параметр, как энергия переключения элемента (затраты энергии на один переход 0/1 или 1/0), считая, что в статике потребление настолько мало, что им можно вовсе пренебречь.

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

Сопоставьте мизерное потребление современных быстродействующих микроконтроллеров с раскаленным утюгом КР580ВМ80 на паре жалких мегагерц тактовой частоты.

Исторически принимались схемотехнические решения в виде ЭСЛ, и технологические в виде перехода на арсенид-галлиевые кристаллы, но цена за скорость остаётся прежней.

ЭСЛ - это исключительно битва за скорость. Энергоэкономичностью там даже и не пахло, требовалось принудительное охлаждение корпусов.

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

будут со временем и стоядерные по 10 ГГц аппараты, которые будут успешно тормозить при загрузке Word 5000.

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

[Aether]

Современное успешное приложение просто не имеет права быть однопоточным.

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

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

Потоков должно быть больше, чем ядер, благо у ширпотребных процессоров ядер пока не слишком много.

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

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

Накладные расходы это сложная тема, можно и десять процессов переключать так часто, что 30% ресурсов сдует моментом, но это будет платой за высокую скорость реакции. С другой стороны, можно один процесс выделять для пользователя так, чтобы не было проблем с интерфейсом, а остальным остаток делить пропорционально - тут и десять тысяч потоков могут занять лишь 5% ресурсов на переключение. Самый плохой подход это, например, оконный режим, когда несколько приложений требуют интерактивности - приходится как-то поделить квант рисования видео кадра на всех, вот тут и выясняется, что чего-то не хватает.

Для КМОП как раз характеристика достаточно линейна.

Если рассматривать затвор, как ёмкость, то всё действительно более-менее линейно, а если прибавить омическое сопротивление проводников, то часть мощности пойдёт на нагрев дополнительно. Ни и это не единственные причины, ведь есть ещё и скин-эффект и излучение. Возможно, у нас немного разные данные, и все они правильные, просто каждые в рамках конкретного устройства и технологии.

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

Проблема в бессистемности, то есть Word 5000 - это компонент стратегии: задача -> технология (математика и организация) -> x86-64 (аппаратная реализация) -> Windows (программная реализация) -> Word 5000 (программная реализация конечного продукта). В итоге, OpenOffice даже 20000-ой версии будет тем же самым видом сбоку на Word 5000, конечно кое-что будет и лучше, но не радикально. Это как взять запорожец для коммерческого извоза, и поставить в него магнитолу. Да, ездить станет приятнее, но значительного комфорта не появится пока не будет полноценного системного решения.