Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
какого алгоритма? ты регэкспы меряешь или что? аллокацию? так у тебя только один пример аллоцирует. а -XX:AlwaysPreTouch выставил? а хип сколько вообще сначала был? а гц смотрел? а не компилит ли что-то джит между вызовами смотрел? а сколько оно работает интерпретатором смотрел? а в с1? а в с2? а инлайн принудительный делал? а ассемблерный листинг смотрел?
это и близко не бенчмарк, какая-то хуйня внутри происходит, ну да и ладно.
Ещё раз повторюсь: какая разница? Никого не волнует, какой там рантайм и какие оно классы грузит. Есть реальная задача, мы меряем, насколько быстро её решает тот или иной язык. Всё.
Я не хочу пирдолиться чтобы создать тепличные условия сраной Йаже, которой в отличие от быстрой однострочной скриптухи (!) нужен ещё какой-то пирдолинг с «питухвм», и КОКОКОмпилятором.
И всё ради того чтобы выиграть жалкие 3 секунды. Чтобы Йажа соснула не за 1410 секунд, а всего за 1407.
Надо не питухвмы городить, а делать оптимизированный зожимающий repeat, который не засирает мегабайты памяти.
> которой в отличие от быстрой однострочной скриптухи (!) нужен ещё какой-то пирдолинг с «питухвм», и КОКОКОмпилятором.
Подтверждаю. Скриптуху вообще time'ом измеряли, со всеми накладными расходами на запуск процесса и безо всяких прогревов.
time perl -wle 'print "Prime" if (1 x shift) !~ /^(11+?)\1+$/' 1165139
Complex regular subexpression recursion limit (32766) exceeded at -e line 1.
Prime
real 0m28.459s
user 0m28.454s
sys 0m0.004s
"But the Complex regular subexpression recursion limit makes perl just say "oh well, I had enough - I'll just pretend it doesn't match". That's wrong. It may even be exploitable."
Для чисел меньше 1073938441 «Перл» всегда будет выдавать корректный результат. С тем же успехом можно обвинить ЙАЖУ в том, что она не сможет корректно обработать числа длиннее 2**31.
> ну то есть опять приходим к тому, что жажа выолняет одно, а пердл другое
Все языки выполняют разное, потому что у них у всех разные реализации движка рагулярных выражений.
А зачем этот супер рипит? Чтобы быстро и экономно по памяти отдавать i-ый символ строки? Ну просто движок регэкспов же не станет с таким работать, эм ай райт? Ну и нахуя экономия, чьё время жизни в промежутке от иммутабельной инициализацией, где ничего с данными произойти не может, до ближайшего тустринг.
Или ты заставил регэкспы работать с каким нибудь потоком String и заимплементил интерфейс?
>чьё время жизни в промежутке от иммутабельной инициализацией где ничего с данными произойти не может, до ближайшего тустринг.
В примере из поста toString вообще не вызывается. На что указывает маленькое количество памяти в тестах. Движок регэксов откусывает из последовательности по символу.
Т.к. код не лазит постоянно в память, а берёт символы из ближайшего кеша алгоритм ускоряется в 5-15 раз.
Такое встречается довольно часто. Иногда нужно сгенерить последовательность символов для итерации.
CharSequence можно представить как ленивый список из Хацкеля. Он в теории мог быть даже бесконечным, если бы не int length().
В «K&R C» был «автовывод» типов: все необъявленные скаляры считались типа int, у всех необъявленных массивов тип элемента был int, у всех необъявленных функций тип результата был int.
Поэтому pituh[-1u]={1}; эквивалентен int pituh[-1u]={1};
Т. е. объявляем массив интов, в квадратных скобках размер, в фигурных — начальные значения некоторого среза массива, начиная с нулевого элемента (всё, что явно не инициализировали в фигурных скобках, инициализируется нулём).
В сишке нельзя инициализировать массив частично: можно или вообще не инициализировать (тогда он не попадёт в экзешник, а будет создаваться при загрузке программы), либо инициализировать полностью (компилятор за нас запишет нули в элементы, которые мы пропустили).
main — это не конструкция языка, это всего лишь известный символ в стандартной библиотеке. Успешной линковки и отладки, когда код из CRT вызовет _main, а в нём массив, начинающийся с единички, вместо вменяемого кода.
main объявлен как массив из одного элемента со значением 0xc3 (что совпадает с опкодом RET у x86). Поскольку у x86 маленький индеец, 0xc3 будет самым первым байтом, а нули будут потом.
Может не сработать из-за DEP, если поддерживается атрибут NX.
У приличных людей он в промпте автоматом выводится.
Кстати не понимаю почему это нигде не настроено по дефолту и в каждом дистре (даже где есть готовые презеты промпта) не настроено отображение кода и приходится его руками вписывать.
Мне код возврата в 90% гораздо важнее знать, чем текущую директорию, текущее время, юзера и прочую питушню.
3.14159265 # 0
Fike # 0
ну кто ж так бенчит? создание тестовых данных за пределы измеряемого времени-то вынеси
vistefan # 0 ⇈
3.14159265 # 0 ⇈
3.14159265 # 0 ⇈
Впрочем заполнение строки питушнёй настолько несущественно, что разница там в пределах погрешности.
Стало даже чуть хуже
Lazy String : 1092
https://ideone.com/M6ZXhR
Fike # 0 ⇈
это и близко не бенчмарк, какая-то хуйня внутри происходит, ну да и ладно.
gost # 0 ⇈
Fike # 0 ⇈
gost # 0 ⇈
Fike # 0 ⇈
мало того, что жажа уже при стартапе загружает кучу всего, так и внутри вызова может наткнуться на какой-то незагруженный класс и пойти читать с диска
gost # 0 ⇈
Fike # 0 ⇈
да, реальная задача
gost # 0 ⇈
И да, копирование картинок в буфер обмена в винде — это ёбанное днище.
TEH3OPHblu_nemyx # 0 ⇈
vistefan # 0 ⇈
Лоооооол
Виндобляди соснули
vistefan # 0 ⇈
3.14159265 # 0 ⇈
У себя я бенчил из jshella.
Со стартованной йажей и загруженными классами.
guest # 0 ⇈
3.14159265 # 0 ⇈
Я не хочу пирдолиться чтобы создать тепличные условия сраной Йаже, которой в отличие от быстрой однострочной скриптухи (!) нужен ещё какой-то пирдолинг с «питухвм», и КОКОКОмпилятором.
И всё ради того чтобы выиграть жалкие 3 секунды. Чтобы Йажа соснула не за 1410 секунд, а всего за 1407.
Надо не питухвмы городить, а делать оптимизированный зожимающий repeat, который не засирает мегабайты памяти.
gost # 0 ⇈
Подтверждаю. Скриптуху вообще time'ом измеряли, со всеми накладными расходами на запуск процесса и безо всяких прогревов.
3.14159265 # 0
А она всё-равно пёрлу сливает
Fike # 0 ⇈
> Complex regular subexpression recursion limit (32766) exceeded at -e line 1.
ты exit code-то хоть проверял?
gost # 0 ⇈
Fike # 0 ⇈
gost # 0 ⇈
Результаты он выдаёт полностью корректные, так что действительно плевать.
Fike # 0 ⇈
> Complex regular subexpression recursion limit (32766) exceeded at -e line 1.
Fike # 0 ⇈
gost # 0 ⇈
Fike # 0 ⇈
> Кстати, я придумал тебе число, на котором пёрл сольётся как лалка и выдаст неправильный ответ.
ну то есть опять приходим к тому, что жажа выолняет одно, а пердл другое
gost # 0 ⇈
> ну то есть опять приходим к тому, что жажа выолняет одно, а пердл другое
Все языки выполняют разное, потому что у них у всех разные реализации движка рагулярных выражений.
Fike # 0 ⇈
gost # 0 ⇈
vistefan # 0 ⇈
admin # 0 ⇈
vistefan # 0 ⇈
Fike # 0 ⇈
TEH3OPHblu_nemyx # 0 ⇈
gost # 0 ⇈
gost # 0 ⇈
Разве не красиво? И это я только два вида кавычек использовал!
MAKAKA # 0 ⇈
gost # 0 ⇈
Красиво. Всё таки «Руби» — очень сладкий язык.
admin # 0 ⇈
gost # 0 ⇈
3.14159265 # 0 ⇈
В каждом языке сделали специальный оператор/метод для повтора строки.
Есть перл, 1 x 75120045
Есть руби и питух "1" * 75120045
В йажа завезли "1".repeat( x ).
Но сделали анскильно.
В той же йажа строки немутабельные. То есть раз мы создали миллион "1" он таким навсегда и останется
Неужели действительно нельзя было сделать чтобы repeat возвращал простой CharSequence. Содержащий повторяемую строку и количество повторений.
И не плодить строки с гигабайтом повторяющихся символов?
Конкретно в этой задаче это дало ускорение 5-15 раз. И константу по памяти.
vistefan # 0 ⇈
Или ты заставил регэкспы работать с каким нибудь потоком String и заимплементил интерфейс?
3.14159265 # 0 ⇈
Будет.
>Или ты заставил регэкспы работать с каким нибудь потоком String и заимплементил интерфейс?
Вообще-то пример кода в посте. https://govnokod.ru/26808
vistefan # 0 ⇈
3.14159265 # 0 ⇈
В примере из поста toString вообще не вызывается. На что указывает маленькое количество памяти в тестах. Движок регэксов откусывает из последовательности по символу.
Т.к. код не лазит постоянно в память, а берёт символы из ближайшего кеша алгоритм ускоряется в 5-15 раз.
Такое встречается довольно часто. Иногда нужно сгенерить последовательность символов для итерации.
CharSequence можно представить как ленивый список из Хацкеля. Он в теории мог быть даже бесконечным, если бы не int length().
vistefan # 0 ⇈
vistefan # 0 ⇈
3.14159265 # 0 ⇈
3.14159265 # 0 ⇈
gost # 0 ⇈
TEH3OPHblu_nemyx # 0 ⇈
gost # 0 ⇈
3.14159265 # 0 ⇈
>main[-1u]={1};
Сишка компактнее. И на мой вкус изящнее.
Путушное решение скучное.
А с main[] я вообще удивился что эта питушня компилится.
gost # 0 ⇈
Плотность в гигабайтах на байт исходного кода всё равно выше.
> И на мой вкус изящнее.
А тут соглашусь, великолепный трюк.
3.14159265 # 0 ⇈
Какая разница сколько там воображаемых петабайт, если эта плотность недостижима на практике? Сишка практичнее.
Компиляцию Питуха невозможно проверить на практике, т.к. нет столько ОЗУ.
А когда столько ОЗУ и дискового пространства появится, то в Сишку просто завезут 128-битные типы и более широкую адресацию.
-1lu переполнится в ещё большие числа.
TEH3OPHblu_nemyx # 0 ⇈
Выхлоп gcc -S a.c:
Выхлоп bcc32 -S a.c:
Выхлоп wcc386 a.c; wdis -a a.obj:
«Цифровой Марс» выдаёт то же, что и «Watcom».
«MSVC» генерирует аналогичную питушню, разве что вставляет комментарий:
Интеловский компилятор ведёт себя аналогично «MSVC».
Выхлоп lcc -S a.c:
Выхлоп clang -S a.c:
И даже «tcc» Фабриса Беллара генерирует такой же массив.
TEH3OPHblu_nemyx # 0 ⇈
В «K&R C» был «автовывод» типов: все необъявленные скаляры считались типа int, у всех необъявленных массивов тип элемента был int, у всех необъявленных функций тип результата был int.
Поэтому pituh[-1u]={1}; эквивалентен int pituh[-1u]={1};
Т. е. объявляем массив интов, в квадратных скобках размер, в фигурных — начальные значения некоторого среза массива, начиная с нулевого элемента (всё, что явно не инициализировали в фигурных скобках, инициализируется нулём).
В сишке нельзя инициализировать массив частично: можно или вообще не инициализировать (тогда он не попадёт в экзешник, а будет создаваться при загрузке программы), либо инициализировать полностью (компилятор за нас запишет нули в элементы, которые мы пропустили).
main — это не конструкция языка, это всего лишь известный символ в стандартной библиотеке. Успешной линковки и отладки, когда код из CRT вызовет _main, а в нём массив, начинающийся с единички, вместо вменяемого кода.
TEH3OPHblu_nemyx # 0 ⇈
main объявлен как массив из одного элемента со значением 0xc3 (что совпадает с опкодом RET у x86). Поскольку у x86 маленький индеец, 0xc3 будет самым первым байтом, а нули будут потом.
Может не сработать из-за DEP, если поддерживается атрибут NX.
3.14159265 # 0 ⇈
В целом, да. Можно написать в машинных кодах какие-то вычисления, переместить в rax и вывести их в консоль через код разврата.
TEH3OPHblu_nemyx # 0 ⇈
В «MSVC», «Borland C», «Watcom C» нужно писать так:
Первая строка не нужна, потому что секция ".text" уже имеется. Эта строка нужна, чтобы заткнуть компилятор.
gost # 0 ⇈
TEH3OPHblu_nemyx # 0 ⇈
3.14159265 # 0 ⇈
Умножает argc на 3.
3.14159265 # 0 ⇈
А вообще реальные Цари не пишут main, а начинают программу переопределяя _start.
3.14159265 # 0 ⇈
Его нужно почистить, чтобы получить нулевой код разврата.
Но хорошо, что у Штеуд в 4 байта вмещается 2 инструкции благодаря variable length схеме.
И наконец-то мы получаем Success с нулём.
https://ideone.com/CCTOQT
TEH3OPHblu_nemyx # 0 ⇈
admin # 0 ⇈
3.14159265 # 0 ⇈
Не нужно хамить.
У приличных людей он в промпте автоматом выводится.
Кстати не понимаю почему это нигде не настроено по дефолту и в каждом дистре (даже где есть готовые презеты промпта) не настроено отображение кода и приходится его руками вписывать.
Мне код возврата в 90% гораздо важнее знать, чем текущую директорию, текущее время, юзера и прочую питушню.
guest # 0 ⇈
какой сёмизм:)
Я запускаю код из IDE, она всегда рисуует exit code
bormand # 0 ⇈
Сишке же. Жаба честно регулярки считает, а пёрл всё сишке скармливает.
3.14159265 # 0 ⇈
ЧЯДНТ?
https://govnokod.ru/26800#comment559728
https://ideone.com/2MelzP
Her # 0
3.14159265 # 0 ⇈
Как ты эту сраную йажу не прогревай.
admin # 0 ⇈
guest # 0 ⇈
admin # 0 ⇈
MAKAKA # 0 ⇈
да
admin # 0 ⇈