у меня ещё тут в haskell сегфолт, воспроизводящийся только на одной системе и не моей при том

но в итоге светлое будущее с Rust откладывается, походу

что-то он выглядит бледно

причем сегфолтится ghc при TH

что-то он выглядит бледно

так там вроде все без unsafe было

так что с чтением coredump тоже будут проблемы, т.к. надо весь ghc пересобирать

а зачем в этой задаче unsafe?

в лучшей сишке операции только safe в терминах раста

читаем данные, делаем вектор оступов и вектор длин, вроде в rust это называется slice?

причем не 2 а один

дальше 2 цикла (итератора в терминах раста)

в одном по четным в другом по нечетным элементам

складываем слайсы в buffer

вызываем write_all когда перестает влезать

а чё раст? по-моему лучшую сишечку можно на расте сделать чтоб было то же самое

ну, не сделали

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

ага

а ну разве memcpy хак в расте сложнее

да моя вроде тоже сейф - я там попробовал идею с чанками фиксированного размера в unboxed vector как я его себе (неправильно) представлял

чисто техническая задача

мне интересно можно ли ещё хаскелл ускорить

мне тоже

получается, что основная засада это реализация буферизации вывода

мало того, стандартные io буфера не работают

я думаю если сделать unboxed вектор отступов то можно

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

ну мы упарывались дня 2 на куче языков

они упарывались 1-1.5 дня на одном

ну мы упарывались дня 2 на куче языков

с субботы вы упарывались, уже не два дня)

ну, куча это два

правда нас больше

ну не фуллтам же.

хз, ощущение что фултайм)

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

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

@optician_owl а это т.к. людей много

один уйдет, другой что-то пишет

@qnikst быстрее всего будет даже не список буферов для ввода, а char **pages , которому делать как раз realloc

на haskell bytestring все таки дорогой, это ForeignPointer и финализатором (возможно пустым) и всеми делами

@voidlizard наверное

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

в haskell отступы + длины + нужно навеное свой Builder для таких данных

rawMem :: ByteString -> Offset -> Size -> Builder

но это будет си какое-то

надо посмотреть, сколько на хаскелле занимает парсинг до момента вывода

мало или нет. было мало, но я уже не помню, насколько мало

в моей версии оно "перемешано"

мы ж каждый раз парсим

на хаскеле?

да

а, у тебя там список строк

vector

но мы его сразу консьюмим

поэтому не должен огорчать gc особо

да там и gc огорчается на копейки

т.е вдвое увеличить размер ввода - и это всё уже терятся на фоне времени вывода

о как

можно ещё попробовать fastBuilder переписать немного

чтобы hPutBuffer получше сделать

или уже свою либу писать по мотива длиннопасты вчера

надо бы её куда-нить перенести, чтобы не потерять

смешно если IRL это всё бессмысленно, т.к. упрётся в скорость консюмера

и поэтому этот ввод-вывод никого не парит

хотя в серверах это важно, наверное

я подозреваю что именно так

вот тогда vmsplice полезен наверное

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

но на примерах с md5 и tee у меня плохо все было

кстати tee забавный

им броадкаст дешево делать

можно посылаемое отдать ведру и оно не будет его копировать а само refcount поддерживать будет

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

где-то я видел, что когда будет записано 2*(размер буффера)

но это какой-то ad-hoc

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

и все это в разы уступает лучшей версии на си

конкретно раст - в четыре раза

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

да, похоже на хорошее резюме