статья вызвала у меня неоднозначные чувства. с одной стороны - монументальный труд, явно выходящий за рамки простого обзора. Чего стоят только формулы, выложенные в виде картинок (да. Тогда еще хабр не позволял вставлять формулы - автор, мягко сказано, знатно помучился). При внимательном чтении все вроде бы сходится. Но при попытке реализовать самостоятельно тесты по описанным алгоритмам, сразу бросаются в глаза грубые опечатки с первой же главы. Например решил я реализовать Частотный блочный тест. и впал в ступор. а как рассчитываются числа pi?
считаю так - не сходится, считаю по-другому - не сходится. нарыл исходники тестов с сайта nist.gov - стало чуть понятнее, но не сильно. и подобных косяков в статье море. чтобы все их вскрыть, потребуется писать новую отдельную и не менее монументальную статью. я не готов, сорян.
И да - вишенка на торте. В середине статьи автор признается, что последовательность, которую он гонял в тестах - вообще ни разу не случайна, и автор привел формулы, ее порождающие (читай главу Тест на линейную сложность). Но внимание: все предыдущие тесты проходили очень успешно. И сразу доверие к таким тестам куда-то испарилось. Масло мне в огонь подкинул комментатор @vasiatka, после чего доверие к тестам NIST вообще упало. Неслучайность последовательности, перманентно мелькавшей в тексте, на мой проф.деформированный взгляд видна невооруженным глазом, однако проходит все тесты. Вот взгяните на такие последовательности: 1011010101 - предложенная в статье 11011001111111011110010101011110001010101111101101110001001100000 - цифры числа Пи 110010001111100011001010001010001101111100011100000111 - цифры корня из двух Не знаю, как по мне, видно что нижние 2 последовательности более сложны и имеют меньше повторяющихся паттернов.
А вообще статья шикарна, несмотря на выявленные недостатки. Автору плюс в карму. Хабр - торт.
Прошу меня простить за столь резкий комментарий. Вы не обязаны ничего представлять общественности, наоборот это я должен доказывать. Но проблемы сортировки на GPU что я озвучил выше - никуда не делись. И я действительно не встречал годные реализации сортировок на GPU для, например, использования СУБД
Тогда Nlogk=10^9*10(примерно 10 - логарифма тут двоичный).
Итого почти 10 млд. Операций экономия. Среди этих операций-операции сравнения ключей, которые для составных ключей могут быть очень не быстрыми. Стоимость сравнения строк, например, O(n). Так что насчет мизерной выгоды нисколько не согласен.
Я специально для вас опубликую код и замеры на массиве из 1 миллиарда записей. Но чуть позже. Просто мне необходимо привести свой экспериментальный проект в божеский вид. А то в процессе экспериментов там лапша по-гуще ассамблера сейчас
Такой размер подойдёт? Сортируемые данные будут находить на диске в момент выполнения сортировки. В оперативную память моего старенького компьютера они не поместится. Поэтому сортироваться будут по факту индексы( указатели на json-записи).Сортируемые данные будут являться json-записями , ключом сортировки - будет текстовое поле объекта длиной до 16 символов.
Сделаем замеры скорости в операциях и по времени. Вас устроит такой вариант теста?
Да тут один человек сказал, что выигрыш мизерный . Даже если бы я представил измерения для 100ГБ элементов - вряд ли это бы повлияло на столь высокую оценку.
На основе представленных измерений тенденция видна. Как доказательство, что концепция верна .
Представьте общественности алгоритм сортировки на GPU составных объектов, физически размещаемых на файловых носителях. большинство авторов больше как сортировку натуральных чисел предложить не могут. даже сортировку строк никто не предложил. А все потому что при сортировке подобных данных вас необходимо работать с указателями. Т.е. вы фактически перемещаете указатели, а сами данные физически не сортируются. В этом проблема
Стоит заметить, что автор испугался далее повышать размер сортируемого массива (хотя на млрд. элементов в тестах замахивался), боясь получить отрицательные значения выгоды, и ненароком разорвать структуру пространства-бытия.
Приятно видеть, что на свете еще остались люди, способные делать библиотеки со вменяемым интерфейсом. Спасибо за наводку, от души плюс куда следует!
так и не понял почему у webcryptoapi такой мудацкий интерфейс. Одни функции возвращают промисы, другие - сразу дают результат. Тот же getRandomValues спроектирован в синхронном стиле, а вот хеш считается asynv'ом. Хотя по логике должно быть наоборот (случайные числа поставляются аппаратурой и здесь могут быть недетерминированные задержки, в отличие от простой как репа функции вычисления хеша). А эти все пляски с бубном вокруг шифрования. Вы же привели простой и лаконичный код.
Благодаря разработчикам интерфейсов webcryptoapi я неожиданно узнал, что, оказывается при создании ключа для симметричного шифра AES нужно указывать опции ['encrypt', 'decrypt'], а то работать не будет. Странно, везде до этого писали что один и тот же ключ годится как для шифрования так и для расшифровки. И вообще ключ - это какой то сверхсекретный магический объект, который должен быть обязательно сформирован специальными функциями generateKey или importKey. О как! Я-то наивный думал, что подойдет любая числовая 128-ми, 192- или 256-битная последовательность. Век живи - век учись!
Так что когда увидел ваш образец, воскликнул: "А что так можно было?" Спасибо.
И вообще, ключ шифрования AES - бинарная последовательность из 256 бит (согласно вашему коду - у вас там в параметрах стоит 256). Точное значение ключа нигде не фигурирует. как вообще работает ваше шифрование?
сомневаюсь что даже каждый взрослый способен решить такую головоломку правильно. я вот до сих пор не понимаю этой бытовой терминологии (шурин, тесть, золовка и прочее). Поэтому решил, что в топике идет речь о 6(!) человеках.
Попробуйте попросить нейронку вывести формулу "гамма-функция произведения" Г(kx)=.... И будете разочарованы результатом. Честно - самому очень нужно. Но увы, мастер диссертаций ChatGPT, несколько не дотягивает мозгами до Ейлера и Гаусса. Всё что мне смогла выкатить нейронка на вопрос: как считать Гамма функцию с заказной точностью от 80 знаков после запятой и выше - это советы, гордо подчерпнутые из Википедии и других интернет-ресурсов. Чудес не бывает.
Максимум что мы имеем - уровень Онотоле Вссермана. И на том спасибо.
А что сложного в понятии "модуль "? Достаточно понимания, что шестеренки стыкуется только с одинаковым значением модуля. Тут же не редуктор для вертолета проектируется.
получается вся магия закрыта в волшебной директиве Py_BEGIN_ALLOW_THREADS
А как она работает ? в том смысле, не кроется ли за ней обычный медленный системный мьютекс ? Вот потому и попросил вас протестовать свое решение в условиях работы одновременно 100к потоков. продумайте тестовый код, который создаст реальную конкуренцию 100к потоков на одном защищаемом Вами ресурсе. тогда и будут видны преимущества приведенного в статье решения. и может ускорение уже не будет таким очевидным из-за Py_BEGIN_ALLOW_THREADS.
нагрузочное тестирование проводить обязательно!!! чтобы самому увидеть как поведет себя твой код . иначе такой программист не вырастет выше уровня hello world
90% игры - это контент : графика сюжет музыкальное оформление. вас нужен не питон , а blender, substant painter, corel, Photoshop, и почие инструменты. Вера в то, что выбрав хайповый язык Вы сразу превратитесь в игродела... хм... был бы у меня falcon9 я бы стал космонавтом. но увы
статья вызвала у меня неоднозначные чувства. с одной стороны - монументальный труд, явно выходящий за рамки простого обзора. Чего стоят только формулы, выложенные в виде картинок (да. Тогда еще хабр не позволял вставлять формулы - автор, мягко сказано, знатно помучился). При внимательном чтении все вроде бы сходится. Но при попытке реализовать самостоятельно тесты по описанным алгоритмам, сразу бросаются в глаза грубые опечатки с первой же главы. Например решил я реализовать Частотный блочный тест. и впал в ступор. а как рассчитываются числа pi?
считаю так - не сходится, считаю по-другому - не сходится. нарыл исходники тестов с сайта nist.gov - стало чуть понятнее, но не сильно. и подобных косяков в статье море. чтобы все их вскрыть, потребуется писать новую отдельную и не менее монументальную статью. я не готов, сорян.
И да - вишенка на торте. В середине статьи автор признается, что последовательность,
которую он гонял в тестах - вообще ни разу не случайна, и автор привел формулы, ее порождающие (читай главу Тест на линейную сложность).
Но внимание: все предыдущие тесты проходили очень успешно. И сразу доверие к таким тестам куда-то испарилось. Масло мне в огонь подкинул комментатор @vasiatka, после чего
доверие к тестам NIST вообще упало.
Неслучайность последовательности, перманентно мелькавшей в тексте, на мой проф.деформированный взгляд
видна невооруженным глазом, однако проходит все тесты. Вот взгяните на такие последовательности:
1011010101 - предложенная в статье
11011001111111011110010101011110001010101111101101110001001100000 - цифры числа Пи
110010001111100011001010001010001101111100011100000111 - цифры корня из двух
Не знаю, как по мне, видно что нижние 2 последовательности более сложны и имеют меньше повторяющихся паттернов.
А вообще статья шикарна, несмотря на выявленные недостатки. Автору плюс в карму. Хабр - торт.
Интересное мнение. А можете провести примеры когда кластеризация невозможна?
Сложность плавной сортировки брал на Википедии. Об оценке, что вы привели - не слышал.
Спасибо за конструктивный комментарий
Прошу меня простить за столь резкий комментарий. Вы не обязаны ничего представлять общественности, наоборот это я должен доказывать. Но проблемы сортировки на GPU что я озвучил выше - никуда не делись. И я действительно не встречал годные реализации сортировок на GPU для, например, использования СУБД
Хорошо. Пусть N=10^9, k=1000,
Тогда Nlogk=10^9*10(примерно 10 - логарифма тут двоичный).
Итого почти 10 млд. Операций экономия. Среди этих операций-операции сравнения ключей, которые для составных ключей могут быть очень не быстрыми. Стоимость сравнения строк, например, O(n). Так что насчет мизерной выгоды нисколько не согласен.
Я специально для вас опубликую код и замеры на массиве из 1 миллиарда записей. Но чуть позже. Просто мне необходимо привести свой экспериментальный проект в божеский вид. А то в процессе экспериментов там лапша по-гуще ассамблера сейчас
Такой размер подойдёт? Сортируемые данные будут находить на диске в момент выполнения сортировки. В оперативную память моего старенького компьютера они не поместится. Поэтому сортироваться будут по факту индексы( указатели на json-записи).Сортируемые данные будут являться json-записями , ключом сортировки - будет текстовое поле объекта длиной до 16 символов.
Сделаем замеры скорости в операциях и по времени. Вас устроит такой вариант теста?
Да тут один человек сказал, что выигрыш мизерный . Даже если бы я представил измерения для 100ГБ элементов - вряд ли это бы повлияло на столь высокую оценку.
На основе представленных измерений тенденция видна. Как доказательство, что концепция верна .
Представьте общественности алгоритм сортировки на GPU составных объектов, физически размещаемых на файловых носителях. большинство авторов больше как сортировку натуральных чисел предложить не могут. даже сортировку строк никто не предложил. А все потому что при сортировке подобных данных вас необходимо работать с указателями. Т.е. вы фактически перемещаете указатели, а сами данные физически не сортируются. В этом проблема
Я правильно понял что экономия 16 млн операций при сортировке 1млн объектов, для вас мизерная?
Это не считая возможности без проблем выполнить сортировку параллельно в 16 потоков.
Стоит заметить, что автор испугался далее повышать размер сортируемого массива (хотя на млрд. элементов в тестах замахивался), боясь получить отрицательные значения выгоды, и ненароком разорвать структуру пространства-бытия.
Вы про этот проект https://github.com/digitalbazaar/forge?
Приятно видеть, что на свете еще остались люди, способные делать библиотеки со вменяемым интерфейсом. Спасибо за наводку, от души плюс куда следует!
так и не понял почему у webcryptoapi такой мудацкий интерфейс. Одни функции возвращают промисы, другие - сразу дают результат. Тот же getRandomValues спроектирован в синхронном стиле, а вот хеш считается asynv'ом. Хотя по логике должно быть наоборот (случайные числа поставляются аппаратурой и здесь могут быть недетерминированные задержки, в отличие от простой как репа функции вычисления хеша). А эти все пляски с бубном вокруг шифрования. Вы же привели простой и лаконичный код.
Благодаря разработчикам интерфейсов webcryptoapi я неожиданно узнал, что, оказывается при создании ключа для симметричного шифра AES нужно указывать опции ['encrypt', 'decrypt'], а то работать не будет. Странно, везде до этого писали что один и тот же ключ годится как для шифрования так и для расшифровки. И вообще ключ - это какой то сверхсекретный магический объект, который должен быть обязательно сформирован специальными функциями generateKey или importKey. О как! Я-то наивный думал, что подойдет любая числовая 128-ми, 192- или 256-битная последовательность. Век живи - век учись!
Так что когда увидел ваш образец, воскликнул: "А что так можно было?" Спасибо.
И вообще, ключ шифрования AES - бинарная последовательность из 256 бит (согласно вашему коду - у вас там в параметрах стоит 256). Точное значение ключа нигде не фигурирует. как вообще работает ваше шифрование?
скажите пожалуйста, что за магия в вашем коде? инструкция
при каждом запуске генерирует новый ключ. Как сервер расшифровывает сообщения клиента, если ключ явно ему не передается?
сомневаюсь что даже каждый взрослый способен решить такую головоломку правильно. я вот до сих пор не понимаю этой бытовой терминологии (шурин, тесть, золовка и прочее). Поэтому решил, что в топике идет речь о 6(!) человеках.
Попробуйте попросить нейронку вывести формулу "гамма-функция произведения" Г(kx)=.... И будете разочарованы результатом. Честно - самому очень нужно. Но увы, мастер диссертаций ChatGPT, несколько не дотягивает мозгами до Ейлера и Гаусса. Всё что мне смогла выкатить нейронка на вопрос: как считать Гамма функцию с заказной точностью от 80 знаков после запятой и выше - это советы, гордо подчерпнутые из Википедии и других интернет-ресурсов. Чудес не бывает.
Максимум что мы имеем - уровень Онотоле Вссермана. И на том спасибо.
А что сложного в понятии "модуль "? Достаточно понимания, что шестеренки стыкуется только с одинаковым значением модуля. Тут же не редуктор для вертолета проектируется.
Попробуйте печатать из PET-G . У него усадка минимальна.
Шестеренку лучше проектировать в SolidWorks. Там есть удобный инструмент по созданию шестеренок: задаешь модуль , диаметр, и количество зубцов.
Скрытый текст
да не нужно жалеть свой шедуллер
получается вся магия закрыта в волшебной директиве Py_BEGIN_ALLOW_THREADS
А как она работает ? в том смысле, не кроется ли за ней обычный медленный системный мьютекс ? Вот потому и попросил вас протестовать свое решение в условиях работы одновременно 100к потоков. продумайте тестовый код, который создаст реальную конкуренцию 100к потоков на одном защищаемом Вами ресурсе. тогда и будут видны преимущества приведенного в статье решения. и может ускорение уже не будет таким очевидным из-за Py_BEGIN_ALLOW_THREADS.
но последнее- предположение.
нагрузочное тестирование проводить обязательно!!! чтобы самому увидеть как поведет себя твой код . иначе такой программист не вырастет выше уровня hello world
90% игры - это контент : графика сюжет музыкальное оформление. вас нужен не питон , а blender, substant painter, corel, Photoshop, и почие инструменты. Вера в то, что выбрав хайповый язык Вы сразу превратитесь в игродела... хм... был бы у меня falcon9 я бы стал космонавтом. но увы
И код тестирования не проведён или я невнимателен