Странно что Фигма по умолчанию не включает эту штуку.
Приходилось писать быстрый рендеринг многострочного текста вдоль кривой Безье, поседел от количества нюансов и того, насколько на самом деле у шрифтов много заморочек и нюансов. У них туча разных вспомогательных линий и размеров.
И выравнивание текста в простейшем случае должно опираться на размер строчной латинской буквы «x», а не на фактический размер букв. В крайнем случае — на размер кегля.
Даже без VR на больших разрешениях типа 11520×2160 или 23040×4320 нужно много VRAM, иначе в играх будет 1 fps. А ещё можно рендерить в 3D пакетах всякое 16K на GPU и тут тоже будет нужно много VRAM.
Но тут речь про LLM, а не графику. У меня OSS 120b выдает 11–16 токенов в секунду в зависимости от настроек, при этом карта забита под 0 и ничего другого в неё уже не влезет.
А описанный в статье способ, фактически, позволяет если не ускорить, то хотя бы одновременно загрузить дополнительно несколько моделей и переключаться между ними, не делая полной выгрузки и повторной загрузки. Например, комбинировать OSS120b с каким‑нибудь VLLM и SDXL.
И, если это делается по слоям, то наверно можно делать какие‑нибудь довольно хитрые конструкции из очень большого числа соединений, типа «одеяла» из десятков тысяч маленьких плат соединенных между собой десятками тысяч микрошлейфов. Вручную/роботами такое сделать почти нереально.
Но это мои фантазии, тут интересно было бы получить информацию о производстве «из первых рук» :)
Вы правы, я взял как пример пароль только из латинских букв одного регистра. Поправил текст. Однако год — это вполне ещё осязаемое время.
Тут есть тонкость: часто пароли из букв и цифр начинаются на буквы и заканчиваются цифрами, то есть цифры стоят только в конце. И перебор можно начинать именно с этих, наиболее вероятных вариантов. И если пароль имеет цифры только в конце, то тогда мы найдём его гораздо быстрее (предположительно, в среднем где‑то за 1 месяц).
Вообще тема глубокая. Можно найти где‑нибудь большие каталоги утекших паролей, статистически проанализировать и найти корреляции и паттерны, по которым пароли делают наиболее часто, и в первую очередь перебирать те варианты, которые соответствуют наиболее частым паттернам.
Там же вроде написано, что RTX 5090 считает ~27 гигахэшей в секунду. И тогда получается, что пароль длиной 10 латинских букв одного регистра на домашнем компе за полтора часа.
Если пароль из 10 заглавных и строчных букв + цифр (26 * 2 + 10) — то уже нужно около года (в среднем 6 месяцев).
Если добавляем спецсимволы — тогда у нас алфавит из, условно говоря, 128 символов, и тогда 1 такая карта будет работать до 1400 лет (а 1400 видеокарт 1 год:3 )
Если говорим про весь ASCII (то есть 256 символов), то до полутора миллионов лет, а 100 000 видеокарт — всего 10 лет
Остаётся выяснить, что дороже: аренда кластера из видеокарт на год или проведение разведывательной операции (которая может длиться от 10 секунд до 10 лет и больше).
Хорошо что никто пока не придумал какую‑нибудь движуху, неявно мотивирующую помогать взламывать пароли. Ну типа помогаешь перебирать хэши и тебе за это капает вознаграждение. Типа блокч...
Жаль, имхо такое сохранять надо. Я с DOS не работал, в детстве когда начинал кодить уже застал эпоху Win98 с окнами и GDI (но не GDI+).
В DOS это вообще же жесть наверное, там вручную надо было графический режим включать и писать оконный стек вообще с нуля, и только потом писать на нем софт. То есть Вы практически мини‑Windows 3.1 туда впихнули. Уважуха.
ИМХО можно просто взять оригинальную Википедию, взять каждую статью, и по каждому суждению устроить «прозвон источников», то есть не просто выяснить, откуда инфа, а проследить всю цепочку источников. И у каждого источника так же прозвонить цепочку финансирования — откуда у источника берутся ресурсы на существования. И не просто в статике, а с привязкой ко времени — когда где всплывала инфа, по какой закономерности. Как раз задача для ИИ.
Интересно, найдутся ли статьи, которые, на первый взгляд, ссылаются на множество источников, а при детальном анализе оказывается, что это какой‑то один центр.
Но почему‑то мне кажется, что публично так делать никто не будет :)
Интересно. Правильно ли я понимаю, что если я захочу запустить рой (например, 1000) таких дронов, то они должны воспринимать друг друга как препятствие, и сложность вычислений пути взлетит по экспоненте? И тут надо прикручивать что‑то типа растровой 3D сетки (ну или октодерева для навигации, но это перебор имхо)?
Такое много где встречается в более‑менее толстых редакторах.
Тут ещё важна фишка, что в одних случаях выражение считается разово, а в других задает постоянную зависимость одной величины от другой.
Задание высоты картинки пропорционально от ширины (Photoshop)
Слева формула считается на каждый кадр, справа - один раз (AfterEffects)
Величина считается разово (CorelDraw)
Формула пересчитывается каждый кадр (Tesseract)
В САПРах (тот же Inventor) обычно система выражений самая навороченная, так как там часто поддерживаются единицы измерения, а не только безразмерные величины.
Очень интересно, хотелось бы взглянуть. Есть ли возможность где‑то посмотреть/скачать? Или хотя бы ссылки какие‑нибудь.
В своё я тоже напихал много новаторства, даже снабдил его 3ds maxовым роликом. Но с точки зрения рациональности эта штука скорее надругательство над ТРИЗ, ибо нафарширована просто всем, что мне тогда пришло в голову :P
Некоторые фичи
Заголовок окна является полем ввода
Экранную клавиатуру можно отделить/скрыть
Числа в поле ввода можно скроллить
Раскладка ввода всегда правильная (sin(x) вместо ышт(ч))
Знак умножения можно не писать: 5log(3;2)
Автокомплит, подсветка и подчёркивание ошибок
Светлая тема с подсветкой, историей и автокомплитом
Вызов по горячей клавише
Системы счисления через префиксы
Одно время работали константы $ и €, равные текущему курсу доллара и евро в рублях. Поскольку знак умножения писать не нужно, можно было просто писать 4$ или $4, и это переводилось в рубли, а обратное преобразование делалось делением, например 5000/$. На деле эти «константы» являются процедурами VB, которые каждый раз скачивают текущий курс. $ вводился через $hift+4, а €через €trl+4
Настройка скинов, звуков и прочего. Есть нативный стиль Win95 через WinAPI
Анимации можно отключить, если бесят
Одно время там работала система обратной связи. В целом, оно либо очень нравилось, либо наоборот, очень не нравилось, то есть была явная поляризация. Так что новаторство да, это та ещё рулетка :)
Надстройка над VBScript. Добавлен оператор Return + статические события + #define через оператор === + некоторые плюшки. Вообще там всё крутится вокруг скриптового движка.
Первоначально время было экспериментом, но потом вошло в релиз
А вот системы счисления парсятся нативно, т.к. слишком уж сложно получилось
Вычисляет оно так:
С помощью одного скрипта выражение подготавливается (замена констант, подмена тригонометрических функций для того чтобы работало переключение градусы/радианы, оператор модуля «|» и прочее)
Генерируется код объявления пользовательских констант и функций
Эти константы и функции + обработанное выражение вставляются в определенное место в другом скрипте, и этот скрипт запускается, выдавая ответ через callback
Это работает и при построении функции, и при простых расчётах. Поэтому получается довольно гибко — можно просто добавлять константы/функции через стандартный интерфейс, а можно вообще влезть в мозг и добавить собственный синтаксис.
Давно уже обновляю что‑либо только если у меня возникает потребность в каком‑то изменении в ПО и я точно знаю, что в обновлении ПО это нужное мне изменение есть + высоковероятно, что ничего другое не сломалось. В остальных случаях лучше не обновлять (если, конечно, дело не касается ИБ).
Вот, например, у софта от клавиатуры уже давненько висит вот этот вот баннер.
Угадайте что произойдёт, если я буду прогрессивным и современным, и обновлю ПО на новую, совершенную версию?
Клавиатура полностью перестаёт работать (не расширенные функции, а вообще вся целиком), ПО висит в автозагрузке, завязывает на себя все нажатия клавиш и тупо зависает. Чтобы восстановить работоспособность, нужно подключить отдельно проводную клавиатуру, загрузиться через безопасный режим, стереть в 0 новое стабильное высокотехнологичное современное совершенное ПО, вручную почистить реестр, почистить настройки в разных папках, потом перезагрузиться, потом долго‑долго искать где скачать никому ненужную нестабильную устаревшую версию ПО, установить его и настроить заново. Только для того, чтобы когда ты нажимаешь клавиши, вводились буквы. Ну, чтобы вернуться к тому, что было.
ПО для звуковой карты и видеокарты это тоже касается, но в меньшей степени.
Я помню как сделал в 11 классе калькулятор, и мне кто‑то сказал, что жрать для калькулятора 30 мб ОЗУ это чудовищный оверхед :) При том, что в эти 30 мб помещалась туча функционала, встроенная IDE, анимация и графика, там даже цифры с анимацией вводились.
Нам нужно, чтобы то, что хранит информацию, и то, что её обрабатывает, было одним и тем же, а не разными устройствами («память и процессор»). Мемристоры — это одна из форм технологий, на которых можно такое сделать
Интересно получилось, и довольно контринтуитивно. Кажется, что кодирование H264 аппаратно ускоряется, и проще его снимать и сразу стримить на серв, попутно впихивая в пакеты данных инфу с GPS и всяких акселерометров. Никогда бы не подумал, что сохранение фоток в jpeg будет оптимальнее. Но практика — критерий истины, как говорится.
Делал в своё время очень тяжелое ПО под реалтайм обработку видео, но на десктопе (кстати там есть возможность писать видео в PNG/JPG сиквенс). Работа с устройствами захвата видео/аудио всегда сопровождалась даже не танцами с бубном, а целым карнавалом. Особенно если это устройства из разных миров (какой‑нибудь SDI Blackmagic, вебкамера и 1394, и все, естественно, снимают в разных форматах — вообще туши свет).
И мне как‑то раньше казалось, что в мобильных ОС учли весь этот опыт, и там должно всё быть как‑то цивилизованнее. В конце концов, там камера является неотъемлемой частью системы.
Но прочитав статью, я понял, что там те же грабли, только потехнологичнее :)
непонятно связан ли HDR с цветом, ведь HDR расшифровывается как расширенные динамический диапазон, а ДД - это количество света (обычно измеряется в степенях двойки, 2⁸ - 8 стоп (steps) , 2¹⁰ - 10 стоп)
Ну, имхо, с технической стороны дисплея всё лаконично — у нас нет просто «света», у нас, как минимум, R, G и B. И мы можем одни компоненты ставить в расширенный диапазон, другие в обычный. А можем все. И за счёт этого у нас возможны соотношения между R, G и B, которые раньше на практике не использовались из‑за технических ограничений, даже не смотря на то, что эти соотношения формально входили в цветовое пространство. А отличия между R, G и B (линейные/нелинейные) — это и есть цвет.
Недавно мелькала инфа про опыты, где стимулировали лазером сетчатку глаза и заставили её в зрительную кору послать цвет, который при обычном использовании глаза увидеть невозможно.
У пяти добровольцев возникло ощущение цвета, который они никогда не видели ранее: описывали его как «сине‑зелётый (blue‑green) с беспрецедентной насыщенностью».
Авторы назвали этот цвет “olo”, из обозначения (0,1,0) в LMS-координатах (L=0, M=1, S=0) — то есть идеализированная активация только M-конусов.
По‑хорошему просится AI тонмаппер. Чтобы я на вход пихать 32бит/канал линейный оригинал, на выходе он выдаваёт либо LUT, либо карту преобразований каждого пикселя. Ещё можно на вход кушать, помимо линейного rgba вывода, буфер id объектов, буфер теней/бликов и вот это всё, чтобы точнее было.
То есть не мыльница «картинка → картинка», а корректор, сохраняющий данные о цвете и возможность вмешаться обработку. Сейчас вроде появляются модели с поддержкой 16бит/канал, но их мало.
Вишенкой на торте была бы возможность файнтюнинга модели под конкретный стиль автора и/или контента.
Странно что Фигма по умолчанию не включает эту штуку.
Приходилось писать быстрый рендеринг многострочного текста вдоль кривой Безье, поседел от количества нюансов и того, насколько на самом деле у шрифтов много заморочек и нюансов. У них туча разных вспомогательных линий и размеров.
И выравнивание текста в простейшем случае должно опираться на размер строчной латинской буквы «x», а не на фактический размер букв. В крайнем случае — на размер кегля.
Даже без VR на больших разрешениях типа 11520×2160 или 23040×4320 нужно много VRAM, иначе в играх будет 1 fps. А ещё можно рендерить в 3D пакетах всякое 16K на GPU и тут тоже будет нужно много VRAM.
Но тут речь про LLM, а не графику. У меня OSS 120b выдает 11–16 токенов в секунду в зависимости от настроек, при этом карта забита под 0 и ничего другого в неё уже не влезет.
А описанный в статье способ, фактически, позволяет если не ускорить, то хотя бы одновременно загрузить дополнительно несколько моделей и переключаться между ними, не делая полной выгрузки и повторной загрузки. Например, комбинировать OSS120b с каким‑нибудь VLLM и SDXL.
Отсутствует разъём, который занимает место.
И, если это делается по слоям, то наверно можно делать какие‑нибудь довольно хитрые конструкции из очень большого числа соединений, типа «одеяла» из десятков тысяч маленьких плат соединенных между собой десятками тысяч микрошлейфов. Вручную/роботами такое сделать почти нереально.
Но это мои фантазии, тут интересно было бы получить информацию о производстве «из первых рук» :)
Мне кажется, что из
не следует что
Это может быть так, а может и нет. Скорее всего нет.
Вы правы, я взял как пример пароль только из латинских букв одного регистра. Поправил текст. Однако год — это вполне ещё осязаемое время.
Тут есть тонкость: часто пароли из букв и цифр начинаются на буквы и заканчиваются цифрами, то есть цифры стоят только в конце. И перебор можно начинать именно с этих, наиболее вероятных вариантов. И если пароль имеет цифры только в конце, то тогда мы найдём его гораздо быстрее (предположительно, в среднем где‑то за 1 месяц).
Вообще тема глубокая. Можно найти где‑нибудь большие каталоги утекших паролей, статистически проанализировать и найти корреляции и паттерны, по которым пароли делают наиболее часто, и в первую очередь перебирать те варианты, которые соответствуют наиболее частым паттернам.
Там же вроде написано, что RTX 5090 считает ~27 гигахэшей в секунду. И тогда получается, что пароль длиной 10 латинских букв одного регистра на домашнем компе за полтора часа.
Если пароль из 10 заглавных и строчных букв + цифр (26 * 2 + 10) — то уже нужно около года (в среднем 6 месяцев).
Если добавляем спецсимволы — тогда у нас алфавит из, условно говоря, 128 символов, и тогда 1 такая карта будет работать до 1400 лет (а 1400 видеокарт 1 год:3 )
Если говорим про весь ASCII (то есть 256 символов), то до полутора миллионов лет, а 100 000 видеокарт — всего 10 лет
Остаётся выяснить, что дороже: аренда кластера из видеокарт на год или проведение разведывательной операции (которая может длиться от 10 секунд до 10 лет и больше).
Хорошо что никто пока не придумал какую‑нибудь движуху, неявно мотивирующую помогать взламывать пароли. Ну типа помогаешь перебирать хэши и тебе за это капает вознаграждение. Типа блокч...
Ой :)
Жаль, имхо такое сохранять надо. Я с DOS не работал, в детстве когда начинал кодить уже застал эпоху Win98 с окнами и GDI (но не GDI+).
В DOS это вообще же жесть наверное, там вручную надо было графический режим включать и писать оконный стек вообще с нуля, и только потом писать на нем софт. То есть Вы практически мини‑Windows 3.1 туда впихнули. Уважуха.
ИМХО можно просто взять оригинальную Википедию, взять каждую статью, и по каждому суждению устроить «прозвон источников», то есть не просто выяснить, откуда инфа, а проследить всю цепочку источников. И у каждого источника так же прозвонить цепочку финансирования — откуда у источника берутся ресурсы на существования. И не просто в статике, а с привязкой ко времени — когда где всплывала инфа, по какой закономерности. Как раз задача для ИИ.
Интересно, найдутся ли статьи, которые, на первый взгляд, ссылаются на множество источников, а при детальном анализе оказывается, что это какой‑то один центр.
Но почему‑то мне кажется, что публично так делать никто не будет :)
Интересно. Правильно ли я понимаю, что если я захочу запустить рой (например, 1000) таких дронов, то они должны воспринимать друг друга как препятствие, и сложность вычислений пути взлетит по экспоненте? И тут надо прикручивать что‑то типа растровой 3D сетки (ну или октодерева для навигации, но это перебор имхо)?
Такое много где встречается в более‑менее толстых редакторах.
Тут ещё важна фишка, что в одних случаях выражение считается разово, а в других задает постоянную зависимость одной величины от другой.
В САПРах (тот же Inventor) обычно система выражений самая навороченная, так как там часто поддерживаются единицы измерения, а не только безразмерные величины.
Т.е. рендеринг гипертекста тоже кастом? Круто! Есть ли возможность где‑то скачать и потыкать?
Очень интересно, хотелось бы взглянуть. Есть ли возможность где‑то посмотреть/скачать? Или хотя бы ссылки какие‑нибудь.
В своё я тоже напихал много новаторства, даже снабдил его 3ds maxовым роликом. Но с точки зрения рациональности эта штука скорее надругательство над ТРИЗ, ибо нафарширована просто всем, что мне тогда пришло в голову :P
Некоторые фичи
Заголовок окна является полем ввода
Экранную клавиатуру можно отделить/скрыть
Числа в поле ввода можно скроллить
Раскладка ввода всегда правильная (sin(x) вместо ышт(ч))
Знак умножения можно не писать: 5log(3;2)
Автокомплит, подсветка и подчёркивание ошибок
Вызов по горячей клавише
Системы счисления через префиксы
Одно время работали константы $ и €, равные текущему курсу доллара и евро в рублях. Поскольку знак умножения писать не нужно, можно было просто писать 4$ или $4, и это переводилось в рубли, а обратное преобразование делалось делением, например 5000/$. На деле эти «константы» являются процедурами VB, которые каждый раз скачивают текущий курс. $ вводился через $hift+4, а € через €trl+4
Настройка скинов, звуков и прочего. Есть нативный стиль Win95 через WinAPI
Анимации можно отключить, если бесят
Одно время там работала система обратной связи. В целом, оно либо очень нравилось, либо наоборот, очень не нравилось, то есть была явная поляризация. Так что новаторство да, это та ещё рулетка :)
Так или иначе, оно постепенно расползлось по разным каталогам софта.
Надстройка над VBScript. Добавлен оператор Return + статические события + #define через оператор === + некоторые плюшки. Вообще там всё крутится вокруг скриптового движка.
Вычисляет оно так:
С помощью одного скрипта выражение подготавливается (замена констант, подмена тригонометрических функций для того чтобы работало переключение градусы/радианы, оператор модуля «|» и прочее)
Генерируется код объявления пользовательских констант и функций
Эти константы и функции + обработанное выражение вставляются в определенное место в другом скрипте, и этот скрипт запускается, выдавая ответ через callback
Это работает и при построении функции, и при простых расчётах. Поэтому получается довольно гибко — можно просто добавлять константы/функции через стандартный интерфейс, а можно вообще влезть в мозг и добавить собственный синтаксис.
Ну он инженерный, графики функций, программирование‑интегрирование, кастомизация, вот это всё
Немного скринов
Давно уже обновляю что‑либо только если у меня возникает потребность в каком‑то изменении в ПО и я точно знаю, что в обновлении ПО это нужное мне изменение есть + высоковероятно, что ничего другое не сломалось. В остальных случаях лучше не обновлять (если, конечно, дело не касается ИБ).
Вот, например, у софта от клавиатуры уже давненько висит вот этот вот баннер.
Угадайте что произойдёт, если я буду прогрессивным и современным, и обновлю ПО на новую, совершенную версию?
Клавиатура полностью перестаёт работать (не расширенные функции, а вообще вся целиком), ПО висит в автозагрузке, завязывает на себя все нажатия клавиш и тупо зависает. Чтобы восстановить работоспособность, нужно подключить отдельно проводную клавиатуру, загрузиться через безопасный режим, стереть в 0 новое стабильное высокотехнологичное современное совершенное ПО, вручную почистить реестр, почистить настройки в разных папках, потом перезагрузиться, потом долго‑долго искать где скачать никому ненужную нестабильную устаревшую версию ПО, установить его и настроить заново. Только для того, чтобы когда ты нажимаешь клавиши, вводились буквы. Ну, чтобы вернуться к тому, что было.
ПО для звуковой карты и видеокарты это тоже касается, но в меньшей степени.
Я помню как сделал в 11 классе калькулятор, и мне кто‑то сказал, что жрать для калькулятора 30 мб ОЗУ это чудовищный оверхед :) При том, что в эти 30 мб помещалась туча функционала, встроенная IDE, анимация и графика, там даже цифры с анимацией вводились.
Нам нужно, чтобы то, что хранит информацию, и то, что её обрабатывает, было одним и тем же, а не разными устройствами («память и процессор»). Мемристоры — это одна из форм технологий, на которых можно такое сделать
Интересно получилось, и довольно контринтуитивно. Кажется, что кодирование H264 аппаратно ускоряется, и проще его снимать и сразу стримить на серв, попутно впихивая в пакеты данных инфу с GPS и всяких акселерометров. Никогда бы не подумал, что сохранение фоток в jpeg будет оптимальнее. Но практика — критерий истины, как говорится.
Делал в своё время очень тяжелое ПО под реалтайм обработку видео, но на десктопе (кстати там есть возможность писать видео в PNG/JPG сиквенс). Работа с устройствами захвата видео/аудио всегда сопровождалась даже не танцами с бубном, а целым карнавалом. Особенно если это устройства из разных миров (какой‑нибудь SDI Blackmagic, вебкамера и 1394, и все, естественно, снимают в разных форматах — вообще туши свет).
И мне как‑то раньше казалось, что в мобильных ОС учли весь этот опыт, и там должно всё быть как‑то цивилизованнее. В конце концов, там камера является неотъемлемой частью системы.
Но прочитав статью, я понял, что там те же грабли, только потехнологичнее :)
Ну, имхо, с технической стороны дисплея всё лаконично — у нас нет просто «света», у нас, как минимум, R, G и B. И мы можем одни компоненты ставить в расширенный диапазон, другие в обычный. А можем все. И за счёт этого у нас возможны соотношения между R, G и B, которые раньше на практике не использовались из‑за технических ограничений, даже не смотря на то, что эти соотношения формально входили в цветовое пространство. А отличия между R, G и B (линейные/нелинейные) — это и есть цвет.
Недавно мелькала инфа про опыты, где стимулировали лазером сетчатку глаза и заставили её в зрительную кору послать цвет, который при обычном использовании глаза увидеть невозможно.
По‑хорошему просится AI тонмаппер. Чтобы я на вход пихать 32бит/канал линейный оригинал, на выходе он выдаваёт либо LUT, либо карту преобразований каждого пикселя. Ещё можно на вход кушать, помимо линейного rgba вывода, буфер id объектов, буфер теней/бликов и вот это всё, чтобы точнее было.
То есть не мыльница «картинка → картинка», а корректор, сохраняющий данные о цвете и возможность вмешаться обработку. Сейчас вроде появляются модели с поддержкой 16бит/канал, но их мало.
Вишенкой на торте была бы возможность файнтюнинга модели под конкретный стиль автора и/или контента.