ВО
вот как раз оказалось сложно
для быстрого преобразования использую bit.rshift
для быстрого преобразования использую bit.rshift
Size: a a a
2021 June 01
ВО
не совсем понятно, как он него добиться unsigned
AK
Быстрое гугление дало мне кучу реализаций на луа. Например вот https://scholzd.github.io/MoonGen/utils_8lua.html
AK
Возьмите что вам нравится
ВО
то есть получается все таки стороннее
я нашел lua-bit64, но думал что-то есть более типовое ил встроенное
спасибо
я нашел lua-bit64, но думал что-то есть более типовое ил встроенное
спасибо
YD
c1, c2, c3, c4 = string.match(s, '(%d+)%.(%d+)%.(%d+)%.(%d+)')
return c1*256^3 + c2*256^2 + c3*256 + c4
сойдет?AK
Ну, надо бы проинициализировать сначала переменные ещё
YD
какие? s?
AK
И чек какой-нить поставить на невалидный матч
YD
это был концепт
DS
MA
Вам нужен
посмотрите как из lua вызывать libC через ffi.
ffi.C.inet_atonпосмотрите как из lua вызывать libC через ffi.
2021 June 02
ВО
Видимо, это и есть то что нужно
спасибо
спасибо
ВО
умножение, степень - это же дико медленно
AB
Прямо уж дико?
AB
На пару тактов дольше чем битовые сдвиги
VG
вообще не факт, luajit оптимизнуть может. Здесь же умножение на степени двойки. К тому же, inet_aton возвращает BigEndian, и для разворачивания порядка байт нужно будет еще немного покрутиться на ffi.
я вчера немного бенчил, наивное решение с умножением примерно в 1.5 раза быстрее, но это примерно 0.3 микросекунды, учитывать их наверное не стоит
я вчера немного бенчил, наивное решение с умножением примерно в 1.5 раза быстрее, но это примерно 0.3 микросекунды, учитывать их наверное не стоит
ВО
а вот это уже интересно
ВО
сейчас использую как раз битовые сдвиги, ожидается примерно 500 вызовов в секунду.
Не хотелось бы, чтобы тарантул все процессорное время тратил только на IP адреса
Не хотелось бы, чтобы тарантул все процессорное время тратил только на IP адреса
VG
наивное решение дает 3М вызовов в секунду, вам хватит?