mayton2019

Любая оптимизация начинается от проблемы. Из проблем памяти я могу отметить технологический предел
на пропускную способность. (так называемая Стена Фон-Неймана). Она частично решается
кешамя для горячих участков кода но никак не решается в обобщенной постановке.

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

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

Ничего не делай. Отнеси в ремонт пускай там сделают. Когда речь касается чего-то стоящего - лучше
не экспериментировать.

Ну... это противоречит идее Java. Платформа ведь создавалась чтобы быть общим знаменателем для десятков аппаратных платформ для встраиваемой бытовой техники. Такая была идея по крайней мере.

И практика платформ показала что поменять софт в 1000 раз дешевле чем поменять оборудование.

UPD: Вот вики описывает 6 попыток реализовать Java-процессор в железе
https://en.wikipedia.org/wiki/Java_processor (3 исследовательских и 3 коммерческих продукта)
надо читать и разбираться что они сделали.
В каком статусе? Используется щас или нет?

У меня был комп Электроника БК1001 и ZXSpectrum которые работали на частотах 3 и 3.5 Мгц и никаких
проблем я не испытывал.

Проблемы теоретически могут быть у комьютерных игр которые завязаны на том что 1 тик или один кадр
игровой логики может быть обработан за 1/50 долю секунды к примеру и некоторые игры при замедлении
тактовой частоты могут вести себя странно. Впрочем в каждом кейсе надо разбираться. Странно - не означает
неправильно. Просто разработчик когда писал игру расчитывал на определенную производительность.

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

Других проблем вобщем-то не предвидится.

Ну для floating point чисел ничего интересного не происходит. Результат будет - бесконечность (Inf).
И эта бесконечность - это вполне себе реальная константа для таких чисел.

Обычно L3 - общий для всех ядер а L2/L1 - персональные кеши для каждого Thread/Kernel.
Но технологии меняются. И я не думаю что это какая-то окончательна архитектура. Могут быть
и исключения.

Этот вопрос нужно адресовать к современной физике. Сделать такой процессор не очень сложно.
Но сложно сделать его потребительски привлекательным. Все делатели процессоров в современном
мире бьются за энергоэффективность. А с повышением частоты там просиходит (пускай физики меня
поправят) квадратичное увеличение потребляемой мощности (к коэффциентиком). Вот сколько именно
ватт я сейчас не скажу но величина будет неприятная. Тоесть 8 ГГц процессор будет греться как кофейник
и будет потреблять более чем в 4 раза если сравнивать его с 2Ггц ядром.

Еще я-бы рассмотрел такой вариант как влияние на здоровье человека. Выж понимете да. Вся современная
радиопередающая техника (мобилы, Wi-Fi, Bluetooth) со всех сторон зажаты медицинскими нормами
всяких международных контролирующих организаций. И не дай бох хоть одна организация докажет
что вероятность поймать рак мозга растет там на 5% от такого процессора - загнобят санкциями.

По поводу мегафлопов. Фактически производительность техно-стека (Процессор-Память-I/O)
зависит не только от проца но и от всех устройств которые в стеке. И даже работая на 8ГГц
ты скорее всего не получишь желаемого роста скорости майнкрафта на переходе от 4 х 2 Ггц просто по той
причине что кеш и память и диск остались ровно теже самые.

Да и вообще. Эпоха гигантизма в процессорах прошла. Щас все двигаются к узкой специализации
CPU/GPU/TPU и к интернету вещей. И майнкрафт здесь никак не будет главным регулятором стратегии.
Уж извини. Водное охлаждение тоже вещь такая себе. Узкий сегмент энтузиастов. Обычным людам это
так же не надо как и квантовый комп.

L3 кеш как сильно бустит производительность игровому серверу?

Да сильно. Вот формулы я не знаю. Да и никто не знает. Это как в симуляции.
Чтоб узнать сколько - ты просто берешь две конфигурации. Запускаешь бенчмарк
и смотришь как было ДО и как стало ПОСЛЕ. И ничего лучше пока не придумали.
Компьютерное железо - это практическая наука. И здесь эксперимент - важнее теории.

По какому алгоритму игровой сервер использует кеш процессора?

Насчет алгоритма я не знаю. Возможно разновидность LRU. Я помню смотрел одно
видео где один С++ ный маг и колдун (кажется Ulrih Drepper) рассказывал об алгоритмах
кешей в железе.

Алгоритм оперирует обычно кусочками памяти в блоках по 64 байта. Кеш-линии.
И если тебе надо прочитать 1 байтик то будет прочитан кусок кратный кеш-линии.
Зато при последующих попытках читать второй и третий байтики алгоритм будет
оперировать с пирамидой кешов. Обычно L1 - самый быстрый и другие медлненее.
Хорошо прогретые кеши обычно содержат 100% нужную информаицю для текущего
ядра процессора. Или для thread.

Кеш придумали для геймеров или для серверов тоже?

Нет. Его создавали просто для эффективного использования железа еще в 20м веке.
Мы его увидели начиная кажется с первых Pentium-ов.

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

Как хорошо будет жить сервер с основной нагрузкой на одно ядро без кеша L3?

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

Если в процессор дать кеша 2gb L3 то его IPC вырастет?

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

проц грузился сильнее видеокарты

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

Все современные задачи делятся условно на 2 категории. CPU-bound. IO-bound.

Первые. Это рендеринг графики. Игры. Численные методы. Майнинг. И все такое. Под это делают разбиение задачи на Processes (Windows/Linux), Threads (Posix). Короче бьються на независимые части и запускаются на отдельных процессорах или ядрах или потоках железа. В таком случае загрузка железа максимальна и отдача максимальна. Биг-дата джобы сюда-же можно положить.

И второй тип задачи - это современные бизнес приложения которые большую часть времени (ну допустим 80%)
стоят на паузе и слушают сетевой порт. И как только что-то прилетает они начинают активничать. Практика показала что большую часть таких задач можно запускать в 1 потоке и все будет нормально. Главное чтоб обработчик долго не тупил. Отработал свой реактивный евент. Или там MQ событие или событие актора и перекинулся на следующее.
Вот. Если грамотно делать второй тип то на 10 потоках ОС можно запустить тысячи акторов или веб-хендлеров бизнес приложения и все будет норм. Тоесть мы фокусируемся на том что I/O важнее.

Попытка смешивать эти юзкейсы или менять местами приводила к проблемам. Например если запускать много потоков ОС в рамках одной бизнес задачи то они очень быстро зацепятся за какой-то глобальный объект (mutex, critical section) и большее число времени процессора будет тратиться не на бизнес задачу а обслуживание этой конкуренции. Вобщем конкарренси - это страшная беда. И парадоксально но увеличение числа ядер или процессоров даже не решают проблему конкарренси а усугубляют. Есть доклад по Erlang на эту тему. И вообще самое лучшее конкарренси - это когда его нет.

Есть еще статья Стоунбрейкера (создатель Postgresql) где он рассуждает на тему куда сгорают мегафлопы в современных dbms под нагрузкой и приходит к очень печальным выводам. Почитайте. Это тоже в тему CPU-bound.

А попробуй память вытащить и включить.

И на кулёчек не надо ложить. Электризуется... со всеми последствиями.

Я какое-то время качал учебные видосы с youtube. И кое что добавлю. Видео публикуется в широком диапазоне размеров и кодеков.

Самый слабый размер - от

3gp 176x144
и самый толстый что я видел

webm 3840x2160

Последнее - это классифицируется как 4К видео. Так вот. Я думаю что нагрузка на ЦП определяется
размером видео. Который в свою очередь определяется толщиной вашего канала интернета
и физическим размером монитора. Плагин плеера должен иметь какую-то разумную логику
активации высоких режимов. Очевидно что на обычном FullHD монике нет смысла качать
графику выше чем пикселов покажет ваш моник.

Что еще может влиять на температуру? Наверное тип кодека. Из таковых я вижу VP9 и AVC1.

Кодек выбирается по непонятному мне алгоритму. Тоесть существуют видосы с одинаковым разрешением
но с разными кодеками. Зачем youtube это делает - непонятно. Но возможно для совместимости.

Вот как-то так.

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

float x = 3.14;

и посмотреть sizeof(...)

Можно еще глянуть как выглядит число 3.14 в бинарном представлении. Сделаешь это кастингом.
И сделать выводы о стандартах хранения флоатов в данном компилляторе.

Теоретически должен быть 32х битный везде.

Но проверь!

Бывают еще double (64bit) extended (80bit),
half float (16bit не встречал в практике никогда но литература ссылается).

Прошу прощения за внезапный UP.

Но мне задали вопрос про Forth. Я увлекся и тут меня (Остапа) понесло.
Вобщем я начал читать и листать всякую инфу по форту. Первое впечатление - полный бардак
в стандартах. Нет никакого общего понимания что такое вообще язык Форт. По крайней
мере я для себя понял что форт - это просто набор слов (words) каждое из которых либо число
либо слово которое вызывает вычисления. Больше реально ничего не регламентировано.
И я так понимаю что Форт-еров это вообще не парит. Они такие себе либеральные оптимисты.
Судя по конференциям средний возраст Форт-иста - далеко за 70 лет. Дедушки с бородами...

По поводу компиллятора и транслятора. Ничего пока непонятно. Целевая платформа
- не всегда x86 а всякое редкое железо. И тренироваться могу пока на GForth который
кое-как работает но не хватает слов. И YForth который крашится в segfault сразу
на моем Linux x64. Остальные я пока не пробовал.

Сам внешний вид кода у меня вызвает немой восторг как когда-то вызывал Common-Lisp.
Это пожалуй редкое чувство я не испытывал давно. И при всем при этом я не нашел
совершенно никакого практического применнеия. Так. Просто забавная мозговая идея
которую приятно думать на сон грядущий.

На главный вопрос автора - и я ответить не могу. Не знаю является или нет. И я не знаю является
ли он вообще ЯЗЫКОМ. МОжет он как Lisp - просто идея. Он просто настолько широк что
определение языка его сужает.

Надеюсь я никого не отвлек своим спичем от важных дел.

Для проведения уроков хочу написать простенький симулятор процессора

Нужно делать тот минимум который нужен для уроков. Если например это арифметика - то
сойдет процессор без регистров. Можно считать что разрабатываем систему команд для
стековой машины. Как Java.

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

Селерон всегда был таким жлобским вариантом Intel. Для бедных короче. В серверы его не ставили. Я когда учился в универе у меня был Celeron-300/Tray. Частота 300Мгц. 32х битный.

Зачем сегодня его покупать - я не знаю. Интерес разве что коллекционера старых вещей.

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