Код редиса не смотрел, возможно там всё просто. Но в общем случае в сложном продукте с миллионами строк кода, который пишет десяток разных команд, гарантировать, что заданный кусок бизнес логики, использующий несколько разных компонент, не выделяет память, практически невозможно даже если по смыслу оно не нужно. Кроме того ещё и код используемых сисколлов надо посмотреть, нет ли аллокаций в коде ядра.
И на самом деле есть аргумент посерьёзнее - OOM killer убивает процесс до того, как malloc возвращает 0, легко проверяется на простом примере. Так что все рассуждения о попытках обработать такую ситуацию - только теория.
Во-первых, серверные мощности возможно рационально загрузить и включить в работу 24/7. Персональные же компьютеры включены не более 12-16 часов в сутки, а средняя загрузка их процессора исчисляется единицами процентов.
Пока не вижу проблем, перенос вычислений на сервера эффективнее использует ресурсы.
В результате, если всем пользователям в мире для удовлетворения их потребностей на текущий момент нужно совокупно N флопс и M байт
Нет таких констант, есть куча задач, для которых чем больше флопов, тем лучше - как классических (типа прогноза погоды), так и новых (те же LLM). Так что насытить потребности в принципе не получится )
Да, и что вы называете кастомной реализацией и некастомной?
Отдельная схема под конкретный функционал или общая схема для интепретации микрокода и код в памяти для разных вещей (legacy инструкции, PMU, управление температурой/частотой и прочих не связанных с основной работой штук, которых в современном процессоре пруд пруди).
Если вы хотите фиксировать событие типа выталкивания строки кэша
Фиксация события, конечно, делается на логике. Вопрос в реакции - особенно если хочется записать в буфер в памяти адрес инструкции, адрес данных, в каком конкретно кеше (а может и в TLB) был промах, latency и т.д. Ну или писать в буфер в память полную историю выполнения, по максимуму минимизируя объём данных (типа Intel PT). Верю, что можно описать на верилоге и реализовать отдельным блоком транзисторов - вопрос, стоит ли?
Вообще вы пробовали сами реализовать какой-нибудь игрушечный процессор с микрокодом и без него?
Нет - так что честно говоря спорю в основном для получения новых знаний )
кастомную реализацию performance counters для GPU
Там возможность семплинга (и соответственно привязки событий к коду) была? Просто счётчик, инкрементирующийся по какому то условию, которое можно получить логической функцией от имеющихся сигналов, конечно проще захардкодить.
Ну да, на мой взгляд либо мы аллоцируем всё сразу и дальше никакой динамической аллокации (скажем, в коде управления станками или автомобилем), или забиваем на обработку и при недостатке памяти тихо умираем. Нормально выйти при недостатке памяти из сложного приложения типа браузера - это надо очень сильно постараться, никто столько ресурсов на написание кода не даст.
Тогда, если мы пользуемся им на полную, new и так исключение кинет. Но coding guidelines могут запрещать использование исключений, по крайней мере про одну компанию, где так принято, все знают ) Ну и даже с исключениями в большом продукте с кучей сторонних библиотек не так всё просто.
Ну как бы общее правило - assert'ом проверяются инварианты, зависящие только от логики кода, а не от внешних факторов.
Другое дело, что корректная обработка возврата 0 из malloc (или нехватки памяти в общем случае) - нетривиальная задача. Как минимум надо гарантировать, что ничего не аллоцируется в коде обработки и разобраться, как при этом взаимодействуют потоки (потому как если память кончилась, она кончилась у всех).
приставка Sony PS1 вообще ДЛЯ МЕНЯ непривлекательна. Смотреть не на что.
На днях прошёл PCшный порт второго Дума под PS1 (использует ресурсы с CD для приставки) - пожалуй, действительно поатмосфернее оригинала, хотя уровни и наполнение пришлось таки поурезать, всё таки даже до нормального 386го она не дотягивала.
Естественно нет, вопрос в общем количестве транзисторов на одну схему интерпретации и память кода под разную функциональность или кастомную реализацию на логике каждой новой фичи мониторинга и т.п. Опять же - я не про базовую функциональность процессора по исполнению инструкций.
Понятно, что без триггеров и сдвиговых регистров процессор не построишь. Вопрос только, стоит ли тратить кастомную логику и транзисторы на каждую фичу, напрямую не связанную с производительностью (выполнением инструкций, постоянно встречающихся в реальном коде) и не дешевле ли вставить интепретатор микрокода? Ну и возможность что-то пофиксить после выхода железяки тоже полезна.
А сгенерировать прерывание по переполнению счётчика? В случае SPE - ещё и записать в буфер в памяти кучу данных об инструкции (latency, DLA и т.д.) в специальном формате.
Код редиса не смотрел, возможно там всё просто. Но в общем случае в сложном продукте с миллионами строк кода, который пишет десяток разных команд, гарантировать, что заданный кусок бизнес логики, использующий несколько разных компонент, не выделяет память, практически невозможно даже если по смыслу оно не нужно. Кроме того ещё и код используемых сисколлов надо посмотреть, нет ли аллокаций в коде ядра.
И на самом деле есть аргумент посерьёзнее - OOM killer убивает процесс до того, как malloc возвращает 0, легко проверяется на простом примере. Так что все рассуждения о попытках обработать такую ситуацию - только теория.
Пока не вижу проблем, перенос вычислений на сервера эффективнее использует ресурсы.
Нет таких констант, есть куча задач, для которых чем больше флопов, тем лучше - как классических (типа прогноза погоды), так и новых (те же LLM). Так что насытить потребности в принципе не получится )
Отдельная схема под конкретный функционал или общая схема для интепретации микрокода и код в памяти для разных вещей (legacy инструкции, PMU, управление температурой/частотой и прочих не связанных с основной работой штук, которых в современном процессоре пруд пруди).
Фиксация события, конечно, делается на логике. Вопрос в реакции - особенно если хочется записать в буфер в памяти адрес инструкции, адрес данных, в каком конкретно кеше (а может и в TLB) был промах, latency и т.д. Ну или писать в буфер в память полную историю выполнения, по максимуму минимизируя объём данных (типа Intel PT). Верю, что можно описать на верилоге и реализовать отдельным блоком транзисторов - вопрос, стоит ли?
Нет - так что честно говоря спорю в основном для получения новых знаний )
Там возможность семплинга (и соответственно привязки событий к коду) была? Просто счётчик, инкрементирующийся по какому то условию, которое можно получить логической функцией от имеющихся сигналов, конечно проще захардкодить.
OOM killer может и до них добраться.
А во время обработки этого запроса точно никаких аллокаций нет?
Только до этого может захотеть что то ещё аллоцировать.
В соответствующем enum'е в llvm примерно столько и есть. И, соответственно, есть работающее семейство компиляторов )
OOM рулетка какая то )
Надеясь что память вдруг появится?
Ну да, на мой взгляд либо мы аллоцируем всё сразу и дальше никакой динамической аллокации (скажем, в коде управления станками или автомобилем), или забиваем на обработку и при недостатке памяти тихо умираем. Нормально выйти при недостатке памяти из сложного приложения типа браузера - это надо очень сильно постараться, никто столько ресурсов на написание кода не даст.
Тогда, если мы пользуемся им на полную, new и так исключение кинет. Но coding guidelines могут запрещать использование исключений, по крайней мере про одну компанию, где так принято, все знают ) Ну и даже с исключениями в большом продукте с кучей сторонних библиотек не так всё просто.
И что можно сделать в этой общей функции, если проверка не сработала? Разве что exit(MEMORY_EXHAUSTED_CODE)...
Ну как бы общее правило - assert'ом проверяются инварианты, зависящие только от логики кода, а не от внешних факторов.
Другое дело, что корректная обработка возврата 0 из malloc (или нехватки памяти в общем случае) - нетривиальная задача. Как минимум надо гарантировать, что ничего не аллоцируется в коде обработки и разобраться, как при этом взаимодействуют потоки (потому как если память кончилась, она кончилась у всех).
На днях прошёл PCшный порт второго Дума под PS1 (использует ресурсы с CD для приставки) - пожалуй, действительно поатмосфернее оригинала, хотя уровни и наполнение пришлось таки поурезать, всё таки даже до нормального 386го она не дотягивала.
Мне до мая прошлого года вполне хватало ASUS 1015 PEM на Атоме - если бы не помер, идущих на нём непройденных игр хватало ещё лет на несколько.
Естественно нет, вопрос в общем количестве транзисторов на одну схему интерпретации и память кода под разную функциональность или кастомную реализацию на логике каждой новой фичи мониторинга и т.п. Опять же - я не про базовую функциональность процессора по исполнению инструкций.
Понятно, что без триггеров и сдвиговых регистров процессор не построишь. Вопрос только, стоит ли тратить кастомную логику и транзисторы на каждую фичу, напрямую не связанную с производительностью (выполнением инструкций, постоянно встречающихся в реальном коде) и не дешевле ли вставить интепретатор микрокода? Ну и возможность что-то пофиксить после выхода железяки тоже полезна.
А сгенерировать прерывание по переполнению счётчика? В случае SPE - ещё и записать в буфер в памяти кучу данных об инструкции (latency, DLA и т.д.) в специальном формате.
Для китайских кастомеров, на которых в основном ориентируется Longsoon, разница принципиальная.