Pull to refresh

Comments 9

Да чего мелочиться, можно парочку кристаллов Cerebras купить — 18 гигабайт локальной SRAM (скорость обмена — 9 ПБ/с).
Мне кажется эти 18гиг на 400тыщ ядер уйдут чисто на кэш и шедулер, на «обвязку» короче.
А еще можно погуглить про отображение файлов в память и не изобретать велосипедов.
А еще можно погуглить про отображение файлов в память и не изобретать велосипедов.


Если вы будете испопользовать данный метод без оглядки, рандомно обращаясь к смапированному в оперативной памяти, то данные в этом случае будут постоянно подкачиваться/писаться с/на SSD/HDD — это не умное решение, скорость работы вашей системы значительно снизится.

Если же вы будете делать сие аккуратно, кусочно, чтобы минимизировать обмен данными с SSD/HDD — фактически и вы будете использовать один из методов, описанный в статье.
Если покупка/аренда большого объёма RAM не решает проблему или невозможна

Раньше был такой сайт, YourDataFitsInRam.com. Домен уже давно протух, запаркован под рекламу, но утверждение по-прежнему верное — сервер с 4TB RAM стоит $26 в час на Амазоне, который далеко не самый дешёвый на рынке — рейт не самого дорогого специалиста в не очень богатой стране, который уйдёт на переписывание кода так, чтоб тот работал оптимальнее с точки зрения памяти. Вообще же, у них можно арендовать машины до 24TB RAM, но уже не почасово — при необходимости можно получить любые ресурсы, которые будут дешевле времени разработчика.


Если данных у вас больше или рабы дороже, найдётся кто-нибудь, кому не нужны советы для школьников, выучивших паскаль на уроках информатики, но не узнавших, что память конечна.


Вместо сохранения строк с 10 байтами или более на запись, вы можете сохранить их как логические значения True или False, которые кодируются просто одни байтом. Можете сжать информацию даже до одного бита, уменьшив расход памяти ещё в восемь раз.

  • Во-первых, интернирование строк, которое решает проблему дублирующихся данных в памяти.


  • Во-вторых, выравнивание данных в памяти, которое совсем не гарантирует, чтоб поле размером в байт будет меньше ссылки / указателя на строку.


  • В третьих, ужатие булева значения до одного бита потребует его упаковки каким-либо способом и добавит оверхед на чтение/запись. Как поколоночно, с использованием какого-нибудь BitArray / BitSet, так и просто общий enum для нескольких полей. Для последнего появляются ещё и требования к другим полям.



Техника № 2. Разбиение на блоки, загрузка данных по одному блоку за раз

No shit, Sherlock. "Не нужно загружать данные в память, если они не нужны в памяти".


Самый простой и распространённый способ индексирования — именование файлов в каталоге:

Это партиционирование, а не индекс.

сервер с 4TB RAM стоит $26 в час на Амазоне, который далеко не самый дешёвый на рынке — рейт не самого дорогого специалиста в не очень богатой стране, который уйдёт на переписывание кода так, чтоб тот работал оптимальнее с точки зрения памяти.


Если ваш проект работает хотя бы 5 лет, то это будет 26x24x365 = более миллиона долларов.

А затраты на зарплату будут ограниченными во времени. Например 3 месяца труда оптимизатора по аж 10 000 долларов = это всего-то 30 тыс. долларов.

Разумеется, нужно по конкретной ситуации смотреть что выгодно, а что нет.
Если ваш проект работает хотя бы 5 лет

  • Если ваш проект работает пять лет машинного времени.
  • Машина под оптимизированную версию, внезапно, тоже не бесплатная.

месяца труда оптимизатора по аж 10 000 долларов = это всего-то 30 тыс. долларов.

  • Это задержка в три месяца.
  • Это $30K, которые ещё не заработаны(и не факт, что будут). Неоптимизированная версия будет деньги есть постепенно, причём пропорционально выручке.
Если ваш проект работает пять лет машинного времени.

Какая разница кто работает? С точки зрения бизнеса — и программист и сервер — это всего лишь затраты.

Машина под оптимизированную версию, внезапно, тоже не бесплатная.


Оптимизация 20% от миллиона — это 200 000 экономии. При зарплате программиста 30 000 чистая экономия составляет 170 000.

Это задержка в три месяца.
Это $30K, которые ещё не заработаны(и не факт, что будут). Неоптимизированная версия будет деньги есть постепенно, причём пропорционально выручке.


Вы сейчас говорите о вреде преждевременной оптимизации с точки зрения бизнеса.
С технической точки зрения это тоже вредно.

Но, напомню, что речь идет о 5 годах.
Уж за 5-то лет можно где-то отыскать 3 месяца на работу.

Тем более, что зарплата смешная по сравению с серверами из примера — посему можно и второго и третьего дополнительных программистов нанять — всё равно будет выгодно.

Sign up to leave a comment.