Сейчас освобожусь и гляну

Time 0: 1 μs value: [536870912, 0] Time 1: 9 hnsecs value: [268435456, 268435456]

https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D0%BC%D0%BE%D1%82%D0%BA%D0%B0_%D1%86%D0%B8%D0%BA%D0%BB%D0%B0

Это старый очень пример с циклами

На стаковерфлоу полно народу, орущего что java быстрее C. Потом им говорят добавить - O2 или -O3 и сразу становится не быстрее

Так это фишка LLVM выходит?

Так это фишка LLVM выходит?

Скорее всего да, в LLVM встроена

А получается что в go нет такой оптимизации? )

вообще это распространённая оптимизация

А получается что в go нет такой оптимизации? )

это странно, на самом деле

я уверен, что и в DMD она есть

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

На стаковерфлоу полно народу, орущего что java быстрее C. Потом им говорят добавить - O2 или -O3 и сразу становится не быстрее

Это понятное дело

Я о том, что GO этого (это оптимизирование) не сделало (не умеет)

Я ж не говорю что я написал сверх круто

Я и написал, что LLVM ОЧЕНЬ круто оптимизирует

Я о том, что GO этого (это оптимизирование) не сделало (не умеет)

вот в Go вообще не шарю, какие там опции у оптимизатора есть

И я такой: да, это крутой оптимизатор!

вот в Go вообще не шарю, какие там опции у оптимизатора есть

Та я включал все что смог

Не вышел каменный цветок...

ldc2 test.d

а dmd со включенным оптимизатором что показывает?

Ну кстати, ldc2 объективно код лучше компилит. Это бесспорно

dmd -release test.d ./test 1 Time 0: 778 ms, 798 μs, and 3 hnsecs value: [536870912, 0] Time 1: 443 ms, 360 μs, and 3 hnsecs value: [268435456, 268435456]

dmd -O -release -inline -boundscheck=off test.d

Time 0: 192 ms, 880 μs, and 5 hnsecs value: [536870912, 0] Time 1: 427 ms, 12 μs, and 3 hnsecs value: [268435456, 268435456]

Пошустрее ГО даже вышло

да сомневаюсь что dmd может обогнать ldc в чем-то. llvm пилят достаточно народу что-бы насовать туда кучу оптимизаций

да сомневаюсь что dmd может обогнать ldc в чем-то. llvm пилят достаточно народу что-бы насовать туда кучу оптимизаций

Может, в одном

В имплиментации своих фич))))

Они там раньше появляются)))

Но не более того

А у Go компилятор свой?

с другой стороны я вот наступаю на ошибки под osx в ldc

то что работает с dmd валится с ldc под osx и не валится под линухом

А у Go компилятор свой?

Да

А у Go компилятор свой?

Самое удивительное что он не использует libc, там своя реализация

И своя реализация ssl

Поэтому они легко собираются в единый бинарник

А... вот это новость. Я все никак не мог понять как они с блокирующими операциями борятся

Короче получается стоит слинковаться с сишной либой которая блокирующая так сразу все прелести Го улетучатся?

Ну как-то в вопросе много обобщений.

как я понимаю libc реализует все низкоуровневые системные вызовы. Обращение к сетевым подсистемам и диковый io верно?

Если так то получается в Go все они заменены на неблокирующие аналоги

libc это обёртка над системными вызовами (что касается работы с системой)

она сама мало что реализует в этом плане. максимум - “подгоняет” поведение системы под какой-то стандарт

насколько я понимаю

Если так то получается в Go все они заменены на неблокирующие аналоги

Нет, неблокирующую работу можно сделать и поверх libc

Нет, неблокирующую работу можно сделать и поверх libc

а как? Типа колбеки какие-то юзать?

Нет, неблокирующую работу можно сделать и поверх libc

кажется не всего

Ну как vibe-core делает

кажется не всего

Я уверен что almost всего

а как? Типа колбеки какие-то юзать?

Ты понимаешь что неблокирующие вызовы это всего лишь очень быстрое переключение маленьких блокирующих системных функций? =)

угу

Ну вот.

Так, но если у Go своя реализация, значит не получилось поверх либси сделать неблокирующуие операции

Так, но если у Go своя реализация, значит не получилось поверх либси сделать неблокирующуие операции

мне кажется это одна из причин

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

я бы на D тоже отказался от glibc

был бы ресурс это сделать)

а минусы отказа о libc какие?

ну она уже написанна

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

В rust когда надо слинковать glibc статически, то его заменяют неким musl

musl немного медленнее glibc

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

нет, вот условно в го изобрели свою либси мне не понятно какие минусы это принесло

нет, вот условно в го изобрели свою либси мне не понятно какие минусы это принесло

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

бинарник больше

но, мне кажется это не важно

кто-то сталкивался с таким код дампом? Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5e05487 in fputc_unlocked () from /usr/lib/libc.so.6 gdb bt #0 0x00007ffff5e05487 in fputc_unlocked () from /usr/lib/libc.so.6 #1 0x000055555560b1ae in std.stdio.File.LockingTextWriter.put!(char).put(char).trustedFPUTC(int, core.stdc.stdio._IO_FILE*) () #2 0x00007ffff77c31ef in std.stdio.File.LockingTextWriter.put!(char).put(char) () from ./lib/libvibe-d_core.so #3 0x00007ffff774c058 in std.range.primitives.doPut!(std.stdio.File.LockingTextWriter, char).doPut(ref std.stdio.File.LockingTextWriter, ref char) () from ./lib/libvibe-d_core.so #4 0x00007ffff774c03c in std.range.primitives.put!(std.stdio.File.LockingTextWriter, char).put(ref std.stdio.File.LockingTextWriter, char) () from ./lib/libvibe-d_core.so #5 0x00007ffff77c3c7b in std.stdio.File.write!(char).write(char) () from ./lib/libvibe-d_core.so #6 0x00007ffff77c3c0f in std.stdio.File.writeln!().writeln() () from ./lib/libvibe-d_core.so #7 0x00007ffff7797eaf in vibe.core.log.FileLogger.endLine() () from ./lib/libvibe-d_core.so #8 0x00007ffff779908a in vibe.core.log.LogOutputRange.finalize() () from ./lib/libvibe-d_core.so #9 0x00005555555f5089 in vibe.core.log.log!(4, "src/main.d", 28, immutable(char)[]).log(immutable(char)[]) () #10 0x00005555555f4f88 in vibe.core.log.logInfo!("src/main.d", 28, immutable(char)[]).logInfo(immutable(char)[]) () #11 0x00005555555e8394 in D main () раніше этот бинарки работал, но однажды упал и больше работать не хочет

Небось dmd проапдейтил)

Небось dmd проапдейтил)

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

в общем понял, что валится на logInfo("Server started!") из vibe.core.log; но почему - не понял. вроде как с файлами проблема, может прав не хватает

segfault это по любому проблема в компиляторе

segfault это по любому проблема в компиляторе

если без logInfo собрать, то печатает и к монге конектит. т.е. не может компилятор vibe.core.log внедрить?

попробуйте в другой файл логировать

или запустите под strace

попробуйте в другой файл логировать

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

или запустите под strace

execve("./client", ["./client"], [/* 20 vars */]) = 0 brk(NULL) = 0x5628875ad000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) в этом проблема видимо, не хватает системных библиотек? хотя наверне нет, почитал, что только для старых актуально. у меня 16.04 убунта

не думаю что в этом

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

open("./lib/tls/x86_64/libphobos2.so.0.71", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("./lib/tls/libphobos2.so.0.71", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("./lib/x86_64/libphobos2.so.0.71", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) это может?

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

этот файл есть, но он и правда не по тем адресам, а просто в ./lib

в общем понял, что валится на logInfo("Server started!") из vibe.core.log; но почему - не понял. вроде как с файлами проблема, может прав не хватает

А, вайб

Обнови вайб

Потому, что вайб при каждом новом dmd фиксят

Обнови вайб

ок, попробую

пните, пожалуйста, как из сорсов вайба собрать бинарники всех библиотек?

пните, пожалуйста, как из сорсов вайба собрать бинарники всех библиотек?

это dub сам должен делать

это dub сам должен делать

какая-то ошибка вылазит и вообще вроде же еще способ есть?

что бы в итоге .so либы получились

ты используешь vibe в проекте, собираешь dub'ом, он распахивает собранные статические либы по своим путям

что бы в итоге .so либы получились

вообще любой проект на dub собрать можно dub build командой

надо находиться в папке с dub.json

Так же можно посмотреть есть ли конфигурация сборки динамических библиотек

это написано может быть в dub.json так же

ок, спасибо, попробую

Уже вторник, а срача все нет...