« Rev
@ProLua   507
Fwd »


Snusmumriken
ок, если так, то хорошая хэш-функция — гораздо более правильное решение проблемы, потому что снимает больше рисков
Да, "хорошая хеширующая функция" может оказаться не такой уж и хорошей, а в твоём конкретном случае — она может оказаться ещё хуже чем функция от luajit. Это тоже НЕ ГАРАНТИРУЕТ ничего. Вообще ничего.
Snusmumriken
Хеш — это всегда вероятности. И в определённых моментах одни "идеальные" хеши работают хуже чем другие. Как карта ляжет. Это тоже риск.
Egor
Да, это pid controller. Нужен чтоб что-то менялось в балансе с изменением другого параметра
т.е. какое-то виртуальное хранилище? или точнее сказать реактивщина?
Max
и о том, что хэш-функция луаджита никогда не работает лучше, чем murmur
Snusmumriken
Так вот, о чём это я. Луажит норм, если с ним уметь работать. Точнее, не менее "норм" чем всё остальное.
Snusmumriken
И по меньшей мере, она гораздо быстрее мур-мура. Во много раз на больших строках. Если тебе скорость хеширования важнее — это лучший хеш чем мурмур. Мурмур, допустим, положит сервер, а луаджитовая функция нет ))
Egor
Реактивщина.
хм, спасибо, но все равно не понимаю для чего может понадобиться, люди его юзают..а я хз...
Max
да, напрягать мозги сложно, но полезно!
Max
(с)
Snusmumriken
Тогда нет никакой разницы между функцией жыта и мурмуром, потому что мы в любом случае будем напрягать мозги, просто в чуть разные стороны )) Сорян за демагогию, но это логично!
Egor
в дефолтном управлении есть такое: local rollAmplitude = 60 local targetRoll = utils.clamp(rollInput * rollAmplitude, -rollAmplitude, rollAmplitude) if (rollPID == nil) then rollPID = pid.new(0.2, 0, 10) end rollPID:inject(targetRoll - currentRoll) targetAngularVelocity = pitchInput * worldRight + rollPID:get() * worldForward + yawInput * worldUp
fgntfg
хм, спасибо, но все равно не понимаю для чего может понадобиться, люди его юзают..а я хз...
Хз. Перемещение камеры, педаль газа, любое не линейное отношение.
fgntfg
Ой, roll, yaw. Это же самолет!
Max
Тогда нет никакой разницы между функцией жыта и мурмуром, потому что мы в любом случае будем напрягать мозги, просто в чуть разные стороны )) Сорян за демагогию, но это логично!
ммм нет, потому что в среднем разница в О-сложности алгоритма гораздо дороже, чем в константе, которая скрывается за О
Snusmumriken
ммм нет, потому что в среднем разница в О-сложности алгоритма гораздо дороже, чем в константе, которая скрывается за О
Только на маленьких строках. Как только житовая функция начинает пропускать символы (длина строки больше условных 16 байт), начинается сплошной прирост )) И это всё лишний раз подтверждает, что а) абстракции текут б) программировать не напрягая мозгов и не изучая свою базу может быть вредно (а может и не быть!) И если ты кодер под луажыт, ты должен знать особенности платформы и не допускать косяков. А если тебе что-то прям остро не нравится но тебе плевать на память — берёшь и патчишь своей хеш-функцией, и думаешь о других проблемах. Когда она упадёт — неизвестно, но ты типа спокоен.
fgntfg
Вот пример работы pid
Egor
Вот пример работы pid
Я правильнопонимаю, что могу его юзать например для управления тягой? т.е. к примеру на вход даю грубо говоря 10, а он мне на выходе 1, ну как линейное уравнение?
fgntfg
Кажется так
vvzvlad
pid исправляет сложности с ошибками измерения и инерционностью, накапливая поправки. Ты говоришь 10, а он поднимает до 10, компенсируя ветер, разное давление, шумы от измерителя и тд
Max
Только на маленьких строках. Как только житовая функция начинает пропускать символы (длина строки больше условных 16 байт), начинается сплошной прирост )) И это всё лишний раз подтверждает, что а) абстракции текут б) программировать не напрягая мозгов и не изучая свою базу может быть вредно (а может и не быть!) И если ты кодер под луажыт, ты должен знать особенности платформы и не допускать косяков. А если тебе что-то прям остро не нравится но тебе плевать на память — берёшь и патчишь своей хеш-функцией, и думаешь о других проблемах. Когда она упадёт — неизвестно, но ты типа спокоен.
поясню, чтобы было понятнее: О-сложность интернирования превращается из константной в линейную, когда хэш-функция плохая. а плохая хэш-функция быстрее хорошей только в константу раз. Предлагаю сойтись на том, что луаджит с безопасной дефолтной хэш-функцией и легко-конфигурируемый для использования опасной и быстрой был бы лучше, чем текущее положение дел
Snusmumriken
У меня просто немножко другое мышление, я не могу сказать "был бы лучше", потому что в моём мире не бывает "общих" случаев, только частные. Для моих задач он более чем подходит, особенно с учётом того что я знаю что происходит. А в будущее я не лезу, вдруг все внезапно перестанут активно хранить списки почти одинаковых строк в luajit'е? Тогда станет совершенно пофигу какая там функция.
Max
перестанут использовать строки?
Snusmumriken
А ВДРУГ! Правда, это офигеть как сложно, придётся хранить и обращаться к переменным примерно так. _G[1][2](_G[4])
Max
хорошо, а улучшение в среднем случае бывает?
Max
_G — это тоже строка)
Snusmumriken
Но она уже есть, мы не создаём новую.
Max
согласен, одна строка интернируется почти любой хэш-функцией так же эффективно, как 0 строк
Snusmumriken
хорошо, а улучшение в среднем случае бывает?
Нет, потому что не бывает "средних случаев" так же как не бывает "общих". Бывают конкретные: "Я пытаюсь использовать луа как быстрый кеш для строк". В этом случае функция хеширования luajit'а ниоч, и можно использовать другую. А можно не использовать, если организовать иначе, исключая дубликаты.
Snusmumriken
Не лучше, не хуже. Просто вот так вот, и всё. Мы решаем конкретные проблемы, поэтому смотрим конкретно на них.
Serezha
ну о чем вы спорите. есть конкретный бяка-кейс с шаблонами - лучше его обсудите
Max
ну ты говоришь, что luajit — плохой "исполнятор" дженерал луа кода и тебе норм. я вот мечтаю о том, чтобы он был хорошим исполнятором дженерал луа кода
Max
а хороший "исполнятор" дженерал кода должен думать о среднем случае
Snusmumriken
В смысле "плохой исполнятор дженерал луа кода"? Ты о том что луажыт ломается при слишком много логики?
Snusmumriken
Потому что в моей работе луажыт не подводил, и скорее всего не подведёт. Значит в "моём дженерале" он наверное хороший ))
Snusmumriken
Нене, тогда теряется смысл джыта, и можно было бы изначально пихнуть puc lua.
Max
он всё ещё будет очень быстрым
Max
и быстрее чем puc lua
Snusmumriken
Ну не очень сильно, раза в три-пять (условно 20 на математике), это обычно не столь критично. Опять таки, в моих условиях.
Max
а сколько, по-твоему, даёт джит?
Snusmumriken
В зависимости от качества кода. На моей практике, прирост 60-300 раз. 200-300 — на простых вещах типа простенького скрипта для перемолки бешеных данных.
Snusmumriken
Уточнил.
Max
300 — это может быть с ffi, который как раз очень плох в интерпретаторе
Max
но я всё равно не верю
Snusmumriken
Нене, без ffi, просто обработка строк или математики. Матрицы считать в промышленных масштабах, например. Нормали для трёхмерных моделек. Почти без разметки памяти в процессе.
Serezha
а сравните луа и лужаит с квикжсом для интереса
Serezha
интересно как там с памятью и быстродействием
Snusmumriken
Хммм. Надо будет конкретно это побенчать, но на глаз — разница между условно "идёшь пить чай" или "успеваешь только запустить музычку на вкладке и уже гоотво" ))
Snusmumriken
Я же сказал, "на моей практике — прирост 60-300 раз". 200-300 — на простых вещах. Вот и всё. Ну и я пишу скриптики под жыт, так что очевидно что я выжимаю сколько могу.
Max
200 - 300 раз даже Майк Полл стесняется показывать на табличке с бенчмарками http://luajit.org/performance_x86.html
Max
а если убрать бенчмарки, в которых используется ffi, останется прирост с разбросом 1.01 - 5
Snusmumriken
Как раз потому что это не "общие случаи" а конкретные )) От Майка потом будут всегда ожидать такой производительности во всех-всех задачах )))
Snusmumriken
Зачем нужно ffi?
Max
для memcpy например
Max
или разметки памяти для массивов
Max
чтобы не перевыделять
Snusmumriken
Вот.
Snusmumriken
Обычная луёвая табличка, которую мы заполняем циферками один раз в начале скрипта, а потом только изменяем эти циферки — не будет перевыделять память. И доступ к ключам будет примерно с той же скоростью.
Snusmumriken
За счёт ffi обычно добиваются быстрой-быстрой генерации всё новых и новых структур, потому что они статические и размечаемые.
Snusmumriken
Это верно в том, что "в цикле" не происходят перераспределения, а цикл отжирает 99.(9)% времени.
Max
в честном бенчмарке это выделение будет внутри цикла
Max
кстати
Max
зачем тебе 10000000 раз считать одно и то же?
Snusmumriken
Ну, надо тупо забенчать, в том конкретном скриптике ещё выдираются строки (из файла с моделькой, который влезает в оперативку), типа: vec3[1], vec3[2], vec3[3] = str:byte(1000, 1002), а потом уже всякие умножения векторов на матрицы и подсчёты нормалей.
Max
в общем, это плохой бенчмарк, ворклоад которого не соответствует реальным задачам (в среднем, в конкретном твоём случает, может, не так, но сорян, бенчмарки про другое)
Snusmumriken
Ещё раз повторяю. Я замечал прирост условно от 60 до 300 раз. От и до. Я замечал (человеческий фактор). Не Вася Пупкин (другой человеческий фактор). У меня не так много способов заметить, потому что в основном я пишу разные вещи под luajit и под lua5.1, которые не пересекаются (одно для себя под одну платформу, другое — на работе под другую платформу).
« Rev
@ProLua   507
Fwd »