серверная память - регистровая, т.е. там стоит дополнительная микросхема для повышения стабильности работы.
Ну раз это статья-ликбез, давайте не допускать фактических ошибок. Регистровая память - это всё-таки про снижение электрической нагрузки и про повышенный объём на планку памяти (который будет недоступен на обычной материнке без поддержки регистровой памяти) за счёт большого количества чипов на планке. А "стабильность работы" - это скорее про ECC, что бывает и на unbuffered-памяти. Вот только на днях подыскивал нерегистровую ECC DDR5.
Я думаю такая точка зрения существует из-за фильмов вроде этого, который выглядит сначала как приличный научно-популярный фильм, ссылающийся на какие-то постулаты квантмеха, а потом выясняется что это ньюэйджовое метафизическое чёрти-что. Но выясняется не всеми, к сожалению.
Согласен, расширение exe и загрузчик в начале файла тут только ради удобства запуска. Дотнет-сборкам вообще не особо нужно прикидываться PE-файлами. Я про другое. .NET Framework, по крайней мере определённых версий, считается компонентом Windows. С некоторой натяжкой это в общем-то системное API. Равно как и Direct3D, например. Вопрос - где проходит граница между "программой" и "скриптом на питоне"?) Что должно/не должно быть в бинаре?
Шикарная статья. Всем, кто пишет про "зачем", предлагаю ознакомиться с жанром 64k intro и теми высотами, которых он достиг на современных графических API. Я к тому, что эта статья примерно из той же категории. Спасибо за перевод!
Подтверждаю, отличный проц в домашний комп. В приличном корпусе под тихим NH-U14S (в спецредакции для сокета SP3) не доставляет никаких проблем. Жаль только не за 200 баксов я его брал.
вместо нативных компилируемых приложений пишут веб-приложения или на JS, или на чём-то компилируемом в JS.
Именно об этом и речь. WASM понемногу набирает в популярности, но новый UI для какого-нибудь спортмагазина сейчас будут писать на TS/JS с каким-нибудь реактом.
Другой у пользователя нет и разработчик приложения не может на это повлиять.
В статье как раз перечислены всякие песочницы, которые были, и которые просто не выстрелили. Ну или уже отслужили своё, как Flash. Собственно и браузер не стал бы такой замечательной песочницей, если б работал без всякой магии вроде угадывания классов (см. комментарии ниже). Просто Гугл вложил огромное количество сил в оптимизацию движка, и по сути захватил Веб как платформу, и навязал её всем остальным. Раньше ещё можно было с этим спорить, но сейчас Веб - это Гугл, ибо Хромиум. Firefox остался единственной альтернативной реализацией, и кажется лет через 10 он к сожалению сдохнет. Гугол вполне себе победил всех в плане экосистемы для приложений, чистый бизнес. Нет никакого "веба", когда код браузера и спеки настолько сложны, что уже никто не напишет это всё с нуля. Есть Хромиум и его API для создания приложений. Чем это лучше какого-нибудь WinAPI с точки зрения отсутствия vendor-lock?
Язык ассемблера вполне себе типизирован - его типы совпадают с типами целевой машины. Вместо всяких enum-ов, классов и union-ов высокоуровневых языков у вас байты, машинные слова и производные от них (какие-нибудь значения с плав. точкой в MMX регистрах). Более того, для машинных инструкций всегда точно специфицируется, что она будет делать с данными и какого они размера.
Да-да-да, вот с этого у меня бомбит больше всего. Из-за того, что в качестве целевого языка компиляции мы используем динамический язык, мы сначала теряем кучу полезной информации о типах, о структуре объектов и т.п., а потом V8 сотоварищи начинает это всё угадывать обратно с использованием всякой магии и статистики. И при этом продвинутому разработчику нужно ЗНАТЬ хотя бы в общих чертах, как это происходит, иначе его код свалится в deopt и внезапно начнёт работать в 50 раз медленнее. Отличная абстракция, которую мы заслужили. Приятно видеть, что хоть кто-то ещё обращает внимание на абсурдность ситуации.
Пользователям нужна песочница для выполнения приложений без ритуала скачивания, установки и без риска.
Вот именно! Нужна песочница и очень простая доставка и выполнение логики на машине клиента. В каком месте из этого следует, что нужно переписать приложение на динамический язык? Ну или на статический, который был создан только ради того, чтобы можно было потом без гемора и кучи прослоек скомпилироваться в динамический? Я вот не могу найти ответы. Сколько виртуальных машин с разными свойствами люди успели напридумать за это время. Наконец-то хоть одна (WebAssembly) подошла.
Я предположу, что WebAssembly постепенно захватит весь современный мир фронтенд-разработки, и мир ПО эволюционным образом превратится в совершенно иной.
Когда это наконец случится, я смогу спокойно умереть. Компилировать статически типизированные языки в динамический только ради возможности доставить логику пользователю - это победа техники над здравым смыслом. Как и вообще необходимость переписывать половину кода в мире только ради того, чтобы засунуть это в браузер. Зачем вообще засовывать приложение в браузер? Зачем делать из браузера операционную систему?
Это как плохой сон, но ты никак не можешь проснуться.
Считаю Far одним из лучших инструментов в плане инвестиций времени - лет 20 одни и те же шорткаты и привычки помогают каждый день. А с учётом того, что я школьником немного застал Нортон и "переходил" с него - то даже больше 20 лет.
Я думаю в пятом пункте речь о том, что РБД реализуют наиболее удачное сочетание гарантий и ограничений по-умолчанию, включая такие гарантии, существование которых интуитивно допускается слишком многими разработчиками.
Например, многие привыкли, что БД должна поддерживать транзакционное изменение нескольких элементов данных сразу, и только потом узнают горькую правду о выбранной ими документно-ориентированной СУБД.
А вообще, это так не работает. Если архитектура призвана жрать много электричества, её будут ставить туда, где можно жрать много, и ничего за это не будет.
В телефонах ARM потому что её можно подключить к аккумулятору, и она всегда будет там лучше, чем x86.
Раз вы задаёте этот вопрос, значит вы используете подход "отдельная директория для public хедеров", как и в этой статье. Ну т.е. когда все публичные заголовочные файлы физически перемещаются в отдельную директорию.
В их папках обычно не создаётся CMakeLists просто потому, что с ними особо нечего делать, кроме как скопировать на этапе install (лично я советую делать это и на этапе сборки, особенно если есть генерируемые хедеры, и использовать их ТОЛЬКО из build-директории, а не из source-директории, но это вопрос отдельный). Раньше копировали как могли, потому что довольно давно существующее свойство таргета PUBLIC_HEADER не сохраняет структуру директорий для публичных хедеров, и потому им проще не пользоваться вовсе.
НО! В версии 3.23 наконец приехал стандартный механизм, который реально работает для публичных хедеров - file sets. Единственный на данный момент поддерживаемый тип file set-а это как раз HEADERS. Для этого типа даже автоматически изменяется INCLUDE_DIRECTORIES таргета. Ну и самое главное - при install(TARGETS)сохраняется относительная структура файлов и директорий - как раз то, что обычно нужно для публичных хедеров.
Это спинофф к TRON. Вы играете за MCP.
Ну раз это статья-ликбез, давайте не допускать фактических ошибок. Регистровая память - это всё-таки про снижение электрической нагрузки и про повышенный объём на планку памяти (который будет недоступен на обычной материнке без поддержки регистровой памяти) за счёт большого количества чипов на планке. А "стабильность работы" - это скорее про ECC, что бывает и на unbuffered-памяти. Вот только на днях подыскивал нерегистровую ECC DDR5.
Я думаю такая точка зрения существует из-за фильмов вроде этого, который выглядит сначала как приличный научно-популярный фильм, ссылающийся на какие-то постулаты квантмеха, а потом выясняется что это ньюэйджовое метафизическое чёрти-что. Но выясняется не всеми, к сожалению.
Согласен, расширение exe и загрузчик в начале файла тут только ради удобства запуска. Дотнет-сборкам вообще не особо нужно прикидываться PE-файлами.
Я про другое. .NET Framework, по крайней мере определённых версий, считается компонентом Windows. С некоторой натяжкой это в общем-то системное API. Равно как и Direct3D, например. Вопрос - где проходит граница между "программой" и "скриптом на питоне"?) Что должно/не должно быть в бинаре?
А что насчёт этого?) http://demojs.org/ Не имеет права на жизнь?)
Шикарная статья. Всем, кто пишет про "зачем", предлагаю ознакомиться с жанром 64k intro и теми высотами, которых он достиг на современных графических API. Я к тому, что эта статья примерно из той же категории. Спасибо за перевод!
Подтверждаю, отличный проц в домашний комп. В приличном корпусе под тихим NH-U14S (в спецредакции для сокета SP3) не доставляет никаких проблем. Жаль только не за 200 баксов я его брал.
Видимо виртуальных машин было сильно больше одной.
Именно об этом и речь. WASM понемногу набирает в популярности, но новый UI для какого-нибудь спортмагазина сейчас будут писать на TS/JS с каким-нибудь реактом.
В статье как раз перечислены всякие песочницы, которые были, и которые просто не выстрелили. Ну или уже отслужили своё, как Flash.
Собственно и браузер не стал бы такой замечательной песочницей, если б работал без всякой магии вроде угадывания классов (см. комментарии ниже). Просто Гугл вложил огромное количество сил в оптимизацию движка, и по сути захватил Веб как платформу, и навязал её всем остальным. Раньше ещё можно было с этим спорить, но сейчас Веб - это Гугл, ибо Хромиум. Firefox остался единственной альтернативной реализацией, и кажется лет через 10 он к сожалению сдохнет.
Гугол вполне себе победил всех в плане экосистемы для приложений, чистый бизнес. Нет никакого "веба", когда код браузера и спеки настолько сложны, что уже никто не напишет это всё с нуля. Есть Хромиум и его API для создания приложений. Чем это лучше какого-нибудь WinAPI с точки зрения отсутствия vendor-lock?
Язык ассемблера вполне себе типизирован - его типы совпадают с типами целевой машины. Вместо всяких enum-ов, классов и union-ов высокоуровневых языков у вас байты, машинные слова и производные от них (какие-нибудь значения с плав. точкой в MMX регистрах). Более того, для машинных инструкций всегда точно специфицируется, что она будет делать с данными и какого они размера.
Да-да-да, вот с этого у меня бомбит больше всего. Из-за того, что в качестве целевого языка компиляции мы используем динамический язык, мы сначала теряем кучу полезной информации о типах, о структуре объектов и т.п., а потом V8 сотоварищи начинает это всё угадывать обратно с использованием всякой магии и статистики. И при этом продвинутому разработчику нужно ЗНАТЬ хотя бы в общих чертах, как это происходит, иначе его код свалится в deopt и внезапно начнёт работать в 50 раз медленнее. Отличная абстракция, которую мы заслужили.
Приятно видеть, что хоть кто-то ещё обращает внимание на абсурдность ситуации.
Вот именно! Нужна песочница и очень простая доставка и выполнение логики на машине клиента. В каком месте из этого следует, что нужно переписать приложение на динамический язык? Ну или на статический, который был создан только ради того, чтобы можно было потом без гемора и кучи прослоек скомпилироваться в динамический? Я вот не могу найти ответы.
Сколько виртуальных машин с разными свойствами люди успели напридумать за это время. Наконец-то хоть одна (WebAssembly) подошла.
Когда это наконец случится, я смогу спокойно умереть. Компилировать статически типизированные языки в динамический только ради возможности доставить логику пользователю - это победа техники над здравым смыслом. Как и вообще необходимость переписывать половину кода в мире только ради того, чтобы засунуть это в браузер. Зачем вообще засовывать приложение в браузер? Зачем делать из браузера операционную систему?
Это как плохой сон, но ты никак не можешь проснуться.
Считаю Far одним из лучших инструментов в плане инвестиций времени - лет 20 одни и те же шорткаты и привычки помогают каждый день. А с учётом того, что я школьником немного застал Нортон и "переходил" с него - то даже больше 20 лет.
Где по ссылке написано что-либо о предпочтениях разработчика по приёму платежей? Не смог найти упоминаний.
Я думаю в пятом пункте речь о том, что РБД реализуют наиболее удачное сочетание гарантий и ограничений по-умолчанию, включая такие гарантии, существование которых интуитивно допускается слишком многими разработчиками.
Например, многие привыкли, что БД должна поддерживать транзакционное изменение нескольких элементов данных сразу, и только потом узнают горькую правду о выбранной ими документно-ориентированной СУБД.
VB6, о, моя молодость. Как гляну на иконку окна, так сразу... (роняет скупую слезу)
https://www.asus.com/ru/Mobile/Phones/ZenFone/ZenFone_2_ZE551ML/
А вообще, это так не работает. Если архитектура призвана жрать много электричества, её будут ставить туда, где можно жрать много, и ничего за это не будет.
В телефонах ARM потому что её можно подключить к аккумулятору, и она всегда будет там лучше, чем x86.
Раз вы задаёте этот вопрос, значит вы используете подход "отдельная директория для public хедеров", как и в этой статье. Ну т.е. когда все публичные заголовочные файлы физически перемещаются в отдельную директорию.
В их папках обычно не создаётся CMakeLists просто потому, что с ними особо нечего делать, кроме как скопировать на этапе install (лично я советую делать это и на этапе сборки, особенно если есть генерируемые хедеры, и использовать их ТОЛЬКО из build-директории, а не из source-директории, но это вопрос отдельный). Раньше копировали как могли, потому что довольно давно существующее свойство таргета
PUBLIC_HEADERне сохраняет структуру директорий для публичных хедеров, и потому им проще не пользоваться вовсе.НО! В версии 3.23 наконец приехал стандартный механизм, который реально работает для публичных хедеров - file sets. Единственный на данный момент поддерживаемый тип file set-а это как раз
HEADERS. Для этого типа даже автоматически изменяетсяINCLUDE_DIRECTORIESтаргета. Ну и самое главное - приinstall(TARGETS)сохраняется относительная структура файлов и директорий - как раз то, что обычно нужно для публичных хедеров.