ну, в первую очередь спорили про динамическую типизацию

так вот он может выдавать очень оптимальный машинный код

Вообще-то нет. Вообще-то типизация имеет околонулевое отношение к производительности. Статическая типизация «всего лишь» означает, что проверка type soundness происходит во время компиляции, в тех же плюсах в рантайме можно творить просто чудеса с типами с минимальным пенальти, не говоря уже о том, что в момент исполнения информация о типах уже утеряна. Так же нет никаких потерь производительности, обусловленных динамической типизацией - Lua тому очень яркий пример.

Тем не менее луа точно так же проигрывает всем классическим статически типизированным языкам

ну, в первую очередь спорили про динамическую типизацию

Про ФП и динамическую типизацию вместе

ну, он в том числе фп

очень даже

два срача в одном: динамика против статики, и что считать фп, а что нет)))

ну, он в том числе фп

Ну он сильно менее ФП, чем та же кложура с которой все и началось.

а по каким признакам это определяется?

а по каким признакам это определяется?

Ну насколько я помню cl, в нём кардинально меньший упор идёт на иммутабельность, чем в кложуре.

а кто мешает иммутабельные структуры использовать

Тем не менее луа точно так же проигрывает всем классическим статически типизированным языкам

так наверно оттого, что он интерпретируется?

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

так наверно оттого, что он интерпретируется?

компилятор

steelbank common lisp

я про него конкретно

так наверно оттого, что он интерпретируется?

Он с jit компилятором

почему называются тогда lua scripts

Жесткую статическую вестимо.

Ну я бы не называл это типами. Там скорее размеры данных

почему называются тогда lua scripts

а, я думал ты про CL

ну я хз, что там сливает типизированным языкам

наверное скрипты, ну то не диво

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

что-то мне кажется оно всё несколько по другому. Вот например нужно вызвать метод какого-то объекта. В статически типизированном языке почти всегда сразу известен адрес кода который нужно выполнить, а в динамически типизированном его еще нужно найти в рантайме

Ну я бы не называл это типами. Там скорее размеры данных

Богатым этот набор типов не назовешь. Но на этом уровне что есть то есть

common lisp. если заморочится, то можно сравнимой с си производительности добиться

Это если сишник не заморачивается

ну я хз, что там сливает типизированным языкам

Любая динамика сливает статике по производительности при всех прочих равных.

Гибкость имеет свою цену

https://i.gyazo.com/6fdcffcc521a6eae4afc659cdee3aae7.png > приятный синтакстис Надеюсь это ты не про скалу

Мне вот так нравится, ещё более ML'но.

Кек https://skillbox.ru/media/code/chto_vybrat_novichku_c_ili_f/

Любая динамика сливает статике по производительности при всех прочих равных.

это да. но тут как раз нюанс бывает, что "прочие не равны"

это да. но тут как раз нюанс бывает, что "прочие не равны"

И эти прочие бывают неравны в любую сторону.

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

Мне вот так нравится, ещё более ML'но.

Ну и куда же без pipeline operator.

Как ReadOnlySequence.Slice записать в Memory/Span?

🤔

@dolfik, а что ты пишешь?

Сокет сервер

На пайпах и вот этом вот всём

Короче

Берешь буфер

let receive() = async { do! Async.SwitchToThreadPool() match getState() with | Connected c -> try let reader = c.Input match! (read reader) with | Ok result -> let buf=result.Buffer if(buf.Length > 0L) then let length = 4L + (result.Buffer.Slice(0,4).ToArray()|>Seg|>toInt|>fst|>int64) // trace<| sprintf "buffer size %i ,expected length %i" buf.Length length if (length <= result.Buffer.Length) then trace<| sprintf "Message received. Length=%i" length parse (result.Buffer.Slice(0L,length).ToArray()|>Seg)|>Async.Start reader.AdvanceTo(result.Buffer.GetPosition(length)) else reader.AdvanceTo(result.Buffer.Start) | Error exn -> trace exn.Message trace exn.StackTrace setState Disconnected with exn-> trace exn.StackTrace trace exn.Message setState Disconnected |_ -> () }

Код из реального проекта

Как ReadOnlySequence.Slice записать в Memory/Span?

Ну для начала записывать его в спан нет смысла, слайс и есть спан. В мемори - копирнуть

Вот самое лучшее что я нашел =)

ToArray это экстеншн метод

Вот самое лучшее что я нашел =)

Ну вот да. Учитывая что мемори стрим по сути массив, то проще сразу в массив копирнуть

Вот мне что-то ToArray не нравится

ну ридонли сиквенс это не массив, а массив массивов)

ну ридонли сиквенс это не массив, а массив массивов)

Я про Memory<>

Вот мне что-то ToArray не нравится

По причине?

Вот мне что-то ToArray не нравится

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

Только надо помнить про волшебный параметр resumeWriterTreshold

В пайпах

Он по умолчанию 32к

По причине?

было бы круто читать не копируя)

Я себе так ногу отстрелил

было бы круто читать не копируя)

Это как, простите?

было бы круто читать не копируя)

В память между тредами?

Дичь какая

По причине?

Он же копирование выполнит, не?

Он же копирование выполнит, не?

Естественно

Он же копирование выполнит, не?

Короче

Дольфик

Посмотри еще на ArrayPool.Shared

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

В память между тредами?

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

Хочется сделать zero alloc

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

SequenceReader есть в третьем коре, но пока не вникал

Посмотри еще на ArrayPool.Shared

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

У вас читатель из сокета - обычно отдельный тред. Если вы читаете из консумера - вы не очень. Пошарить результат чтения с консумером через стек читателя невозможно. Но можно через стек консумера (стакаллок перед полингом и через аут параметр отдаем в консумера) Или через хип

SequenceReader есть в третьем коре, но пока не вникал

воу! не знал)

@neftedollar я же покекать принес

У вас читатель из сокета - обычно отдельный тред. Если вы читаете из консумера - вы не очень. Пошарить результат чтения с консумером через стек читателя невозможно. Но можно через стек консумера (стакаллок перед полингом и через аут параметр отдаем в консумера) Или через хип

у нас читатель это PipeReader который после прочтения выдает ReadOnlySequence который вполне можно самому разбирать, но до 3го кора это было крайне неудобно, проще всего ToArray()

@neftedollar я же покекать принес

ну вот ты покекал, а убирать кто будет?

у нас читатель это PipeReader который после прочтения выдает ReadOnlySequence который вполне можно самому разбирать, но до 3го кора это было крайне неудобно, проще всего ToArray()

Там нельзя свой буфер указать?

Там нельзя свой буфер указать?

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

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

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

Короче, лучше аррэйПул да

ну вот ты покекал, а убирать кто будет?