вообще это как раз тот кусок, который мне все равно изобретать если либу использовать буду

мне интересно несколько вещей, можно ли придумать интерфейс который будет хорошо специализироваться для per-capability буфферов

но видимо это плохая идея до тех пор пока нельзя временно пиннить тред к капабилити

а как это "временно"? на время логанья чтоль?

ага

типа: pinned $ do x <- getBuffer writeLogToBuffer x msg

кметт такое предлагал сделать

поидее это 1 бит в инфе о процессе менять

без такой фичи поведения можно добиться, только если логирование не аллоцирует ничего и работает только с # объектами

@A64m_qb0 ICFP сломалось

https://www.youtube.com/channel/UCwRL68qZFfub1Ep1EScfmBw

видео выложили

и воркшопы тоже?

нет конечно

олсо https://www.youtube.com/playlist?list=PLnqUlCo055hVknu7QAW_RUZRmRZWXmnvv православнее

@A64m_qb0 ICFP сломалось

да все нормально, видео с прошлого icfp вообще было сразу (только не разрезанное), в этот раз я не нашел где стримы можно не в прямом эфире смотреть

а вот остальное только три месяца назад закончили выкладывать

со звуком беда какая-то

ещё и звук вам

со звуком беда какая-то

на icfp хорошего звука не бывает

но для многих докладов хоть пейпер есть, весело когда с какого-нибудь hiw выкладывают видео где полностью неразличимый хуррбурр и еще постоянно камера перефокусируется, так что и слайдов не видно

а бенч там про парсинг, да, это мимо

Открыл issue на добавление бенча про форматтинг: * https://github.com/andrewthad/chronos/issues/22 Да, это именно та библиотека, которую я имел в виду! Видел твит, что там человек бенчи реализовывал. Печально, конечно, что там только парсинг. Мне пока ни разу не приходилось парсить время, бенчи для форматирования были бы более полезными...

какой профит от инлайнинга?

весь профит от инлайнинга, пока не заинлайнишь - ничего как следует не оптимизируешь

это же тупо встраивание кода в то место короче какой-то копи-паст только на уровне компилятора

так пока код не вставишь - ничего с ним не сделаешь

т.е. какое-то время можно попереставлять "непрозрачные" функции, но только какое-то время, дальше уже без прозрачности ничего не сделать

это какой-то лямбда лифтинг?

да вообще все оптимизации

тоесть, если просадка в перформансе, то тыкай инлайн где попало и будет ок?

не все так просто, конечно

ну по большей степени так?

@nishirken будет жить. Поприветствуем!

в хаскеле же правила перезаписи, т.е. переставлением функций можно добиться больше чем обычно

ну реврайтинг тоже ок для оптимизаций

т.е. некоторые вещи нельзя инлайнить раньше времени, чтоб было за что правилам зацепится

но INLINE в общем-то на это и заточен

но не INLINEABLE

а в чем разница между ними?

и есть еще менее благоприятный способ для правил - экспоз олл анфолдингс или как там он называется

а в чем разница между ними?

компилятор особо не старается заинлайнить инлайнабл функцию, чтоб правилам были доступны внутренности для обработки правилами, но внутренности сохраняются для обработки правилами, как и в случае инлайн функций

правда, можно по мемту применения решить чтоб инлайнабл работал как инлайн для данного конкретного применения функции, есть "магическая" функция inline

чот пока не въехал во всю эту магию

ну есть некое пространство решений

мы можем сохранить разверку в неизменном виде, чтоб правила могли работать с внутренностями функции, но оптимизировать мы будем потом n по месту применения можем сначала оптимизировать одни внутренности, а потом сохранить в HI для дальнейшего использования, оптимизировать придется меньше, но правилам зацепиться не за что можем не сохранять развертки дакже отдельно мы можем принимать решения инлайнить по месту определения или по обстоятельствам по месту применения в хаскеле нет способа проаннотировать это все так ясно и поотдельности

есть набор каких-то мутных прагм которые называются примерно одинаково, ключей и автоматики у которой свои эвристики когда и что делать

в смысле не принимать решение инлайнить по месту определения, а принимать решение по месту определения, будем ли инлайнить на месте применения

Открыл issue на добавление бенча про форматтинг: * https://github.com/andrewthad/chronos/issues/22 Да, это именно та библиотека, которую я имел в виду! Видел твит, что там человек бенчи реализовывал. Печально, конечно, что там только парсинг. Мне пока ни разу не приходилось парсить время, бенчи для форматирования были бы более полезными...

я использовал thyme но мне нужно было представление в int64 и просто начал его раньше чем Хроно использовать

в смысле не принимать решение инлайнить по месту определения, а принимать решение по месту определения, будем ли инлайнить на месте применения

для этого одна и таже прагма?

что-то в хроне не понравилось но на увроне байкшеддинга

для этого одна и таже прагма?

есть inline inlineable specialize

первое говорит заинлайнь всегда

второе - сохрани развертку

третье сгенерируй специализацию и сохрани

для первого есть модификаторы когда оно срабатывает

третье сгенерируй специализацию и сохрани

это как?

лучше бы они inlinable назвали specializable

но я не знаю ни одного живого человека который умеет этим пользоваться и объяснить

это как?

есть полиморфная функция, ты ее инстанциируешь конкретным типом и сохраняешь полученный обьект

тогда если в другом модуле компилятор встретит такую же специализацию он возьмёт готовый код

просто вчера у Кметта была ошибка, и он сделал инлайн и ошибка еще более специфицировалась

ошибка компилятора или в программе?

inline на тайпчеккер не влияет никак

ну, можно написать такие правила перезаписи, что будет влиять

inline или правила?

и.е. если заинлайнилось то правило перепишет во что-то другого типа?

{-# RULES "foo inlined" foo = bogus #-}

?

можно же делать так чтоб получался нетайпчекающийся код если правило не сработало это описанная техника, обычно так правда не делают

тогда если foo не заинлайнено, то ошибка будет?

похоже на то, что выше?

только нужно сделать чтобы стреляло только на 0

вроде того, да

также обсуждается еще один способ сделать так чтоб что-то без инлайна не тайпчекалось

СПЖ в некоторых обсуждениях левити-полиморфизма предлагает использовать существующий механизм специализации для того чтоб генерить несколько версий кода левити полиморфного объявления

и Лин типы туда же

СПЖ в некоторых обсуждениях левити-полиморфизма предлагает использовать существующий механизм специализации для того чтоб генерить несколько версий кода левити полиморфного объявления

ничё не знаю про левити, а взрыва комбинаторного не будет?

ничё не знаю про левити, а взрыва комбинаторного не будет?

Так СПЖ так и обосновывает, мол, на практике при специализации взрыва нет, так и тут не будет

к тому же, по умолчнанию выводятся лифтед типы, т.е. пользователю такой фичи придется писать страшные сигнатуры, которые он будет писать пока они ему нужны

т.е. куча функций левити полиморфными не станут просто потому что программисту наплевать какие они там будут