> Причина этих ограничений: железячники не умеют проектировать протоколы.

Железячники умеют проектировать протоколы. Например, Ethernet. До сих пор работает.

Причина этих ограничений, в том, что любой проводник на плате, на шинном
разъеме - это маленькая доля в себестоимости устройства. И закладываться
на 32-битные и 64-битные адреса, когда больше 1 Мб RAM "в обозримой перспективе
не просматривается" как-то невыгодно. Конечно, надо заглядывать вперед,
но прогресс идет такими зигзагами темпами, что любые оценки
необходимой величины адресного пространства - это волюнтаризм, более-менее
подкрепленный правдоподобными рассуждениями.

При переходе с TCP/IP ver. 4 на TCP/IP ver. 6 длина IP-адреса увеличивается
с 32 до 128 бит. Кажется, что теперь навсегда хватит... Интересно, долго ли
продержится эта иллюзия ? С другой стороны, если мы даже понимаем, что это -
иллюзия, где все-таки остановиться ? На 256 ? На 1024 ? ...

> А зачем мне другой процессор, когда мне и нынешнего много?

Вам, возможно.
Но Вы не один на планете.
Некоторым не хватает.

Собственно, Вы подтверждаете мои подозрения,
из-за которых я и начал задавать эти вопросы (см. выше).

> Серьезно, ну нет таких новинок: x86 как была x86, так и осталась;

Думаю, Вы просто не в курсе.

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

Да и в рамках линейки x86 тоже происходили драматические изменения.
Из моей практики: в 90-х одна программа отлично работала на 286 и
отказывалась работать на 386. Конечно, это была "шибко хитрая" программа,
которая выжимала из процессора все, что только можно (нужно было очень быстро
произвести некоторые вычисления). Можно сказать, что она "работала с аппаратурой",
хотя никакая внешняя аппаратура не использовалась - зато ЦП использовался и в
хвост, и в гриву. Выяснилось, что у 386-го - упреждающая подкачка в кэш, и потому
некоторые обновления не достигают процессора. Разобраться было сложно, исправить -
просто. Это пример, когда от программы требуется некоторая "особая эффективность",
и этим он близок к случаям "работы с оборудованием". Возможно, Вам такие задачи
не попадались, или Вы инстинктивно их избегаете... Это, опять же Ваш выбор. А вот
мне такие задачи как раз нравятся, я, можно сказать, специалист по ним :)

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

"Причина этих ограничений, в том, что любой проводник на плате, на шинном
разъеме - это маленькая доля в себестоимости устройства. И закладываться
на 32-битные и 64-битные адреса, когда больше 1 Мб RAM "в обозримой перспективе
не просматривается" как-то невыгодно."
Конечно! Давайте каждые два года добавлять один бит в ширину шины, а программисты пусть мучаются?
Вы понимаете, что это перекладывание с больной головы на здоровую?
Железячники экономят два цента, программисты переписывают тонну критического софта каждые два года, пользователи десять лет живут с крайне нестабильным ПО, которое всё время в процессе переписывания.

"При переходе с TCP/IP ver. 4 на TCP/IP ver. 6 длина IP-адреса увеличивается
с 32 до 128 бит. Кажется, что теперь навсегда хватит... Интересно, долго ли
продержится эта иллюзия ?"
Я слабо представляю, как кому-то может не хватить 128 бит.
Они что, каждому атому солнечной системы айпишник выдать хотят?
Сдуру, конечно, можно много чего сломать, растащив куски адреса на технические нужды.

Но вообще ipv6 - это навсегда.

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

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

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

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

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

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

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

> Они что, каждому атому солнечной системы айпишник выдать хотят?

Нет, всего-навсего каждой кофеварке, холодильнику, проигрывателю и мобильному телефону.

> Сдуру, конечно, можно много чего сломать, растащив куски адреса на технические
> нужды.

Это, несомненно, будет сделано,
"и делается уже" (c) :)

> Но вообще ipv6 - это навсегда.

Вы просто повторяете Била Гейтса,
который в 198Х-м году сказал,
что 1 Мб оперативки хватит навсегда.

Знаем мы цену таким прогнозам.

> 64-битное адресное пространство, кстати, тоже.

Кстати, тоже

> Так выпьем же за инерцию в прогрессе хардвера!

Да, давайте все будем работать на первом пне...

Хотя, мне лично всегда больше нравилось 486DX :)
Одна только фигня с ней - не успевала подхватывать
прерывания от карты 100Мб Ethernet. Впрочем, рост
скоростей передачи данных тоже можно законодательно
заморозить.

Да, двух- и более-ядерные процессоры надо немедленно отменить!
Или, по крайней мере, запретить ОС их замечать...

> Так вот, в треугольнике железо - ОС - софт железячники нагло, безосновательно совершенно прихватизировали изменения.

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

Вообще, тут смешаны две совершенно разные проблемы:
1) усовершенствования в хардвере (которые хоть и напрягают, но их игнорирование
приводит к гарантированному отставанию).
2) зоопарк устройств, связанный с множеством конкурирующих производителей.

Первая, на мой взгляд, принципиально неустранимая,
вторая - неустранимая в рамках данной социальной формации.

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

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

"Нет, всего-навсего каждой кофеварке, холодильнику, проигрывателю и мобильному телефону."

2^128 - это вообще-то 3.4^38.
Я понимаю, конечно, потребительская революция в китае, но нет у нас столько кофеварок.

"Мне кажется, все находится в развитии, и быстрее всего все-таки прикладной софт."
Прикладной софт не общается с железом! А когда общается, то это у него получается плохо.
А вот ОС вынуждена стоять на месте, пока железо ползает и копошится.

Вот это-то и ужасно!

# Я отчетливо помню время, когда SMP было новым и нестабильным.
А на подходе многоядерные (n > 2), так что форс-мажор еще впереди.
И ваще, надо немного больше смотреть назад и вперед.

# Возможно, в кофеварке понадобится не один ip-ник :)

# ОС не так уж и стоят на месте.
Например, Linux довольно ловко подхватила 64-битные архитектуры.
Да и в самой ОС какие-то подвижки постоянно происходят,
а если и медленно - у меня нет ощущения, что это из-за
аппаратуры, скорее причина - внутренняя. То же могу сказать
про FreeBSD. Впрочем, я не варился внутри этих проектов,
сужу только по внешним признакам.

А в чём форс-мажор от многоядерности?

Вот у меня сейчас два. Приятно: можно собирать -j3, флеш-плагин, когда тупит, отъедает всего одно ядро. Минусов не заметил :)

а если их будет 4 ?
софт новых просто не заметит.
а переделанный софт (в данном случае - ОС) -
это, как всегда, новые ошибки :)

"софт новых просто не заметит."
?? Какой софт?

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

Ну и да, make -j5 давно уже.

отлично!
но ведь в какой-то недавний момент это было проблемой :)

какой софт ? планировщих ОС за это отвечает, вроде-бы

кстати, что такое make -j5 и причем оно тут ?

Планировщик моей ОС умеет многопроцессорность лет на десять дольше, чем мне это понадобилось.
Твоей - тоже, кстати.

-j [jobs], --jobs[=jobs]
Specifies the number of jobs (commands) to run simul‐
taneously. If there is more than one -j option, the
last one is effective. If the -j option is given
without an argument, make will not limit the number of
jobs that can run simultaneously.

Распараллеливание компиляции, работает сто лет.

Простите, коллега, но это к SMP не имеет никакого отношения
и появилось значительно раньше.

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

Конечно, как разные процессы!

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

Вопросы? Предложения?

они будут работать на 4х ядрах, если планировщик ОС
умеет размещать процессы на 4х ядрах. а умеет ?
и давно ли ?

Умеет. Лет 15 как.
make -j3 работает тоже лет 20, как.

> Умеет. Лет 15 как.

Какая именно ОС ?

> make -j3 работает тоже лет 20, как.

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

"Какая именно ОС?"
Linux?

"Это, как мы уже выяснили, вообще про другое."
Выяснили мы, что ты путаешься в трёх соснах.

Сначала восклицаешь:
jobs запускаются как отдельные процессы.
Потом спрашиваешь:
если планировщик ОС умеет размещать процессы на 4х ядрах. а умеет ?

Сам же себе ответил.

>> Умеет. Лет 15 как.
>"Какая именно ОС?"
>Linux?

Хм... ты прав. Linux - c 1996, WinNT - c 1993.
Не думал, что так давно.

> Выяснили мы, что ты путаешься в трёх соснах.

Вовсе нет.
Псевдопараллельные процессы имеют смысл и на 1 процессоре.
Читай меня внимательней :)

Имеют :) Но вот.

Даже с x86 не все так гладко.

x86-64 is a superset of the x86 instruction set architecture.
(отсюда: http://en.wikipedia.org/wiki/X86-64 )
т.е. чтобы воспользоваться этими возможностями, надо что-то поправить
в консерватории

софтвере.

А тем временем Intel сделал попытку уйти от х86 ( http://en.wikipedia.org/wiki/IA-64 ),
но массовый рынок игрушку не принял. Зато в высокопроизводительных вычислениях она
вроде-бы на месте.

> Да всем давно пофиг, честно говоря, главное, чтобы шустрая была.

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

IA-64 не интересна.
В первую очередь потому, что под нее очень сложно писать виртуальные машины/JIT.

Ну и в принципе - оно медленное и при этом сложное. За такие-то деньги!

А x86-64 на сервере - уже реальность, на клиенте всё равно, что происходит, там вообще только браузер нужен.