https://gist.github.com/yellow-apple/69993c04f8d9afc0d72c56f27e55187f int bufcap = 120000; char *buf = malloc(bufcap); int buflen; // тут нужен = 0

о блин

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

нет конечно

хотя нет, сложно, чексуммы не совпадают

SML, в отличие от Окамля, вызывает C-функции напрямую

в этой конкретной задаче непрерывые куски по 5 байт, sse кажется не поможет, даже dword за раз копировать смысла нет

8 символов за раз копировать

а сдвиг на реальную длину делать, если запас есть

splice для чтения отдачи в fd (хотя я не уверен, что это так работает)

на сколько меня там обогнали, процентов 10 уже есть?

Да окамл у меня тормозит, 9 сек

но я не окамлист, одна надежда, у кого-нибудь бомбанет и он перепишет

на сколько меня там обогнали, процентов 10 уже есть?

на моем тракторе: 0.867s vs 1.158s, но у меня макось и clang, так что на линухах может и по-другому все

$ time ./1 < ./49zGQ6Zt.txt > /dev/null real 0m0.800s user 0m0.796s sys 0m0.002s $ time ./2 < ./49zGQ6Zt.txt > /dev/null real 0m0.726s user 0m0.708s sys 0m0.007s $ time ./3 < ./49zGQ6Zt.txt > /dev/null real 0m1.278s user 0m1.256s sys 0m0.008s gcc -O2 —------- $ time ./1 < ./49zGQ6Zt.txt > /dev/null real 0m1.314s user 0m1.282s sys 0m0.007s $ time ./2 < ./49zGQ6Zt.txt > /dev/null real 0m0.716s user 0m0.703s sys 0m0.006s $ time ./3 < ./49zGQ6Zt.txt > /dev/null real 0m0.905s user 0m0.902s sys 0m0.001s clang -O3

open Batteries let lns = IO.lines_of IO.stdin |> Enum.map (String.split_on_char ' ') |> Array.of_enum let ps = Array.map (fun (x::_) -> x) lns let ss = Array.map (fun (_::x::_) -> x) lns let () = ps |> Array.iter (fun p -> ss |> Array.iter (fun s -> IO.nwrite IO.stdout p; IO.write_line IO.stdout s )) но тут опять какой-то лишний перенос строки в конце или что-то вроде

$ ocamlbuild -r -use-ocamlfind -pkgs 'batteries' 'bso.native' -tag 'optimize(3)'

4.04.0+flambda

Попробуйте скопмилировать один и тот же .c-файл через gcc и g++ и сравнить производительность того, что та выходе. У меня в 2014 был кусок кода, который после g++ работал быстрее

Хотя, казалось бы

эффекта от оптимизатора незаметно

В 1поточном режиме с оптимизирующим компилятором он должен быть близок к С и Расту по скорости, а по времени написания к Хаскелю.

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

какие там резервы по оптимизации ещё остались? в сишке

наверно можно попробовать с restrict поиграться, но у меня из-за этого пока только ухудшалось

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

Я не эксперт, но может попробовать без батареек?

джейнстритовскими либами чтоли?

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

offset_map.c у меня 0.98 моё 0.60

-O3

лучше достать какую-нибудь задачу поbynthtcytt, с какого нибудь advent of code

лучше haskell доразогнать и либы дописать если надо

просто в си играться не интересно

вообще не понимаю, как в на нем пишете, я читать себя не могу заставить

А какие-то summary по всей этой специальной олимпиаде есть?

https://gist.github.com/voidlizard/c736e3d7fcd382c6f9904f8b653102b5#file-special-olympics-md

Не - безо всего

этож окамл, там ничего юзабельного "без всего" нету

как и в хаскеле, собственно, если не хуже

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

кстати насчет более сложной программы

сейчас си дошёл до очень интересного уровня

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

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

но очень жалко времени

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

небольшой

и на окамле также можно сделать, кстати, там ио можно передавать слайс массива

@kir я в си так делаю

И совать '\0' сразу после слова, а потом через strcpy собирать буфер.

читаем вход в свой буффер с realloc, после этого собираем длины и смещения

\0 не надо b strcopy не надо

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

strncpy?

нет, это медленее

strcpy проверяет на \0

а мы это уже сделали

наверно можно попробовать с restrict поиграться, но у меня из-за этого пока только ухудшалось

можешь еще манипуляции над vmsplice попробовать

Да, я забыл про memmove

вот, ещё один человек говорит про vmsplice!

маловероятно что кто-то

Что дальше? FORTH? K? APL?

на куде?

J?

GPU shaders?

J?

Его бы тоже стоило

Еще R и APL

а у кого есть практический опыт со сплайсами?

куда дальше-то где sml? опять чтоли мне писать?

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

C SML падажжы, процесс идёт

т.е. со сплайсами аллоцируем страницу дампим туда, потом vmsplice(stdout,page_size,1,SPLICE_F_GIFT)?

а там можно даже много сегментов давать

о, ваще!

а почему с vmsplice будет быстрее? Кернелогуру, расскажите.

_поидее_ если там с gift то страница тупо отдается ядру

и меньше копирований между буфферами и ядроспейсом

может гуру честно расскажут

м

а если в ринг 0 запустить

на практике я не знаю, ни разу не использовал

splice() moves data between two file descriptors without copying between kernel address space and user address space. It transfers up to len bytes of data from the file descriptor fd_in to the file descriptor fd_out, where one of the file descriptors must refer to a pipe.

вот что ман сплайса говорит

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

да