Pull to refresh

Comments 500

А не стратегия ли win-win между программистами и аппаратчиками, когда на всё более быстрое железо, выпускается всё более медленный софт (Word 2016 запускается столько же времени, сколько Word95 на компьютере в 500 раз слабее)?
P.S. Привет Electron в Skype…
image
В далеком далеком прошлом ;) нажатие на кнопку формировало картинку на аппаратном уровне. не нашел схемы более низкого уровня ;(
А сейчас цепочка событий распухла до неприличия.
Клавиатуры (блютуз). Буквы в юникоде с модификаторами направления и прочим.
Отрисовка на виртуальном видеоадаптере виртуальной машины. Куча вычислительной
мощности уходит на виртуализацию и отвязку от аппаратного уровня.
Да, производительность губится многими ненужными слоями абстракции. И многие разработчики не думают о том, нужен ли тут очередной слой, а пишут просто так, как принято.

Ну уберут лишнии слои абстракции, оптимизируют код по максимум. Но как это поможет запустить ИИ для Go от DeepMind на мобилке или даже обычном компе (как простая модель ИИ)? Для этого нужна интеграция с другим вычислительным устройством.

Но как это поможет запустить ИИ для Go от DeepMind на мобилке или даже обычном компе (как простая модель ИИ)?
Для чего это? Вы не можете без этого жить прям?

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


Но речь не обо мне одном. Игру Go привел в качестве примера задачи, в которой существует огромное количество ветвлений и неопределенностей на каждом шагу и с которой современные методы на основе глубинного обучения от DeepMind справляются на отлично. Также можно привести в качестве примеров ботов к Starcraft 2, что даже более приближено к реальной жизни, но они пока не обходят уверенно человека.


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

Также можно привести в качестве примеров ботов к Starcraft 2, что даже более приближено к реальной жизни, но они пока не обходят уверенно человека.
А кому будет нужна игра, в которой боты уверенно и всегда будут обходить игрока? :)

жизнь без страданий не жизнь

Ну например играть то всё ещё можно против людей, а ботов использовать для тренировки. Ну и кроме того есть куча игр где можно группой людей играть против одного бота(или меньшей группы ботов) и тогда тоже интереснее если боты сильнее. Если совсем начать фантазировать, то на базе таких ботов можно сделать гораздо более интересных мобов/боссов для каких-нибудь ММО. И т.д. и т.п. :)

А если бот-босс будет читерить, его забанят админы? Или например будет на точке загрузки игроков ждать? Или сражаться только со слабыми персонажами, выбивать часть пати перед смертью итд.

Если будет "читерить", то есть нарушать какие-то заранее определённые правила, то тогда его надо фиксить. Во всех остальных случаях лично я буду только рад.

Бот «обучился» и начал «читерить». Вы предлагаете фиксы, а зачем тогда мы его вообще обучали? Уже Сейчас можно задать ботам такие паттерны поведения, что на форумах только и будут сообщения: «Когда его уже пофиксят?».

У нас с вами по моему какое-то разное понимание того что значит "читерить".


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

Ну вот помню, в WoW был босс (в виде группы ботов, вроде как PvP), который фокусил хилов в пати. Довольно интересный босс был, требовалось много контроля и координации группы.
в какой локации, не подскажете? м...wow. ностальгия… 3 раза из универа отчислялась, благодаря этой игрушке
Испытание крестоносца назывался инст, против чемпионов фракций
Да, но тот босс и рассчитан на такое поведение. Сомневаюсь, что его дпс сравним с дпсом боссов, рассчитанных на танков. Простейшие примеры — боссы, которые уязвимы после применения некоторых способностей (самый частый — враги с огромным оружием, или таранящие) просто перестают применять эти способности и становятся непобедимы. или наоборот, создают неотражаемые комбинации. Чтобы не допустить подобного, придётся опять возвращаться к достаточно жестко заданному поведению.
Вламывал нормально, я как раз хилом играл. Там как раз вся тактика строилась вокруг контроля и сэйвов, чтобы «враги» хилов не перещелкали.
Просто придумываются правила, которые не получается нарушать ))
Скажем красная зона вместо запрета на кемперство.
То, что боты будут умнее, еще не значит, что играть с ними будет не интересно. Просто у разработчиков будет больше возможностей, боты смогут «поддаваться» так, что игрок не будет этого замечать.
Надеюсь, появится ИИ с разным уровнем игры, а не один и тот же ИИ с пенальти / бонусами, в зависимости от уровня сложности.

Почему вы думаете, что пенальти и разный уровень игры — это разные вещи?

Бонус +100% к добываемым ресурсам не изменяет логики самого бота. Если у него есть «баг» в логике, то этот баг там и останется. Как и пенальти на 25% получаемого урона не шибко усложнит игру, если у бота уровень интеллекта и маневренность черного тролля из второй готики.
+25% на получаемый урон от атаки черного тролля в Gothic 2 сделает из него одного из самых страшных врагов. В игре, в которой сложность определяется в том числе и неудобным управлением — это существенное пенальти. 25% даже из падальщика сделают ночной кошмар.
Хоть +1000%. Он является одинм из слабейших противников во второй готике, т.к. его легко забить на первом уровне с обычной палкой на 5 урона с классическим управлением: просто бегаешь вокруг и бьешь боковым ударом. Ударить в ответ он не может, т.к. он очень медленно поворачивается, что позволяет легко держаться за его спиной и успевать бить, так что не смотря на наносимую 1 урона, из-за низкого навыка, силы и урона оружия, умирает он довольно быстро, руки устать не успевают.
Падальщики легко забиваются двуручным оружием с… классическим управлением: просто стоишь на одном месте и машешь оружием вправо-влево. Проклинаемые многими полевые жуки убиваются полностью аналогично, только одноручным оружием. Любого одиночного бойца с двуручем легко убить с одноручником: блок-боковой удар, повторить до смерти оппонента. AI там на столько туп, что сколько не усиливай противников, их довольно легко убить простым набором движений с тем самым «неудобным» классическим управлением, просто анимация обычного удара зависит от навыка и имеет большую паузу в завершении движения связки, а анимация боковых ударов не зависит и имеет очень короткое окно остаточной анимации, из-за чего легко продолжается блоком или ударов в другую сторону.
Потому, что это разные вещи?
Примерно так же, как навык профессиональных игроков прятаться в неочевидных местах и стрелять в полтора пикселя, мелькнувшие на экране разнится от новичка с хаками на автонаведение и показ противников сквозь стены.
Потому что, на примере шутера, пенальти — это искусственно сниженная меткость бота, меньшее количество hp и меньший урон на Easy, а на Hard эти показатели просто выше.
А разный уровень игры предполагает разное поведение бота, у него одинаковое количество hp и одинаковый урон на разных уровнях сложности, не значительно отличается меткость, главное отличие в поведении, во взаимодействии с игроком; засады, ловушки, выработка контр тактики… Разница в ощущения от игры с ботами первого и второго типа — колоссальная!
потому, что боты без пенальти в том же старкрафт видят всю карту в одном окне и им не нужно перемещать камеру в места событий, не говоря уже о том, что они могут делать до 40 000 действий в минуту, а это 666 действий в секунду, человек так делать не может, уже не говоря о том, что alphastar просто пытается эмитировать игру людей без понимания игры, выигрывая только за счёт читов по скорости действий и «видимости всей карты в одном окне» это неоднократно разбиралось на канале Alex007.
А кому будет нужна игра, в которой боты уверенно и всегда будут обходить игрока? :)


И вот создали они себе бог(т)ов, чтобы было кому молиться… :)

история компьютерного язычества (С)
UFO landed and left these words here

А кто ж тогда все доски для го раскупил после того, как это произошло?

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

Военным.
Ну вообще страшненько конечно.

Также можно привести в качестве примеров ботов к Starcraft 2, что даже более приближено к реальной жизни, но они пока не обходят уверенно человека.

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

Я надеялся, что следующая версия ИИ для StarCraft от DeepMind будет обучаться на играх сама с собой. Как было с игрой Go: сначала обучалась на человеческом опыте, потом AlphaZero, которая училась, играя сама с собой.

AlphaStar (ИИ для StarCraft) обучается по той же схеме. Начальное приближение получил от игр людей, а потом играл сам с собой.
От тех же DeepMind боты для дота 2. Играя сами с собой боты пришли к стилю игры — равное распределения ресурсов. И побежлая команды из про игроков доказали жизнеспособность подхода. Но на игре команд это не сказалось. Все по прежнему предпочитают распределение на роли. Возможно это из-за того что игры против ботов были как развлечение.

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

Так боты играли в совершенно другую доту с совершенно другим балансом (в котором у людей не было опыта). В этом варианте доты, действительно, возможно, что равное распределение ресурсов и было более эффективно.

Они не обходят потому что их абузят. Сами боты к тому же нечестные и натянутые на глобус.
На мобилах тот еще прикол.
Виртуальная машина C# работает совместно с виртуальной машиной JAVA
через абстракции Линукса над конкретной архитектурой железа.
При этом все более длительное нужно делать асинхронно, чтобы не мешать
свистолко-перделкам на экране. Так как пользователи любят красивые эффекты
анимации, что действие началось и требуется подождать. Расчетов на 100-200 мс,
а в основном потоке их делать запрещено. ANR прилетит.
UFO landed and left these words here
А C# в Android вообще отродясь не было.
UFO landed and left these words here

AlphaGO требовала больших мощностей для обучения нейросети, но для запуска в последних играх использовался уже всего один компьютер, а не кластер.
Информация из википедии:
Версия, которая выиграла у Фань Хуэя в октябре 2015 года, работала в кластере из нескольких машин с использованием 176 графических процессоров.
В игре с Ли Седолем в марте 2016 года AlphaGo использовала 48 TPU процессоров.
В матче против Кэ Цзе в мае 2017 года новая версия AlphaGo использовала только один компьютер на Google Cloud c 4 TPU процессорами, то есть примерно в 10 раз меньшую вычислительную мощность, чем была использована в матче с Ли Седолем.

О том и речь, что TPU — это другое вычислительное устройство, не обычный процессор CPU.

Учитывая уплотнение компоновки на чипе и появление 64-ядерных процессоров, думаю в скором времени не составит большого труда сделать процессор, в котором будет штук 20 обычных ядер, штук 20 TPU, штук 20 ARM и еще видеоядро как у топовой видеокарты :-)

И фреоновый кондиционер в комплекте =)

Тогда я всё-таки напишу статью "Как настроить циркуляцию в системном блоке или Замена ЭЛТ-монитора для котика".

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

Весь вопрос дадут ли вам доступ к самой сети(данным), а не к вычислителю. Обсчитать при наличии доступа к данным можно на чем угодно.
«ИИ» это апогей человеческого расп*здяйства: люди окончательно «обленились» и вместо того чтобы думать самим — собрались и написали «нейронную сеть», которая будет думать за них… картинки там раскрашивать, моськи голливудских актрис к порнухе прикручивать… эпично, нет слов. Что дальше? Рэпера в президенты и поливать поля газировкой..?? (отсылка к фильму «Идиократия»)
Я вот их тех, кто ненавидит фреймворки и хочет каждый узел оптимизировать пока дым из ушей не пойдёт, обсуждать, планировать систему ДО начала её реализации, учитывать всевозможные нестандартные кейсы её эксплуатации и дальнейшей модернизации, нормализовать данные по максимуму насколько это вообще возможно, обходить стороной сборщики мусора и интерпретируемые языки… но «жизнь такова какова, и никакова больше» (с) поэтому я пишу говнокод на яве и иногда перед сном пустив слезу мечтаю о параллельной вселенной, в которой «всё правильно»
Я вот их тех, кто ненавидит фреймворки и хочет каждый узел оптимизировать пока дым из ушей не пойдёт, обсуждать, планировать систему ДО начала её реализации, учитывать всевозможные нестандартные кейсы её эксплуатации и дальнейшей модернизации, нормализовать данные по максимуму насколько это вообще возможно, обходить стороной сборщики мусора и интерпретируемые языки…


Не волнуйтесь, со временем это пройдёт
Рэпера в президенты

Вообще-то Двэйн Элизондо Камачо был бойцом без правил и порнозвездой.
ИИ тоже можно оптимизировать.
Прошу меня простить, но для меня вы сказали типа этого — «ВОТ УБЕРУТ СЛОИ АБСТРАКЦИИ ЛИШНЕЕ ВОТ ЗАПУЩУ Я НОВУЮ КАЛДУ НА GEFORCE4. УХ ЗАЖИВЁМ». Только в негативном окрасе)
В вся эта фигня с раздуванием давно была посчитана, и если кротко… Где мы не гоняем данные\матан, чем больше слоёв и больше «высокого» получим в итоге кучу кала которая будет с трудом работать и тратить кучу времени просто на перемещения данных в памяти
Губится не только производительность. Губятся подходы к разработке.
Модный нынче тренд — фреймворки. Важно освоить очередной фреймворк, а что скрывается под ним никого не интересует.
В результате когда все это начинает тормозить, или давать не тот результат, которого ожидали, все списывается на фреймворк — «он так работает, мы с этим ничего не можем поделать».
Количество (в процентном соотношении) разработчиков, способных заглянуть по фреймворк, разобраться с особенностями API той платформы, под которую ведется разработка и использовать их для разработки высокопропроизводительной системы, стремительно падает.

Ответ девов «зато быстро сделали таск» получили бабло, давай следуйщий. Херак — в продакшн. А потом «а посмотри почему у клиента а 2х пользователях на сайте все дико тормозит». Так вы же криворукие так написали. «Ну у нас нет времени переделывать, у нас новые таски, скажем пусть купит 100500гиг памяти и все буде ок» рукалицо

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

И настроить автоскейл. Потом счету удивляться.


«А давайте запилим микросервисы, это сейчас ведь модно».
В итоге вместо вызова метода в коде имеем дикий оверхед на сокеты/хтпп/жсон и сериализации десериализации.

В итоге вместо вызова метода в коде имеем дикий оверхед на сокеты/хтпп/жсон и сериализации десериализации.

Зато можно масштабироваться. Вечно. В никуда. Наверное, просто никто не прикидывает сколько реально ресурсов НУЖНО

Правильно. Юзер за все заплатит (все эти инстансы и автоскейлы учтены в стоимости услуг для потребителя — чудес не бывает)

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

Так надо не на разрабов сетовать, а на требования рынка (т.е самих потребителей). А программисту скоько заплатили, столько он и споет.
Звучит, как будто зодчий из 16 века, посмотрел на современные многоэтажки и говорит:"что за ерунда! Это фуфло бетонное и 100 лет не простоит. Вот я замки строил из чистого камня 500 лет назад, так они до сих пор не покосились". И будет прав, только никто все равно не будет покупать жилье на которое надо собирать деньги три поколения.

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

Осталось лишь заставить себя пользоваться такими вот картинками "аппаратного уровня".
Я понимаю, что кажется, что диод зажечь — схема и не нужна особо, а спека на какой-то sx1509b, внезапно, десятки страниц.

Одно слово ASIC (ПЛИС), имхо за ними будущее, как только производители перестанут жевать сопли и не станут пихать этот функционал в каждый процессор, причем с общим стандартом и открытыми спецификациями, а не так как сейчас, чтобы начать разрабатывать нужно заплатить четырехзначные суммы

Ну интел на эту тему сыграла — сначала Xeon Phi (который вроде как уже хоронят), потом тупо встраивание FPGA в Xeon. В результате имеем процессоры с адовым TDP под 200+ Ватт и адовой ценой просто на само железо.
Во-первых, ПЛИС и ASIC — это не одно и то же. ПЛИС — это FPGA.
Во-вторых, как верно заметил JerleShannara плата за реконфигурируемость ПЛИС — это огромные накладные расходы, выливающиеся в то, что дизайн на ПЛИС имеет скорость и потребление, сравнимые с ASIC на пять-шесть поколений технологии старше (= медленный кипятильник).
Я разработчик для ПЛИС. Практически в каждом достаточно сложном проекте в состав конфигурации FPGA входит ARM-ядро (Microblaze). А сейчас Intel и Xilinx выпускаются гибриды — ARM + FPGA на одном кристалле.

Потому что делать на конечных автоматах то, что можно написать на Си — нерационально. Быстрее разработка, легче отладка, меньше ошибок, кушает меньше ресурсов. Потому что у FPGA конечное число логических вентилей и ЛЮБОЙ кусок логики или необходимость помнить что-то (если только не используется внешняя память — а DDR3 на платах с FPGA часто встречается) расходует эти ресурсы. Более того — с приближением к этому лимиту сильно возрастает сложность задачи по разводке схемы, она может даже не развестись с нужными скоростными характеристиками. Дешёвые FPGA стоят совсем недорого, каждый купить может какой-нибудь Microzed, а быстрые стоят тысячи долларов. А для серьёзных задач нужны быстрые. Реализовать процессор на FPGA можно, только вы получите 32-битный медленный аналог CPU 20-летней давности за сумасшедшие деньги. FPGA адекватны только для особого спектра задач, например для высокоскоростной потоковой обработки данных, когда вы пишете несколько конечных автоматов, на выходе будет стоять, скажем IP-ядро контроллер Ethernet MAC-уровня, а если есть несколько тысяч долларов и лишние ресурсы, то можно даже сделать TCP/IP. Но для такой задачи нужно разработать свою печатную плату (а иногда не одну), произвести её (это очень дорого по сравнению с любыми Xeon)

А ещё область разработки для FPGA — это заповедник проприетарщины. Честно, тут нечему завидовать. Тут ситуация как в разработке ПО до появления Open Source — платные «компиляторы» и пр.

И чтобы 2 раза не вставать: нет, квантовые компьютеры никогда не заменят обычные. Они работают по совершенно другому принципу, для них известно всего пара десятков очень узконаправленных алгоритмов и максимум, что их ждёт — роль сопроцессоров для спец. вычислений (криптография, некоторые области математики и пр.). Если удастся создать квантовый компьютер с достаточным числом кубитов (а вероятность этого экспоненциально уменьшается с каждым новым кубитом)
Возможно, будущее за специальной архитектурой. Например, в кристалле два ядра из восьми могут быть выделены для операционной системы. Тогда можно упростить системные вызовы, убрав многие слои из драйверов, защищённых вызовов и виртуализации. Будет что-то наподобие real mode для DOS, только для Windows 11.

Процы будут покупаться под конкретную ось :) АМД доведёт линух до ума, сделав его полноценным конкурентом Майкам.
Скорей уж у Майкрософт будет две версии «двух палок» — для Интел и для АМД.
Так то оно так, но у любой медали есть две стороны.
Блюпуп-клавиатура это удобство, но в тоже время требует другого интерфейса работы с собой, а это требует абстракции, чтобы в использующей клавиатуру программе не было необходимости делать несколько реализаций ввода. Юникод решил проблему не-латинских символов и «ой, а у меня не та страница кодировки» и теперь я всегда уверен, что буква будет показана верно.
И т.д. и т.п. с одной стороны мы тратим мощности на ненужные на первый взгляд вещи, а с другой решаем много проблем с удобством и надёжностью работы.

Банально на примере вашей схемы. Что будет, если вместо 5 вольт случайно подадут 220? Светодиод сгорит, а чтобы этого не было требуется ставить защиту, которая усложняет схему.
это я к тому, что раньше делали, что позволяло железо.
А теперь напридумывали столько удобств. Но чтобы они все работали
нужны мощности как для крутого шутера из 2000х
Мне ситуация с разработкой ПО напоминает историю развития автомобилей.
Раньше это были повозки с двигателем без всяких удобств и какого-либо комфорта и люди тоже использовали то что есть. Сейчас же в автомобиле всё меньше деталей необходимых для выполнения задачи перемещения из точки А в точку Б, а остальное это всякие магнитолы, кондиционеры, массажеры попы и т.д. То есть по сути вещи, которые требуют ресурсов, уменьшают надёжность, стоят денег, но при этом добавляют комфорт водителю и пассажирам.
В результате любители езды по лесам говорят, что это отстой, т.к. ненадёжно, а им нужно ремонтироваться в 100500 километрах от дома и для этого нет ничего лучше козла. Городские же жители с удовольствиям ездят на ненадёжных и неэффективных, но комфортных автомобилях. И давайте будем честными, вы не захотите ездить на старом (это которому лет 50) автомобиле, а вернётесь к новому, т.к. при всех минусах комфорт оказывается дороже.

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

А то, что человек «подсаживается» на приятное и комфортное было до эры электроники: ожирение и алкоголизм :)

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

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

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

Если человек с детства жил на свалке, то он даже не будет видеть в этом проблемы. Пример — Индия.

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

Видят, даже пытаются что-то делать. Тем не менее там свалки размером с высотные здания.

Ну автомобилю которому 50 лет вряд ли, но вот который был создан 20 лет назад вполне. В комфорте через пару часов возможно уснуть через пару часов, а так, когда ощущаешь пятой точкой все неровности, за 4-6 часов трудновато будет уснуть.
В разработке ПО такой же подход. Свой алгоритм разработки под каждую конкретную задачу. Где-то нужен сервис чтоб с консолькой и мог запускаться во всяких овнах, а где-то красивая картинка нужна или там куча "светофоров"

Аналогия с старым и новым авто не точная.
Современное «авто» это когда мотор крутит уменьшенные колеса (какие то R3 с шинами типа 20\5), колеса крутят ленту, от ленты уже вращаются полуоси, с нормальными R15 185\80.
Зато R15 185\80 легко меняются на гусеницу или лодочный винт!
да, но вместо атмосферного 0,9 там придется ставить дизель 4.0
Главное чтобы не было dependency hell.
А чуть посложнее задача и решения на аппаратном уровне приводят к подобному.
Там скорее всего одним из факторов была радиоционная устойчивость. Но в целом да, интересная реализация часов на 100+ микросхемах.
Да, скорее всего.
И даж параграф есть:
«What surprised me, though, was the similarities between the Shuttle computer and the Soviet clock. I expected the Shuttle computer to use 1980s microprocessors and be a generation ahead of the Soyuz clock, but instead the two systems both use TTL technology, and in many cases chips with almost identical functionality.»
А сейчас цепочка событий распухла до неприличия.
Клавиатуры (блютуз). Буквы в юникоде с модификаторами направления и прочим.
Отрисовка на виртуальном видеоадаптере виртуальной машины. Куча вычислительной
мощности уходит на виртуализацию и отвязку от аппаратного уровня.

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

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

Точки баланса в каждом случае различны. Они в многомерном пространстве с осями "производительность", "безопасность", "стоимость разработки", "сложность поддержки", etc… Плохое с одной точки зрения решение может быть удовлетворительным или даже хорошим с другой точки зрения. Если система конкретно тормозит, возможно, она хороша в чём-то другом (например, в низкой стоимости разработки).

Справедливости ради, фунционал у 2016 и 95 ворда отличается.
Даже размеры интерфейса.
Не в 500 раз, конечно, хотя для, как миниум, UI, цифры близки, как мне кажется.

Для UI давно можно было переехать на SVG графику. И проблема с десятками наборов ресурсов для разных разрешений вплоть до 8К решилась бы, причем экономно.
UI это не картинка, UI это структура элементов управления. Положить под капот SVG вероятно хорошая идея, но это лишь часть вопроса, нужен адекватный UI Markup Language
А потом жалуемся на раздутый софт. Растр быстрее вектора потому что вектор нужно растрировать для его отображения.

Никто не мешает хранить ресурсы в векторе (компактно), а потом при необходимости конвертить в растр для ускорения отображения (типа JIT компиляции такой). Действительно — пользователи ОБЫЧНО то же разрешение экрана на своих устройствах не меняют. Поэтому и растры им нужны не в виде коллекции на все случаи жизни, а конкретные

пользователи ОБЫЧНО то же разрешение экрана на своих устройствах не меняют

Но сейчас получает всё большее распространение несколько мониторов, и подключение ноутбуков ко внешним мониторам, зачастую разным на работе и дома. Хотя даже тут ничто не мешает кешировать несколько вариантов.
Так почему никто не переехал?
Ну, Майкрософт, допустим, не хочет, но почему тот же LibreOffice не уделал всех?
Так почему никто не переехал?

В андроиде есть возможность графические ресурсы для UI на подмножестве SVG делать (VectorDrawable/VectorDrawableCompat). Иногда используют. А иногда (чаще) проще нарезать картинки (все равно у адекватного дизайнера автоматом режутся)
Т.е. таки никому не нужно.
У нас в приложениях почти всё в SVG.
В основном потому, что переезд стоит дорого.
Возьмите что-то попроще. Ну например простые картинки-скетчи. Логично использовать в них векторную графику, но это дорого, потому почти везде jpg размером в полмегабайта.
SVG довольно тяжелая штука, насколько я понимаю

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


Я бы привел в пример для сравнения скриптовую сцену в игре и фильм.

При запуске проверяем разрешение экрана, если оно не изменилось с предыдущего запуска, используем растеризованные иконки с прошлого запуска.
Если это первый запуск — растеризуем и сохраняем куда-нибудь.
Экранов может быть более одного.
Между экранами можно окна перетаскивать и вообще (как минимум в Windows) окно может быть на двух экранах сразу.
Если я не ошибаюсь в WPF\XAML так и сделано. Да и вообще, насколько мне известно эта технология мощная, гибкая, продуманная, хотя и от мелкософта.

Нет, не решилась бы, потому что для разных размеров элементов и разных разрешений нужны разные уровни детализации иконок. Если вы посмотрите в качественные иконпаки, то иконки для, условно, 12х12 будут не просто уменьшенными копиями 32х32, но ещё и с небольшой перерисовкой.

Вот тут самое время вспомнить про решение разрабов Хайку ОС — HVIF :)
en.wikipedia.org/wiki/Haiku_Vector_Icon_Format
разбор формата в HEX-редакторе:
blog.leahhanson.us/post/recursecenter2016/haiku_icons.html
Насколько я помню, SVG это XML-текст, который еще надо долго парсить и т.д., а HVIF это бинарный формат, в котором урезано много того, что не относится к задаче, да еще и есть то, что реально надо — LOD варианты иконок, к примеру. :)

Личная просьба тем, кто это, возможно, когда-то прочитает — если будете пилить какой-то свой пет-проект (еще лучше — на чем-то дохлом, типа ардуины), попробуйте ради веселья использовать этот формат в нем. :) Заодно и на статейку материал будет!
фунционал у 2016 и 95 ворда отличается.

Это мягко выражаясь. Если в нем, как и в экселе, списки для покупок писать, разница незаметна, и возникает непонимание. Ну так и пишите списки покупок в Notepad++.

Отличия между 2016 и офисами 90х годов просто колоссальные, примерно такие же, как между современным смартфоном и нокией 3110.
И какие же интересно? Со времён Word 97 кроме ленточного интерфейса отличий не вижу. Где они? Чуть более плавную прокрутку сделали? Лично она меня только раздражает. В плане форматирования текста отличий ноль! У меня есть portable версия Word 97 размером в 50 Мб вроде. Так у неё весь основной функционал современного ворда есть!
Формат файла, сейчас специально сделал три версии одного файла: rtf, doc, docx. DOCX в 10 раз меньше RTF и в два раза меньше DOC.
Смена темы оформления одним кликом. Выбор шрифта с демонстрацией этого шрифта без применения.
Насчёт рисования математических выражений не уверен, мне кажется в 97 ворде надо было плагин ставить.

Математические выражения в адекватном виде появились только в 2007 ворде. Но, блин, почему вещи, которыми пользуются процентов этак 10 пользователей (слияние, рецензирование, рассылки, темы, математические выражения), не вынести в плагины или модули и make WinWord small and mighty again? Многим и правда старичка-Лексикона хватало.

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

Wordpad есть по-умолчанию в каждом дистрибутиве windows. Это сами юзеры кушают кактус используя "Word" для простых документов.

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

Вырванивание по ширине в нем есть, не знаю как давно. Также он поддерживает docx, так что вордовские файлы можно просматриваь им п-умолчанию. Хотя я бы хотел видеть в нем то же что есть в онлайновой версии офиса и удобную(как в ворде) работу с облаком.

в макос есть вполне вменяемый TextEdit, в браузере всегда можно открыть Google Docs с поддержкой всех распространенных форматов… Десктопные программы умирают (

Вы пробовали работать в google docs с большим документом со сложным форматированием? Онлайн сервисы хороши когда вам нужно быстро накидать пару страниц текста с типовым форматированием, но если вам работу работать нужно, то они умирают в первые полчаса.

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

Речь даже не форматировании или чем-то сложном. Просто например банальную табличку с данными пару десятков тыс. строчек и десяток столбцов открыть. С самым минимумом форматирования и формул в них, в основном просто статические данные.

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

Хотя точно такую же табличку даже древний Excel 2000 открывает без проблем за секунду используя всего 10-20 Мб памяти, почти не нагружая процессор и при этом все будет «летать» во время работы.
А никто не говорит, что надо гуглодоксом пользоваться для сложных документов.

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

Ну, это примерно как обсуждать — будет ли Автокад в облаке. Облако ориентировано на решение задач большинства. Я не проводил анализ, но, допускаю, что большинству нужно решать именно простые задачи.

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

docx, понятное дело, появился позже. Да, объём у него меньше, но согласитесь, что в настоящее время файл объёмом даже в 50 Мб никого не смущает.
Предпросмотр шрифтов крайне удобная штука, тут спору нет!
Но вот что-то прям такого нового с 97 года они всё равно нифига не добавили :-)
Знаете, многое зависит от того, чем вы занимаетесь в ворде. Если вам раз в день надо служебку написать, изменив один из старых файлов — тогда вообще непонятно, зачем покупать офис, это можно в гуглдокс сделать.
Например у нас в компании ворд (и вообще офисный пакет) изпользуется на всю катушку. Как пример про темы (я уверен, многие снисходительно усмехнулись, когда я про них упомянул) представьте себе процедуру изменения корпоративного стиля в компании, сотрудники которой раскиданы по всему миру. Элементарная замена шрифта и цветов превращается в ад для специалистов соответствующих отделов. В новом ворде я просто выбираю тему и не парюсь. Они её как то там обновляют по необходимости, не вникал.
У нас в 90% случаях используется LibreOffice. Но на нескольких рабочих местах куплен Office 365. Из него используем только Word для оформления красочных руководств по эксплуатации. Тут я с Вами соглашусь — его возможности в плане оформления на порядок выше того же Libre. Но в то же время, применение довольно специфическое, много всякой графики, эффектов типа теней и т.п.
А обычные текстовые документы практически произвольной сложности легко делаются в LibreOffice Writer.
Самое забавное, что прямо в то же время я поражался пакету MS Works, который выглядел более юзер-френдли, чем офис, и в нем был предпросмотр шрифтов, помимо всяких других рюшечек. На 95 виндах! :)
Не имею ни малейшего понятия, кто и зачем (конкуренция разных команд? или купили разработчиков?) его сделал, и что с ним потом стало…
Works был сильно дешевле, на сколько помню.

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

Вот-вот, а все уже и забыли. :) Если пойти путем честного сравнения, то можно вспомнить, что в ХРю (вроде) появился штатный способ использовать зипы как папки, то есть можно легко упаковать любой старый док в зип и будет это открываться уж никак не медленнее… :)
Для rtf достаточно WordPad и калькулятор, для doc — MS Word (если я правильно помню, его можно было купить отдельно) и i486, для docx — MS Office с современным компьютером. А docx это всего лишь зипованый XML, надеюсь хотя бы что XML это не внутреннее представление документов в MSO.
docs — это зипованый набор xml-файлов. Потому и меньше. Переименуйте и загляните.
Если зазиповать doc, то получится в два раза меньше, чем такой же docx.

Upd. Надо читать все каменты, прежде, чем писать свои :)

Кстати я многие документы в нотпаде держу

С учетом того, что существует Markdown и такие прекрасные визуальные редакторы как Typora, это почти что превращается в базовую версию ворда, но с дополнительными плюсами (простой текстовый формат возможностью простого версионирования).

Все-таки там нет форматирования, это не очень удобно и наглядно.

Ну так Markdown — то же самое + подсветка и форматирование как бонус.

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

Но я все же советую Visual Code — там нативная поддержка Markdown и плагино намного больше.

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

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

Его практически и изучать не нужно — он очень простой, ну и любой текстовый документ уже сам по себе практически Markdown)

Отличия громадные, но сколько процентов пользователей используют этот новый функционал? Тут пардон куча пользователей не использует всего функционала, который в Office 97 был.
Не являюсь постоянным пользователем «офиса», но тоже интересно, чем отличается старая версия от новой в плане функционала.
Вот список по Word
www.stl-training.co.uk/versions/word-difference.php
Вот по Excel
www.stl-training.co.uk/versions/excel-difference.php

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

P.S. С нетерпением жду, когда в offline-excel завезут XLOOKUP. И да, даже если он из-за этого увеличится на 100Мб, жаловаться не буду.
90% пользователей как использовало 20% возможностей Word-95, так и использует те же функции в Word-2016.
И в Word-2025 так же будет.

Потому что большего им просто не требуется.
Значит можно написать маленький и проворный редактор, в котором будут только эти используемые 20% функций. И продавать за 10 баксов лайф-тайм лицензии.
Совершенно верно.
Но Microsoft это делать не будет, потому что как потом продавать MS Office?
А другие не смогут, потому что пользователи уже привыкли к Word/Excel и менять не захотят.

А вы думали, почему так легко найти и установить пиратскую версию Офиса?
Многие до сих пор верят — это потому, что глупые программисты Microsoft просто не могут сделать нормальную защиту.
respecto, на самом деле после 2007-го офиса это стало проблемой, если, конечно, вы хотите обновлять офис. А пользоваться дырявым, это ещё то удовольствие.
А другие не смогут, потому что пользователи уже привыкли к Word/Excel и менять не захотят.

ИМХО захотят если он будет выполнять эти 20% возможностей, а не как OO/LO и иже с ним.

Этот редактор есть за бесплатно. называется гуглдокс. А тот факт, что наконец-то не нужно без конца пересылать разные версии документа почтой—это просто чудо какое-то!
У него есть один недостаток — без интернета не работает.
Я не готов сливать все свои документы какой-нибудь корпорации, особенно Гуглу.
Для Гугла твои «не хочу» даже не замечают.
Твои ЛИЧНЫЕ документы вообще никому неинтересны.
А вот как в составе хомячков — ты выполняешь свои роли.
Переведу, что AlexWenner хотел сказать.
Google все равно, смог он получить в свои загребущие системы личные документы Revertis или нет.
Но ему не все равно, когда счет документов, обрататываемых в Google Docs, исчисляется миллионнами штук. Он получает из них достаточно данных, чтобы строить модели, делать предсказания, и продавать рекламу.
Таким образом, наличие в цепких лапках Гугла одного-единственного Хабраюзера Гугл никак не беспокоит. Гугл беспокоит решение вопроса в виде охвата в миллионы людей.

Тем не менее, считаю, что каждый имеет право решить отдавать свои документы Гуглу или кому-то еще и наслаждаться таргетированной рекламой или нет. Так что вопрос Privacy, так же как и вопрос наличия устойчивого соединия к сети Internet, остается актуальным.
Разве локальный офис заливает что-то на их сервера?
Заливку подозрительных файлов на сервера MS в Windows Defender я отключаю, если что.
Вообще-то приложения на Electron не лишены достоинств — за пару вечеров, с неглубокими познаниями в реверс-инжиниринге, можно поправить исходники «для себя»: сделать вечный триал, вырезать рекламу, допилить кнопку в UI.
В нативном коде это тоже довольно несложно, в сети куча мануалов по реверсу нативных Windows приложений.
В нативном можно весьма усложнить дебаггинг приложения. В электроне разработчики ограничены виртуальной машиной JS.
Прямо с языка снял )
3ds Max 6 на ведре с Intel Core Duo 2 и видеокартой 128 Мб умещался на CD и периодически вылетал. Спустя 15 лет, 3ds Max 2020 раздулся до 5 Гб, на i7 и GTX 745 более тормозной и вылетает чаще.
А блендер как тогда летал и мог кучу всего так и сейчас 200 мб весит и летает на сопоставимом железе. Например, на упомянутой вами «корке».
Так это они специально, просто что бы заставочку показать, что бы все знали что это Word 2016. Если бы он открывался как блокнот, то никто бы не знал что это MS Office, тем более что чем дольше грузится программа, тем она солиднее. Ничего в маркетинге не смыслите :)
Вот вы говорите про экономный код, а что будет в итоге — PCIE5 никому не нужен, DDR6 пылятся на складе, новые 128 ядреные процессоры лежат в магазинах в паутине? Ужас, стагнация, убытки? Да вы, батенька, анархист! /sarcasm
PS если серьёзно — достаточно давно встречаю статьи о новых типах транзисторов с потенциально большими скоростями, новые типы памяти и прочие любопытные штуки, которые всерьёз не финансируются, пока работают (и приносят прибыль) уже освоенные технологии.
То есть вы всерьез думаете, что тот же Intel который год мужественно терпит огромные убытки из-за невозможности освоить 10 и 7 нм, но не вкладывается в разработку новых технологий? С целью, извините, дать конкурентам побольше заработать на существующих?
Продолжать дальше выжимать кремний (с закономерным профитом и получением 10 7 5нм в итоге) или уходить с него на графен, оптику или что-нибудь ещё, с затратами на порядки большими и не факт, что успешными?
Конечно же продолжаем!
PS не говорю, что сейчас исследования в нексген-технологиях не ведутся и/или денег совсем не дают, но по сравнению с переходом на новые техпроцессы…
уходить с него на что-нибудь
или уходить с него на что именно? Проблема ровно в том, что несмотря на огромные RnD-расходы, уходить все еще некуда, просто некуда. На графене за пятнадцать лет даже одиночные транзисторы толком не заработали, на нанотрубках все даже хуже, чем на графене, никакой «оптики» просто не существует.
Лучшее, что мы имеем со всех этих «новых технологий» — это силовые транзисторы на нитриде галлия для быстрой зарядки мобильников.
Как кажется с моего кресла, мы ещё в физический предел не упёрлись (вроде 7 нм, 5 и 3 ещё достижимы и обещается в ближайшие годы?), а к тому времени что-нибудь и выстрелит.
Хотя, возможно, все очерки типа «показан прототип нового транзистора/памяти/etc» — фэйк или белый шум, я ж не настоящий схемотехник.
Как кажется с моего кресла
я ж не настоящий схемотехник
К сожалению, вам кажется. Из моего кресла настоящего схемотехника довольно хорошо видно, что реальной альтернативы кремнию для вычислений общего назначения в ближайшие лет двадцать не будет.
В физический предел уперлись уже очень давно (он, к слову, около 20 нм), с тех пор все «7-5-3 нм» — это упаковка транзисторов сначала вертикально (FinFET), а потом в несколько слоев (nansheet, nanowire и прочие GAAFET).


«показан прототип нового транзистора/памяти/etc» — фэйк или белый шум
«Прототип» — это не то же самое, что можно реально серийно производить. У MRAM например были офигительные прототипы, но при попытках довести технологию выяснилось, что когда надо обеспечить больше трех циклов перезаписи, она оказывается не только не быстрее SRAM, но и чуть ли не медленнее флэша, что делает ее просто ненужной. И таких историй море, но о них редко пишут в новостях, ведь британские ученым не отчитываются ими по грантам.
Спасибо за более адекватную реальности точку зрения, теперь я в унынии:
пока всё и так работает (т.к. добавление лишних прослоек компенсируется ускорением железа) — никто не станет делать более чистый код: это, в большинстве случаев, не выгодно, а когда перестанет работать — останется слишком большое количество людей, который привыкли быстрее хватать стильный-новый фреймворк, обмазывать так-себе-кодом и пушить в прод.

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

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

мм…
Больше обнаруженных уязвимостей = больше закрытых уязвимостей = меньше потезницальных 0-day угроз, или я снова неправ и это не так работает?

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

В успешных проектах так иначе бы ядро линукса было дырявое
Эмм, хорошо вычищенное старое теперь не вариант, прощай iptables?
можно же сторонним пакетом поставить, так же как и ifconfig.
Я к тому что iptables вычищен от глюков как и ядро линукс
я не знаю, что там под не первой свежестью вы имеете ввиду, но в вебе вообще взлетело всё, что должно было умереть не родившись.
ПХП — язык созданный для одной домашней страницы взлетел, тогда как Питон, который уже тогда был круче до сих пор только набирает и отбирает свою долю популярности.
Джумла взлетела, Вордпрес не просто взлетел, уже создает вакансии «разработчик плагинов под вордпрес». Первое было когда-то лютым геморром, второе — движок для блогов, который вдруг ВНИЗАПНА стал движком для всего…
Маджента взлетела, хотя был опенсурсный ОпенКарт…
и таких примеров взлетевших в вебе недоразумений еще вагон, например ТИПО3 (да отсохнет его карбюратор во веки веков)
Да, веб к сожалению до сих пор большей частью в глубоких потемках болтается. Даже не знаю сколько еще времени должно пройти, что бы это поменялось :) Уже вот плавно какое-то отдаленное подобие ИИ начинает просматриваться, а веб всё еще в программном средневековье.
Десктоп тем более — куча современных программ даже не умеют в масштабирование шрифтов.
Огромное спасибо за информацию, особенно про упаковку транзисторов и картинку. Если можете, посоветуйте пожалуйста где обо всем этом можно почитать, чтоб более-менее человеческим языком, доступным для обычного человека хотябы программиста.
На правах саморекламы: вот тут моя статья по этому поводу. Насчет доступного языка на 100% не уверен, но я старался.

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

Так вот же, Intel действительно упёрлись и стремительно теряют долю рынка, сьедаемую AMD с более совершенными технологиями фабрики TSMC. И ничего революционного не происходит уже несколько лет, и все стонут от дефицита серверных процессоров. Более того, Intel теперь сами пытаются попасть на TSMC, чтобы сократить потери и очереди.
А до того GlobalFoundries решили выкинуть в трубу многомиллиардные исследования для 7 нм и остановиться на 14 нм навсегда — потому что не могли довести прототипы до промышленного освоения. Более того, они на этом потеряли не только инвестированные арабскими шейхами деньги, но и контракт с AMD, который принес бы им сейчас золотые горы. А так они накормили своего основного конкурента, окончательно отказавших от притязаний на самые вкусные рынки. То есть речь идёт как раз не об абстрактном прогрессе, а о том, что прямо сегодня инвесторы терпят убытки, а эффективные менеджеры получают вместо опционов пинки под зад (нынешние CEO и CTO и Intel, и GloFo ещё и двух лет не отработали).
У вас есть какие-то разумные объяснения такому поведению в условиях, когда можно было просто придумать что-то принципиально новое? У меня вот без привлечения рептилоидов не получается.
Поставили не на ту лошадь?
А инвесторы, видимо, устали слушать отчёт об успешных испытаниях нового прототипа сферического коня в ваккуме техпроцесса, которому нужно ещё 2 года и 4 вагона долларов для выхода в релиз*
*но это не точно, может и не выйти, как и в прошлый раз.
PS Радует, что хоть где-то эффективные, но несправившиеся менеджеры получают под зад коленом вместо золотого парашюта, как в Boeing.
Поставили не на ту лошадь?
Но это не бьется с концепцией «как действительно упрутся и необходимость будет подпирать, что-то придумают». Вот же, уперлись, подпирает еще как. Ничего не придумали. Причем их очень много таких ничего не придумавших и начавших вместо этого упускать колоссальные прибыли. Вот вам прямо список с годами, объясните мне хотя бы его половину.
image
Вот вам прямо список с годами, объясните мне хотя бы его половину.

MIT в прошлом году опубликовал хорошую статью с анализом по этому вопросу.
Отстал на пол года с переходом на следующее поколение — забудь о прибыли, чипы следующего поколения от конкурентов продаются в каждой подворотне и выгоднее заказать и свои чипы у конкурента, а не допиливать велосипед, иначе акционеры не поймут.
И пока все не упрутся в физику до конца — прорывных технологи не будет — то есть реально все, без возможности заказать чипы по следующему поколению техпроцесса у соседей.
К тому же, не всем нужен самый тонкий и свежий техпроцесс, массовые контроллеры/логика спокойно и на старых техпроцессах будут выпускаться и продаваться миллионами.
PS это не попытка отстоять свою точку зрения не смотря на факты, это досужие рассуждения на тему, с целью получить ещё несколько интересных ссылок и идей. Вашу правоту признал несколькими постами выше.
без возможности заказать чипы по следующему поколению техпроцесса у соседей
Возможность заказать свои чипы соседям есть у разработчиков чипов, а не у фабрик. GloFo и UMC не могут заказывать производство на TSMC при всем желании. Все, что они могут сделать — придумать что-то прорывное и отобрать долю производственного рынка обратно. Точнее, как мы выяснили, они не могут этого сделать)

массовые контроллеры/логика спокойно и на старых техпроцессах будут выпускаться и продаваться миллионами.
А вот это совсем другая история, причем сразу в нескольких измерениях.
image
Рынок «старых технологий» во-первых, меньше, чем новых, а во-вторых, он гораздо конкурентнее, потому что прибыли меньше, больших клиентов тоже меньше, а игроков на рынке больше. Так что для того, чтобы хорошо себя чувствовать там, фабрике надо быть едва ли не менее изобретательной, чем при работе с передовыми нодами. Причем изобретательной в вещах, котоые с одной стороны, дешевле, а с другой — очень сложно придумать и реализовать что-то такое, что конкуренты не смогут быстро повторить. И что не сможет повторить TSMC со своими практически бесконечными ресурсами на RnD.

Можете пояснить за циклы "тик-так":


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

Я не совсем понимаю, почему так упорно идут от 90/65нм вниз, это маркетинг, инерция сознания или правда технически оправданно?

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

Второй вопрос — отличная тема для докторской диссертации. Он не имеет ответа в общем случае, потому что зависит от того, насколько новый процесс лучше старого, есть ли у архитектуры ресурсы для оптимизации и т.д. и т.п.
Если совсем грубо, то наверное перейти на новый техпроцесс дороже, но проще и быстрее, чем выжимать соки из имеющегося. И это «быстрее» во многих случаях означает сорвать куш с новым продуктом или вылететь в трубу. Спокойно шлифовать архитектуру годами можно только при полном отсутствии конкурентов.

или правда технически оправданно
Правда технически и экономически оправдано в большинстве случаев, где это происходит.
А условные копеечные микроконтроллеры клепали и будут еще долго клепать на 180 нм.
Эх, раз уж тут так активно отвечают на вопросы задам и я свой.
Я вот вроде бы знаю кто такие Intel и AMD. Но примерно года три-четыре назад начал все чаще слышать упоминание таких названий как Global Foundry, TSMC и еще какие-то в разговорах о амд и интел. И вот эти ребята мне совершенно непонятны, в частности кто они такие, где живут, чем именно занимаются и, главное, как именно и почему они связаны с AMD и Intel.
Intel, AMD, Samsung, Apple, Qualcomm и т.д. — это компании, которые разрабатывают микросхемы и продают их. Производить их они могут сами (как Intel и Samsung) или аутсорсить сторонним фабрикам (как AMD, Apple и Qualcomm).
TSMC и GlobalFoundries как раз и есть эти сторонние фабрики. Они не продают никакие микросхемы конечным пользователям, но предоставляют услуги производства разработчикам.
Например, GloFo — это бывшие фабрики AMD, выделенные в самостоятельную компанию, TSMC всегда имел бизнес-модель фабрики, а заводы Samsung производят чипы и для своих, и для сторонних заказчиков (которым раньше был например Apple).
Модель сторонних фабрик появилась, потому что производственное оборудование стоит безумно дорого, и почти никто из разработчиков не может себе его позволить.
Ну вот, опять зарабатывают продавцы лопат в итоге.
Как человек, регулярно пользующийся услушами этих «продавцов лопат», могу сказать, что во-первых, они не так много зарабатывают, а во-вторых, без них как минимум трети микроэлектронной индустрии просто не было бы, причем лучшей трети.
это очень круто, спасибо!
UFO landed and left these words here

От доходов с продажи крайне востребованной продукции, разумеется.

Помнится я когда-то давно читал статью с подобной картинкой, где прогнозировалось сужение отрасли до 2-3 фабрик. К сожалению не могу даже год вспомнить.
Такое развитие событий было понятным и предсказуемым лет пятнадцать назад так точно. Прямо сейчас требовательная к нанометрам часть отрасли уже сократилась как раз до двух с половиной фабрик, которые и делят самую вкусную часть пирога.
Забавнее то, что поставщик оборудования для литографии уже давно вообще монопольный.
Если я ничего не путаю, то Canon и Nikon ещё в районе 90-65 нм сдулись и сейчас подбирают какие-то крохи типа производителей светодиодов.
Немного занудства про закон Мура. Почему-то в печатных изданиях до 2000х годов, это закон говорил об удвоении производительности каждые полтора года, а с 2000х годов, упоминая этот закон, начали говорить про удвоение каждые полтора года транзисторов. Какой удобный закон — сначала говорит одно, потом другое… Но всё-таки, удвоение количества транзисторов и удвоение производительности, это не одно и то же.
Даже, в приведённой вами ссылке на Вики, удвоение транзисторов каждый год (а не полтора):
появление новых моделей микросхем наблюдалось спустя примерно год после предшественников, при этом количество транзисторов в них возрастало каждый раз приблизительно вдвое
/зануда off/

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

Формулировка такая общепринятая, «закон Мура». А как было в точности, боюсь, даже сам Гордон Мур уже не вспомнит, что и где было сказано.

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

это в любом случае просто красивая цитата которая уже давно живет своей жизнью в мире журналистов.
Не обижайте журналистов, эту цитату подхватили на щит и таскали на нем много лет вовсе не они, а маркетологи Intel, торжественно возложившие на свою компанию обязанность сделать «закон Мура» самосбывающимся пророчеством.
Сейчас рерайтеры играют в «испорченный телефон», переписывая друг у друга.
Быренько нагуглил среди старых статей:
compress.ru/article.aspx?id=9558
www.ferra.ru/review/techlife/s25856.htm

Ровно сорок лет назад, 19 апреля 1965 года, в журнале Electronics (vol. 39, N8) в рубрике «Эксперты смотрят в будущее» вышла знаменитая теперь статья Гордона Мура «Cramming more components onto integrated circuits», в которой тогдашний директор отдела разработок компании Fairchild Semiconductors и будущий со-основатель корпорации Intel дал прогноз развития микроэлектроники на ближайшие десять лет на основании анализа шестилетнего развития младенческой тогда еще электроники, предсказав, что количество элементов на кристаллах электронных микросхем будет и далее удваиваться каждый год.
К тому времени когда это станет действительно актулаьным Rust подрастёт во всех смыслах и решит эту проблему.
Насколько я знаю, он уже решает множество проблем.
Вон, в DropBox несколько лет назад, запилили управление хранилищем на Go. Оно выполняло свои функции, но тормозило из-за GC. Они переписали его на Rust, и производительность возросла намного. Пересказываю по памяти, но эта история была у них в блоге.
Да, я слышал эту историю, но пока раст нельзя назвать популярным языком — есть ещё куда расти.
Уже несколько лет подряд он занимает первое место среди любимых языков в рейтингах StackOverflow. А у вас он непопулярен :)
Популярен он будет когда работы на нём будет больше чем сейчас на питоне.
Но это ведь разные ниши. На одних языках можно быстро наговнокодить и релизнуть, а на других долго кодить, но сделать на века.
Я же не говорил что он займёт нишу питона, я говорил что широта использования будет сравнима, если хотите можно сказать популярен раст будет когда C/C++ будут вытеснены хотя бы наполовину из новых проектов.
Тут нужна картинка с фразой «вы находитесь здесь» :)
Но это ваше право, хотите используйте, хотите нет.
Я только это и сказал — что пока мы находимся здесь.

А точно был мальчик? Потому что я тоже эту публикацию помню, а потом вроде бы оказалось что там журналистов учёные насиловали как могли, и на самом деле Dropbox переписал на Rust только пару мелких служб в которых у них затык по производительности был, а всё остальное как было на Go так и есть.

Фигасе "мелкие службы". Magic Pocket использующий Rust это по сути центральная компонента их хранилища. Конечно, его не полностью переписали с Go, но всё же. К сожалению, презентации где о переписывании рассказывалось более подробно более не доступны...

Там вроде только OSD переписали — то есть собственно демон который висит над диском и шурудит секторами, по одному демону на диск, а остальное осталось как есть; да и Magic Pocket там важная, но не самая объёмная часть инфраструктуры. То есть да, в целом дело хорошее и вселяет надежду (я уже джва году жду не дождусь возможности попробовать Rust в embedded продакшне), но я не уверен, что это большая веха для Rust. Скорее просто ещё одно напоминание о том что такие вещи вообще не стоит писать на garbage collected языках.

И как он ускорит код написанный на C++?

А почему именно раст, а не тот же хаскель?

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

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

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

Проблема не только в менеджерах. Но и в том, что всем вдруг понадобилась кроссплатформенность. Раньше программку/мессенджер можно было написать на Делфи/плюсах и только под винду, оно бы весило 10мб от силы, а теперь надо весь GUI делать кроссплатформенным, и весит это всё сотни мегабайт, и гигабайт оперативки при запуске.

А почему не условная компиляция? А при скачивании отдавать юзеру аналог cpuZ, чтобы поставить собранную точно под его устрйоство версию?

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

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

Вот для Rust'а многие пытаются это сделать

Дадите ссылки? Интересно
Можете начать изучение отсюда: areweguiyet.com
А потом поиском по гитхабу :)
Я говорил о качественной библиотеке ;)

А что с ними?


Хотя у меня вроде все тулкиты одинаково шрифты отрисовывают, что Qt, что Gtk (есть полторы программы), что какой-нибудь Tk.

Они сглаживаются, причём мерзким алгоритмом, которого точно нет в ОС. Речь идёт о Windows без ClearType.
Скриншот

А, ну это по некоторым причинам я воспроизвести не могу, да и под виндой в имеющихся там у меня полутора приложениях (вроде ориджина) не наблюдаю.

Я конечно не автор, но Qt не нативен. Вот прямо сейчас я не могу настроить compose в телеграме и курсор выглядит в брузере и в тележке не так как в системе. Это баги которым уже лет больше чем я пользуюсь линуксом. В винде-же отрисовка даже кнопок отличается, и программу на Qt видно сразу.


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

А разве gtk рисует «как принято в системе», то есть в иксах?

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

Так под линуксом вообще ничего нативного нет по определению. У меня вот DE на кутях, и ровно обратная ситуация: Gtk выглядит совершенно ненативно.

В этом и проблема и преимущество линукса одновременно — зоопарк DE, зоопарк фреймворков и подходов к API. Получаем ситуацию как у меня сегодня после обновления elementary os — все приложения gtk младше 3.ХХ стали выглядеть как win98, другие нормально, третьи по Qt'шному. Меня, как UI перфекциониста который зачитывался Apple HIG в свое время, это очень расстраивает. Еще больше меня расстраивает когда я вижу как мелкая программа (brasero вроде) тянет 140 метров зависимостей и свякие Qt-шные либы.

Еще больше меня расстраивает когда я вижу как мелкая программа (brasero вроде) тянет 140 метров зависимостей и свякие Qt-шные либы.

Это всего лишь значит, что кутей у вас в системе не было. У меня вот есть, и результат:


Calculating dependencies... done!
[ebuild  N     ] x11-themes/sound-theme-freedesktop-0.8::gentoo  468 KiB
[ebuild  N     ] media-libs/libcanberra-0.30-r5::gentoo  USE="alsa gstreamer gtk gtk3 sound udev -gnome -oss -pulseaudio -tdb" ABI_X86="(64) -32 (-x32)" 312 KiB
[ebuild  N     ] dev-libs/libisofs-1.5.2::gentoo  USE="acl xattr zlib -debug -static-libs -verbose-debug" 838 KiB
[ebuild  N     ] app-crypt/gcr-3.34.0-r1:0/1::gentoo  USE="-debug -gtk -introspection -test -vala" 1 421 KiB
[ebuild  N     ] gnome-base/gvfs-1.40.2::gentoo  USE="cdda http (policykit) udev udisks -afp -archive -bluray -elogind -fuse -gnome-keyring -gnome-online-accounts -google -gphoto2 -ios -mtp -nfs -samba -systemd -test -zeroconf" 1 177 KiB
[ebuild  N     ] app-cdr/brasero-3.12.2-r1:0/3.1::gentoo  USE="css libburn mp3 -introspection -nautilus (-packagekit) -playlist -test -tracker" 3 655 KiB

Total: 6 packages (6 new), Size of downloads: 7 867 KiB

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

Я прекрасно понимаю что elementary os с pantheon на gtk тянет к себе qt-шные либы потому что в ней их нет.
Я говорю про то что сейчас у меня в системе 2 библиотеки отрисовки интерфейса, как минимум, и каждая из них отличается по UX и UI друг от друга. И каждая из них требует своих танцев с бубном чтоб с ней было удобно работать мне, как пользователю.


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


btw с виндой не сравнить — мои приложения под bcb из 98 винды работают под десяткой и даже выглядят нативно без подтягиваний зависимостей, тогда как gtk2 в gtk3 уже выглядит как родом из 90-х.

Кроссплатформенный гуй пытаются сделать с конца 90х, а воз и ныне там. Три основных подхода


  • оборачивать существующие платформенные библиотеки (Java SWT, React Native, Java AWT, Xamarin Forms, WxWidgets)
  • рисовать все самим (Swing, Flutter, QT)
  • использовать HTML (Electron)

Все имеют фатальные недостатки. В итоге одна компания пиарит подход 1 (React Native), через 3 года видно что это хрень и уже другая компания начинает пиарить подход 2 (Flutter) только для того, чтобы через 3 года все увидели, что это тоже хрень и кто-то начал пиарить подход 1.

Пользуюсь многим софтом на трех платформах (мак, вин, лин) — Firefox, Thunderbird, Chrome и куча по мелочи. qBittorent всякие которые на Qt.


Качеством доволен вполне. Понятно что неидеально, но не раздражает.

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

В пятой версии Qt уже не сама рисует, перешли к подходу 1 :)

А как же QtQuick/QML? Они рендерятся вручную силами Qt.


И из той же оперы под C#: WPF (win only), Avalonia… Кстати, даже под более простой шарп нет, имхо, нормального кросс-платформенного GUI.

Очень интересно! А почему его вытеснил Electron? Вроде sciter такой прикольный.
Я так понимаю, основной тренд новых средств разработки задают продуктологи, которые точно не понимают, какой новый продукт (для пользователей) нужно запускать — поэтому новые средства должны позволять быстро ставить эксперименты, менять интерфейс, ставить a/b тесты и т.п.
Сейчас на Delphi под FMX спокойно пишется код, который без всяких переделок работает на Win/macOS/Android/iOS. Только сегодня программу собирал под три платформы. В новой версии Delphi и поддержка Linux есть, но я её пока не пробовал.
Это хорошие новости, хотя я об этом давно слышал.
Проблема только в том, что если захочешь кому-то предложить на Дельфи написать, сразу обосрут. Что в компании на работе, что в опенсорсном сообществе.
Это не проблема. Разработчиков на Delphi лично у нас в городе вполне хватает. Компания у нас небольшая, разработка на Delphi очень выгодна, т.к. происходит довольно быстро, и не требуется нанимать разных программистов под разные платформы.
К слову довольно крупное оупенсорс Паскаль сообщество:
freepascal.ru
с радостью возьмется за предложенную и оплаченную работу :)
Хм, и какие там расценки? :)
FDA847 Добейти меня. Под мак из делфей можно без точки сборки на их железе скомпилить?

А то все хочу да хочу в свои стеки программирования еще ios добавить, но останавливает необходимость иметь их телефон и что-то на стол.

Не очень понял что имеется в виду по «точкой сборки»? При пересборке проекта под другую платформу можно выбрать как его там запускать — либо на эмуляторе, либо на реальном железе. С эмулятором я не пробовал, запускал на живом маке.
При разработке под iOS живой мак вроде как обязателен, т.к. он осуществляет подпись приложения. Без этого программу не выложить в AppStore. На Хабре как-то писались несколько статей об этом.
В остальном сборка под iOS почти ничем не отличается от сборки под мак.
Таким образом весь основном функционал отлаживается сначала под виндой. Это очень комфортно, потому что компилятор Delphi крайне быстрый. А потом уже интерфейсные части отлаживаются под конкретную платформу. Тут процесс дольше идёт, т.к. сборка, например, под Android небольшого проекта занимает около 30-40 сек.
Вам нужна MacOS с установленным XCode т.к. Delphi тащит оттуда SDK для платформы. Можно использовать установленный в виртуалку MacOS — потом для компиляции он не нужен. (но нужен для запуска, да. Если говорить о iOS/MacOS) И самое главное! iOS Simulator 13.x пока что не поддерживается. Только старее. (хотя, имхо, это никак не мешает)

Насчет Android:
Android вот х64 завезли наконец-то. Правда App Bundle пока не завезли :( В комплекте есть Android SDK но старый(!) — лучше использовать «родной» от Google — хотя Embarcadero и не рекомендует — однако у меня проблем не возникло.

ПС: Есть «косяк» на данный момент. Если вы выложите Android x64 APK — оно не заработает на arm v7 :) Delphi по-умолчанию не пакует в x64 APK 32-х битный бинарник. Нужно «ручками» добавить в deploy конфигурацию.

Насчет Linux:
Да, завезли, но официально — пока только консоль, без GUI (кажется х64 only). История с SDK такая же. Нужна ОС с которой Delphi вытянет SDK (Да, и снова можно «виртуалку»). Однако FMX GUI для линукса есть на просторах интернета. Вроде бы как у них разраб ушел который его пилил, там прям скандал какой-то был. Но оно есть и работает исправно. Правда денег стоит www.fmxlinux.com/order.html (ну или… вы знаете где искать)

PPS: Очень круто что отладчик работает и в iOS, и в MacOS, и в Windows/Linux/Android… Но учтите что отладчик для Android только х32 например. Если мне не изменяет память то для MacOS тоже. А значит отладка на «Каталине» невозможна. (Собирать х64 MacOS Delphi при этом умеет само собой)
Да, завезли, но официально — пока только консоль, без GUI

fmxlinux уже куплен Идерой и входит в поставку, если что. То есть — официально в Delphi завезли уже и Linux GUI. К слову — говорят что работает отлично. Не пробовал, я на Лазарусе под Линукс пишу.
Проверил. доступен с 10.3.1 через GetIt — действительно, упустил. Прошу прощения. Хотя это всеравно не «из коробки» как обычно у них. Но хоть так.

Вы просто компилируете одно и то же приложение на разные платформы?
Как решаете вопрос с отсутствием "курсора" на мобильных платформах?

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

Вопрос — нужен ли весь код на плюсах или вполне достаточно будет условного Kotlin Native, а то и просто в JVM с тонкой прослойкой HAL на С?
Пока, по ощущениям, в некоторых областях RnD дело идёт именно к этому.

Хоть и так, главное не превращать каждое приложение в недобраузер с кодом на JS.

И браузер на java. Запущенный под wine на эльбрусе

Раньше вы нанимали команду под IOS,Android,Win,Web. А теперь нанимаете только веб-прогеров и они пилят вам все это на одном (практически) стеке.
Выгода налицо.

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

Выгода на лицо. Рука-лицо в комплекте.
Раньше вы нанимали команду под IOS,Android,Win,Web. А теперь нанимаете только веб-прогеров и они пилят вам все это на одном (практически) стеке.

А теперь можно нанять одну команду Delphi и она соберет один код под IOS,Android,Win,Mac,Linux (FMX) и Web (UniGUI). Мы именно так и делаем.
Надо просто тестировать своё ПО на слабых машинах, с ограничением по памяти, с урезанным интернетом.
Это дорого. Работал в не совсем безызвестном навителе, занимался в том числе и оптимизациями по памяти на слабых устройствах. Так вот, отладка на этом занимает очень много времени, и тратит, в том числе, и моральные ресурсы программиста.

Как у пожарников. Работа не пыльная, но как пожар, так хоть увольняйся

Скорее наоборот, пока запустится приложение с накрученной на него дебажной информацией и логгером использования памяти, успеешь забыть, что проверить хотел. Скучно очень.
UFO landed and left these words here
Либо мы приструним свои амбиции, либо мы вернёмся к написанию более экономного и эффективного кода. Иначе говоря, назад в будущее.

Во-первых, какой бы экономный и эффективный код не был, это не поможет в долговременной перспективе. Во-вторых, также есть Закон Обстинга, который гласит о том, мощь компиляторов удваивается каждые 18 лет, так что с неэффективным кодом не все так плохо. В третьих, есть другие архитектуры, которые могут кардинально увеличивать производительность определенных вычислений (нейросети): Аппаратное ускорение глубоких нейросетей: GPU, FPGA, ASIC, TPU, VPU, IPU, DPU, NPU, RPU, NNP и другие буквы.

Ну и нафига нейросети банальному мессенджеру на JS? :)

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

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

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

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


Для чего надо: всяческие автопилоты, роботы-уборщики. Если говорить про мобилки — консультанты, помощники (не такие, как Siri). И куча других приложений на самом деле, в которых идет активное взаимодействие с окружающей средой и в которых существует большое количество неопределенностей.


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

С ИИ на мобилке человек может быть уже не нужен

Нафига заставлять банальный мессенджер на JS выполнять функции IDE, CRM и CMS?
Вот все сначала так говорят. А потом импорт адресных книг, смайлики, просмотр картинок-видосиков, дополнения, встроенные приложения, сохранение в облаке…
В соревновании, кто первым напишет свою операционную систему участвуют: утилита для записи дисков Nero Burning Rom и утилита просмотра картинок ACDSee…

В итоге выиграл браузер Chrome, ага.