На картинку котика можно поместить. Он тоже к виртуальной памяти не относится, зато милый :)
А если серьезно, то виртуальная память с точки зрения прикладного программиста решает по сути три задачи:
1) Предоставление больших непрерывных блоков (когда свободной памяти в системе 2GB, но четырьмя кусками по 512MB, а нужен буфер в 1GB). Нет необходимости самостоятельно алгоритмически заморачиваться фрагментацией.
2) Отсутствие заботы о том, что память может закончиться (привет свапу). В подавляющем большинстве реального кода обработчиками std::bad_alloc никто не заморачивается.
3) Работа с не-памятью как с памятью: есть какой-то громадный файл в котором нужно что-то поискать - мапим его на память и работаем, как будто прочитали и загрузили. а уж что там с диска подтянуть и когда лишнее освободить - пусть ОС разбирается. Это, кстати, пожалуй единственный случай, когда прикладной программист осознанно и явно (хоть и через прослойку ОС, ессно) взаимодействует с подсистемой виртуальной памяти. Остальные от него просто прозрачно скрыты.
Остальные плюшки типа обеспечения постоянства адресов от прикладного программиста надежно скрыты под капотом.
а... сейчас a go вроде как именно самообслуживание, где-то даже с кассирами, если верить вики.
Ну в целом подход амазона был понятен. Чтобы запустить что-то с ИИ надо сначала ИИ обучить. Датасетов по безбарьерным продажам тогда не было в виду отсутствия таковых продаж. Вменяемую синтетику для этой задачи нагенерить малореально. Нужно брать камеры, делать макеты торговых залов, брать массовку и.о. покупателей, и вторую, вручную размечающую данные. И проверять идею. Ничего удивительного в том, что экономически могло быть целесообразнее строить не макеты, а реальные магазины и в качестве первой массовки использовать реальных живых покупателей я не вижу. В том что идея не смогла преодолеть грань между proof of concept и mvp - тоже: увы, это судьба большинства смелых идей.
ps: Без физических не встречал, самообслуживание - массово. Статистикой со стороны магазинов не обладаю, но по покупательским впечатлениям бОльшая часть продаж именно через самостоятельное пробитие. Наиболее удобная история в некоторых гиперах, когда сканируешь товар прямо в зале, перед тем как в тележку положить. Либо взятым портативным сканером, либо приложухой на своем смартфоне (последнее не уверен что живо, было в одном из ашанов).
С этими-то что не так? По крайней мере в Москве сейчас в каждом втором супермаркете кассы самообслуживания стоят. Причём их массово повводили после довольно коротких пилотов в нескольких (очевидно - успешных).
Тут вот какое дело. Чем больше кучка индусов (читай - объем решаемых задач), тем меньше проигрывает AI (и начиная с какого-то размера начинает выигрывать). Ибо громадные затраты на разработку самого AI и инфраструктуру размазываются по задачам, а электричество для серверов и прочие эксплуатационные расходы все же меньше плошки риса, даже самой скудной. Господа инвесторы именно с этими мыслями деньги несут.
Естественно это все в предположении того, что концепция AI разработки действительно полностью реализована (в возможности чего лично я сильно сомневаюсь, но к делу это не относится).
Строго говоря диалог на кдпв (практически) никакого отношения к виртуальнсти памяти не имеет.
В первой части грустного диалога описаны теоретические мытарства без менеджера памяти (условного malloc/new). Который мало того, что держит под капотом кухню для выделения памяти всяким там векторам и интам, никогда* не ходит к операционке за памятью для единичных выделений, запрашивая сразу крупные блоки из которых потом сам нарезает что нужно, так ещё совершенно* безразличен к тому, виртуальные ли там адреса в куче, иль физические, да и порою к тому есть ли вообще этажом ниже какая-либо ос (ардуинщики не дадут соврать)
Факап второй части связан с отсутствием разграничения доступа к памяти. Механизмы которого никак* на виртуализацию не завязаны. Может быть как разграничение без виртуализации, так и виртуализация без разграничения.
Это отличный показатель способности проходить тест на IQ.
И, емнип, он постоянно перенормируется так, чтобы глобальный средний был 100. Что собственно можно наблюдать на табличке лидеров: разброс и отклонения участников там минимальны
> Странное, на мой взгляд, предложение. О работе архиваторов, как и о MP3
Это предложение естественно не для практического использования, а для понимания концептуального отличия loseless алгоритмов от mp3 и прочая: они не отсекают гармоник, и прочую психоаккустику, которую можно выкинуть из сигнала, особо не испортив его для уха. Они прямо как zip (естественно не в смысле конкретных алгоритмов) обратимо кодируют одну последовательность байт в другую. Естественно, априорное знание о том, что входная последовательность байт - это оцифрованный звук позволяет эффективнее (как с точки зрения ресурсов, так и уровня сжатия) его сжимать по сравнению с универсальными алгоритмами типа deflate (zip) без предобработки. Но теоретически ничто не мешает добавить riff-заголовок к, скажем текстовому файлу (чтобы сделать из него "wav"), сжать его flac и после распаковки и отрезания заголовка получить тот же самый исходный файл. Если то же упражнение проделать с mp3 - на выходе окажется полная лютая фигня. А теки и прочая это уже фишки контейнеров, а не алгоритмов сжатия.
Тут вопрос в том, что если даже для постановочного фото "как у нас все серьёзно" не нашли ничего лучше Hantek'а пятой серии для фона и калечного щупа от 830го на передний план, то что же там с оснащением реальных рабочих мест?
Плохо сочетается “сначала зашифровать, потом сжимать ". А вот " сначала сжать, затем шифровать" это в общем-то best practice: теоретически чем меньше избыточность входных данных тем сложнее криптоанализ.
Wav* это и есть loseless формат, только без сжатия. Сожмите его zip'ом - получите со сжатием. Flac и co это [утрированно] такой специальный zip, оптимизированный под сжатие данных, характерных для LPCM из реальной жизни. Но суть та же: после декодинга получается не "[почти] такой же звук", а бит-в-бит идентичный LPCM.
(*) под wav естественно понимается “LPCM в riff-контейнере", как и бывает в большинстве случаев. Технически, кончено в riff-контейнер wav'а можно засунуть зоть mp3, хоть flac. Но так почти не делают
Что S/PDIF, что HDMI могут передавать в том числе сжатый звук, но базовый "кодек" у обоих - чистый PCM. И кодеки они не "там", а в первую очередь - на носителях и просто сквозняком доставляются от плеера к устройству воспроизведения через S/PDIF/HDMI. В отличии от bluetooth с весьма ограниченной пропускной способностью ни S/PDIF ни HDMI сжимать звук для передачи необходимости нет. Причем если через S/PDIF пролезет только HiRes Stereo (24bit@96kHz), то HDMI спокойно пропустит 8 24bit@192kHz каналов. Куда уж еще losslessней непонятно.
В смысле ? Реализация поддержки всяких там Dolby/DTS * в HDMI опциональна, а вот PCM (который как раз и есть несжатый loseless в чистом виде) - базовое требование.
Просто логин-пароль не секьюрно. Даже сайтики в интернетике все чаще склоняют к 2FA. Некоторые могут и аутентификацию по криптотокенам поддерживать.
Для целей связи классическая 2FA подойдет не очень по многим причинам. А вот криптотокен - вполне. Его можно даже попробовать встроить в телефон (поздравляю, мы только что придумали e-sim). Ну или сделать отдельным подключаемым устройством со стандартизированной шиной и форм-фактором (например - в виде маленькой пластиковой карточки)
На картинку котика можно поместить. Он тоже к виртуальной памяти не относится, зато милый :)
А если серьезно, то виртуальная память с точки зрения прикладного программиста решает по сути три задачи:
1) Предоставление больших непрерывных блоков (когда свободной памяти в системе 2GB, но четырьмя кусками по 512MB, а нужен буфер в 1GB). Нет необходимости самостоятельно алгоритмически заморачиваться фрагментацией.
2) Отсутствие заботы о том, что память может закончиться (привет свапу). В подавляющем большинстве реального кода обработчиками std::bad_alloc никто не заморачивается.
3) Работа с не-памятью как с памятью: есть какой-то громадный файл в котором нужно что-то поискать - мапим его на память и работаем, как будто прочитали и загрузили. а уж что там с диска подтянуть и когда лишнее освободить - пусть ОС разбирается. Это, кстати, пожалуй единственный случай, когда прикладной программист осознанно и явно (хоть и через прослойку ОС, ессно) взаимодействует с подсистемой виртуальной памяти. Остальные от него просто прозрачно скрыты.
Остальные плюшки типа обеспечения постоянства адресов от прикладного программиста надежно скрыты под капотом.
а... сейчас a go вроде как именно самообслуживание, где-то даже с кассирами, если верить вики.
Ну в целом подход амазона был понятен. Чтобы запустить что-то с ИИ надо сначала ИИ обучить. Датасетов по безбарьерным продажам тогда не было в виду отсутствия таковых продаж. Вменяемую синтетику для этой задачи нагенерить малореально. Нужно брать камеры, делать макеты торговых залов, брать массовку и.о. покупателей, и вторую, вручную размечающую данные. И проверять идею.
Ничего удивительного в том, что экономически могло быть целесообразнее строить не макеты, а реальные магазины и в качестве первой массовки использовать реальных живых покупателей я не вижу. В том что идея не смогла преодолеть грань между proof of concept и mvp - тоже: увы, это судьба большинства смелых идей.
ps:
Без физических не встречал, самообслуживание - массово. Статистикой со стороны магазинов не обладаю, но по покупательским впечатлениям бОльшая часть продаж именно через самостоятельное пробитие. Наиболее удобная история в некоторых гиперах, когда сканируешь товар прямо в зале, перед тем как в тележку положить. Либо взятым портативным сканером, либо приложухой на своем смартфоне (последнее не уверен что живо, было в одном из ашанов).
С этими-то что не так? По крайней мере в Москве сейчас в каждом втором супермаркете кассы самообслуживания стоят. Причём их массово повводили после довольно коротких пилотов в нескольких (очевидно - успешных).
Тут вот какое дело. Чем больше кучка индусов (читай - объем решаемых задач), тем меньше проигрывает AI (и начиная с какого-то размера начинает выигрывать). Ибо громадные затраты на разработку самого AI и инфраструктуру размазываются по задачам, а электричество для серверов и прочие эксплуатационные расходы все же меньше плошки риса, даже самой скудной. Господа инвесторы именно с этими мыслями деньги несут.
Естественно это все в предположении того, что концепция AI разработки действительно полностью реализована (в возможности чего лично я сильно сомневаюсь, но к делу это не относится).
Строго говоря диалог на кдпв (практически) никакого отношения к виртуальнсти памяти не имеет.
В первой части грустного диалога описаны теоретические мытарства без менеджера памяти (условного malloc/new). Который мало того, что держит под капотом кухню для выделения памяти всяким там векторам и интам, никогда* не ходит к операционке за памятью для единичных выделений, запрашивая сразу крупные блоки из которых потом сам нарезает что нужно, так ещё совершенно* безразличен к тому, виртуальные ли там адреса в куче, иль физические, да и порою к тому есть ли вообще этажом ниже какая-либо ос (ардуинщики не дадут соврать)
Факап второй части связан с отсутствием разграничения доступа к памяти. Механизмы которого никак* на виртуализацию не завязаны. Может быть как разграничение без виртуализации, так и виртуализация без разграничения.
(*) почти
Это отличный показатель способности проходить тест на IQ.
И, емнип, он постоянно перенормируется так, чтобы глобальный средний был 100. Что собственно можно наблюдать на табличке лидеров: разброс и отклонения участников там минимальны
При чем здесь подпись, когда речь в инициативе про [э]лектронное [п]равительство (госуслуги и прочая).
Например предоставляешь вход в свой личный кабинет через oauth учеткой госуслуг - отсчитай 5рэ за API запрос (если я правильно понял идею)
> Странное, на мой взгляд, предложение. О работе архиваторов, как и о MP3
Это предложение естественно не для практического использования, а для понимания концептуального отличия loseless алгоритмов от mp3 и прочая: они не отсекают гармоник, и прочую психоаккустику, которую можно выкинуть из сигнала, особо не испортив его для уха. Они прямо как zip (естественно не в смысле конкретных алгоритмов) обратимо кодируют одну последовательность байт в другую. Естественно, априорное знание о том, что входная последовательность байт - это оцифрованный звук позволяет эффективнее (как с точки зрения ресурсов, так и уровня сжатия) его сжимать по сравнению с универсальными алгоритмами типа deflate (zip) без предобработки. Но теоретически ничто не мешает добавить riff-заголовок к, скажем текстовому файлу (чтобы сделать из него "wav"), сжать его flac и после распаковки и отрезания заголовка получить тот же самый исходный файл. Если то же упражнение проделать с mp3 - на выходе окажется полная лютая фигня.
А теки и прочая это уже фишки контейнеров, а не алгоритмов сжатия.
Тут вопрос в том, что если даже для постановочного фото "как у нас все серьёзно" не нашли ничего лучше Hantek'а пятой серии для фона и калечного щупа от 830го на передний план, то что же там с оснащением реальных рабочих мест?
Плохо сочетается “сначала зашифровать, потом сжимать ". А вот " сначала сжать, затем шифровать" это в общем-то best practice: теоретически чем меньше избыточность входных данных тем сложнее криптоанализ.
Строго говоря шифрование - гораздо более дешевая операция, чем компрессия
Wav* это и есть loseless формат, только без сжатия. Сожмите его zip'ом - получите со сжатием. Flac и co это [утрированно] такой специальный zip, оптимизированный под сжатие данных, характерных для LPCM из реальной жизни. Но суть та же: после декодинга получается не "[почти] такой же звук", а бит-в-бит идентичный LPCM.
(*) под wav естественно понимается “LPCM в riff-контейнере", как и бывает в большинстве случаев. Технически, кончено в riff-контейнер wav'а можно засунуть зоть mp3, хоть flac. Но так почти не делают
Крутите настройки даунмиксера, добавляя децибел центральному каналу.
Что S/PDIF, что HDMI могут передавать в том числе сжатый звук, но базовый "кодек" у обоих - чистый PCM.
И кодеки они не "там", а в первую очередь - на носителях и просто сквозняком доставляются от плеера к устройству воспроизведения через S/PDIF/HDMI. В отличии от bluetooth с весьма ограниченной пропускной способностью ни S/PDIF ни HDMI сжимать звук для передачи необходимости нет.
Причем если через S/PDIF пролезет только HiRes Stereo (24bit@96kHz), то HDMI спокойно пропустит 8 24bit@192kHz каналов. Куда уж еще losslessней непонятно.
В смысле ? Реализация поддержки всяких там Dolby/DTS * в HDMI опциональна, а вот PCM (который как раз и есть несжатый loseless в чистом виде) - базовое требование.
Красота: даже в красивом пресс релизе засветился дешманский щуп, леченый термоклеем.
Просто логин-пароль не секьюрно. Даже сайтики в интернетике все чаще склоняют к 2FA. Некоторые могут и аутентификацию по криптотокенам поддерживать.
Для целей связи классическая 2FA подойдет не очень по многим причинам. А вот криптотокен - вполне. Его можно даже попробовать встроить в телефон (поздравляю, мы только что придумали e-sim). Ну или сделать отдельным подключаемым устройством со стандартизированной шиной и форм-фактором (например - в виде маленькой пластиковой карточки)
Импортозамещения же
https://www.consultant.ru/document/cons_doc_LAW_183175/
Оно не крякает как утка. Массив - структура данных, со скоростью доступа к элементам в O(1). У PHPшных "массивов" это далеко не так.
> такого понятия как "ассоциативный массив"
А еще в природе существует понятие "морская свинка". К свинье относится примерно так же: тож млекопитающее, тож четыре лапы.
Строго говоря PHP относится к
Ибо PHPшные "массивы" на самом деле - упорядоченные map.