S>Т.е. все что было в книгах про экономию памяти — стало вновь актуально и будет актуально в ближайшие лет 5 а то и 10
S>Статья в тему: https://habr.com/ru/posts/985774/
первый_раз?.jpg
как подорожала, так и подешевеет
Re[2]: Расчехляйте скиллы - снова придется считать байты
Здравствуйте, Shmj, Вы писали:
S>Т.е. все что было в книгах про экономию памяти — стало вновь актуально и будет актуально в ближайшие лет 5 а то и 10
А я таки предлагал обменять прекрасные кошерные 36GB, на однокомнатную квартриру 36кв.м,
смотрите, а то на следуюшей недели уже будет двухкомнатная...
ЗЫ: Это раньше ногами пиздили, чтоб вместо if (list == null || list.empty())
надо писать if (org.apache.commons.collections4.CollectionUtils.isEmpty(list))
Здравствуйте, Shmj, Вы писали:
S>Т.е. все что было в книгах про экономию памяти — стало вновь актуально и будет актуально в ближайшие лет 5 а то и 10
S>Статья в тему: https://habr.com/ru/posts/985774/
С разморозкой- мне собрали бюджетный ящик с 32г рамы и i7 в 2013г. 2013г КАРЛ!!!!!11111
Но лаптоп с 16г рамы и по сей день считают достаточным и имеют наглость продавать "примиальные" сурфейсы с макбуками за кучу денег с 16гб
Re[2]: Расчехляйте скиллы - снова придется считать байты
Здравствуйте, Артём, Вы писали:
Аё>С разморозкой- мне собрали бюджетный ящик с 32г рамы и i7 в 2013г. 2013г КАРЛ!!!!!11111 Аё>Но лаптоп с 16г рамы и по сей день считают достаточным и имеют наглость продавать "примиальные" сурфейсы с макбуками за кучу денег с 16гб
Если не устанавливать вирт. машин (в т.ч. Docker) — то для большинства задач рабочих — 16 Гб. терпимо, т.е. ты. просто не упрешься в потолок. Больше нужно когда у тебя много вирт. машин крутится, как то для тестов — и каждая жрет пирог памяти — там сразу заметно.
Другое дело что сейчас есть локальные нейросети и уже для их задач — совсем другие объемы нужны. Но похоже пока откладывается — все нейросетевые вычисления будут по подписке, т.е. на сервере. А ноуты и компы останутся для обычных задач.
=сначала спроси у GPT=
Re[3]: Расчехляйте скиллы - снова придется считать байты
Здравствуйте, Shmj, Вы писали:
S>Другое дело что сейчас есть локальные нейросети и уже для их задач — совсем другие объемы нужны. Но похоже пока откладывается — все нейросетевые вычисления будут по подписке, т.е. на сервере. А ноуты и компы останутся для обычных задач.
Ну почему, разные модели, разные задачи, можно и на слабом железе. Например, NER модели, а не генеративные. Вот например nvidia/gliner-PII.
GLiNER-PII создан по образцу моделей Gretel GLiNER PII/PHI. Основанный на базе GLiNER large-v2.1, он обнаруживает и классифицирует широкий спектр персональных данных (PII) и защищенной медицинской информации (PHI) в структурированном и неструктурированном тексте. Он не является генеративным и создает аннотации сущностей на уровне фрагментов с оценками достоверности по более чем 55 категориям.
Зачем нужен винегрет из регулярных выражений, NLP, эвристики, сторонних библиотек — прикручиваем это и всё! То что это будет медленнее в несколько тысяч раз (для простых случаев) мало кого волнует. Не думаю, что фарш удастся провернуть назад.
Re[3]: Расчехляйте скиллы - снова придется считать байты
Здравствуйте, Shmj, Вы писали:
S>Если не устанавливать вирт. машин (в т.ч. Docker) — то для большинства задач рабочих — 16 Гб. терпимо, т.е. ты. просто не упрешься в потолок.
Если заниматься сборкой C++ных проектов хотя бы от 50 .cpp-файлов в проекте, то приходится запускать компиляцию в параллель и 16Gb -- это самый самый минимум для такого занятия. И то, если в проекте более-менее плотно используются шаблоны, то придется ограничиться 3-4 параллельными потоками сборки, т.к. на один .cpp-файл запросто может уходить по 2-2.5-3Gb памяти. Это как раз то, что я сейчас наблюдаю под Linux с GCC 13.3 в проекте текущего заказчика.
Так что исходя из моего опыта, на нынешний момент для C++ разработчика нужна машина с минимум 24Gb, а лучше 32Gb.
Re[2]: Расчехляйте скиллы - снова придется считать байты
Здравствуйте, yoyozhik, Вы писали:
Y>ЗЫ: Это раньше ногами пиздили, чтоб вместо if (list == null || list.empty()) Y>надо писать if (org.apache.commons.collections4.CollectionUtils.isEmpty(list)) Y>А теперь наоборот? зачем нам лишние 30кб?
Вообще то это не оптимизация совсем. Сколько занимает исполняемый код по большому счету пофиг. Хоть гигабайт (на деле меньше). А вот сколько занимают структуры данных в памяти — это не пофиг совсем. И, например, если требуется держать в памяти 100 миллиардов флажков true или false — уже будет не пофиг, будет 1 бит на флажок или 64 бита (а то и больше), как массово идет сейчас. Сейчас часто ленятся максимально упаковывать структуры данных. И кстати ленятся, так как это положительно сказывается на быстродействии. Но когда памяти станет не хватать, некоторые лениться перестанут. А некоторые и сейчас не ленятся, если что, был у меня проект, когда я в памяти все считал — я там весьма жестко все упаковывал. Хоть и проект оригинальный загнулся, наработки его до сих пор используются.
Re: Расчехляйте скиллы - снова придется считать байты
Здравствуйте, Shmj, Вы писали:
S>Т.е. все что было в книгах про экономию памяти — стало вновь актуально и будет актуально в ближайшие лет 5 а то и 10
S>Статья в тему: https://habr.com/ru/posts/985774/
Здравствуйте, elmal, Вы писали: E> ... А вот сколько занимают структуры данных в памяти — это не пофиг совсем. И, например, если требуется держать в памяти 100 миллиардов флажков true или false — уже будет не пофиг, будет 1 бит на флажок или 64 бита (а то и больше), как массово идет сейчас. Сейчас часто ленятся максимально упаковывать структуры данных.
Если укладывать данные поразрядно, то появится разночтение одних и тех же данных на вычислительных устройствах с прямым и обратным порядком байт. Иногда, действительно, проще выделить под флажок целое слово, чем проверять порядок байт вычислительного устройства при каждом доступе к данным.
Здравствуйте, Pitirimov, Вы писали:
P>Если укладывать данные поразрядно, то появится разночтение одних и тех же данных на вычислительных устройствах с прямым и обратным порядком байт. Иногда, действительно, проще выделить под флажок целое слово, чем проверять порядок байт вычислительного устройства при каждом доступе к данным.
С чего бы это? За то, что все было совместимо, отвечает компилятор. А битовые маски работают одинаково на любом порядке байт, это нужно их реализовывать неправильно через хаки лютейшие, чтобы порядок байт был важен. Единственное — через битовые маски будет несколько медленнее.
Плюс если делать сериализацию бинарно в файл, а затем этот файл открывать на другой архитектуре — тут да, будут неимоверные грабли! Но это не имеет никакого отношения к укладке данных. И если такое требуется, то используется совсем другие сериализаторы, не такие быстрые, но которым на архитектуру процессора пофиг.
Re: Расчехляйте скиллы - снова придется считать байты
Хм, я слышал что память подорожала, но чтоб настолько... Я как раз десктоп собрал в октябре, сча посмотрел он стоит почти в 2 раза дороже, в основном за счет памяти.
Re[2]: Расчехляйте скиллы - снова придется считать байты
Здравствуйте, Serpuh, Вы писали:
S>Хм, я слышал что память подорожала, но чтоб настолько... Я как раз десктоп собрал в октябре, сча посмотрел он стоит почти в 2 раза дороже, в основном за счет памяти.
Пишут что в ближайший год дешевле вряд ли будет. А вот дороже — вполне может быть...
cf8bee54ad5419be531ae5a1f07d5ac3.jpg
cf8bee54ad5419be531ae5a1f07d5ac3.jpg (160.14 KiB) Viewed 3260 times
e34c80d5643c76de8694b1db8d6a13a7.jpg
e34c80d5643c76de8694b1db8d6a13a7.jpg (123.07 KiB) Viewed 3260 times
С обратной стороны платы нас ждёт чудо инженерной мысли... от которого становится грустно. Сердцем устройства является микроконтроллер с маркировкой 701N-F8, который также известен как JieLi AC701N. Это относительно популярный чип, использующийся в TWS-наушниках и представляющий из себя полноценную систему на кристалле:
В основе лежит двухъядерный (!) DSP-процессор собственной (!!) архитектуры Pi32v2 с FPU, способный работать на частоте до 160МГц (!!!) и имеющий 32КБ кэша инструкций и 16КБ кэша данных. Также у чипа есть MMU для продвинутой адресации памяти или реализации защищенного режима. Это уровень RP2350 или старших версий ESP 32
В качестве памяти здесь доступно целых 640КБ SRAM-ОЗУ, а также 1МБ Flash. Вот это уже действительно серьёзно.
Присутствует Bluetooth-радиотракт, обеспечивающий совместимость с стандартом версии 5.3. С софтовой точки зрения здесь тоже всё хорошо: поддерживаются все основные кодеки, плюс есть поддержка не-звуковых профилей по типу L2CAP и RFCOMM для коммуникации с другими устройствами.
Есть также контроллеры I2C, UART, SPI, USB, MMC, GPIO и даже ШИМ.
За звук отвечает двухканальный ЦАП для с встроенным предусилителем и возможностью воспроизведения PCM-потока с частотой дискретизации до 96кГц. Также есть четырехканальный АЦП для сэмплирования звука с микрофона и других подобных целей.
А за питание отвечает встроенный PMU, который состоит из контроллера заряда Li-Ion аккумуляторов, LDO и DC-DC Buck преобразователя,
Это невероятно круто по меркам копеечного микроконтроллера.
Но вот это меня шокировало больше всего: :o
...разъём Type‑C и провода, которые соединяют плату с микрофоном (используется для определения силы затяжки) :esurprised:
P.S. Раньше, когда я видел валяющуюся на полу и в грязи симку или банковскую карту, всегда думал: а вон два процессора валяются... :lol:
Теперь буду ещё за вейпами посматривать. :wink:
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
