Комментарии 39

Я так понимаю, после шуточки "Кстати, по этой же причине стирание информации потребляет намного больше энергии, чем чтение и запись. Поэтому хотите сэкономить заряд, поменьше удаляйте файлы!" статью можно не читать?
(Мало кто не знает, что удаление файла – "лёгкая" операция, всё его содержимое не затирается).


Ну в смысле весь текст до и после примерно того же уровня достоверности?

Но флэш память как раз должна «затереть» все ячейки прежде чем в них будет записана новая информация, не важно, в момент удалении, в фоне или перед записью новой информации. См. команду Trim, например.
Речь шла о удалении файлов в файловой системе. Во всех их в таком случае в соответствующей записи просто выставляется бит «удалён». Перемещение файла в другой каталог в пределах одного диска — смена указателя на «родительский» элемент.
Так что при удалении файла в системе он не затрётся нулями/единицами полностью — об этом и был предыдущий комментарий.

PS: Если не верите — покурите исходники имеющихся ФС (Ext, FAT, NTFS).
Я и читал и писал исходники ФС. НО где в статье (да и в упомянутом комментарии) упоминание файловых систем? Как раз для этого я упомянул команду TRIM, которая после «проставки бита удаления» отправляет накопителю в каких секторах был этот файл чтобы он их почистил.
В своем первом комментарии я и описал общий случай — когда то их чистить всё равно придется.
В общем случае да. Курим discard в linux. Я специально проверял данные на уровне inode и физ. секторов: информация стирается секунд через двадцать после удаления, после deallocate (аналог (S)ATA Trim или SCSI UNMAP в NVMe).

Конечно, так ли это на физ. уровне, уверенным быть нельзя, так как драйвер Samsung в ядре под Linux не поддерживает (скорее -вал) физическое монтирование per NVMe версии 1.4.

в общем случае "физические сектора" (которые контроллер представляет ОС) и физические ячейки флеша — две большие разницы

В sata это не так, там реальные данные (разумеется, нужны спец SMART утилиты). В nvme да, но есть стандарт (не думаю, что доделан у Samsung), позволяющий «примонтировать» «реальный диск».
В sata это не так

Это так для практически любого флеш-накопителя с выделенным контроллером: хотя бы потому, что физический объем флеш-памяти как правило больше (или в случае китайских флешек на 100500GB — меньше), чем "объем накопителя".


разумеется, нужны спец SMART утилиты

ну мы здесь вроде как про штатную работу накопителя говорим, а не про диагностические/fronestic режимы

Как это относится к "поменьше удаляйте файлы"?
Какие ячейки физически стирать во флеше решает контроллер, по одному ему ведомым алгоритмам.
Даже "стирание с перезаписью нулями" на уровне ОС совершенно не означает стирания физических ячеек во флеш-памяти, где была расположена исходная информация.
Команда trim так же ничего не удаляет сама по себе, а просто сообщает контроллеру, что те физические ячейки, которые отображались на данные адреса, полезной нагрузки не несут и их можно использовать в одному контроллеру ведомых алгоритмах

Я не писал что это как то относится, а только написал, что это не менее дешевая операция чем перезапись. А алгоритмы в контроллере не важно какие — важно что в отличии от HDD ячейки флэша должны быть вначале почищены.

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

Мне кажется, что дело тут не только в типе памяти.

Андроид, как ни крути, построен на Java машине. И приложениях, которые при закрытии фактически остаются в памяти ддо тех пор, пока в системе ее не останется мало и не запустится сборщик мусора.

В iOS такого безобразия нет, отсюда и скорость работы выше.

Для сравнения — были такие телефоны Blackberry на своей Blackberry OS 10.x.x (последняя была 10.3.3), фактически это QNX 8.0.0. Там тоже нативные приложения работают безо всяких прослоек (есть подсистема андроид для установки и запуска андроид приложений).

Так вот. Даже на очень скромном по нынешним меркам железе (Snapdragon 826, 2 ядра по 1.7ГГц и 2Гб оперативки) работает очень шустро, плавно и абсолютно без лагов, присущих андроиду.

И что-то я сомневаюсь, что в модели 13-го года (Blackberry Z30, к примеру) или даже 15-го (Blackberry Leap) была NVM память…
Андроид, как ни крути, построен на Java машине.

Технически, там уже лет шесть AOT.

Но что это меняет по сути? Отменяет невыгрузку приложения из памяти при его «закрытии»? Отменяет периодический запуск сборщика мусора, который приводит к лагам? Отменяет постоянно работающую в памяти java-машину?

Да, это делает сам код чуть быстрее. Но не более того.
Из оперативной памяти. А не nvme. И нормальные приложения имеют только на Java одной оболочку. Библиотеки на Си и бинарники в linux ядре запускаются. Это и Chrome, и gnuradio, и Mx player (туда целый ffmpeg можно засунуть).
У меня вообще Ubuntu без вертуализации на Android запускается — и ничего.
И приложениях, которые при закрытии фактически остаются в памяти ддо тех пор, пока в системе ее не останется мало и не запустится сборщик мусора.

Это просто RAM app cache или типа того. Я сам так думал пока не написал апп под андроид, они закрываются если их закрывать а не сворачивать. Классика — https://www.linuxatemyram.com/

Ну не знаю, не знаю… Вроде как и закрываю, потом иду в «работающие приложения» и вот оно там болтается (именно работающие, а не «приложения в кеше»).

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

Так что все равно остается ощущение что источник тормозов андроида — джавамашина. Где ее нет (иос, симбиан, блекбери, там все работает существенно быстрее даже на более скромных ресурсах).
И когда оно все начинает лагать и тормозить приходится руками принудительно все ненужное закрывать.

гхм, у меня обратное впечатление: после запуска «жирного» приложения другие начинают открываться заметно медленнее (их «выбило» из памяти и они запускаются с нуля)


а вот такое (руками приложения закрывать) уже и не помню когда в последний раз делал.

Ios тоже это имеет. Вы смахивайте-то приложения. Я напомню, что Chrome потребляет огромное количество памяти, потому что он правильно отрисовывает всё, а не так как Сафари. А так как на iOS chrome это тоже Safari…
Во-первых, в UFS последовательный интерфейс. А это значит, что можно одновременно и записывать и считывать. eMMC мог делать только что-то одно. Поэтому UFS работает быстрее!
Чтобы одновременно записывать и считывать нужен не последовательный, а дуплексный интерфейс (в UFS он такой и есть — последовательный дуплексный, в eMMC — параллельный полудуплексный). Но быстрее он не только (и не столько) по этой причине — сам интерфейс гораздо быстрей пересовывает данные.
Redmi K 30 Pro
Poco F2 Pro

Так кто именно тестировался?


И скрины тестов CrystalDiskMark бредовые:


  • Разные версии.
  • 1 GB улетит в кэш SSD, надо хотя бы 32.
По скорости работы с памятью это одно и то же, просто один аппарат для китайского рынка, а второй для европейского.
Я не очень основной посыл (я бы даже сказал пафос) статьи.

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

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

Покупайте нормальные телефоны, а не бюджетные и не будет никаких фризов.


А если ещё на разницу между ценой айфончега съездить отдохнуть, то и раздражать многое перестанет, не только телефоны.

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

Цена не всегда определяет. Купил себе Nokia 9, жене Galaxy S10e, за одни и те же деньги.
В итоге Нокия безбожно тормозит, а самсунг летает.

Логично предположить (и наверное несложно проверить) что SSD в смартфонах проигрывают 'взрослым' в том числе потому что больше заточены на энергоэффективность

Похоже на то. У Apple например накопитель iPhone 6s подключался по PCIe x2, а последующие — уже по х1. Урезали также и количество ядер встроенного контроллера.
память — это RAM, ОЗУ
то, о чём вы пишите — Storage (где-то встречал перевод «Хранилище»)
NVMe и UFS — не типы памяти. NVMe — протокол; а UFS — целый набор спецификаций и на протокол, и на SCSI-подобную «шину».
Память — это про архитектуру (способ доступа), а не про реализацию.
Меня это же смутило: протокол и спецификации / протокол сравниваются по конкретной их реализации и внезапно выходит, что в любой реализации можно поставить быструю и медленную память.
Почему бы в сравнение не добавить pcie4 nvme ssd?
Результаты будут ещё более красивее ( 5 Гб/с чтение, 4.5Гб/с запись), но так же ничего значимого не покажут, кроме того факта, что производитель какую захочет память ( быструю и дорогую или подешевле и помедленнее), ту и поставит.
А вот тут никого не смутило,
image

что XS по всем показателям лучше чем более новый 11Pro? А по произвольному чтению/записи практически в 1,5 раза. И уже получается, что не
Apple… по произвольной они подчистую сливают Android-смартфонам

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

Информация

Дата основания
Местоположение
Россия
Сайт
droider.ru
Численность
2–10 человек
Дата регистрации

Блог на Хабре