x86 капец

Если не нужно конкретно тебе - это не означает, что это не нужно всем

Ну так покажи кому, а то я не вижу. Разве что крестовикам, но там уже минимум двадцать ядер нужно — слишком уже долго иначе компилируется.

Разве что крестовикам, но там уже минимум двадцать ядер нужно — слишком уже долго иначе компилируется.

Мне 8 пока хватает, через год думаю какой-нибудь 3900X с 12 ядрами поставить.

Мне 8 пока хватает, через год думаю какой-нибудь 3900X с 12 ядрами поставить

А теперь представь, что я 7 лет подряд проект на 4 млн строк компилил на одном ядре ноута.

ok, you win, hands down:)

А что мешает разбить такой проект на 40 проектов библиотек по 100 тыс строк и компилить только ту, над которой работаешь? А потом ещё и научиться компилировать только изменённые объектные файлы для пущего удовольствия.

Победила Windows 95, а её заменили в итоге на юниксо-подобную Windows NT

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

Сходу.
1. Тяжеловесные страницы это не только пейсбук. Например торговые площадки.
2. 1С - мягко говоря куда как прожорливее стала.
3. А если говорить про обьем, то согласитесь что за 10 лет работы компании он таки станет больше. И это касается не только 1С. Что бы не использовали, хоть excel, хоть любую СУБД &etc обьем данных за время работы компании таки вырастает.

Но в целом я с вами согласен, основная проблема не в железе, а в софте как таковом. Софт перестает справляться с возросшими объемами данных, есть два выхода:
1. рефакторинг, чем софтверной компании заниматься ну совсем неохота.
2. более мощное железо.
Пункт первый редко но встречается. Чаще всего не в ИТ компаниях но где есть свой отдел девелоперов. Реже у компаний разрабатывающих узко специализированное ПО. Но всё это капля в море. Поэтому в основном, к сожалению, оказывается пункт второй.
Современный софт, включая(особенно) вэб, это 100 слоев абстракций, для вычисления 2+2.

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

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

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

Разве что крестовикам, но там уже минимум двадцать ядер нужно — слишком уже долго иначе компилируется.

А теперь представь, что я 7 лет подряд проект на 4 млн строк компилил на одном ядре ноута.

А теперь представь, что проект (c++) больше 1 млн строк я компилил шустро ещё в 2003-м году емним на дуроне 600, да, сейчас пошустрее стало но так же на одном ядре потому что уже в виртуалке и большего мне не надо.

Нет именно как я написал. Первично была утилизация. А «перемещение этих сервисов между узлами» появилось гораздо позже уже как следствие. Варя ещё с конца 90-х робила.

Тебе ничего не мешает запускать несколько сервисов в одной ОС

Мешает если это разные ОС.

1. Тяжеловесные страницы это не только пейсбук. Например торговые площадки.

Перегруженность скриптами - это точно такая же проблема торговых площадок, а не объективная необходимость

1С - мягко говоря куда как прожорливее стала.

И из-за этого весь мир должен клепать процессоры в 7, 5 и 3 нм? )

А если говорить про обьем, то согласитесь что за 10 лет работы компании он таки станет больше. И это касается не только 1С. Что бы не использовали, хоть excel, хоть любую СУБД &etc обьем данных за время работы компании таки вырастает.

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

Но в целом я с вами согласен, основная проблема не в железе, а в софте как таковом.

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

Современный софт, включая(особенно) вэб, это 100 слоев абстракций, для вычисления 2+2.

Мне еще нравится термин «накладные расходы» по отношению к программированию. Косвенные расходы, не являющиеся необходимыми. Например по абсолютно субъективным прикидкам, 95% технологических задач на производствах решабельны с помощью микроконтроллеров и компьютеров 20-30 летнего возраста. Но это и позор с точки зрения внедрения современной техники, и вспомогательных рюшечек хочется :)

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

Я писал не только про 1С и экономистов. Например, мы создали SoftName заложили относительно ТЗ 1000% увеличения нагрузки со временем, протестировали, прошло время, у пользователей аппетиты растут, софт модифицируется согласно требованиям пользователей, и/или данных становиться больше, и вот наступает тот самый момент, что то что работало на том же железе «10 лет» назад, дико тормозит уже в текущей ситуации.
А архивные базы само собой. Это только в актуальной где нужны все данные оперативно.

RISC-V

После того как MIPS освободили от патентов его можно закапывать.

Хотя ещё неизвестно, лучше ли Canvas (или чем там заменяют флеш?), чем Flash?

Ну естественно. Теперь ты тупо пишешь код на чем угодно, компилируешь в вебассемблер и твое приложение тупо рисуется в канве https://www.newgrounds.com/portal/view/758385
В основном на юнити-веб сейчас клепают

у пользователей аппетиты растут,

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

Стоит пейсбуку или какому-нибудь инетмагазину распухнуть скриптами и объемом до такой степени, что страница будет тормозить на приличной части массовых компов-смартфонов - проблема уменьшения накладных расходов никуда не денется )

Я приблизительно об этом и написал. Для вариантов узкоспециализированного софта как раз идут на рефакторинг. Для массового «забивают болт» на пользователей. А-ля «у вас на старом смартафоне не робит/тормозит? Покупайте новый», так же и с любим другим железом. Планета потребителей. Sad but true.

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

Имхо юзверы будут страдать, но кушать кактус. То есть покупать новое(более дорогое) железо. «Иначе я в любимом чатике не пообщаюсь». Это же не только к ИТ относиться, абсолютно ко всему рынку потребления, чайники, микроволновки, машины &etc

Имхо юзверы будут страдать, но кушать кактус. То есть покупать новое(более дорогое) железо. «Иначе я в любимом чатике не пообщаюсь». Это же не только к ИТ относиться, абсолютно ко всему рынку потребления, чайники, микроволновки, машины &etc

Ну да, все так, но я больше будущее прогнозирую ) Рост производительности процессоров замедлился, а возможно и скоро упрется в технологические нюансы. То есть дальнейшее «потребление кактуса» может начать обходиться юзерам слишком дорого. И проблема перекочует уже с юзеров на чатоводов и продавцов рекламы. Будет интересно понаблюдать.

Тут тоже есть нюанс. Человек существо адаптирующееся. Скажут что «теперь все работает медленнее и сделать ничего нельзя», будут кушать кактус. Главное что хоть как-то но работает.
И потом будут вспоминать, как и мы старперы, что раньше и солнце было ярче и щи кислее. :)

ЗЫ Разве много появилось криков со стороны пользаков после обновлений Meltdown & Spectre ? Ну покричали. «А караван идет» (с)

Тут тоже есть нюанс. Человек существо адаптирующееся. Скажут что «теперь все работает медленнее и сделать ничего нельзя», будут кушать кактус. Главное что хоть как-то но работает.

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

Разве много появилось криков со стороны пользаков после обновлений Meltdown & Spectre ? Ну покричали. «А караван идет»

Эти дыры - чисто психологическая проблема небольшой части параноидально напряженных пользователей. Остальным на подслушивание чихать. Объективных то проблем они не доставляют. В отличие от открывания вкладки по 2 минуты с подвисаниями.

Ерунда все это. Никакого капца не будет.

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

Intel - это не только процессоры, это еще и исследования, это еще и разработка и локомотив того что на сегодняшний день считается стандартом - PCI express, USB, SATA, NVM, WiFi и тд итп, список огромен.

Ну выпустит условный Amazon, новый Graviton 100500 на ARM-архитектуре, ну затребует этот Graviton шину x100500 для обмена данными, и раз уж он такой оуенный, то вместе с этим и SATA v.100500 и USB100500.1 для устройств - Амазон шоле будет проводить исследования на тему из какого изотопа какого вещества делать проводники ? Или кетайский Allwinner, забивающий на свои же процы спустя год ? Ахахаха.

Apple в этом плане чуть удобнее, фанбои будут жрать говно, если Эппл скажет, и убеждать других в том что это круто и элитно.

• Вася, у тебя Intel, а у меня AMD, грузится на 10 сек быстрее, стоит в два раза меньша.
• Да, Петька, ты прав, Intel зажрался, пойду куплю AMD.

…

• Коля, твоя Каталина грузится 30 сек, приложухи открывает с задержками, внешний вид прибит гвоздями, и занимает 20 гиг, а моя Манжара грузится за 5 сек, может быть кастомизирована как я захочу, работает как молния и занимает 5 гиг.
• Ну и что, зато это Apple.

Если даже Cyrix\VIA несмотря на полную бинарную совместимость не смог - то ARM и подавно будет в жопе где ему и место.

А что мешает разбить такой проект на 40 проектов библиотек по 100 тыс строк и компилить только ту, над которой работаешь? А потом ещё и научиться компилировать только изменённые объектные файлы для пущего удовольствия

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

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

Это не пиар, это правда. Более того, она не стала наследником VMS, а создавалась без тяжести наследия, за исключением собственного виндового. Таким образом она получила: нормальный многопоток без fork; продвинутые права доступа к файлам и другим ресурсам системы, вроде рабочего стола или сокета; RPC на уровне ядра, а не как в DBus, где нужно минимум четыре смены контекста для одного вызова; самая продвинутая система инициализации в мире на то время; встроенную в ядро графику, что сделало ее на много лет номер один платформой для игорей и только сейчас Wayland пытается повторить этот подвиг.

А теперь представь, что проект (c++) больше 1 млн строк я компилил шустро ещё в 2003-м году емним на дуроне 600, да, сейчас пошустрее стало но так же на одном ядре потому что уже в виртуалке и большего мне не надо

Поздравляю, коллега. Так что, больше двух ядер не нужно?

Например по абсолютно субъективным прикидкам, 95% технологических задач на производствах решабельны с помощью микроконтроллеров и компьютеров 20-30 летнего возраста

20-30 лет назад все-таки шли на большие ухищрения для того, чтобы выдавить последние крохи производительности из системы. Собсна, примерно поэтому у нас до сих пор используются монолиты в качестве ядер ОС.

В отличие от открывания вкладки по 2 минуты с подвисаниями.

Я только об этом. Ну будет по 5 минут висеть. Если решения нет, будут продолжать «кушать» ибо так сказали «сверху». А «Вишенку» «мы всегда добавим» типа «зато новая функция появилась» так уже много лет идет и пофигу что Лично Вам эта «Вишенка» не нужна.

Без обид. Но, прочитал бред человека который никогда не видел winapi.

Поздравляю, коллега. Так что, больше двух ядер не нужно?

Лично мне для конпеляния конкретного проекта ненужно. dixi

Без обид. Но, прочитал бред человека который никогда не видел winapi

Вот так вот, семь лет под винду пишешь, а тебе потом «прочитал бред человека, который никогда не видел winapi». Пардон, нескромный вопрос: а ты под винду сам когда-нибудь писал?

С середины 90-х. NT это с 3.5 (правда быстро на 3.51 перешло, кстати хорошая система была до 4.0). А надстройки это с 3.1
И что бы два раза не вставать. Основной системой дома был OS/2. На работе шинда. Был кейз с кучей дисков с доками winapi купленный официально за не маленькие деньги, поверьте на слово, я знаю о чем топлю.

PSS

Вот так вот, семь лет под винду пишешь, а тебе потом «прочитал бред человека, который никогда не видел winapi»

Что бы третий раз не вставать. Вот вы «последнии семь лет» пишите под шинду. Используете функции winapi? Прямо создаете кучу структур, которые передаете в функцию, которая вернет значение, потом ещё кучу структур, которую передаете в другую функцию и так далее? Вы драйвера пишите?
Или все-таки речь про написание на каком-нибудь c# в VS? А к winapi мы не прикасаемся и даже не знаем что это такое?

Был кейз с кучей дисков с доками winapi купленный официально за не маленькие деньги, поверьте на слово, я знаю о чем топлю

Доки по winapi уже довольно давно распространяются бесплатно, а для особо желающих есть полные сорцы самого ядра и клиентских библиотек для NT 4.0, на базе которых сделан ReactOS — сорцы последнего использовать безопаснее в плане проблем с законом. А всё дело в том, что помимо документированных фич есть недокументированные, и любая глубокая разработка неизбежно приходит в эту область.

Вы драйвера пишите?

Нет, не пишу. Тебе есть что ответить по тезисам из исходного сообщения?

x86 капец (комментарий)

Если нет, то проходи мимо.

А всё дело в том, что помимо документированных фич есть недокументированные

Вот! С этого мы и начинали «вирусопейсательство», точнее шуточные програмулины друг другу подсовывать на 1-ое апреля. На этом и закончили благо повзрослели и уже не так интересно стало. Если вы не в курсе то это ещё с msdos пошло. У меня где-то книжка завалялась по недокументированным функциям. Кстати очень вкусные.
Поэтому некоторый софт типа автокад не запускался на pcdos и многие другие.

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

ЗЫ Но Вы так и не ответили на вопрос. Правда последнии 7 лет что-то писали используя winapi напрямую ?

Веский спич, но не по теме. Тема была про «юникс-подобность».

С какого-то фига в том же рендренге и т.п. шинда да-авно не была лучшей. Почему? Пиксар создавал мульты на шинде? Нет. dreamworks на шинде? Нет. Надеюсь линейка понятна?

Pixar делал мульты на собственной системе, котора появлилось у него еще до приобретения джобсом, и использовали они много чего, в том числе раб станции от Silicon Graphics и Sun с его NeWS.

Но вот шёл 1995 год, в винде было OpenGL и вот-вот появлялось Direct3D, Next отходил от производства компов и ОС в сторону кроссплатформы, эпл сделал ставку на QuickDraw 3D вместо OpenGL, которая в итоге не сыграла и в 1998 году с приходом жобса эпл таки принял OpenGL, отстав таким образом от винды на несколько лет.

Возвращаясь к тезису: я не писал про рендеринг в целом — я присал про игры. Модификация Display PostScript (DPS) от Джобса уделала NeWS и X server еще до появления 32-битных форточек за счет отказа от поддержки сети. Причем, другие софтописатели пытались натянуть DPS на X-сервер, и ничего толкового у них не получилось. Этим опытом невозбранно воспользовался Бил Гейтс, создав минимальную прокладку между пользовательским софтом и железом. В том числе это вылилось, например, в замечательное аппаратное ускорение прокрутки и перемещения окон, которое не связано с играми, но все же — это в итоге сделало винду платформой номер один для домашних графических десктопов. Pixar и Dreamworks — это совершенно другой сегмент, это не компы для домохозяек.

Но Вы так и не ответили на вопрос. Правда последнии 7 лет что-то писали используя winapi напрямую?

Я много чего использовал, и напрямую, и не напрямую. Когда ты работаешь с проектом на миллионы строк, то там кроме WinAPi есть очень много самых разных API, с которыми приходится работать.

Веский спич, но не по теме. Тема была про «юникс-подобность»

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

Я много чего использовал, и напрямую, и не напрямую. Когда ты работаешь с проектом на миллионы строк, то там кроме WinAPi есть очень много самых разных API, с которыми приходится работать.

Ясно, по Жванецкому «долго бился головой об стену, в общем ушел от ответа»

Ясно, по Жванецкому «долго бился головой об стену, в общем ушел от ответа»

Это был ответ. Что тебе еще нужно? Здесь люди софт пишут, а не языком по клаве возят.

Это был ответ. Что тебе еще нужно? Здесь люди софт пишут, а не языком по клаве возят.

Ну давайте скопипастите простой «на три захода» вариант winapi. Тогда я поверю вашим словам.

Ну давайте скопипастите простой «на три захода» вариант winapi

Я не понял этой фразы.

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

Но ведь не на бОльшие же, чем на создание процессоров на единицах нанометров ) И в общем это нормальный профессионализм разработчиков и программеров - делать свой предмет эффективно с вниманием к мелочам. А то в соседних топиках все время всплывает понятие «говнокод» и плач по поводу тяп-ляп програмирования. А попробуй напиши говнокод в микроконтроллер с 1 килобайтом памяти ) Или чтобы на дискетку поместились сеть, математика, управление, БД и UI :)

Ну будет по 5 минут висеть. Если решения нет, будут продолжать «кушать» ибо так сказали «сверху». А «Вишенку» «мы всегда добавим» типа «зато новая функция появилась» так уже много лет идет и пофигу что Лично Вам эта «Вишенка» не нужна.

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

И в общем это нормальный профессионализм разработчиков и программеров - делать свой предмет эффективно с вниманием к мелочам

«Premature optimization is the root of all evil». Оптимизированный код тяжело писать, отлаживать, поддерживать. Оптимизированный код — это одна из причин наличия уязвимостей в никсах, винде, и еще куче софта.

А попробуй напиши говнокод в микроконтроллер с 1 килобайтом памяти ) Или чтобы на дискетку поместились сеть, математика, управление, БД и UI

Дешманючие SoC-и для вских роутеров или бабушкофонов стоимостью менее доллара (оптом) по техпроцессу 40 нм обладают памятью в мегабайты, а если устройство стоит несколько долларов, то там уже наверняка будут десятки мегабайт. За 20$ уже можно приобрести ПЛИС и запрограммировать его процессором, на который встанет линь.

«Premature optimization is the root of all evil». Оптимизированный код тяжело писать, отлаживать, поддерживать. Оптимизированный код — это одна из причин наличия уязвимостей в никсах, винде, и еще куче софта.

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

Дешманючие SoC-и для вских роутеров или бабушкофонов стоимостью менее доллара (оптом) по техпроцессу 40 нм обладают памятью в мегабайты, а если устройство стоит несколько долларов, то там уже наверняка будут десятки мегабайт. За 20$ уже можно приобрести ПЛИС и запрограммировать его процессором, на который встанет линь.

А зачем вы это сообщили? Речь была о том, что большинство технологических задач на производстве решаемо на процессорах и контроллерах 20-30 летней давности. Основное можно сделать, не вылезая за килобайты-мегабайты и мегагерцы тактовой. Какой-то явной потребности в гигабайтах и гигагерцах у производства не было и нет. Реальный мир попросту не имеет таких скоростей и таких объемов информации. Навязанные излишества по бросовой цене.

Ладно, убедил.

Речь была о том, что большинство технологических задач на производстве решаемо на процессорах и контроллерах 20-30 летней давности. Основное можно сделать, не вылезая за килобайты-мегабайты и мегагерцы тактовой

1995 год — это десятки мегагерц, даже на низкопроизводительных контроллерах. На последних актуальны 16 бит, а значит 64 Кб памяти. Современные устройства до сих пор работают на сотнях мегагерц, что недалеко от показателей того времени. Да, памяти было сильно меньше, но она была быстрее, на уровне процессорного кэша. К слову, такое построение оперативки применяется до сих пор, когда у контроллера кроме «L2 кэша» оперативной памяти нету.

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

Какое производство? Если речь идет про какое-нибудь ЧПУ, то там уже нужны десятки мегабайт при условии, что мы напрочь забываем, откуда берется эта самая программа для станка. Сколько нужно оперативной памяти, чтобы уместить картинку с экрана 20"? Уже мегабайты, Контроль положения и коррекция осуществляется миллионы раз в секунду. А иначе зачем тебе вообще ЧПУ?

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

1995 год — это десятки мегагерц, даже на низкопроизводительных контроллерах.

А 90-й год - это единицы мегагерц и что? О чем мы вообще говорим?

Какое производство?

Почти любое.

Если речь идет про какое-нибудь ЧПУ, то там уже нужны десятки мегабайт

Не нужны. Координаты, траектории, скорости с любой разумной дискретностью - это информация объемом в единицы-десятки килобайт

Сколько нужно оперативной памяти, чтобы уместить картинку с экрана 20"?

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

Контроль положения и коррекция осуществляется миллионы раз в секунду

Миллионы раз в секунду для движения реального предмета? Зачем? ) За миллионную долю секунды даже высокооборотное сверло повернется на жалкие доли градуса, а уж что касается перемещения… )

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

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

А гигабайты и гигагерцы - это порождение виртуального мира для обслуживания самого себя.

Координаты, траектории, скорости с любой разумной дискретностью - это информация объемом в единицы-десятки килобайт

Типовой ротационный энкодер на 2000-5000 PPR при 50 оборотов в секунду будет выдавать сотни тысяч импульсов в секунду, и для обработки только одного этого сигнала нужно будет минимум единицы мегагерц. Мне кажется, что ты застрял в девяностых, а технологии ушли вперед.

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

Пардон, ты когда-нибудь разрабатывал программу с станка с ЧПУ? Я в свое время это делал, и я бы в своем уме никогда не сел бы такое разрабатывать в 2020 году с одним только калькулятором, потому что вычисления достаточно тяжелые и ошибиться просто, а узнаешь ты про ошибку только когда получишь брак на выходе.

Миллионы раз в секунду для движения реального предмета? Зачем? ) За миллионную долю секунды даже высокооборотное сверло повернется на жалкие доли градуса, а уж что касается перемещения

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

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

Только он вам ее не даст. Чтобы собрать информацию о человеке, которую можно было бы уместить в несколько килобайт, нужно собрать гигабайты информации об этом человеке, включая фоточки, которые ни в какие килобайты не умещаются, и всю историю его действий в сети.

Все данные со всех датчиков самолета или космической ракеты - в сотню килобайт. Всю мировую литературу за тысячелетия - в один хдд

300 часов показаний датчика пассажирского самолета весят примерно гигабайт.

Типовой ротационный энкодер на 2000-5000 PPR при 50 оборотов в секунду будет выдавать сотни тысяч импульсов в секунду, и для обработки только одного этого сигнала нужно будет минимум единицы мегагерц. Мне кажется, что ты застрял в девяностых, а технологии ушли вперед.

Ротационный энкодер не требует обработку мегагерцами :) Он требует просто счет импульсов, там нечего обрабатывать программно )

Пардон, ты когда-нибудь разрабатывал программу с станка с ЧПУ? Я в свое время это делал, и я бы в своем уме никогда не сел бы такое разрабатывать в 2020 году с одним только калькулятором, потому что вычисления достаточно тяжелые и ошибиться просто, а узнаешь ты про ошибку только когда получишь брак на выходе.

Станки с ЧПУ существуют со времен перфокарт и дискретных схем на транзисторах, а то и на лампах ) Нет никакой объективной потребности в тяжеловесных вычислениях )

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

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

Только он вам ее не даст. Чтобы собрать информацию о человеке, которую можно было бы уместить в несколько килобайт, нужно собрать гигабайты информации об этом человеке, включая фоточки, которые ни в какие килобайты не умещаются, и всю историю его действий в сети.

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

300 часов показаний датчика пассажирского самолета весят примерно гигабайт.

Почему бы не сказать то же самое как 3 мегабайта в час или килобайт в секунду? ) Их тоже не нужно хранить месяцами каждую миллисекунду.

Ротационный энкодер не требует обработку мегагерцами :) Он требует просто счет импульсов, там нечего обрабатывать программно )

Например, нарезка шестигранников, квадратов, и просто самых разных симметричных поверхностей эффективнее всего делается при помощи синхронизировано вращающихся резца и заготовки: https://en.wikipedia.org/wiki/Polygonal_turning

От синхронизации фаз будет зависеть точность изготовления, потому речь идет про доли градуса.

Станки с ЧПУ существуют со времен перфокарт и дискретных схем на транзисторах, а то и на лампах ) Нет никакой объективной потребности в тяжеловесных вычислениях )

Только ты забываешь, что станки с ЧПУ были говном. Раньше вон шестерни часами строгали настанках и не парились, а теперь почему-то всем хочется станок, который за минуту вытачивает полностью готовую шестерню. Эффективная стоимость такого станка — 60 старых, а реально стоит как десять.

Не меняет реальная механика скорость и положение с такой скоростью

От современных ЧПУ требуется высокая скорость реза сложных поверхностей при высокой точности. Иначе они не нужны. Скорости могут быть и десятки сантиметров, и метры в секунду, и если ты не успел за 1/10'000 или даже 1/100'000 секунды определить тенденцию отклонения инструмента, то уже через 1/1000 секунды ты уйдешь на десятки микрон от необходимой формы, получив таким образом брак.

Вот как ты думаешь, почему в звукозаписи используют частоты дискретизации в 40-50 кГц, когда ухо выше 10 кГц уже толком не слышит звук? Основной диапазон-то лежит в районе 500-8000 Гц.

Почему бы не сказать то же самое как 3 мегабайта в час или килобайт в секунду? ) Их тоже не нужно хранить месяцами каждую миллисекунду

Ну, и какой вывод? Гигабайты нужны? Звукозапись там еще жирнее будет с десятками килобайт в секунду.

Всех ваших скачанных и разосланных котиков и просмотренные фильмы в блюрэй хранить тоже не нужно

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

А гигабайты и гигагерцы - это порождение виртуального мира для обслуживания самого себя

Например, нарезка шестигранников, квадратов, и просто самых разных симметричных поверхностей эффективнее всего делается при помощи синхронизировано вращающихся резца и заготовки: https://en.wikipedia.org/wiki/Polygonal_turning. От синхронизации фаз будет зависеть точность изготовления, потому речь идет про доли градуса.

Зачем вы это писали? ) Импульсы с энкодеров все равно не обрабатываются, а считаются )

Только ты забываешь, что станки с ЧПУ были говном. Раньше вон шестерни часами строгали настанках и не парились, а теперь почему-то всем хочется станок, который за минуту вытачивает полностью готовую шестерню. Эффективная стоимость такого станка — 60 старых, а реально стоит как десять.

Современные станки стали лучше за счет более современных технологий позиционирования и обработки, а не за счет усложнения математики. Это все та же механика и геометрия.

От современных ЧПУ требуется высокая скорость реза сложных поверхностей при высокой точности. Иначе они не нужны. Скорости могут быть и десятки сантиметров, и метры в секунду, и если ты не успел за 1/10’000 или даже 1/100’000 секунды определить тенденцию отклонения инструмента, то уже через 1/1000 секунды ты уйдешь на десятки микрон от необходимой формы, получив таким образом брак.

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

Вот как ты думаешь, почему в звукозаписи используют частоты дискретизации в 40-50 кГц, когда ухо выше 10 кГц уже толком не слышит звук? Основной диапазон-то лежит в районе 500-8000 Гц.

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

Ну, и какой вывод? Гигабайты нужны? Звукозапись там еще жирнее будет с десятками килобайт в секунду.

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

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

Ок, назовите примеры из реального мира, которые требуют гигабайтов/гигагерцев. Чтобы это не было нечто виртуальное, начавшееся в компьютере и в нем же закончившееся. Не что-нибудь типа «мы тут сосканировали нечто на терабайт, поэтому нам до зарезу нужно это обработать с помощью терафлопсов чтобы оставить в компьютере те же терабайты, только обработанные.»