Пин-код назван именно пин-кодом, а не паролем чтобы не создавать путаницу, когда каждое из полей ввода имеет в своём имени слово Пароль. И в него как раз лучше всего вводить какой-то небольшой пароль, который легко удержать в памяти. А пароль из эмодзи не подразумевает только слова, там можно рисовать рисунок, который нельзя перебрать по словарю. Пин-код не обязательный для ввода, но поможет исключить коллизии с другими пользователями если будет одинаковый рисунок.
Простой рисунок с однократным нажатием.
Рисунок основаны на цветовых градациях, но важен не только цвет, но и порядок нажатия для достижения цвета.
Основанная идея блока с эмодзи в том, что можно запомнить рисунок из эмодзи, а не сами эмодзи. Если их менять местами, то придется запоминать сами эмодзи или буквы на них. А скрытие эмодзи сделает невозможным или очень затруднительным ввод сложно рисунка.
Процесс генерации пароля в Visual Password многоступенчатый и довольно сильно избыточный, основанный на множественном перемешивании байт, добавлении к ним огромного количества соли, множественного вычисления SHA-256 хешей и шифрования AES-GCM. Т.е. генерация не мгновенная. Если взломщик не держит в своём распоряжении квантовый суперкомпьютер, то шансы подобрать пароль у него примерно никакие.
Расчёты выше не учитывают, что длину пароля взломщик тоже не знает, а это тоже огромный такой фактор. И количество символов в кейворде и пин-коде не ограниченно четырьмя и латинским алфавитом.
И никто не мешает вам генерировать пароль длиной 100 символов, но брать из него только 98, делая отступ по одному символу в начале и в конце. А ещё можно добавлять свой символ в определённую позицию пароля. И такие махинации сделают абсолютно бесполезным перебор всех комбинаций, но по-прежнему сохранят главную фичу Visual Password – возможность использовать очень сложный пароль, не записывая его.
Моя утилита создавалась совсем для других целей. И совсем не предназначена для вашего сценария. В комментарии выше описал наиболее подходящий кейс использования.
При использовании классического менеджера паролей, например Bitwarden, слабое место — это мастер-пароль, который может быть невероятно сложным, но его нужно где-то хранить вне менеджера паролей. А ещё есть пин-код для повседневной авторизации, который обычно нигде не записан, но сам по себе очень простой. Визуальный пароль помогает решить эту проблему.
Но Paint.NET давно уже не является программой с открытым исходным кодом. И ваша ссылка статье ведёт на репозиторий, где выкладывают лишь новые релизы, но не код.
Самое важное про burst не сказано. При работе с этим компилятором нужно забыть про Vetor2/3/4, Mtrix4x4. И вместо них использовать float2/3/4 float4x4/4x3/etc. А также всю математику из Math, Mathf заменить на math из пакета Mathematics. Все оптимизации burst завязаны именно на этих структурах и пакете математики, без них будет просадка по производительности т.к. большинство simd оптимизаций не сработают.
Большей части населения РФ требуется не только игра, но и её перевод на русский язык. После ввода ограничений количество игр на русском языке будет стремиться к нулю.
Вспомнил, что в c# есть Span<T>.Fill. Для C использовал компилятор clang-19.1.0 с аргументом "-O3". Результат, абсолютно одинаковая скорость. Так что выводы в статье абсолютно неверные, как и код для тестирования.
Похоже что так и есть. Chatgpt говорит, что: memset относится к языку C как часть стандартной библиотеки, но её оптимизация зависит от компилятора и библиотеки, связанной с ОС.
Без SIMD такой буст как в тестах в статье просто невозможен.
Ваш код проверил, цифры те же +- что и у обычного массива.
Насчёт этого не понял. Этот код с Vector256 ну просто не может быть по скорости таким же как как ваш из статьи.
upd: не заметил, что вы написали в комментарии скомпилированный код C, а не c#. На C я не работал. Поэтому подумал, что там есть SIMD инструкции после компиляции и не проверил свою гипотезу.
Не стал упоминать Vector512 иначе бы пришлось этот маленький пример превратить в простыню из:
if (Vector512.IsHardwareAccelerated) {}
else if (Vector256.IsHardwareAccelerated) {}
else if (Vector128.IsHardwareAccelerated) {}
else if (Vector64.IsHardwareAccelerated) {}
else {}
Но это всё не имеет значения в контексте этого теста. Да и моё железо не поддерживает Vector512.
Компилятор C активно использует SIMD инструкции. А в вашем коде c# таких инструкций нет. Перепишите код с использованием Vector128/Vector256 и повторите тест. А то как-то нечестно получилось.
unsafe
{
const int typicalItarationsCount = 10;
const int arraySize = 1073741824;
var lineLength = sizeof(Vector256<byte>);
var linesCount = arraySize / lineLength;
var tmpArray = new byte[arraySize];
for (var iteration = 0; iteration < typicalItarationsCount; ++iteration)
{
var watch = new Stopwatch();
watch.Start();
fixed (byte* tmpArrayPtr = tmpArray)
for (long i = 0; i < linesCount; ++i)
{
var vector = Vector256.Create((byte) 1);
vector.Store(tmpArrayPtr + i * lineLength);
}
watch.Stop();
tmpArray = new byte[arraySize];
Console.WriteLine($"iter={iteration} seq time={watch.ElapsedMilliseconds}");
}
}
Примерно так это выглядит на моём пк. Цифры не идеальны т.к. в фоне работает много процессов. Я не ставил целью сделать идеальный тест. Лишь хотел показать тенденцию.
Мой код с Vector256
Код из статьи
Если сравнивать C и c#, то только так. У меня нет настроенного рабочего окружения под C чтобы проверить разницу с шарпом. Оставляю это для вас.
На размер билда это никак не влияет. Абсолютно любой формат изображения попадёт в билд как текстура определённого формата, выбранного в зависимости от платформы. Т.е. любой png/psd/jpg будет конвертирован в какой-нибудь BC7. И финальный размер текстуры будет зависеть от настроек импорта, а не от формата исходного изображения.
Самым известным является то, что движок Unity использует только один поток обработки информации при работе с процессором.
Если unity работает только в одном потоке, то как я сделал этот скриншот профайлера, где видно, что загружены все ядра процессора?
Автор статьи вообще знает о юнити хоть что-то кроме домыслов сделанных на основе даже не знаю чего? Вопрос риторический.
За последние годы в unity проделана огромная работа, делающая движок многопоточным. Есть шикарный инструментарий для программистов Job system. Есть компилятор burst который выдаёт производительность в 10-20 раз большую чем il2cpp и сравним по скорости с нативным плюсовым кодом. Нативные библиотеки такие как физика, система частиц, звук используют дополнительные потоки для своих вычислений. В 23 версии появился Awaitable. А использовать родные Thread никто никогда не запрещал. В каждой новой версии юнити появляется всё большее количество апи которые позволяют работать с движком вне основного потока. Но автор с абсолютной уверенностью пишет, что unity это однопоточный движок, который не умеет в мультипоточность. И эта статья заплюсована.
Пин-код назван именно пин-кодом, а не паролем чтобы не создавать путаницу, когда каждое из полей ввода имеет в своём имени слово Пароль. И в него как раз лучше всего вводить какой-то небольшой пароль, который легко удержать в памяти. А пароль из эмодзи не подразумевает только слова, там можно рисовать рисунок, который нельзя перебрать по словарю. Пин-код не обязательный для ввода, но поможет исключить коллизии с другими пользователями если будет одинаковый рисунок.
Основанная идея блока с эмодзи в том, что можно запомнить рисунок из эмодзи, а не сами эмодзи. Если их менять местами, то придется запоминать сами эмодзи или буквы на них. А скрытие эмодзи сделает невозможным или очень затруднительным ввод сложно рисунка.
Если использовать по 4 символа в кейворде, пин-коде и визуальном пароле. И ограничить себя латинским алфавитом и цифрами.
Всего позиций для символов: 3 фактора × 4 символа = 12 позиций
На каждой позиции может быть любое из 36 значений
Общее количество комбинаций: 36 × 36 × 36 × ... (12 раз) = 36^12 = 4 738 381 338 321 616 896
Процесс генерации пароля в Visual Password многоступенчатый и довольно сильно избыточный, основанный на множественном перемешивании байт, добавлении к ним огромного количества соли, множественного вычисления SHA-256 хешей и шифрования AES-GCM. Т.е. генерация не мгновенная. Если взломщик не держит в своём распоряжении квантовый суперкомпьютер, то шансы подобрать пароль у него примерно никакие.
Расчёты выше не учитывают, что длину пароля взломщик тоже не знает, а это тоже огромный такой фактор. И количество символов в кейворде и пин-коде не ограниченно четырьмя и латинским алфавитом.
И никто не мешает вам генерировать пароль длиной 100 символов, но брать из него только 98, делая отступ по одному символу в начале и в конце. А ещё можно добавлять свой символ в определённую позицию пароля. И такие махинации сделают абсолютно бесполезным перебор всех комбинаций, но по-прежнему сохранят главную фичу Visual Password – возможность использовать очень сложный пароль, не записывая его.
Моя утилита создавалась совсем для других целей. И совсем не предназначена для вашего сценария. В комментарии выше описал наиболее подходящий кейс использования.
При использовании классического менеджера паролей, например Bitwarden, слабое место — это мастер-пароль, который может быть невероятно сложным, но его нужно где-то хранить вне менеджера паролей. А ещё есть пин-код для повседневной авторизации, который обычно нигде не записан, но сам по себе очень простой. Визуальный пароль помогает решить эту проблему.
Но Paint.NET давно уже не является программой с открытым исходным кодом. И ваша ссылка статье ведёт на репозиторий, где выкладывают лишь новые релизы, но не код.
Самое важное про burst не сказано. При работе с этим компилятором нужно забыть про Vetor2/3/4, Mtrix4x4. И вместо них использовать float2/3/4 float4x4/4x3/etc. А также всю математику из Math, Mathf заменить на math из пакета Mathematics. Все оптимизации burst завязаны именно на этих структурах и пакете математики, без них будет просадка по производительности т.к. большинство simd оптимизаций не сработают.
Попробуйте добавить атрибут [SkipLocalsInit], чтобы избежать постоянной инициализации нулями span'ов. Должно стать быстрее.
Большей части населения РФ требуется не только игра, но и её перевод на русский язык. После ввода ограничений количество игр на русском языке будет стремиться к нулю.
Вспомнил, что в c# есть Span<T>.Fill. Для C использовал компилятор clang-19.1.0 с аргументом "-O3". Результат, абсолютно одинаковая скорость. Так что выводы в статье абсолютно неверные, как и код для тестирования.
Похоже что так и есть. Chatgpt говорит, что:
memsetотносится к языку C как часть стандартной библиотеки, но её оптимизация зависит от компилятора и библиотеки, связанной с ОС.Без SIMD такой буст как в тестах в статье просто невозможен.
Отметил на скрине avx инструкции.
Можно здесь посмотреть. https://sharplab.io/
Насчёт этого не понял. Этот код с Vector256 ну просто не может быть по скорости таким же как как ваш из статьи.
upd: не заметил, что вы написали в комментарии скомпилированный код C, а не c#. На C я не работал. Поэтому подумал, что там есть SIMD инструкции после компиляции и не проверил свою гипотезу.
Не стал упоминать Vector512 иначе бы пришлось этот маленький пример превратить в простыню из:
Но это всё не имеет значения в контексте этого теста. Да и моё железо не поддерживает Vector512.
Компилятор C активно использует SIMD инструкции. А в вашем коде c# таких инструкций нет. Перепишите код с использованием Vector128/Vector256 и повторите тест. А то как-то нечестно получилось.
Примерно так это выглядит на моём пк. Цифры не идеальны т.к. в фоне работает много процессов. Я не ставил целью сделать идеальный тест. Лишь хотел показать тенденцию.
Если сравнивать C и c#, то только так. У меня нет настроенного рабочего окружения под C чтобы проверить разницу с шарпом. Оставляю это для вас.
В превью статьи ещё осталось "капнуть".
На размер билда это никак не влияет. Абсолютно любой формат изображения попадёт в билд как текстура определённого формата, выбранного в зависимости от платформы. Т.е. любой png/psd/jpg будет конвертирован в какой-нибудь BC7. И финальный размер текстуры будет зависеть от настроек импорта, а не от формата исходного изображения.
Ещё PotPlayer отличная штука.
Зачем размещать статью в хабе Unity, если внутри статьи нет ни слова о Unity?
Если unity работает только в одном потоке, то как я сделал этот скриншот профайлера, где видно, что загружены все ядра процессора?
Автор статьи вообще знает о юнити хоть что-то кроме домыслов сделанных на основе даже не знаю чего? Вопрос риторический.
За последние годы в unity проделана огромная работа, делающая движок многопоточным. Есть шикарный инструментарий для программистов Job system. Есть компилятор burst который выдаёт производительность в 10-20 раз большую чем il2cpp и сравним по скорости с нативным плюсовым кодом. Нативные библиотеки такие как физика, система частиц, звук используют дополнительные потоки для своих вычислений. В 23 версии появился Awaitable. А использовать родные Thread никто никогда не запрещал. В каждой новой версии юнити появляется всё большее количество апи которые позволяют работать с движком вне основного потока. Но автор с абсолютной уверенностью пишет, что unity это однопоточный движок, который не умеет в мультипоточность. И эта статья заплюсована.
Job system и burst вышли из чата.