Немного не верное утверждение. Сейчас по дефолту GOMAXPROC=NUMCPU.
Я буду обновлять комментарии перед отправкой. Я буду обновлять комментарии перед отправкой. Я буду обновлять комментарии перед отправкой.
В первый раз не смог «осилить» первую главу. Сегодня же наткнулся, увидел что Вы автор, вспомнил про «Беги до последнего» решил попытаться ещё раз и прочитал залпом, желаю продолжения.
Есть конечно, к чему придраться, но зачем? Хорошая, атмосферная история, пишите ещё, пожалуйста
При большом потреблении памяти мусор всё равно будет, так что, в теории, должно тогда дать прирость, но вызов GC, насколько я помню, тоже вызывает stopTheWorld. Именно в этом моменте было интересно, будет ли в сумме две таких остановки мира быстрее, чем одна из-за runtime.ReadMemStat, по логике — да
>Там в сигнатурах есть подстановки с $$, т. е. код в любом случае получится невалидный. Поэтому генерируем в закомментированном виде. Ну и, конечно, исторически сложилось :)
Ага, спасибо, просто у себя, обычно, предпочитаю генерировать код валидный и с паниками, но против исторически сложившихся фактов ничего не имею ;)
И, ещё бы хотелось полюбопытствовать в чём у вас пишут код =)
Спасибо за статью, было интересно. Подскажите, а принудительный вызов runtime.GC() перед вызовом runtime.ReadMemStat() не снижает время StopTheWorld?
И второй вопрос, просто по стилистике, а почему был сделан выбор в пользу генерации закоментированнх методов, а не, к примеру пустых методов или методов с panic(«not implemented»)?
Смотрите, если eface (interface{}), состоит из двух слов (указатель на структуру описывающую тип и указатель на данные), то в iface (в Вашем случае — Stringer) в себя ещё включает таблицу методов.
В данном случае аллокация, на данный момент неизбежна, так-как в рантайме происходят несколько вещей:
Проверка на соответсвие передаваемого типа интерфейсу (наличию методов)
Создание интерфейса
И самое главное: вызов метода через интерфейс(переходим к объекту в памяти, от него к таблице методов и вызываем)
Сделать это не засунув t в кучу — довольно проблематично, насколько мне известно. (А вот если GetString будет принимать напрямую Text, а не интерфейс, то аллокаций не будет)
Другое дело, что в данном примере t — статичен и можно было произвести оптимизацию, но, я достаточно плохо разбираюсь в компиляторах, что бы оценить сложность таких оптимизаций
Не успел отредактировать предыдущий комментарий. Решение быстрое, но не верное. Выдаваемый флаг зависит от введеного PIN'a (последовательность простых операций над входной строкой и перегон в BASE64)
На всякий случай проверил, всё правильно сказал. Лучше менять на je (у него опкод 0x74, тогда как у jnz 0x75).
Оффсет инструкции для смены в hex-редакторе: 0x17F5 (Меняем 75 на 74).
Результат:
Enter your PIN (8 digits):
12345678
PIN is correct! Flag:
84140ad7249dc0fdbdd02cd13cb3262f
Спасибо за статью.
Подскажите, я, наверное, подтупливаю, но вроде можно было просто заменить условный переход безусловным
— jnz short loc_4017FC
+++ jmp short loc_4017FC; Переходим всегда на ветку с выдачей флага
or
+++ je short loc_4017FC; Получим флаг только при не правильном PIN'e
Да, Вы абсолютно правы.Могу даже дополнить, что если надо скастовать слайс в слайс интерфейсов, то с большей долей вероятности — что то не так.
В данном случае int не при чём, вместо int'а там мог быть слайс строк или булов, или своих структур, для этого надо изменить только само определения слайса.
Данный метод быстрее, чем перебор циклом и гораздо быстрее, чем рефлексия, но я, как уже говорил выше, не стал бы его использовать в продакшене.
Это просто интересный «ещё один» способ сделать так. Лучше очевидно — меньшим количеством аллокаций и большей скоростью выполнения. Но я бы не рекомендовал использовать подобное в продакшене.
Это не в коем случае не плач про дженерики.
Лично для меня это был не большой челлендж, смогу или нет — как итог — с удовольствием поковырялся в исходниках Go и его рантайме
Есть логические ошибки, уже упомянутые в комментариях, но рассказ всё равно получился интересным, если не сильно не «загоняться». Приятно было прочитать хороший, легкий, рассказ от земляка. Спасибо )
ИМХО — смысла нет, возможно, конечно, если Presto переписать на потоки\процессы\рутины, то он и бы и стал работать на 10-30% быстрее, но, это бы не сыграло роли, он и так довольно шустрый. Короче — фап^W хайп на многопоточность сделал своё чёрное дело =(. Остается только надеяться, что Opera Software официально откроет сорцы, а то сейчас они вроде как и есть, а сделать с ними ничего нельзя.
UPD:
Или давайте распространять апдейты патчами, ночью, в поле
С одной стороны — довольно интересно, с другой стороны — Raspberry Pi + камера + linux + OpenCV, вывод передается дальше на usb+serial port (вкратце суть устройства)
Штатной возможности изменять строки — нет, но если сильно хочется — можно через unsafe.
В примере реализованным мной была попытка сделать type assertation без аллокаций, получилось, побочный эффект — ускорение примерно в 5 раз, но этот код просто проверка идеи
Я буду обновлять комментарии перед отправкой. Я буду обновлять комментарии перед отправкой. Я буду обновлять комментарии перед отправкой.
Есть конечно, к чему придраться, но зачем? Хорошая, атмосферная история, пишите ещё, пожалуйста
>Там в сигнатурах есть подстановки с $$, т. е. код в любом случае получится невалидный. Поэтому генерируем в закомментированном виде. Ну и, конечно, исторически сложилось :)
Ага, спасибо, просто у себя, обычно, предпочитаю генерировать код валидный и с паниками, но против исторически сложившихся фактов ничего не имею ;)
И, ещё бы хотелось полюбопытствовать в чём у вас пишут код =)
И второй вопрос, просто по стилистике, а почему был сделан выбор в пользу генерации закоментированнх методов, а не, к примеру пустых методов или методов с panic(«not implemented»)?
var arg interface{}
arg = 1;
arg = false;
В данном случае аллокация, на данный момент неизбежна, так-как в рантайме происходят несколько вещей:
Сделать это не засунув t в кучу — довольно проблематично, насколько мне известно. (А вот если GetString будет принимать напрямую Text, а не интерфейс, то аллокаций не будет)
Другое дело, что в данном примере t — статичен и можно было произвести оптимизацию, но, я достаточно плохо разбираюсь в компиляторах, что бы оценить сложность таких оптимизаций
Оффсет инструкции для смены в hex-редакторе: 0x17F5 (Меняем 75 на 74).
Результат:
Enter your PIN (8 digits):
12345678
PIN is correct! Flag:
84140ad7249dc0fdbdd02cd13cb3262f
Подскажите, я, наверное, подтупливаю, но вроде можно было просто заменить условный переход безусловным
— jnz short loc_4017FC
+++ jmp short loc_4017FC; Переходим всегда на ветку с выдачей флага
or
+++ je short loc_4017FC; Получим флаг только при не правильном PIN'e
Это ведь было-бы гораздо быстрее брута PIN'а
В данном случае int не при чём, вместо int'а там мог быть слайс строк или булов, или своих структур, для этого надо изменить только само определения слайса.
Данный метод быстрее, чем перебор циклом и гораздо быстрее, чем рефлексия, но я, как уже говорил выше, не стал бы его использовать в продакшене.
Это не в коем случае не плач про дженерики.
Лично для меня это был не большой челлендж, смогу или нет — как итог — с удовольствием поковырялся в исходниках Go и его рантайме
UPD:
Или давайте распространять апдейты патчами, ночью, в поле
В примере реализованным мной была попытка сделать type assertation без аллокаций, получилось, побочный эффект — ускорение примерно в 5 раз, но этот код просто проверка идеи