Можно просто справа вверху иконку сделать и всё, при наведении появляется тултип «Объяснить код с SourceCraft».
Кнопка справа вверху
Если на первых порах надо привлечь внимание, то можно чтобы она периодически (то есть не всё время) ненавязчиво сияла, подпрыгивала или покачивалась. Ну или жонглировала черными штуками используя оранжевокрасные как руки, если заморачиваться. Главное не перегнуть палку, чтобы не раздражало.
Еще можно объяснение выстраивать учитывая профиль того, кто читает. Если у него там 735 статей про написание драйверов на С, то азы ему объяснять не надо, надо сразу к делу и с терминологией. А если видно, что он новичок и/или у него другая профессия — то надо разжевывать, и тому подобное.
5090 в 2,3 раза быстрее RTX 4090 и может выдавать 350+ FPS в играх, особенно с применением DLSS 4.
Инпутлаговое нарисованное MFG же. Играть можно, но не во всё. В BF6 и синглплеерах это можно вытерпеть, в CS с его сумасшедшими таймингами — нет.
На сегодняшний день это бескомпромиссное решение для профессионалов, стримеров и энтузиастов, которым нужен максимум в 4K.
Оно и 12К тянет вполне, даже в нативе (BF6 и Metro Exodus 12K выдавали где‑то 40–50 фпс), и GPT OSS 120b тянет 15 токенов/сек (а Qwen 3 Coder 30b вообще 192 т/с). В 3ds max можно почти в реалтайме рендерить Арнольдом прямо во вьюпорте. У меня даже получалось рендерить 16K (15360×8640) изображения на GPU, что раньше было за гранью. Ещё тут не 2, как у предыдущих карточек, а 3 аппаратных видеоэнкодера — можно поставить какой‑нибудь ffmpeg/Premiere кодировать видео и параллельно продолжать работать/играть.
Но: ИМХО, самая главная сила у неё не в ядрах и +100500 фпс, как заявляет маркетинг, а в большем количестве памяти, потому что малейшая её нехватка для любой задачи существенно просаживает производительность. Тот же Deathloop у меня жрет ~30 Гб VRAM, то есть впритык. Если с ним параллельно запустить хоть что‑то маленькое, FPS сажается раз в 10 и начинаются лютые лаги. Соответственно, на 4090 он уже бы просто не заработал.
PS. Вроде как карточке уже джейлбрейкнули интерконнект, чтобы если их несколько штук втыкаешь для ИИ, они могли между собой общаться напрямую (не полонценный Nvlink, просто ускорение взаимодействия через PCIE). Разумеется, гарантия после такого отправляется в помойку.
Будет написано на новом модном фраемворке, в котором иконка будет храниться в виде промпта который будет на каждой прорисовке отправляться в облако Azue вместе с вашими файлами, чтобы их ИИ отрисовал современную стильную дизайнерскую пиктограмму, каждый пиксель которой будет отправлен отдельным json пакетом.
Есть такое, она довольно поверхностно объясняет, и больше про то, какую задачу код решает, а не как именно он это делает и почему именно так. Фактически это выглядит как перевод с языка программирования на русский.
Однако мне понравилось, что он понимает контекст статьи, даже если она довольно большая (затестил на своей про подсветку на 500 вт), связывает смысл кода с решаемой задачей и понимает довольно хитрые приёмы.
Код с двойными указателями
public bool Render(IBooffer1D<RenderLedValueType> values)
{
if (E.IsInvalid(values) || E.IsInvalid(this))
return false;
using var sc = DisposeProtectedScope;
if (sc.IsFailed())
return false;
using var sc1 = values.DisposeProtectedScope;
if (sc1.IsFailed())
return false;
DisposeProtectedScopeToken preprocessedValuesDisposeToken = default;
if (Preprocess(values, out var preprocessedValues))
{
if (preprocessedValues != values)
if (!E.IsInvalid(preprocessedValues))
{
preprocessedValuesDisposeToken = preprocessedValues.DisposeProtectedScope;
values = preprocessedValues;
}
}
using (preprocessedValuesDisposeToken)
unsafe
{
if (values.TryGetPointers(out var source_begin, out var source_end))
{
var mapPack = addressMap.Value;
var location = (double2)pepector.Create(Installation.Bounds).xy;
var size = (double2)pepector.Create(Installation.Bounds).zw - location;
canvasLocker.EnterWriteLock();
try
{
for (int mapIndex = 0; mapIndex < mapPack.MapCount; mapIndex++)
{
if (mapPack.TryGetMapPointers(mapIndex, out var begin, out var count, out var end, out var end4))
{
var end8 = begin + count / 8 * 8;
var ptr = begin;
var source_ptr = source_begin;
while (ptr < end8)
{
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
}
while (ptr < end)
**ptr++ = *source_ptr++;
}
}
}
finally
{
canvasLocker?.ExitWriteLock();
}
}
{
if (addressMap.Value.TryGetAllMapPointers(out var allBegin, out var count, out var end, out var end4))
{
AfterRender(_canvas.Value, allBegin, count, end, end4);
}
}
}
return true;
}
Метод Render принимает на вход объект values типа IBooffer1D<RenderLedValueType> и выполняет рендеринг данных на светодиодную установку.
В начале метода происходит проверка входных данных на валидность с помощью метода E.IsInvalid. Если данные невалидны, метод возвращает false. Затем создаётся защищённая область (DisposeProtectedScope), которая предотвращает выгрузку объекта во время рендеринга.
Далее происходит предварительная обработка данных с помощью метода Preprocess, который может изменить входные данные. Затем выполняется основной цикл рендеринга, который копирует данные из буфера values в целевые адреса, используя указатели.
После завершения рендеринга вызывается метод AfterRender, который выполняет дополнительные операции после рендеринга. В конце метода возвращается true, что означает успешное выполнение рендеринга.
Этот код демонстрирует использование ручного управления памятью и оптимизаций для обеспечения высокой производительности рендеринга на светодиодную установку.
Но вот на этом фрагменте я понял, что коменты в коде оно не читает.
Вычисление прозрачности картинки на основе яркости с использованием SIMD
static readonly Vector512<ushort> _rgb_koefficients = Vector512.Create(
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0
);
static readonly Vector512<ushort> _channelRegrouping = Vector512.Create(
(ushort)0, (ushort)4, (ushort)8, (ushort)12, (ushort)16, (ushort)20, (ushort)24, (ushort)28, //Красные
(ushort)1, (ushort)5, (ushort)9, (ushort)13, (ushort)17, (ushort)21, (ushort)25, (ushort)29, //Зелёные
(ushort)2, (ushort)6, (ushort)10, (ushort)14, (ushort)18, (ushort)22, (ushort)26, (ushort)30, //Синие
(ushort)3, (ushort)7, (ushort)11, (ushort)15, (ushort)19, (ushort)23, (ushort)27, (ushort)31 //Пофиг
);
static readonly Vector256<byte> _byte_unrar_indices = Vector256.Create(
(byte)31, (byte)31, (byte)31, (byte)0,
(byte)31, (byte)31, (byte)31, (byte)1,
(byte)31, (byte)31, (byte)31, (byte)2,
(byte)31, (byte)31, (byte)31, (byte)3,
(byte)31, (byte)31, (byte)31, (byte)4,
(byte)31, (byte)31, (byte)31, (byte)5,
(byte)31, (byte)31, (byte)31, (byte)6,
(byte)31, (byte)31, (byte)31, (byte)7
);
static readonly Vector256<byte> _rgb_alpha_masks = Vector256.Create(
0, 0, 0, 0xFF,
0, 0, 0, 0xFF,
0, 0, 0, 0xFF,
0, 0, 0, 0xFF,
0, 0, 0, 0xFF,
0, 0, 0, 0xFF,
0, 0, 0, 0xFF,
0, 0, 0, 0xFF
);
private static byte* _avx512_byte_Avx512BW(byte* ptr, byte* end_vec)
{
//Прогружаем маски и прочую шелуху в регистры
var rgb_koefficients = _rgb_koefficients;
var channelRegrouping = _channelRegrouping;
var byte_unrar_indices = _byte_unrar_indices;
var rgb_alpha_masks = _rgb_alpha_masks;
while (ptr < end_vec)
{
var colorsBytes = Vector256.LoadAligned<byte>(ptr);
var colorsUShort = Avx512BW.ConvertToVector512UInt16(colorsBytes);
//Умножаем RGB коэффициенты
var colorsMultipled = colorsUShort * rgb_koefficients;
//Складываем для каждого пикселя его перемноженные RGB
Vector128<ushort> sums;
{
//Тасуем RGB RGB RGB RGB RGB RGB RGB RGB в RRRRRRRR GGGGGGGG BBBBBBBB AAAAAAAA
var regroupedChannels = Vector512.Shuffle(colorsMultipled, channelRegrouping);
//Теперь нам нужно 3 вектора красных, зелёных и синих компонент
var lower = regroupedChannels.GetLower(); //RRRRRRRR GGGGGGGG
var reds = lower.GetLower(); //RRRRRRRR
var greens = lower.GetUpper(); //GGGGGGGG
var blues = regroupedChannels.GetUpper().GetLower(); //BBBBBBBB
//Складываем попарно компоненты сразу 8 пикселей
sums = reds + greens + blues; //RRRRRRRR + GGGGGGGG + BBBBBBBB = SUM SUM SUM SUM SUM SUM SUM SUM
}
//Делим все 8 сумм на 128
var lumsAsUShorts = Vector128.ShiftRightLogical(sums, 7);
//Получаем яркости
//Преобразуем яркости из ушортов обратно в байты
var lumsAsBytes = Avx2.PackUnsignedSaturate(*(Vector256<short>*)&lumsAsUShorts, Vector256<short>.Zero);
//Раздвигаем яркости чтобы прицелиться
//ими на места альфа-каналов
var lumsShuffled = Vector256.Shuffle(lumsAsBytes, byte_unrar_indices);
////Совмещаем считанные в самом начале цвета 8 пикселей с
////посчитанными альфа-каналами
var blendedResult = Avx2.BlendVariable(colorsBytes, lumsShuffled, rgb_alpha_masks);
//Пишем результат
Vector256.StoreAligned(blendedResult, ptr);
////Следующие 8 пикселей
ptr += (256 / 8 / sizeof(byte));
}
return ptr;
}
Данный фрагмент кода написан на языке C# и использует SIMD-инструкции (Single Instruction, Multiple Data) для параллельной обработки данных. Он предназначен для работы с цветовыми компонентами изображений и включает в себя несколько статических векторных переменных и функцию _avx512_byte_Avx512BW, которая выполняет обработку байтовых данных.
В коде используются векторы для хранения коэффициентов RGB, индексов для перегруппировки каналов цвета, а также маски для работы с альфа-каналами. Функция _avx512_byte_Avx512BW загружает байтовые данные в вектор, преобразует их в 16-битные значения, выполняет умножение на коэффициенты RGB, перегруппировку каналов, суммирование компонентов и другие операции для получения яркости пикселей. Затем яркость преобразуется обратно в байты, и результат сохраняется в памяти.
Этот код интересен тем, что демонстрирует использование SIMD-оптимизаций для ускорения обработки изображений. Он позволяет эффективно работать с большими объёмами данных, выполняя операции параллельно на нескольких элементах одновременно.
То есть оно как-бы более-менее перечислило, что там происходит, но не последовательно, потеряло нить, можно сказать. Лучше было бы что‑то в духе «на входе X, на выходе Y, делаем сначала это, потом это, потом это».
В целом, имхо, для начала функция норм. Только я бы кнопку сделал маленькой‑квадратной и поместил бы в правый верхний угол области с кодом, чтобы она не занимала столько места.
Если я правильно понимаю, то проверки для всех трёх измерений идентичны, поэтому можно сделать как‑то так:
public ContainmentType Contains(BoundingSphere sphere)
{
float3 clampedCenter = float3.Clamp(sphere.Center, Min, Max);
float radius = sphere.Radius;
{
var distanceSquared = float3.DistancePow2(sphere.Center, clampedCenter);
if (distanceSquared > radius * radius)
return ContainmentType.Disjoint;
}
float3 thisSize = Max - Min;
for (int dimensionIndex = 0; dimensionIndex < 3; dimensionIndex++)
{
//if (dimensionIndex is 0 or 1)
if (thisSize[dimensionIndex] <= radius)
return ContainmentType.Intersects;
if (Min[dimensionIndex] > sphere.Center[dimensionIndex] - radius)
return ContainmentType.Intersects;
if (sphere.Center[dimensionIndex] > Max[dimensionIndex] - radius)
return ContainmentType.Intersects;
}
return ContainmentType.Contains;
}
Массивы в C# — это аллокации в куче. В подавляющем большинстве случаев на них пофиг, особенно если они короткоживущие. Но если среда выполнения обладает кривым сборщиком мусора и код выполняется слишком часто, это может вызывать подлагивания даже на 0 поколении.
В.NET 10, ЕМНИП, завезли аллокацию массивов на стеке, если компилятор видит, что это не разрушит логику, ИМХО, Ваш пример туда как раз попадает. Поэтому в.NET 10 проблем точно не должно быть.
Да) Я сам минут 10 искал, и таки нашёл. Сейчас решил эксперимент поставить на локальной Qwen3-vl-30b
Она почти сразу распрощалась с кукухой
Давайте внимательно посмотрим на изображение.
Все буквы выглядят как Q со странным шрифтом и хвостиком, но, как и сказано, одна из них — это буква O.
Разберёмся:
Буква Q обычно имеет хвостик, который выходит вправо-вниз.
Буква O — это просто круг, без хвостика.
Значит, нам нужно найти ту единственную букву, которая не имеет хвостика — то есть, это O.
Теперь посмотрим на изображение. Всё выглядит одинаково, но если внимательно рассмотреть, можно заметить, что все буквы — это Q, но в одной из них хвостик отсутствует.
Посмотрим на вторую строку снизу, второй столбец слева.
Нет, давайте пересчитаем.
Посмотрим на вторую строку снизу, второй столбец слева — там, кажется, хвостик отсутствует.
Но давайте уточним.
На самом деле, если внимательно посмотреть, то все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте проверим.
На самом деле, все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хво
Мне кажется смысл тут в том, чтобы код был написан так, чтобы глаза цеплялись за важное и не цеплялись за неважное. Чем больше расхождение, тем выше вероятность что‑то пропустить, поэтому нужно учитывать особенности зрения.
Глаза эволюционно сделаны для поиска всяких бананов в листве и мамонтов с саблезубыми кошками в траве. Картинка обрабатывается уже на уровне сетчатки, выделяются ключевые паттерны и передаются в зрительный нерв, вроде бы даже доказано, что там какое‑то подобие разложения Фурье происходит.
Если глаз видит кучу подобных объектов (типа травинок), то они передаются в мозг не по отдельности, а как «куча объектов которые в среднем похожи на травинку» или вообще как шум такого‑то цвета такой‑то интенсивности.
не в длине строки как таковой, а в том, что тут куча подобных объектов, слабо отличающихся друг от друга. И зрение «на аппаратном уровне» это не фильтрует. Это буквально аналог всяких загадок типа такой.
Найдите среди букв Q букву O без хвостика
Тут, ИМХО, можно не просто ловить какие‑то конкретные паттерны типа длинных строк или множества однотипных конструкций, которые уязвимы перед зрением, а генерировать для кода тепловую карту удобочитаемости (сеткой и/или алгоритмами).Карту можно выводить прямо в IDE (типа под плохим кодом постепенно проступают красные пятна) или просто искать на карте экстремумы и выводить их в лог.
ИМХО данный термин о тренде, а не о конкретной методике/системе методик.
Методики ещё 100 500 раз поменяются, потому что ещё ничего не устаканилось. Например, мы только‑только начинаем подходить к моменту, когда сети LLM начнут не просто генерить код, а еще его пробовать компилировать, запускать и отлаживать. И будет «вайбкодинг уже не тот»
Вы оспариваете релевантность мнения компилятора о коде?
Как посмел!!!
Я говорю о сложности и многогранности подходов при оценке и конструировании сложных систем, и об отсутствии универсального подхода. Слепо следовать догмам из умных книжек умных людей конечно всегда проще, но думать головой — эффективнее. А брать какие‑то два готовых подхода, да ещё и устраивать из них дихотомию, причём в отрыве от контекста, это... ну, скажем так, довольно бессмысленно.
PS. У компилятора нет мнения, потому что компилятор — автомат. Хороший автомат, сделанный умными людьми.
Важна ещё релевантность. Мой кот как то понюхал мой хеллоуворлд на QSharp на планшете и начал его закапывать. Но есть сомнения в его знаниях о квантовой механике.
Мк рано или поздно кто‑нибудь автоматизирует то, что Вы делали вручную.
Некая штука, которая комплексно смотрит разные признаки в тексте статьи/комента и у автора в профиле, и выдаёт «вероятность иишности». Можно в виде расширения для хрома, с опцией «скрыть всё с иишностью выше X%».
Методы выявления могут быть как алгоритмическо‑статистические, так и ИИшные (клин клином :3). Можно, например, нафайнтюнить какую‑нибудь небольшую LLM, чтобы ей на вход текст, а она тебе крошечный json с единственным числом от 0 до 100. Главное чтобы детекторов было много разных, и итоговая была суперпозицей их результатов.
Про поворот экрана - меня дико бесит то как он сделан на Android: ты поворачиваешь экран, а телефон реагирует на это ну через секунду примерно, это отвратительно. При этом датчики не тупят, не ошибаются, экран перерисовать недолго. Но пользователь оказывается в ненужном тильте всё время поворота. Эта секундная задержка всё никак не убирается сообществом... Короче, поворот это вещь полезная, но не для всех удобная. Хотя, в случае с Андроидом, поддержка поворота экрана синонимична "адаптиву" - правильной работе приложения на абсолютно любых экранах.
Тут есть ещё проблема с устройствами с изменяемой диагональю — будь то складные или раздвигаемые смартфоны. В большинстве случаев это работает не просто криво, а очень криво. По лагу на поворот соглашусь, но тут имхо дело в тупизне акселерометров.
Акселерометры обычно выдают ужасно зашумлённые данные, самый тупой способ бороться с этим для однозначного определения ориентации — усреднять последние N значений, что, ИМХО, в большинстве случаев и делается. Айфон сам по себе качественная железяка, датчики там скорее всего качественнее стоят с меньшим шумом + у айфонов отдельный аппаратный декодер для датчиков, который давит шумы, и делает это далеко не тупым усреднением. Скорее всего там даже не фильтр Калмана, а что‑то посерьёзнее, с небольшим ИИ может быть. Поэтому айфон лучше и быстрее понимает, в каком положении его держат.
Топовые андройдофоны скорее всего тоже обладают качественными датчиками, но вот ПО, вследствие своей универсальности, заточено работать и с плохими, и с хорошими данными, поэтому «на всякий случай» делают лаг по времени. Плюс декодирование и шумоподавление там в подавляющем большинстве случаев, если вообще не всегда, делается софтверно. А это уже компромиссы, потому что батарея.
Про анимации — ты говоришь что тебе не нравится что они вычисляются в реальном времени? Ну смотри: у нас есть оркестратор, который отвечает за отрисовку - каждый кадр который видишь на телефоне - был запланирован им. Если предыдущий ещё не нарисовался, то следующий не нужен. Таким образом, непоказываемые кадры не рассчитываются. Что вообще рассчитывается в кадре? Много всего, но если сильно упрощать то размеры и положения UI. Анимация зависит как раз от этих параметров. Поэтому вычислять её в реальном времени - логично и адаптивно. Немного математики, и линейное движение превращается в 3д перемещение с переменным приращением и эластичностью.
Я может неточно выразился — мне, наоборот, нравится, что они вычисляются в реальном времени. И под реальным временем я имел ввиду что ОС айфонов гибридная, и реакция на UI там обрабатывается (по крайней мере, обрабатывалась раньше) подходами, близкими к подходам работы ОС реального времени. То есть на уровне ядра ОС планировщик учитывает необходимость своевременного расчета кадров GUI.
А внутреннюю кухню анимаций я хорошо понимаю — довольно долго занимался разработкой тяжёлого десктопного ПО для обработки видео в реальном времени. Там и анимации были, и синхронизация c чересстрочной развёрткой, и много чего ещё. В частности, делал интерпретатор скриптов с нативной поддержкой этих самых нелинейных анимаций на уровне синтаксиса, с синхронизацией с кадровым потоком. Это не GUI, но, ИМХО, архитектура и подходы здесь почти идентичны.
рано или поздно всё заканчивается, и им придётся снова завоёвывать расположение аудитории
This. Хайп сложился из внимания к деталям и маркетинга. Сейчас этот хайп живёт по инерции, она не бесконечна, и однажды кончится. А «снова завоёвывать расположение аудитории» у них уже не получится. К тому времени мир будет совсем другим.
Можно просто справа вверху иконку сделать и всё, при наведении появляется тултип «Объяснить код с SourceCraft».
Если на первых порах надо привлечь внимание, то можно чтобы она периодически (то есть не всё время) ненавязчиво сияла, подпрыгивала или покачивалась. Ну или жонглировала черными штуками используя оранжевокрасные как руки, если заморачиваться. Главное не перегнуть палку, чтобы не раздражало.
Еще можно объяснение выстраивать учитывая профиль того, кто читает. Если у него там 735 статей про написание драйверов на С, то азы ему объяснять не надо, надо сразу к делу и с терминологией. А если видно, что он новичок и/или у него другая профессия — то надо разжевывать, и тому подобное.
Инпутлаговое нарисованное MFG же. Играть можно, но не во всё. В BF6 и синглплеерах это можно вытерпеть, в CS с его сумасшедшими таймингами — нет.
Оно и 12К тянет вполне, даже в нативе (BF6 и Metro Exodus 12K выдавали где‑то 40–50 фпс), и GPT OSS 120b тянет 15 токенов/сек (а Qwen 3 Coder 30b вообще 192 т/с). В 3ds max можно почти в реалтайме рендерить Арнольдом прямо во вьюпорте. У меня даже получалось рендерить 16K (15360×8640) изображения на GPU, что раньше было за гранью. Ещё тут не 2, как у предыдущих карточек, а 3 аппаратных видеоэнкодера — можно поставить какой‑нибудь ffmpeg/Premiere кодировать видео и параллельно продолжать работать/играть.
Но: ИМХО, самая главная сила у неё не в ядрах и +100500 фпс, как заявляет маркетинг, а в большем количестве памяти, потому что малейшая её нехватка для любой задачи существенно просаживает производительность. Тот же Deathloop у меня жрет ~30 Гб VRAM, то есть впритык. Если с ним параллельно запустить хоть что‑то маленькое, FPS сажается раз в 10 и начинаются лютые лаги. Соответственно, на 4090 он уже бы просто не заработал.
PS. Вроде как карточке уже джейлбрейкнули интерконнект, чтобы если их несколько штук втыкаешь для ИИ, они могли между собой общаться напрямую (не полонценный Nvlink, просто ускорение взаимодействия через PCIE). Разумеется, гарантия после такого отправляется в помойку.
Будет написано на новом модном фраемворке, в котором иконка будет храниться в виде промпта который будет на каждой прорисовке отправляться в облако Azue вместе с вашими файлами, чтобы их ИИ отрисовал современную стильную дизайнерскую пиктограмму, каждый пиксель которой будет отправлен отдельным json пакетом.
Ну всё, теперь оно будет жрать 6 Гб ОЗУ и 3 Гб видеопамяти, и загружаться 10 секунд.
Будьте так добры, пожалуйста, не трогайте. Просто пусть как было будет.
Есть такое, она довольно поверхностно объясняет, и больше про то, какую задачу код решает, а не как именно он это делает и почему именно так. Фактически это выглядит как перевод с языка программирования на русский.
Однако мне понравилось, что он понимает контекст статьи, даже если она довольно большая (затестил на своей про подсветку на 500 вт), связывает смысл кода с решаемой задачей и понимает довольно хитрые приёмы.
Код с двойными указателями
Но вот на этом фрагменте я понял, что коменты в коде оно не читает.
Вычисление прозрачности картинки на основе яркости с использованием SIMD
То есть оно как-бы более-менее перечислило, что там происходит, но не последовательно, потеряло нить, можно сказать. Лучше было бы что‑то в духе «на входе X, на выходе Y, делаем сначала это, потом это, потом это».
В целом, имхо, для начала функция норм. Только я бы кнопку сделал маленькой‑квадратной и поместил бы в правый верхний угол области с кодом, чтобы она не занимала столько места.
Если я правильно понимаю, то проверки для всех трёх измерений идентичны, поэтому можно сделать как‑то так:
Массивы в C# — это аллокации в куче. В подавляющем большинстве случаев на них пофиг, особенно если они короткоживущие. Но если среда выполнения обладает кривым сборщиком мусора и код выполняется слишком часто, это может вызывать подлагивания даже на 0 поколении.
В.NET 10, ЕМНИП, завезли аллокацию массивов на стеке, если компилятор видит, что это не разрушит логику, ИМХО, Ваш пример туда как раз попадает. Поэтому в.NET 10 проблем точно не должно быть.
..или просто большой.
Скрытый текст
Да) Я сам минут 10 искал, и таки нашёл. Сейчас решил эксперимент поставить на локальной Qwen3-vl-30b
Она почти сразу распрощалась с кукухой
Мне кажется смысл тут в том, чтобы код был написан так, чтобы глаза цеплялись за важное и не цеплялись за неважное. Чем больше расхождение, тем выше вероятность что‑то пропустить, поэтому нужно учитывать особенности зрения.
Глаза эволюционно сделаны для поиска всяких бананов в листве и мамонтов с саблезубыми кошками в траве. Картинка обрабатывается уже на уровне сетчатки, выделяются ключевые паттерны и передаются в зрительный нерв, вроде бы даже доказано, что там какое‑то подобие разложения Фурье происходит.
Если глаз видит кучу подобных объектов (типа травинок), то они передаются в мозг не по отдельности, а как «куча объектов которые в среднем похожи на травинку» или вообще как шум такого‑то цвета такой‑то интенсивности.
ИМХО проблема кода типа
не в длине строки как таковой, а в том, что тут куча подобных объектов, слабо отличающихся друг от друга. И зрение «на аппаратном уровне» это не фильтрует. Это буквально аналог всяких загадок типа такой.
Тут, ИМХО, можно не просто ловить какие‑то конкретные паттерны типа длинных строк или множества однотипных конструкций, которые уязвимы перед зрением, а генерировать для кода тепловую карту удобочитаемости (сеткой и/или алгоритмами). Карту можно выводить прямо в IDE (типа под плохим кодом постепенно проступают красные пятна) или просто искать на карте экстремумы и выводить их в лог.
Добросовестная конкуренция. Иначе это источник не прогресса, а кое‑чего другого.
Ок
Реальный, игрался с дым‑машиной :)
ИМХО данный термин о тренде, а не о конкретной методике/системе методик.
Методики ещё 100 500 раз поменяются, потому что ещё ничего не устаканилось. Например, мы только‑только начинаем подходить к моменту, когда сети LLM начнут не просто генерить код, а еще его пробовать компилировать, запускать и отлаживать. И будет «вайбкодинг уже не тот»
Фотографируйте в RAW/DNG.
Артхауса же. А вообще штука годная, даже не для артхаусного кода. Наконец‑то можно будет сократить пепекторы до вменяемого размера
Как посмел!!!
Я говорю о сложности и многогранности подходов при оценке и конструировании сложных систем, и об отсутствии универсального подхода. Слепо следовать догмам из умных книжек умных людей конечно всегда проще, но думать головой — эффективнее. А брать какие‑то два готовых подхода, да ещё и устраивать из них дихотомию, причём в отрыве от контекста, это... ну, скажем так, довольно бессмысленно.
PS. У компилятора нет мнения, потому что компилятор — автомат. Хороший автомат, сделанный умными людьми.
Важна ещё релевантность. Мой кот как то понюхал мой хеллоуворлд на QSharp на планшете и начал его закапывать. Но есть сомнения в его знаниях о квантовой механике.
Мк рано или поздно кто‑нибудь автоматизирует то, что Вы делали вручную.
Некая штука, которая комплексно смотрит разные признаки в тексте статьи/комента и у автора в профиле, и выдаёт «вероятность иишности». Можно в виде расширения для хрома, с опцией «скрыть всё с иишностью выше X%».
Методы выявления могут быть как алгоритмическо‑статистические, так и ИИшные (клин клином :3). Можно, например, нафайнтюнить какую‑нибудь небольшую LLM, чтобы ей на вход текст, а она тебе крошечный json с единственным числом от 0 до 100. Главное чтобы детекторов было много разных, и итоговая была суперпозицей их результатов.
Тут есть ещё проблема с устройствами с изменяемой диагональю — будь то складные или раздвигаемые смартфоны. В большинстве случаев это работает не просто криво, а очень криво. По лагу на поворот соглашусь, но тут имхо дело в тупизне акселерометров.
Акселерометры обычно выдают ужасно зашумлённые данные, самый тупой способ бороться с этим для однозначного определения ориентации — усреднять последние N значений, что, ИМХО, в большинстве случаев и делается. Айфон сам по себе качественная железяка, датчики там скорее всего качественнее стоят с меньшим шумом + у айфонов отдельный аппаратный декодер для датчиков, который давит шумы, и делает это далеко не тупым усреднением. Скорее всего там даже не фильтр Калмана, а что‑то посерьёзнее, с небольшим ИИ может быть. Поэтому айфон лучше и быстрее понимает, в каком положении его держат.
Топовые андройдофоны скорее всего тоже обладают качественными датчиками, но вот ПО, вследствие своей универсальности, заточено работать и с плохими, и с хорошими данными, поэтому «на всякий случай» делают лаг по времени. Плюс декодирование и шумоподавление там в подавляющем большинстве случаев, если вообще не всегда, делается софтверно. А это уже компромиссы, потому что батарея.
Я может неточно выразился — мне, наоборот, нравится, что они вычисляются в реальном времени. И под реальным временем я имел ввиду что ОС айфонов гибридная, и реакция на UI там обрабатывается (по крайней мере, обрабатывалась раньше) подходами, близкими к подходам работы ОС реального времени. То есть на уровне ядра ОС планировщик учитывает необходимость своевременного расчета кадров GUI.
А внутреннюю кухню анимаций я хорошо понимаю — довольно долго занимался разработкой тяжёлого десктопного ПО для обработки видео в реальном времени. Там и анимации были, и синхронизация c чересстрочной развёрткой, и много чего ещё. В частности, делал интерпретатор скриптов с нативной поддержкой этих самых нелинейных анимаций на уровне синтаксиса, с синхронизацией с кадровым потоком. Это не GUI, но, ИМХО, архитектура и подходы здесь почти идентичны.
This. Хайп сложился из внимания к деталям и маркетинга. Сейчас этот хайп живёт по инерции, она не бесконечна, и однажды кончится. А «снова завоёвывать расположение аудитории» у них уже не получится. К тому времени мир будет совсем другим.