форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
Сообщение от opennews (??) on 24-Апр-16, 10:50
Бразильский разработчик Леандро Перейра (Leandro Pereira) из Intel Open Source Technology Center развивает новый легковесный http-сервер Lwan (https://lwan.ws/), нацеленный на минимальное потребление ресурсов и поддерживающий отдачу как статического, так и динамического контента. Lwan может использовать обособленно или в форме встраиваемой библиотеки. Разработка Lwan началась четыре года назад в форме персонального исследовательского проекта, нацеленного на изучение методов многопоточной обработки данных и неблокирующего ввода. Код проекта написан на языке Си и распространяется (https://github.com/lpereira/lwan) под лицензией GPLv2+. Поддерживается работа в Linux и FreeBSD. Сервер включает встроенный движок-шаблонизатор  Mustache (https://mustache.github.io/), поддерживает подключение обработчиков контента, написанных на языках Си и Lua, и предоставляет API для разработки интегрированных с http-сервером web-приложений и для создания дополнений, расширяющих возможности http-сервера. Lwan поддерживает протоколы HTTP/1.0, HTTP/1.1 (с поддержкой keep-alive и pipelined) и PROXY, для перенаправления запросов применяется сопоставление по шаблонам Lua (http://www.lua.org/manual/5.2/manual.html#6.4.1). Для асинхронной обработки соединений используются сопрограммы, выполнение которых координируется встроенным планировщиком совместной многозадачности, что позволяет создать иллюзию блокирующего ввода/вывода для обработчиков запросов. Сервер обеспечивает минимальное потребление памяти и минимизирует число системных вызовов, операций копирования и распределения памяти. Например, для 10 тысяч ожидающих обработки соединений расходуется около 500 Кб ОЗУ. Размер исполняемого файла составляет 110 Кб. В зависимости от размера файла выбирается оптимальный метод его отдачи, например, для файлов больше 16 Кб не используется прямая отдача без промежуточного копирования в пространство пользователя, а для небольших файлов применяется векторизированный ввод/вывод из созданных через mmap буферов. URL: https://lwan.ws/ Новость: http://www.opennet.me/opennews/art.shtml?num=44301
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–2 +/–
Сообщение от Аноним (??) on 24-Апр-16, 10:50
На гоу это занимало бы мегабайт 30.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–17 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 12:00
	Не сравнивайте разные вещи, на go идет самодостаточный бинарник, а этот бинарник на C требует glibc, а он потянет больше чем 30 мегабайт в итоге.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	9. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+5 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 12:23
	Вот же врунишка! "Hello world" с оф.сайт (первый) в статике весит меньше метра! shell> cc -Wall -Werror -I$HOME/local/include/lwan -L$HOME/local/lib hello.c -llwan-common -lz shell> file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped shell> cc -v Using built-in specs. COLLECT_GCC=cc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i586-alpine-linux-musl/5.3.0/lto-wrapper Target: i586-alpine-linux-musl Configured with: /home/buildozer/aports/main/gcc/src/gcc-5.3.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --build=i586-alpine-linux-musl --host=i586-alpine-linux-musl --target=i586-alpine-linux-musl --with-pkgversion='Alpine 5.3.0' --enable-checking=release --disable-fixed-point --disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror --disable-symvers --enable-__cxa_atexit --enable-esp --enable-cloog-backend --enable-languages=c,c++,objc,java,fortran,ada --with-arch=i586 --with-tune=generic --enable-cld --disable-libssp --disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads --enable-tls --with-system-zlib Thread model: posix gcc version 5.3.0 (Alpine 5.3.0) shell> ls -lh a.out -rwx------ 1 xxx users 769K Apr 24 12:18 a.out* shell> strip a.out shell> ls -lh a.out -rwx------ 1 xxx users 246K Apr 24 12:21 a.out* -- Иди ***зди в другом месте, школьник! Тебе здесь не рады.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	13. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от angra (ok) on 24-Апр-16, 12:34
	Ты забыл продемонстрировать главное - его работу без libc.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	15. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Олег (??) on 24-Апр-16, 12:55
	А ты забыл что go тоже требует libc: $ readelf -d .. .. 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	17. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от 8203 on 24-Апр-16, 13:13
	-tags netgo
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	35. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от angra (ok) on 24-Апр-16, 15:17
	$ go build hw.go $ readelf -d hw There is no dynamic section in this file. $ ldd hw     not a dynamic executable А не лжец ли ты?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	54. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:24
	А как насчет размером похвастаться? Что, "хелловордишко" на 5 метров всего получается, а если побольше логики сунуть то либрофис начинает отдыхать? Гугл вообще тормозное блоатваре умеет, у них серверов много. Их даже питон не парил, до поры до времени.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	60. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от angra (ok) on 24-Апр-16, 17:46
	Если очень хочется, то держи 35236  hw_gccgo Динамическая линковка Go 71884  hw_cpp Динамическая линковка C++ 1948696 hw_go Статическая линковка Go 1415286 hw_cpp_static Статическая линковка C++ При этом заметь, я вообще не сравнивал Go с С по возможностям или встроенный http модуль Go с сабжем. Просто указал на некоторые... неточности.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	85. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–2 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 22:34
	Крутое сравнение. Кода нет, флагов сборки нет, какие-то цифры. Видимо на слово предлагается поверить. Ну так вот, эксперт: на encode.ru народ в секции оффтопика развлекался тем кто crush (упаковщик такой, lempel-ziv довольно сильный, С++) меньше соберет. Ну так вот, мистер: линуксовй ELF утрамбовали в 3 килобайта, а виндовый PE EXE - в 2 с чем-то. А там серьезный match finder, неплохо руливший в свое время и прочее. Я правда только до 12 килобайтов догнался стандартными средствами gcc, в основном за счет секций. Так что если у тебя хелловорлд в 70 кил - у тебя рукожопие и ты не умеешь gcc пользоваться. От слова вообще.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	101. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+3 +/–
	Сообщение от Аноним (??) on 25-Апр-16, 06:10
	Владелец encode.ru, проследуйте на свой ресурс.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	105. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 25-Апр-16, 10:16
	> Владелец encode.ru, проследуйте на свой ресурс. Очень жаль что я не его владелец. Потому что специалистов там в отличие от - много. С мировыми именами. Там можно повстречать и Charles Bloom-а, и Matt Mahoney, известных своими "учебниками", Yann Collett известного своими алгоритмами, ряд россиян известных своими наработками. Кто интересовался сжатием - видел эти имена. В учебниках и вокруг. А между делом специалисты не против позажигать. Когда за дело берется эксперт, результат за себя говорит сам. Понятное дело что тебе возразить нечего, остается только посылать.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	112. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от angra (ok) on 25-Апр-16, 14:00
	Когда грубо сравниваются разные программы, то умные и честные люди их сравнивают в дефолтных настройках. Можешь пойти и рассказать авторам gсс и ментейнерам debian, что у них всех рукожопие и их дефолты не позволяют С++ однозначно выиграть у Go идиотское соревнование на минимальность размера бинаря. Кстати, в приведенном примере динамической линковки для Go сборка выполнялась используя gccgo, то есть в конечном итоге через тот же gcc.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	136. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 26-Апр-16, 16:11
	> Когда грубо сравниваются разные программы, то умные и честные люди их сравнивают > в дефолтных настройках. А кто тебя знает что ты считаешь "дефолтными настройками". По дефолту сишный компилер обычно оптимизаций не делает (-O0), потому что так дебажить проще. Но никто в здравом уме не кладет дебажный билд в пакеты для юзеров. > Можешь пойти и рассказать авторам gсс и ментейнерам debian, что у них всех рукожопие Тут в пору говорить про скудоумие. Майнтайнеры дебиана билдуют с отличными от дефолтов gcc опциями. У кого -O2, а у кого -O3, как у LZ4, где скорость - его все, а может быть и -Os, как у лисообразных браузеров. > и их дефолты не позволяют С++ однозначно выиграть у Go идиотское соревнование Так gcc'ом никто не компилит с дефолтами, кроме ГОпников типа тебя. У дебиана и вовсе есть мощные механизмы для применения "недефолтных" флагов на автомате. Но такие как ты не в курсе этих вещей, но мнение уже имеют. За что и получают заслуженную репутацию ламерюг. > Кстати, в приведенном примере динамической линковки для Go сборка выполнялась используя > gccgo, то есть в конечном итоге через тот же gcc. Какую практическую ценность представляет твое оторванное от жизни сравнение? Никто не билдует реальные программы gcc'ом без флагов. Особенно майнтайнеры дебиана при пакетировании.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	59. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:43
	Ой щи. Ребята, вы хоть прокачайтесь в изучении вопроса о компиляции! Вот эта строчка: >a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped Равносильна: >There is no dynamic section in this file. Потому что называется _статической_ линковкой. Однако, для glibc все что слинкованно с -lpthread всеравно требует наличия рантайм библиотек, в частности того же libc.so и librt.so, libpthread.so! Потому что кто-то слишком палится, что его код кто-то сопрет.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	65. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от angra (ok) on 24-Апр-16, 17:54
	Поэтому я и сказал о необходимости продемонстрировать работоспособность без libc. А то некоторые не знают, что статически слинковать ее недостаточно и вообще делать это настоятельно не рекомендуется. Справедливости ради там был приведен пример линковки не с glibc, а с musl, которая якобы более дружественна к статической линковке. Но во-первых, это был уход в сторону от поднятого вопроса, а во-вторых, опять таки требует доказательства полной работоспособности, так как musl сама по себе не полностью совместима с glibc.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	68. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 18:09
	Вот лови: poc/lwan> readelf -d a.out There is no dynamic section in this file. poc/lwan> ./a.out Loading configuration file: a.out.conf. Could not read config file, using defaults. Using 2 threads, maximum 2048 sockets per thread. Listening on http://127.0.0.1:8080. Ready to serve. ^Z[1] + Stopped              ./a.out poc/lwan> kill -CONT %1 poc/lwan> j [1] +  6804 Running              ./a.out poc/lwan> telnet localhost 8080 GET HTTP1.0 / HTTP/1.1 400 Bad request Content-Length: 1124 Content-Type: text/html Connection: close Date: Sun, 24 Apr 2016 15:04:56 GMT Expires: Sun, 01 May 2016 15:04:56 GMT Server: lwan <html... [OPENNET не дает постить html-таги о_О] ^C Console escape. Commands are: l      go to line mode c      go to character mode z      suspend telnet e      exit telnet poc/lwan> -- И больше не ****ди. Хочешь поставить под сомнение мнения людей: проверяй сам, а не уклоняйся как некоторые про "без libc". Без libc вебсервер нынче фуфло полное, т.к. ни libmagic, ни libpng, ни libgd, ни libMYSQL и прочее-прочее НЕ запустить. Бери сервер на асме, чо, запускай его на фряшке, если осилишь, ссыль внизу дали.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	70. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от angra (ok) on 24-Апр-16, 18:13
	Похоже ты так и не понял, о чем речь шла.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	72. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–2 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 18:20
	>Похоже ты так и не понял, о чем речь шла. И о чем же? Что для тебя выражение "без libc"? Я так понял это когда прога собрана со статичной линковкой, а readelf/ldd и прочие пишут, что "нет динамических символов". Для нормального программиста без libc это когда у тебя нету никаких заголовочных файлов в /usr/include из стандартной библиотеки Си и у тебя все компилируется, а бинарник работает. Да, в Си есть 32 встроенные функции и на них можно написать _любое_ приложение с 0 (НУЛЬ) зависимостями, даже stdio.h или string.h не понадобятся! Объясни, что ты хотел мне донести, пожалуйста, слушаю.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	78. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от angra (ok) on 24-Апр-16, 20:14
	Это значит, что приложениие будет работать при удалении _из системы_ glibc, например созданием контейнера, состоящего только из самого приложения. Несмотря на то, что ты слинковал glibc статически, часть ее функций требует наличия shared glibc в системе, причем желательно близкой версии. Важный момент - часть функций. То есть все будет хорошо только до тех пор, пока не дошло до их вызова. А значит для доказательства полноценной работоспособности со статической линковкой glibc мало показать факт запуска приложения при удаленной из системы glibc, надо еще убедится, что оно работает во всех возможных ситуациях. Именно по этому с glibc и не рекомендуется линковаться статически при написании портируемых бинарей под линукс. Вместо этого минимизируется требуемая версия glibc.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	81. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 21:55
	Ты это проверял лично? Или просто трындишь надеясь на свою правоту? >созданием контейнера Что это? Какой еще нафиг гхонтейнер? Вот, запихнул в чтрут, где нет libc: shell> mkdir 4noobs shell> mkdir 4noobs/etc shell> cp /etc/hosts 4noobs/etc/ shell> cp /etc/resolv.conf  4noobs/etc/ shell> cp /bin/busybox busybox         busybox.static shell> cp /bin/busybox.static  4noobs/ shell> mkdir 4noobs/bin shell> cp /bin/busybox.static 4noobs/bin/ shell> cp a.out 4noobs/ shell> mkdir 4noobs/proc shell> mount -t proc /proc 4noobs/proc shell> cd 4noobs/bin shell> ln -s busybox.static sh shell> ln -s busybox.static ls shell> cd - /home/xxx/devel/c/poc/lwan shell> chroot 4noobs/ /bin/sh shell> ls a.out  bin    etc    proc shell> ./a.out Loading configuration file: a.out.conf. Could not read config file, using defaults. Using 2 threads, maximum 2048 sockets per thread. Listening on http://127.0.0.1:8080. Ready to serve. ^Z[1]+  Stopped                    ./a.out shell> kill -CONT %1 shell> ls -lh total 720 -rwx------    1 0        100       768.1K Apr 24 18:49 a.out drwxr-sr-x    2 0        100         4.0K Apr 24 18:50 bin drwxr-sr-x    2 0        100         4.0K Apr 24 18:48 etc dr-xr-xr-x   85 0        30             0 Apr 24 18:41 proc shell> И в другой консольке: ~> telnet localhost 8080 GET / HTTP/1.0 HTTP/1.0 200 OK Content-Length: 13 Content-Type: text/plain Connection: close Date: Sun, 24 Apr 2016 18:53:35 GMT Expires: Sun, 01 May 2016 18:53:35 GMT Server: lwan Hello, World! --- А теперь ты все это доказываешь мне для своего любимого golang. Вперед!
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	83. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от angra (ok) on 24-Апр-16, 22:16
	Не, ты реально безнадежен. Специально ведь подчеркнул ключевые моменты, но ты опять ничего не понял.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	84. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–2 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 22:20
	Давай мне утилиту для проверки как ты сказал всех моментов. Или слабо отвечать за свои слова? Вот как ты узнал, что твой сервак на go работает "без libc"? Поверил? Продолжай и дальше верить. Чем больше человек верит, тем легче им управлять.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	86. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–2 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 22:36
	И что ты втираешь мне все про glibc? Как это связано с кодом lwan или с кодом golang? Что, только чуваки из golang умеют собирать бинари "без libc"? Да, точно. Они, наверное, боги. А кругом все остальные п****ры, и ты, самый главный из их числа. Все что я тебе выдал собрано gcc + musl. И свои отговорки "musl это читерство, хны-хны" засунь себе куда подальше! Вобщем, вместо того, чтобы вести себя как мужик и четко понимать о чем говоришь, ты поешь как бабка из пятого подъезда. Где-то что-то услышал, где что-то увидел, но вот проверить лично что да как, у тебя ума нет. Можешь ничего не отвечать и дальше переходить на личности, рано или поздно жизнь научит тебя отвечать за слова.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	87. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–2 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 22:45
	> Это значит, что приложениие будет работать при удалении _из системы_ glibc, например > созданием контейнера, состоящего только из самого приложения. Дядя, ты совсем дубак? Представь себе, если программа слинкована статически - она и libc в себя влинковывает! Статически!
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	94. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 23:54
	>Представь себе, если программа слинкована статически - она и libc в себя влинковывает! Не совсем. Ребята из glibc постарались сделать так, что librt требует рантайм либ даже при статической линковке. Просто чтобы код не воровали: они запихнули в него подобие dlopen() Увы, аппонент не удосужился прочесть код lwan, чтобы увидеть, что никакие подобные вызовы он не содержит, но продолжает свято верить, что golang это божественное произведение, а все что не на golang написано по определению работает не так, криво и вообще там все сломано. Конечно, проверить, что он не прав -- лень.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	107. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от angra (ok) on 25-Апр-16, 10:53
	> Не совсем. Ребята из glibc постарались сделать так, что librt требует рантайм > либ даже при статической линковке. Есть и другие проблемные функции. > Увы, аппонент не удосужился прочесть код lwan, чтобы увидеть, что никакие подобные > вызовы он не содержит Можно узнать, зачем _мне_ нужно читать код lwan? Я никаких утверждений на его счет вообще не делал. Только указывал на глупости и вранье других по поводу линковки в С и Go. , но продолжает свято верить, что golang это > божественное произведение, а все что не на golang написано по определению > работает не так, криво и вообще там все сломано. Признайся честно, какие вещества употреблял, когда такое увидел в треде? Попробуй перечитать, когда тебя попустит.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	127. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 25-Апр-16, 22:49
	>Можно узнать, зачем _мне_ нужно читать код lwan? Я никаких утверждений на его счет вообще не делал. Сообщение 4.13, цитирую: >Ты забыл продемонстрировать главное - его работу без libc. Ты это, завязывай с пустословием пока пацанов совсем не расстроил. Я тебе все продемонстрировал. Ты даже hello world не прочитал: а там всего лишь один GET используется и все мои тесты/замеры укладываются в твои "все возможные ситуации" и не вызывают функций, о которых ты трясешься. Как теперь будешь отмазываться, а? Снова скажешь, что я что-то не понял? Из нас двоих ты не понимаешь главное: за базар надо отвечать и если не прав, то извинятся, как мужик. Запомни ты не идеален, когда придет время камня или пули, ты же не увернешься, а всего-то нужно было извиниться.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	114. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 25-Апр-16, 15:35
	> Не совсем. Ребята из glibc постарались сделать так, что librt требует рантайм > либ даже при статической линковке. В сях можно хоть -nostdlib сказать и дальше сам как хочешь реализуй. Можно также другой libc взять, если нужно.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	133. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 26-Апр-16, 11:41
	> Не совсем. Ребята из glibc постарались сделать так, что librt требует рантайм > либ даже при статической линковке. Просто чтобы код не воровали: они > запихнули в него подобие dlopen() Странное решение. Тем не менее, для "runtime-less" окружений в C навалом опций, поэтому если это становится принципиально - сишник всегда свое возьмет. Гопный хипстер напрасно полез быковать в этом плане. Пусть на своем гопнике напишет бутлоадер какй-нибудь, когда 40-метровую стандартную либу технически некуда впихнуть и нет ничего, ни printf ни malloc, пока сам не напишешь, если нужны. Технически, сишечка - что-то типа умного кроссплатформенного ассемблера, а любые либы - вообще опция. Чисто-алгоритмический код даже на системные вызовы не полагается. А что, гопники смогут написать код работаюший в окружении где syscalls вообще нету? Если да - ок, тогда мы с этим гопом будем говорить на равных. А до тех пор у него нос не дорос пальцы так растопыривать, он лишь показал себя некомпетентным бддлокодером. > Увы, аппонент не удосужился прочесть код lwan, чтобы увидеть, что никакие подобные > вызовы он не содержит, но продолжает свято верить, что golang это > божественное произведение, Язык нашел свою аудиторию - вебные бддлокодеры, которым эта смесь js и питона как раз самое оно.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	99. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Алконим on 25-Апр-16, 03:22
	У меня статически слинкованая програма на Го, которую я скомпилил на Федоре, отказалась работать в докере в контейнере с Alpine — упала в корку. Почему — не разбирался, я её скомпили в Alpine и просто забил на Го. В конце концов статическая линковка с glibc вынуждает сменить лицензию, а musl — глючный тормоз.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	115. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 25-Апр-16, 15:38
	Сэр отпинал всех, от go до musl. Хорошо, а как это делать правильно по мнению сэра? Или сэр разочаровался в программировании и занялся садоводством?
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	45. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 16:48
	> "Hello world" с оф.сайт (первый) в статике весит меньше метра! А тут весь сервак 110 кил. И без затуплений из-за GC :)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	21. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 14:00
	А питон +500 мб. Нужно просто правильно инструмент выбирать.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	41. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 16:21
	> А питон +500 мб. Нужно просто правильно инструмент выбирать. Очередной "не слышал, не знаю, но мое мнение таково …" Tinypy > implementation of python in 64k of code впрочем,  неясно, причем тут вообще питон …
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	46. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+2 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 16:50
	>> implementation of python in 64k of code А он по славной питоновской традиции как обычно половину скриптов выполнять не сможет? А то что сможет - будет ползать с известной скоростью, как обычно? Динамический язык вообще сложно скомпилить, только субсет. А если jit - годогенерация опять же тормозит и памяти много трескает.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	67. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Нимано on 24-Апр-16, 18:09
	> А он по славной питоновской традиции как обычно половину скриптов выполнять не > сможет? И че? Вам шашечки (выполнять любые скрипты) или ехать (конкретное приложение, т.е. в этом случае http)? > А то что сможет - будет ползать с известной скоростью, Анонимам не угодишь. > Динамический язык вообще сложно скомпилить, только субсет. Нет. Динамичный язык компилять не сложно. Сложно найти динамичный (не игрушечный) язык, который бы не компилялся как минимум в байткод. Ну и сложно "втиснуть" динамичность в такие рамки, чтобы компиляция в "нативный код"  стала действительно эффективной, а не просто эдаким "захардкоженным" аналогом интерпретатора. Поэтому и получается "эффективная" (в смысле скорости выполнения конечного результата) компиляция в основном для подмножества языка. > А если jit - годогенерация опять же тормозит и памяти много трескает. Т.е. скомпилировать "классическим" методом невозможно, но зато Just In Time домкраты тормозят, память трескают, но исправно компиляют не только подмножество стремительных механизмов для подъема тяжестей? o_O. Не, я понимаю, что одно упоминание питона вызывает у вас какие-то очень неприятные воспоминания и соответствующую реакцию, но все же – на счет питона, это вам все же в соседнюю ветку, в новость про пай-пай.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	89. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 23:24
	> И че? Вам шашечки (выполнять любые скрипты) или ехать > (конкретное приложение, т.е. в этом случае http)? Только скорость и потребление ресурсов будет раз в 50 хуже. До оптимизации системных вызовов как в lwan дело не дойдет. Какой смысл уменьшать количество системных вызовов, если большинство команд идущих в проц - логика интерпретатора, а не программы? > Анонимам не угодишь. Мы в состоянии отличить скрипткидиса от программиста. Даже и не пытайся, твой сраный код этой штуке не конкурент даже теоретически. Иди лохов на бирже разводи, если конкуренция на бирже еще не напрягает. > Нет. Динамичный язык компилять не сложно. Сложно найти динамичный (не игрушечный) язык, > который бы не компилялся как минимум в байткод. Байткод может быть и всего лишь более компактной заменой ключевых слов. Это не отменяет нужды его интерпретировать. Проблемы начинаются когда хочется сгенерить машинный код (посмотри в вике что это). Поскольку язык ДИНАМИЧЕСКИЙ, заранее все рассчитать становится очень нетривиально и вместо компилятора начинает требоваться AI, способный осознать что делает эта программа. В частности как она может менять типы во всех возможных случаях, а если там еще и что-то типа eval() есть - надо к программе еще и компилятор весь подшить, бонусом. Как максимум - или jit делают, со своими проблемами, или компилируют статичски типизированный субсет, где все сильно упрощается. > Ну и сложно "втиснуть" динамичность в такие рамки, чтобы компиляция в "нативный > код"  стала действительно эффективной, а не просто эдаким "захардкоженным" аналогом > интерпретатора. Поздравляю, дошло. Более того - даже когда это нативный код (JIT например) - ему придется делать множество проверок не изменился ли тип и что там еще. Если речь зашла о оптимизации количества системных вызовов как в сабже - это априори не будет конкурентом такой штуке.   > Т.е. скомпилировать "классическим" методом невозможно, но зато Just In Time домкраты тормозят, > память трескают, но исправно компиляют не только подмножество стремительных механизмов > для подъема тяжестей? o_O. Jit делают достаточно сложный анализ в рантайме и кодогенерацию. Все это и проца прилично требует и памяти кушает очень даже. В скомпилированных программах все это тоже было, но 1 раз и на этапе компиляции. Которую, возвожно, вообще другой компьтер производил. А в jit сам изволь, еще и с превышением. > Не, я понимаю, что одно упоминание питона вызывает у вас какие-то очень > неприятные воспоминания и соответствующую реакцию, но все же – на счет > питона, это вам все же в соседнюю ветку, в новость про пай-пай. Это вы тут с какими-то "приложениями" приперлись. При том что на питоне они заведомо не конкурент штуке где дошло дело до оптимизации системных вызовов.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	98. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Нимано on 25-Апр-16, 03:00
	Сами что-то придумали, сам опровергли – молодца! ) > Байткод может быть и всего лишь более компактной заменой ключевых слов. Это > не отменяет нужды его интерпретировать. А может быть, вы определитесь – нельзя компилировать или все же генерировать "эффективный  машинный код"? Как хорошо, что вы забыли (после того как не знали), иначе наверняка и микрокод приплели бы (посмотрите в вашей любимой википедии что это такое, причем тут интерпретация и каким боком все это относится к "машинному"). А то очень смахивает на попытку объяснить попадание пятой точки в лужу желанием принять грязевую ванну. ) > Проблемы начинаются когда хочется сгенерить машинный > код (посмотри в вике что это). Кстати, википедия в этом особо не поможет, тут желательно что-то типа http://www.intel.com/content/www/us/en/architecture-and-tech... ну, с поправкой на архитектуру. А то боюсь, что с помощью википедии вы много не нагенеруете. > Поскольку язык ДИНАМИЧЕСКИЙ, заранее все > ... > проблемами, или компилируют статичски типизированный субсет, где все сильно упрощается.   >> стала действительно эффективной, а не просто эдаким "захардкоженным" аналогом интерпретатора. > Поздравляю, дошло. А, классический Отвечатель  –  прочел кусочек, ответил. Прочел следующий, ответил. Это многое объясняет. > Более того - даже когда это нативный код (JIT например) > - ему придется делать множество проверок не изменился ли тип и > что там еще. Угу, "сторожей" приставляют, чтобы отлавливать все новые типы, присылаемые из параллельной вселенной. А так все верно, да! >> Т.е. скомпилировать "классическим" методом невозможно, но зато Just In Time домкраты тормозят, > Jit делают достаточно сложный анализ в рантайме и кодогенерацию. Т.е. до кое-кого так и не дошло, что Just In Time компилятор таки все же компилятор? Н-да. > Это вы тут с какими-то "приложениями" приперлись. При том что на питоне > они заведомо не конкурент штуке где дошло дело до оптимизации системных > вызовов. Хорошо наверное быть Отвечателем –  взял и придумал себе что-то, а потом и ответил, позорно посрамив всех неведомых врагов! )
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	116. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 25-Апр-16, 16:10
	> Сами что-то придумали, сам опровергли – молодца! ) Тут было явно более одного анонима и думали они по разному, однако. > А может быть, вы определитесь – нельзя компилировать или все же генерировать > "эффективный  машинный код"? От "компиляции" в байткод нету толка - избавляет от неэффективного парсинга строк, но байткод все-равно интерпретируется. В результате выполняемых CPU большинство команд - код интерпретатора. Служебная сущность, вообще не формирует логику программы. > такое, причем тут интерпретация и каким боком все это относится к "машинному"). Важно вот что: логика программы либо представляется в виде машинных команд, которые напрямую выполняются на CPU, не разбавленные побочными вещами - тогда быстро. Либо это не происходит, со всеми вытекающими. > А то очень смахивает на попытку объяснить попадание пятой точки в лужу > желанием принять грязевую ванну. ) Я и не сомневался что у тебя жгло пониже спины, вот и принимаешь грязевые ваны. За километр видно питониста, выгораживающего фетиш. > http://www.intel.com/content/www/us/en/architecture-and-tech.../ Читать на интеле про процессоры вообще - несколько однобоко. Так что попытка понта не удалась, иди охлаждай пятую точку в воде уже. > ну, с поправкой на архитектуру. А то боюсь, что с помощью википедии > вы много не нагенеруете. Википедия даст общую идею. А конкретику реализации - это уже у производителя разумеется. > А, классический Отвечатель Ну ты то вообще классический бугуртовщик, да еще и гонщик к тому же. Пытаешься сосватать байткод как эквивалент машинного кода. Ага, щазззз, дубаков нет. > Угу, "сторожей" приставляют, чтобы отлавливать все новые типы, присылаемые из > параллельной вселенной. А так все верно, да! Тюринг доказал что одна программа (в нашем случае компилятор) не может проанализировать другую программу (в нашем случае то что програмер нагенерил) и вынести определенный вердикт (в нашем случае - о том изменится ли тип). С какими-то оговорками и ограничениями наверное можно попробовать проскочить, но это глюкоопасно, т.к. программер может делать все что угодно в пределах возможностей языка. И предусмотреть вообще все обычно невозможно. Поэтому jit обычно явно проверяет - не меняется ли тип. Это разбавляет код программы кучей проверок. А в машинном коде многие вещи могут быть и как логическая или арифметическая операция напрямую. Есть большая разница: сложить r1 и r2 в которых было 2 и 3 и получить 5 за 1 такт процессора, или потратить еще уйму тактов на проверки какие там типы у кого были и что должно получиться. Поэтому даже лучшие jit легко проигрывают нативному коду в 2.5-5 раз. > Т.е. до кое-кого так и не дошло, что Just In Time компилятор > таки все же компилятор? Н-да. Обычно он компилятор только наполовину, с большими оговорками. Т.е. самые горячие куски перегоняются в машинный код, а остальное интерпретируется. К тому же jit не может тратить столько же ресурсов как компилятор на компиляцию. Одно дело если компилятор будет 2 минуты оптимизировать код в compile time, и совсем другое - если jit встрянет на  2 минуты в run time. И даже так - из-за динамичности производительность оказывается ниже и к тому же не постоянная. Ну то-есть про реальное время, даже самое лажовенькое, можно сразу забыть. Нормальное ограничениьице: программа не может нормально взаимодействовать с реальным миром и процессами в нем, а так все хорошо. Ну в общем сойдет для лагучей вебни. И все. > Хорошо наверное быть Отвечателем –  взял и придумал себе что-то, а > потом и ответил, позорно посрамив всех неведомых врагов! ) Да зачем вас срамить? Вы сами гораздо лучше справляетесь.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	124. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–3 +/–
	Сообщение от Нимано on 25-Апр-16, 20:03
	> Тут было явно более одного анонима и думали они по разному, однако. Ну да, писать из под анонима так удобно – если что, то "это не я сел в лужу! Это другой аноним!" Только вот проблемка, пока что _каждый_ из этих анонимов, не исключая конретно вас, такого красивого, порол знатную чушь ) >> А может быть, вы определитесь – нельзя компилировать или все же генерировать >> "эффективный  машинный код"? > От "компиляции" в байткод нету толка - избавляет от неэффективного парсинга строк, > но байткод все-равно интерпретируется. Открою вам страшную тайну (вернее, повторю свой прервый постинг) – байткод совсем необязателен. Зайдите в  гугол и найдите всякие трансляторы питона в С++, Си и т.д. Там зачастую никаким байткодом и близко не пользовались.  А еще расскажите об отсутствие толка всяких промежуточных кодов гццшникам со шлагновщиками – а то они, болезные, не знают об этом. Ну да, куда им до анонимов опеннета! ) Просто особого профита от этого нет (разжевывать лень, но если вы хотя бы немного знаете тот же Си, подумайте на досуге, как можно поместить в один массив несколько различных типов данных, что для этого нужно и какие у такого подхода могут быть минусы), но никаких бредовых идей типа > заранее все рассчитать становится очень нетривиально и вместо компилятора > начинает требоваться AI, способный осознать что делает эта программа. не требуется ) > Важно вот что: логика программы либо представляется в виде машинных команд, которые > напрямую выполняются на CPU, Очень точная формулировка! ) Хотя, чего я ожидал от анонимов. У одного JIT компилятор вовсе и не компилятор. У другого, генерированием машинных кодов для "динамических типов" должен заниматься ИИ,  иначе мол, все очень не тривиально (т.е. по сути оказывается в Си нельзя сделать массив с разными типами, особенно, если хранить там данные, введенные пользователем – ведь нельзя будет предсказать тип конкретного элемента, а значит нужен ИИ, способный осознать! Иначе низя! О как!). Третий вообще умудрился Тюринга к выводу типов приткнуть и сделать какие-то свои, анонимные выводы. Правда, начисто проигнорировав ключевое слово "cторож"/guard. А уж компиляторы у него и половинчатые бывают *рукалицо* > За километр видно питониста, выгораживающего фетиш. О как, оказывается это я упорно несу бред, понтуясь набором "вумных слов" ) >> http://www.intel.com/content/www/us/en/architecture-and-tech.../ >> ну, с поправкой на архитектуру. > Читать на интеле про процессоры вообще - несколько однобоко. Так что попытка > понта не удалась, иди охлаждай пятую точку в воде уже. Проигнорировать часть предложения даже для вас слишком уж жирно. Тоньше нужно быть, тоньше. А если бы я захотел попонтоваться, то упомянул бы, что 4 томика "от интеля" у меня на книжной полке стоят. Так что мимо. ) > Ну ты то вообще классический бугуртовщик, да еще и гонщик к тому > же. Громче и чаще, авось кто поверит. Заодно и от лажи отвлечет =) > Пытаешься сосватать байткод как эквивалент машинного кода. Неа, читайте внимательнее! Я же не аноним, чтобы с умным видом нести чепуху. >> Угу, "сторожей" приставляют, чтобы отлавливать все новые типы, присылаемые из >> параллельной вселенной. А так все верно, да! > Тюринг доказал что одна программа (в нашем случае компилятор) Умудриться приплести Тюринга к типам  – и при этом проигнорировать ключевое слово "сторож"/guard  – это сильно. А я ведь специально "подставился", так как, если пытаться копать в сторону джитов чуть глубже википедии, то пройти мимо guard-ов очень сложно. В общем, все ясно с вами – слышали где-то звон и решили понтанутся. Понт окончился очередной грязевой ванной ) > Есть большая разница: сложить r1 и > r2 в которых было 2 и 3 и получить 5 за > 1 такт процессора, или потратить еще уйму тактов на проверки какие > там типы у кого были и что должно получиться. Какой бред^W шедевр! И все это с умным и уверенным видом! Еще, пишите еще! ) > Обычно он компилятор только наполовину, Ну да, а еще наверняка есть "половинная беременность" – это когда с большими оговорками … Я так понимаю, копать и уточнять в эту сторону бесполезно, т.к. у анонимов свое, собственное понимание этого термина, да еще и меняющееся от случая к случаю. > К тому же jit не может тратить столько же ресурсов как компилятор на компиляцию. А мусью в курсе, зачем компиляют в байткод и какие это дает возможности? А о разных "уровнях" оптимизации? Хотя, откуда. У одного анонима это вообще "замена ключевых слов", у  (конечно же) другого от оного "толка нет", просто "избавляет от неэффективного парсинга строк". Ну анонимы опеннета у нас известные знатоки, которые еще и ребят из гцц или шланга компиляторы писать поучат! ) > И даже так - из-за динамичности производительность оказывается > ниже и к тому же не постоянная. Ну то-есть про реальное > время, даже самое лажовенькое, можно сразу забыть. Еще один шедевр. YMMD! =) Оказывается динамичность виновата, о как! Значит glibc (и еще куча имплементаций cтандартной библиотеки) в общем и malloc/free в частности вполне подходит для использования в "реальном времени" ? Нормально. > Да зачем вас срамить? Вы сами гораздо лучше справляетесь. Пишите еще! Жду с нетерпением дальнейших "посрамлений" )
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	135. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 26-Апр-16, 15:28
	> "это не я сел в лужу! Это другой аноним!" А еще анонимы могут подключаться к дискуссии если у них есть возражения. У лолок от этого развивается мания преследования, что вызывает много лулзов. > вас, такого красивого, порол знатную чушь ) В тред врывается Д'Артаньян! Как шаблонно, фи. > Открою вам страшную тайну (вернее, повторю свой прервый постинг) – байткод совсем > необязателен. Зайдите в  гугол и найдите всякие трансляторы питона в С++, Си и т.д. И узнайте о том что они умеют сильно урезаный поддиалект? ;) > Там зачастую никаким байткодом и близко не пользовались. Обычно там делают ограничения и поддерживают только часть языка. Неудобно это - динамически типизированный язык в статически типизированный транслировать. Теоретически возможно, практически - надо реализовать проверки типов и прочее. Код густо разбавляется и чуда не происходит. Поэтому соревнуются с 1929 годом^W^W интерпретатором. > А еще расскажите об отсутствие толка всяких промежуточных кодов > гццшникам со шлагновщиками – а то они, болезные, не знают об этом. > Ну да, куда им до анонимов опеннета! ) Зачем у них промежуточные коды - еще можно понять. Но это внутренние сущности. Они мало кого интересуют кроме авторов компилятра. Остальных интересует как работает программа. Тут то и будет облом. Хоть так эмить проверки типов, хоть эдак. Они будут. Это главное. В лучшем случае оптимизатор может попроовать что-то удалить, с понятным успехом. Лучший способ помочь оптимизатору - не подваливать ему лишней работы. > поместить в один массив несколько различных типов данных, У современных процессоров операции регистр-регистр быстрые, за 1 такт даже несколько операций может произойти. А обращение к массиву - шанс нарваться на доступ в RAM и отдохнуть. У быстрых процессоров это до сотен тактов. Есть кэш, но будет ли это cache hit... если ты все будешь в массивы пхать - не будет! Если программа и рабочий набор уместилась в кэш, скорость работы может подскочить в РАЗЫ. На современных процах по этой причине unroll loop'ов может себя и не оправдать. Экономия на jmp в конце цикла может убиться усилением cache miss из-за разжирения кода. Быстрый код должен быть маленьким и работать с компактными наборами данных, иначе он будет выносить кэш и станет медленным. > что для этого нужно и какие у такого подхода могут быть минусы), но никаких > бредовых идей типа Идея напихать все в массивы, не адресуемые напрямую с такой же скоростью как регистры да еще и норовящие осесть в медленной RAM, агрессивно затирая кэш - гениально, чё. > не требуется ) Ну это ты просто не видел как программа разгоняется разиков в 5 "на ровном месте", если ты в кэш смог уместиться. Вот и предлагаешь способы улучшения thrashing кэша. > Очень точная формулировка! ) > Хотя, чего я ожидал от анонимов. Не знаю как там анонимы, а лично ты показал что не понимаешь архитектуру процессоров. Процессорные ядра сильно обгоняют RAM у всего что сложнее микроконтроллера (и даже у некоторых мк). А ты предлагашь способы засорения кэша. Будет очень производительно, даже не сомневайся. > У другого, генерированием машинных кодов для "динамических типов" должен заниматься ИИ, Это был бы самый быстрый и эффективный способ. Я ж не ты, заведомо провальную канитель с массивами не посоветую. {...спам...} > элемента, а значит нужен ИИ, способный осознать! Иначе низя! О как!). Советовать заведомо фэйловые решения типа бреда с массивами - твоя привилегия. > анонимные выводы. Правда, начисто проигнорировав ключевое слово "cторож"/guard. Да хоть горшком называй проверки изменений типов, на результат не влияет. > О как, оказывается это я упорно несу бред, понтуясь набором "вумных слов" ) Не только. Ты еще слился на полном непонимании стомости операций у современных CPU, что такое кэш и все такое. > Проигнорировать часть предложения даже для вас слишком уж жирно. Тоньше нужно быть, тоньше. Зачем быть тонким с кадром, который не понимает основ кэширования но машет интеловским маном? Ты более тонко не заметишь с таким то умищем. > А если бы я захотел попонтоваться, то упомянул бы, что 4 томика > "от интеля" у меня на книжной полке стоят. Так что мимо. ) Используешь как груз для засолки? Иначе не понятно как ты ухитрился пройти мимо процессорных кэшей, регистровых операций и быть настолько не в курсе стоимости процессорных операций, что предлагаешь заведомо провальные решения. > Громче и чаще, авось кто поверит. Заодно и от лажи отвлечет =) Ты так задорно зажигаешь что аудитория уже задолжала анонимам за билеты в цирк. > Неа, читайте внимательнее! Я же не аноним, чтобы с умным видом нести чепуху. Если ты так настаиваешь...  ок, теперь ты не аноним ;). > Умудриться приплести Тюринга к типам  – и при этом проигнорировать ключевое > слово "сторож"/guard  – это сильно. А подумать головой о том что "сторож" было включен в более общее понятие "проверки типов" - это для таких как ты слишком сложно? Понимаешь ли, когда операция регистр-регистр делается за такт, по сравнению с этим вообще любое лишнее трепыхание - дорогое. Как его ни обзови, даже если ты уложишься в еще 1 такт - таки падение скорости в 2 раза. > А я ведь специально "подставился", Что-то слишком хорошо сыграл по части кэшей и прочих массивов. Не верю что ты настолько талантливый актер. > Понт окончился очередной грязевой ванной ) Так вылезай из лужи, чудак. И не грози южному централу, попивая сок у себя в квартале. > Ну да, а еще наверняка есть "половинная беременность" – это когда с > большими оговорками … А мир вообще не черно белый, бывают всякие гибридные подходы. Jit один из них. >> К тому же jit не может тратить столько же ресурсов как компилятор на компиляцию. > А мусью в курсе, зачем компиляют в байткод и какие это дает возможности? Да, однако в конечном итоге нас интересует качество машинного кода на энной платформе. Тяжелые оптимизации - ресурсоемкие, jit не может позволить себе стать полноценной билдфермой. С соответствующими последствиями для качества кода. Если хочется тяжелые оптимизации, AOT уместнее. Его реалтайм не жмет, потребление ресурсов менее критично т.к. еще не делится с работающей программой, а там где этого надо хорошо и много - может быть сделано другим компьютером, мощным и крутым, то что для смартфонного проца 10 минут, для мощного билдсервера - секунд 20. Но он и воздух греет в других объемах. Jit так не может. > А о разных "уровнях" оптимизации? > Хотя, откуда. Да куда нам, анонимам, чай пить. > У одного анонима это вообще "замена ключевых слов", у  (конечно же) > другого от оного "толка нет", просто "избавляет от неэффективного парсинга строк". У дефолтного питона оно как-то так вроде и реализовано - питон интерпретирует этот байткод, медленно и печально. > гцц или шланга компиляторы писать поучат! ) Эти то промежуточными кодами пользуются поумнее дефолтного питона. Но это вообще их внутренние сущности, остальных они мало интересуют. > Еще один шедевр. YMMD! =) > Оказывается динамичность виновата, о как! Она такому состоянию дел дополнительно способствует. Добиться того чтобы конструкции языка транслировались в нечто простое, легкое и предсказуемое - не так то просто. И да, в сишечке я могу и посмотреть во что моя конструкция реально разложилась в виде машинного кода и я смогу довольно хорошо просчитать что будет и может быть. А что, сможешь так же круто заинструментировать jit? Ты кстати ничего не сказал про overcommit или latency, если уж мы про время. > Значит glibc (и еще куча имплементаций cтандартной библиотеки) в общем и malloc/free > в частности вполне подходит для использования в "реальном времени" ? Нормально. В си можно работать и без libc, и без выделения памяти malloc'ом. Как тебе такой оборот? На си с полоборота пишут загрузчики и ядра, которые работают когда файловой системы, управления памятью и прочих malloc еще и в проекте нет. Зарубиться с таким инструментарием в вопросе предсказуемости операций - ну попробуй. > Пишите еще! Жду с нетерпением дальнейших "посрамлений" ) Ну если ты так настаиваешь...
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	137. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–2 +/–
	Сообщение от Нимано_ on 26-Апр-16, 20:19
	О, четвертый (или пятый?) "другой аноним!" подключился. > А еще анонимы могут подключаться к дискуссии если у них есть возражения. Ну да, и знатно садиться в лужу. Все как всегда. Вы бы хоть номерки добавляли, чтобы вас различать можно было. >> Зайдите в  гугол и найдите всякие трансляторы питона в С++, Си и т.д. > И узнайте о том что они умеют сильно урезаный поддиалект? ;) Т.е. та же nuitka умеет уже только сильно урезанный диалект? Ну окай. ЧуЙствуется очередной Эксперт. > Неудобно это -  динамически типизированный язык в статически типизированный транслировать. > Теоретически возможно, практически … О, хоть один из анонимов соизволил наконец прочитать мое первое сообщение и пересказать его мне же, своими словами? Гениально! Так держать! > Зачем у них промежуточные коды - еще можно понять. Но это внутренние > сущности. Они мало кого интересуют кроме авторов компилятра. Т.е. все же толк (о чем, как бы, и была речь) от них есть? >> подумайте на досуге, как можно >> поместить в один массив несколько различных типов данных > Быстрый код должен быть маленьким и работать Знатно вы свалили с темы и перевели стрелки, хотя с фантазией у вас все в порядке ) Или проблемы не только с чтением, но и с "думаньем"? Повторяю для тех, у кого проблемы с восприятием, речь шла о > подумайте на досуге, как можно поместить в один массив несколько различных типов данных т.к. по мнению какого-то из анонимов, "динамичность" нельзя нормально скомпилировать и требуется ИИ. > Идея напихать все в массивы, не адресуемые напрямую с такой же скоростью > как регистры да еще и норовящие осесть в медленной RAM, агрессивно > затирая кэш - гениально, чё. Молодец, домашнее задание засчитываю (хотя у вас и слишком много отсебятины), минусы вы осознали хорошо, а теперь, главный вопрос: что насчет возможностей? Можно так делать в Си или нельзя? Ведь там нет ИИ! > Вот и предлагаешь способы улучшения thrashing кэша. > {много вумных слов} > А ты предлагашь способы засорения > кэша. Будет очень производительно, даже не сомневайся. > Советовать заведомо фэйловые решения типа бреда с массивами - твоя привилегия. Какие бурные фантазии на ровном месте – Чтение явно не так хорошо дается Отвечателю, хотя вроде бы подвижки есть. Зато с фантазией все в порядке – придумал что-то, опроверг, доволен. Все в лучших традициях анонима ) >> анонимные выводы. Правда, начисто проигнорировав ключевое слово "cторож"/guard. > Да хоть горшком называй проверки изменений типов, на результат не влияет. Вообще, это был намек в сторону "появления новых типов". А то, если послушать анонимов, оные прям из ниоткуда берутся. Ну и заодно, простая и очевидная попытка подловить/проверка, наскольно анонимы "в теме" обсуждаемого – благо я тоже не первый раз на опеннет зашел. И, как мы видим – вполне сработало, анонимы один за другим упорно лажались ) Разясняю: Вот цитатка – в отличии от анонимов, у меня нет нужнды в подтасовках и бредовой отсебятины: >> ему придется делать множество проверок не изменился ли тип и что там еще. > Угу, "сторожей" приставляют, чтобы отлавливать все новые типы, Нормальный человек, который хоть немного "в теме" –  или сразу ответил бы, что де, так он и писал. Или сперва глянул и уточнил, а потом ответил. Благо, как уже упоминалось раннее, пройти мимо "guard"-ов  очень таки сложно. А знающий аноним мог бы вообще замусолить тему … Ну, или – вообще проигнорировать и не отвечать, даже если "в теме" – мало ли чему человек не придал значения, может ему влом перед очередным опеннетчкиком хлебные крошки метать. В общем, было бы вполне нормальное поведение. Но увы, это не про Анонимов. Анонимы, ничтоже сумняшеся опять затянули свою песнь про  типы,  да еще и пытались Тюринга к выводу оных приплести. Эпично. Т.е., как и подозревалось, нифига анонимы не знают, но пытаются пускать в глаза пыль умными словами. Вот и тут, у одного конкретного анонима guardы оказывается входят в более общее понятие "проверки типов". Прям хоть *рукалицо.жпг* делай — анонимам походу все божья роса ) > Не только. Ты еще слился на полном непонимании стомости операций у современных > CPU, что такое кэш и все такое. ... > Зачем быть тонким с кадром, который не понимает основ кэширования но машет > интеловским маном? Ты более тонко не заметишь с таким то умищем. Что, анонимы совсем отчаялись и пытаются использовать любой призрачный шанс? =) Хотя да, признаю, эпичная попытка перевода стрелок! Да и в фантазии вам не откажешь. Кстати, а пруфец где? А то очень похоже на очередное "сам придумал, сам опроверг, сам доволен". А так – только и остается задаться вопросом, как же у вас должно <эт-самое> пониже спины, чтобы так отчаянно пытаться высосать из домашнего задания для анонимов (для Отвечателей процитирую еще раз) > разжевывать лень, но если вы хотя бы немного знаете тот же Си, подумайте на досуге, > как можно поместить в один массив несколько различных типов данных, что для этого > нужно и какие у такого подхода могут быть минусы такую знатную и шикарную отсебятину ) Кстати, даже если опустить весь контекст предложения, то тот же " … какие могут у этого подхода быть минусы" кое-кто знатно профейлил. Когда советуют что-то, то обычно упоминают как минимум не только минусы, иначе назвать это советом могут только особо одаренные с сугубо альтернативно-анонимным пониманием всего и вся. > аудитория уже задолжала анонимам за билеты в цирк. Не очень удивительно, коль анонимы с таким упорством строят из себя клоунов-Покорителей-Луж, знатно и по нескольку раз лажаясь в каждом ответе ) =========================== > А подумать головой о том что "сторож" было включен в более общее > понятие "проверки типов" - это для таких как ты слишком сложно? А вот мы и добрались до очередного перла^W шедевра! ) Во первых, "осознали" вы это только после жирного намека, а вернее, разжевывания. И главное, во вторых: включение в «более общее понятие 'проверки типов'» вообще-то отдает очередной, сугубо личной верованием^W терминологией очередного анонима. Потому как у всех остальных, знакомых с темой не по википедии и собственным домыслам – проверка типов может входить в обязанность "сторожа". Но вот наоборот – ну никак нет. До этого, в принципе, даже самому дотумкать не сложно, а уж упоминаний этого … Но это же не про анонима, который мог  промолчать или быстренько уточнить – но предпочел <эт самое в лужу>. Зато с умным видом, да. Молодца! Так что, увы, очередная попытка спрыгнуть не удалась и вы опять расслабляетесь в лечебной грязи =) > Что-то слишком хорошо сыграл по части кэшей и прочих массивов. Не верю > что ты настолько талантливый актер. Давайте давайте, переводите стрелки, авось и получится разок ) >>> К тому же jit не может тратить столько же ресурсов как компилятор на компиляцию. >> А мусью в курсе, зачем компиляют в байткод и какие это дает возможности? > Да, однако в конечном итоге нас интересует качество машинного кода на энной > платформе. > много вумных слов > Jit так не может. Т.е. мусью как минимум про возможности не в курсе, но продолжает делать умный вид. Ясно. То, что конкретный jit чего-то не может, как бы вообще не показатель. Вон, те же разработчики жабоскрипто-ВМок например отнюдь не зря и по капризу левой пятки хотят "заиметь" байткод. >> А о разных "уровнях" оптимизации? >> Хотя, откуда. > Да куда нам, анонимам, чай пить. Ну вон, выше, анонимы были не в курсе преимуществ, которые может дать байтод (как раз из-за различных уровней/вариантов оптимизаций, причем львиная доля этих самых ресурсоемких оптимизаций особо от целевой машины не зависит) и исправно заладили про что-то, что якобы jit ну никак не может, ну и про нагрев воздуха не забыли – видимо наболело ) > В си можно работать и без libc, и без выделения памяти malloc'ом. > Как тебе такой оборот? Опять свинчивание с темы. Анонимы такие анонимы! А glibc у нас теперь на динамичном языке, да? Или почему его нельзя использовать? > Зарубиться с таким инструментарием в вопросе > предсказуемости операций - ну попробуй. Увы для вас, пробовал и даже в свое время вполне успешно "рубился" на "всех уровнях", вплоть до загрузчиков. Так что,  потоком вумных слов аноним пусть кого другого удивляет и от нахождения собственной пятой точки в микро-озере отвлекает ) > Ну если ты так настаиваешь... Спасибо, Маэстро Луж, вы опять были неповторимы! ЗЫ: молодца, взял и зарегистрировал ник. > Участник:    Нимано > ФИО:    Лох Педальный Ну да – крутой аргумент, прям слов нет. Знатно у вас припекает )
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	150. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 28-Апр-16, 10:48
	> Ну да, и знатно садиться в лужу. Все как всегда. Посадить меня в лужу может какой-нибудь сильный сишник. Как тот разработчик нжинкса. Ты для этого хиловат. > Вы бы хоть номерки добавляли, чтобы вас различать можно было. Если тебе хочется веселить публику - зачем мешать? > Т.е. та же nuitka умеет уже только сильно урезанный диалект? > Ну окай. ЧуЙствуется очередной Эксперт. Это вообще что-то внеклассовое. С технической точки зрения эта штука насколько я понимаю гибрид, где "простые" вещи компилируются трансляцией в си а сложные - интерпретируются, используя libpython. Достаточно оригиальный подход, однако я не понимаю чему оно противоречит и что ты доказал. > О, хоть один из анонимов соизволил наконец прочитать мое первое сообщение и > пересказать его мне же, своими словами? Гениально! Так держать! Да вы там всей толпой наспамили километр. > Т.е. все же толк (о чем, как бы, и была речь) от них есть? Толк от технологий есть там где они применены по делу и что-то привносят. Это не про .pyc файлы и их байткод, где сочетаются минусы и бинарей и интерпретаторов. > т.к. по мнению какого-то из анонимов, "динамичность" нельзя нормально скомпилировать и > требуется ИИ. Именно так. Ты конечно выжал из себя пример хитрозадого гибрида, но если ты обратишь внимание, там у них интерпретатор приволокли. > вы осознали хорошо, а теперь, главный вопрос: что насчет возможностей? Можно > так делать в Си или нельзя? Ведь там нет ИИ! ИИ требуется для того чтобы привести динамические типы в статические без выполнения кучи проверок в рантайме (интерпретатор в качестве решения проблемы - еще тяжеловеснее). Чтобы сложить 2 и 3 как эффективное "add r1, r2" - надо быть уверенным что r1 и r2 остаются именно integer'ами, и не превращаются, например, в строку. В этом месте Тюринг дает пендаль: чтобы получить эту уверенность путем предвычислений во время сборки, без кучи проверок в рантайме, надо быть AI. Сишникам с их типами (которые вообще фэйк) Тюринг тоже порой икается, по поводу чего есть "register", "volatile" и т.п.. > Все в лучших традициях анонима ) Да ты фигачь все массивами, посмотришь что получится. > Вообще, это был намек в сторону "появления новых типов". А то, если > послушать анонимов, оные прям из ниоткуда берутся. Откуда бы они ни брались, это подразумевает ряд действий. В рантайме. Т.е. замедление этого куска кода по сравнению с тривиальным add r1, r2, априори в разы. > И, как мы видим – вполне сработало, анонимы один за другим упорно лажались ) Ты тоже хорош, предложил какой-то дурацкий способ и доволен по уши. > Благо, как уже упоминалось раннее, пройти мимо "guard"-ов  очень таки сложно. Вот ежкин кот. Я сказал про проверки. Guard насколько я понимаю частный случай и есть. Тебя не смущает что это будут какие-то дополнительные действия, далекие от add r1, r2 для тех же integer'ов? > Но увы, это не про Анонимов. Анонимы, ничтоже сумняшеся опять затянули свою > песнь про  типы,  да еще и пытались Тюринга к выводу оных приплести. Эпично. Так ты покажи где в этой логике промах? > Т.е., как и подозревалось, нифига анонимы не знают, но пытаются пускать в > глаза пыль умными словами. По-моему я довольно фундаментальную проблему озвучил, какое-то следствие из Тюринга. Заранее просчитать в build time все варианты изменения типов в динамических ЯП невозможно. А рантайм-проверки - можно, но они замедляют выполнение, однако. С точки зрения оптимизации, предвычисление в build time гораздо лучше чем вычисления в run time. > guardы оказывается входят в более общее понятие "проверки типов". А что, не входят? ... > Что, анонимы совсем отчаялись и пытаются использовать любой призрачный шанс? =) Если оппонент затупляет - что ж поделать. > какие могут у этого подхода быть минусы" кое-кто знатно профейлил. Когда > советуют что-то, то обычно упоминают как минимум не только минусы, Не очень понятно о чем ты. Если ты про бидон - там даже видные участники сообщества признают что гвидобэйсик получился враждебным для оптимизаций. Динамическая типизация враждебна оптимизациям сама по себе - делать операции без существенного оверхеда в рантайме, посчитав какие типы будут заранее - мешает Тюринг. А приволочь интерпретатор или натыкать проверок - можно, но что насчет скорости? > включение в «более общее понятие 'проверки типов'» вообще-то отдает очередной, > сугубо личной верованием^W терминологией очередного анонима. Не к чему докопаться - займись буквоедством? Можешь еще орфографические ошибки поискать, дарю идею. > Так что, увы, очередная попытка спрыгнуть не удалась и вы опять расслабляетесь > в лечебной грязи =) Ты на этом так переклинен что это уже напоминает синдром утенка, чтоли. > Давайте давайте, переводите стрелки, авось и получится разок ) Это ты так намекаешь, что если технические аргументы закончились - нужно провести персональную атаку на оппонента? У тебя и это плохо получается. > То, что конкретный jit чего-то не может, как бы вообще не показатель. Это не "конкретный jit" а некий constraint: чем более качественный код мы хотим получить, тем больше времени надо потратить на анализ. Не уверен что есть строгая теория доказывающая это, но на практике вот так. Хорошо видно на примере скорости компиляции clang по версиям ;). > Вон, те же разработчики жабоскрипто-ВМок например отнюдь не зря и по > капризу левой пятки хотят "заиметь" байткод. Не той стороной, дядя Федор, бутерброд ешь. Они хотят заиметь нормальный IR. Не навязывающий динамическую типизацию, в отличие от JS, и позволяющий эффективную трансляцию в машинный код. Динамические типы гэ в плане оптимизации. Поверх низкоуровневго рантайма - можно сделать и динамические типы, если хочется. С оверхедом только у любителей динамических типов, без отравления жизни остальным. Это как раз нормальный шаг в сторону более вменяемого рантайма, не зависящего от ЯПов. > Ну вон, выше, анонимы были не в курсе преимуществ, которые может дать > байтод (как раз из-за различных уровней/вариантов оптимизаций, Питону это как мертвому припарки. Те кто посообразительнее, и кто на деньги из-за тормозняков попадает - уже сделали выводы. У гугля есть go, дропбокс в который там уже раз переписывают. Что-то showcases производительности превратились в failboat. > заладили про что-то, что якобы jit ну никак не может, ну > и про нагрев воздуха не забыли – видимо наболело ) Ты прав, JIT и даже AOT на стороне юзера - больная тема. Сомневаешься? Посмотри сколько времени .NET в винде после установки генерит сборки в нативном коде из абстрактного. Всего полдня лагания компа - и готово. >> В си можно работать и без libc, и без выделения памяти malloc'ом. >> Как тебе такой оборот? > Опять свинчивание с темы. Анонимы такие анонимы! А в чем свинчивание? В том что кто-то смеет пользоваться возможностями ЯП и компилятора? Так си тем и хорош - хочешь, пользуешься либой. Не хочешь - не пользуешься. Модно самому себе свой libc написать, с шахматами и поэтессами. Если это зачем-то надо. > А glibc у нас теперь на динамичном языке, да? Glibc - всего лишь одна из реализаций libc, которая может использоваться а может и не использоваться, на усмотрение програмера. > Или почему его нельзя использовать? Можно. Если его свойства устраивают - мы им пользуемся. А если не устраивают - не пользуемся. И просто берем что-нибудь другое или пишем свое. Инструментарий позволяет. А не лезем доказывать с синдромом утенка что "не такой уж он и плохой". > Увы для вас, пробовал и даже в свое время вполне успешно "рубился" > на "всех уровнях", вплоть до загрузчиков. Это "увы" не ощущается. Увы. > Спасибо, Маэстро Луж, вы опять были неповторимы! Да не за что, меня эта дискуссия тоже поулыбала. > ЗЫ: молодца, взял и зарегистрировал ник. >> Участник:    Нимано >> ФИО:    Лох Педальный > Ну да – крутой аргумент, прям слов нет. Ты так активно педалировал тему анонимов, что он стал НЕаноним :P. >  Знатно у вас припекает ) Уверен что у меня? :) Впрочем, если тебе нужен этот ник - напиши какую-нибудь ненужную почту в ответе - я тебе пароль туда вышлю, пока не забыл. Мне этот ник не требуется.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	156. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Нимано_ on 28-Апр-16, 17:29
	>> сложно "втиснуть" динамичность в такие рамки, чтобы компиляция в "нативный код"   >> стала действительно эффективной, а не просто эдаким "захардкоженным" аналогом интерпретатора. > ИИ требуется для того чтобы привести динамические типы в статические без выполнения > кучи проверок в рантайме (интерпретатор в качестве решения проблемы - еще > тяжеловеснее). Наконец-то хоть до одного из анонимов дошло. А то "компилировать нельзя, ИИ нужен!!". > чтобы получить эту уверенность путем предвычислений во время сборки, без кучи проверок > в рантайме, надо быть AI. В общем случае возможно что-то эдакое можно и подвести. Но тут вылезает куча оговорок и все эти обобщения могут быстро оказаться "ни о чем". Например, если не брать в расчет хитровывернутый код, то проследить "execution path" и вывести нужные типы – ну не совсем тривиально, но и далеко не проблема "божественного ИИ"-класса. > Сишникам с их типами (которые вообще > фэйк) Тюринг тоже порой икается, по поводу чего есть "register", "volatile" > и т.п.. То, что в си слабая типизация, вроде как не тайна, не? >> Вообще, это был намек в сторону "появления новых типов". А то, если >> послушать анонимов, оные прям из ниоткуда берутся. > Откуда бы они ни брались, это подразумевает ряд действий. В рантайме. Т.е. > замедление этого куска кода по сравнению с тривиальным add r1, r2, > априори в разы. Еще раз: проследить "code execution path", вывести типы, генерировать код. Т.к. сам по себе, внезапно, тип не изменится, то проверки при (нетривиальном) присвоении новых значений,  будет достаточно. Причем, часть из них [проверок] скорее всего можно будет опустить и уж тем более не нужно пихать их перед каждой операцией. Этих самых "нетривиальных"  (т.е. не вида x += 42 или x = x + y, при том что тип y для именно этой ветки вычислений известен) присвоений на самом деле не так уж и много (и не надо кивать на хитровывернутый индусо-код). Такой подход позволит разбить код на блоки, в идеале (ну или в зависимости от требований) с одной точкой входа и в котором типы переменных по определению не изменяются. Т.е. конкретно для этих блоков оптимизация будет вполне себе ничего. Опять же, совсем не обязательно, что на выходе такого блока будут нескольно типов, а это, опять же, позволит объединять/"инлайнить" блоки. Хотя да, можно придумать пример попорукого кода, где все это не будет работать – но такой код далеко не тот показатель, на который стоит ориентироваться. >> И, как мы видим – вполне сработало, анонимы один за другим упорно лажались ) > Ты тоже хорош, предложил какой-то дурацкий способ и доволен по уши. Ну, я то расчитывал на наглядном примере объяснить, что "динамизьм" можно и в си клепануть и оно скомпиляется без ИИ. Кто же знал, что у анонов настолько бурная фантазия? > Вот ежкин кот. Я сказал про проверки. Guard насколько я понимаю частный > случай и есть. Тебя не смущает что это будут какие-то дополнительные > действия, далекие от add r1, r2 для тех же integer'ов? Неа, ведь анонимов не смущает, что есть некая устоявшаяся терминология, переиначивать (а анонимов никто за язык^W пальцы не тянул) которую – как минимум чревато быть не понятым. Ну и заодно показать, что на самом деле познания – в лучшем случае общие, больше из разряда "а я вот считаю". Что само по себе не является чем-то отрицательным, если конечно технически более-менее обоснованно. Но вот делать при этом умный и уверенный вид, предоставляя все в виде истины в последней инстанции … >> Но увы, это не про Анонимов. Анонимы, ничтоже сумняшеся опять затянули свою >> песнь про  типы,  да еще и пытались Тюринга к выводу оных приплести. Эпично. > Так ты покажи где в этой логике промах? Не-не. Дурных нема. Аноним пусть сам доказывает, что то, что он имел в виду — действительно применимо именно в этом конкретном случае ) >> guardы оказывается входят в более общее понятие "проверки типов". > А что, не входят? Ну, если пользоваться общепринятой терминологией тех же мозилловцев, пай-пайщиков и еще кучи людей, то нет. Максимум можно встретить [i]type guard[/i] >> какие могут у этого подхода быть минусы" кое-кто знатно профейлил. Когда >> советуют что-то, то обычно упоминают как минимум не только минусы, > Не очень понятно о чем ты. Очевидно же о "советовании" использования массивов. Аноним придумал в очередной раз что-то, блестяще опроверг, а вот на мелочах опять спалился ) >> включение в «более общее понятие 'проверки типов'» вообще-то отдает очередной, >> сугубо личной верованием^W терминологией очередного анонима. > Не к чему докопаться - займись буквоедством? Можешь еще орфографические ошибки поискать, > дарю идею. Упорно переиначивать устоявшуюся терминологию обычно таки не самая лучшая идея. Все равно что "жать на курок" или обзывать системный блок "процессором". Оно даже без дополнений автора понятно, что он отнюдь не то имел в виду, но осадочек-то остается > Это ты так намекаешь, что если технические аргументы закончились - нужно провести > персональную атаку на оппонента? У тебя и это плохо получается. Не, я же не Аноним, мне это как бы не нунжно. Хотя обозвать инкриминирование "перевода стрелок" персональной атакой – это сильно )   А что, нужно было написать от имени оппонента, что он "Лох Педальный" и ходить, раздуваясь от ЧСВ? Ну да, это стильно и аргументативно! ) >> То, что конкретный jit чего-то не может, как бы вообще не показатель. > Это не "конкретный jit" а некий constraint: чем более качественный код мы > хотим получить, тем больше времени надо потратить на анализ. На пальцах – jitу не обязательно каждый раз анализировать с нуля. Религиозных запретов на сохранение промежуточных результатов нет. > Ты прав, JIT и даже AOT на стороне юзера - больная тема. > Сомневаешься? Посмотри сколько времени .NET в винде после установки генерит сборки > в нативном коде из абстрактного. Всего полдня лагания компа - и > готово. То же самое можно было сказать 200 лет назад о "самобеглых колясках" – шумны, вонючи, медленны и легко уделываются хорошей тройкой. Как и о первых пароходах. В общем, аргумент весьма сомнительный. >>> Участник:    Нимано >>> ФИО:    Лох Педальный Это почти из разряда "Написать на двери оппонента <такой-то – дурак>, навалять кучу под дверь и ходить гордым и довольным". Т.е. мне не понять. > Ты так активно педалировал тему анонимов, что он стал НЕаноним :P. Т.е. это уже я прятаться за безликим "Анонимом", активно каждый раз твердя "я другой Аноним!"? Ну окай, пусть будет так. Хорошо, что анонимы не в курсе моего реального адреса, а то боюсь, "доказательства превосходства" в виде надписей на двери и, возможно, кое-чего похуже и попахучее под оной, я бы не оценил. >>  Знатно у вас припекает ) > Уверен что у меня? :) Т.е. написать от "как-бы имени" оппонента, какой он "педальный лох" – признак адекватной реакции? Ой, да ладно вам сказки рассказывать ) > Впрочем, если тебе нужен этот ник - > напиши какую-нибудь ненужную почту в ответе - я тебе пароль туда > вышлю, пока не забыл. Мне этот ник не требуется. Да не особо – "ним-Ано", не? Просто, чтобы не прятаться за безликим "Аноним", в отличие от. Хотя, если совесть гложет, то пожалуйста: nimano@you-spam.com
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	16. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от h31 (ok) on 24-Апр-16, 13:11
	> На гоу это занимало бы мегабайт 30. Если тебе не хватает места на диске - могу выслать карту памяти. Как раз валялась одна RS-MMC на 32 мб. В общем, пиши адрес.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	113. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 25-Апр-16, 14:14
	Он под мостом живет
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	34. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним32 on 24-Апр-16, 15:13
	зачем же так преувеличивать :) вот смотрю: % lh /usr/lib/go/pkg/linux_amd64_dynlink/libstd.so -rw-r--r-- 1 root root 41M апр 24 14:58 /usr/lib/go/pkg/linux_amd64_dynlink/libstd.so а это размер всей стандартной динамической библиотеки языка Go. а под 30-атник будет весить аналог gitlab-a написанного на go, к примеру тот же gogs: % lh /usr/share/gogs/gogs -rwxr-xr-x 1 root root 31M мар  7 12:53 /usr/share/gogs/gogs
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	47. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 16:57
	> а это размер всей стандартной динамической библиотеки языка Go. Поэтому даже heдlo world будет жрать не менее 40 метров памяти, прикинь? Просто потому что библу вгрузил. Не в обиду гугелю, libre office будет стартовать быстрее чем такие программы.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	66. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от angra (ok) on 24-Апр-16, 18:01
	$ time ./hw >/dev/null real    0m0.002s user    0m0.000s sys    0m0.002s Сегодня просто набег лжецов.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	90. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 23:27
	Хорошо врешь, спору нет. А теперь то же самое, с холодным кэшом. Чтобы совсем ЗБС - с механического диска.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	108. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от angra (ok) on 25-Апр-16, 11:02
	Да легко: $ time ./hw >/dev/null real    0m0.042s user    0m0.000s sys    0m0.002s Что еще придумаешь? Попросишь теперь с пятидюймовой дискетки стартануть на 8086 с 640kb памяти? Хотя если очень хочется страшных чисел, то я тебе помогу $ time go run hw.go >/dev/null real    0m1.357s user    0m0.527s sys    0m0.059s Можешь теперь сравнить с запуском libreoffice с его предварительной сборкой из исходников.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	118. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 25-Апр-16, 16:17
	> $ time ./hw >/dev/null > real 0m0.042s > user 0m0.000s > sys 0m0.002s Ты что-то совсем заврался, паря. Если у тебя либа 40 метров весит, она явно не могла прочитаться ни за 0.02 секунды, ни за 0.04. Особенно на механическом жестком диске, где диску надо еще кучу seek сделать, каждый из которых добрый десяток миллисекунд. > Что еще придумаешь? Попросишь теперь с пятидюймовой дискетки стартануть Попрошу не гнать внаглую, с офигением настолько, что это обнаруживается элементарной математикой. > $ time go run hw.go >/dev/null > real 0m1.357s > user 0m0.527s > sys 0m0.059s Вот это уже более правдоподобно. > Можешь теперь сравнить с запуском libreoffice Там подольше будет - больше файлов вгружается. > с его предварительной сборкой из исходников. Ну тогда и ты пересобери свою 40-метровую стандартную либу. А почему я должен компилять, а ты нет? Я либрофис компилирую настолько же часто как ты - стандартную гопную библиотеку.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	122. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от angra (ok) on 25-Апр-16, 16:46
	Вообще-то это был вариант для статической линковки, которая по дефолту в Go используется. Вариант с динамической линковкой с 40метровой либой смотри ниже у  Аноним32. Зачем мне пересобирать полностью 40 метровую либу, когда достаточно из нее взять и собрать лишь нужные данной программе части(благо в hello world! их немного)? При этом скорость сборки у Go настолько велика, что позволяет использовать программы на нем как скрипты, то есть хранить только исходный код и собирать из него бинарь на ходу при каждом запуске. Что и было продемонстрировано во втором тайминге. И если ты вдруг не понимаешь, то динамическая линковка со всей стандартной либой используется только в случае, если используются одновременно множество программ на Go. Либа при этом загрузится всего один раз. Точно также как однократно загружаются либы для программ на С или С++. Но об этом ты конечно не подумал. Вместо этого как дурак требуешь динамическую линковку со всей стандартной либой Go ради hello world. Интересно, если ты так уж не веришь моим таймингам, то что тебе мешает за пять минут поставить себе Go и их проверить?
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	139. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 26-Апр-16, 22:35
	> используется. Вариант с динамической линковкой с 40метровой либой смотри ниже у Аноним32. Выбор из hello world на мег и стандартной либы на 40 - хорошо придумано. А вменяемые варианты у гугла бывают? > Зачем мне пересобирать полностью 40 метровую либу, Затем же зачем и оппоненту пересобирать libre office, наверное. А почему libreoffice пересобирать надо, а гопную либу - нет? > когда достаточно из нее взять и собрать лишь нужные данной программе части > (благо в hello world! их немного)? Этак мы дойдем до того что из либры код оказывается тоже можно скопипастить. Не говоря про мелочи жизни типа разных libc. > код и собирать из него бинарь на ходу при каждом запуске. > Что и было продемонстрировано во втором тайминге. Запуск сишных программ как "скриптов" - баян, которому много лет (с каких там пор в линухе binfmt_misc?). Пользователи го только сейчас узнали что так можно было? С разморозкой, слоупоки. > И если ты вдруг не понимаешь, то динамическая линковка со всей стандартной > либой используется только в случае, если используются одновременно множество программ > на Go. Либа при этом загрузится всего один раз. Блаблабла. Хорошо придумано - поругать си, похвалить го. И главное за одно и то же. Ну не булшит ли? > об этом ты конечно не подумал. Вместо этого как дурак требуешь > динамическую линковку со всей стандартной либой Go ради hello world. Программ на го меньше чем сишных. Если система стартанула - libc вероятно загружен. Для 40-метровой стандартной либы это будет не фактом. Да и такой шмат одним юнитом как-то не очень вменяемо. > Интересно, если ты так уж не веришь моим таймингам, то что тебе > мешает за пять минут поставить себе Go и их проверить? Нахреннужность мне оного. Если кто-то мне показывает тайминг типа 0.01 секунды - это заведомый ЛПП, или индикация того что индивид не знает что такое погрешность измерений, не может отсеивать явно кривые результаты и вообще не способен вменяемо что-либо измерять. Даже на уровне тривиальной вузовской лабы.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	145. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 27-Апр-16, 16:53
	похоже парниша ты просто не осилил установку Go и теперь пытаешься нелепо отмазаться.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	109. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним32 on 25-Апр-16, 11:17
	на довольно древнем нетбуке с hdd % cat /sys/block/sda/queue/rotational 1 используется стандартный компилятор go, не gccgo. хеловорд со статической линковкой: # sync && echo 3 > /proc/sys/vm/drop_caches % time ./hello real    0m0.087s user    0m0.000s sys    0m0.003s с динамической, то есть с подгрузкой всей стандартной динамической библиотеки языка Go на 41 мб: # sync && echo 3 > /proc/sys/vm/drop_caches % time ./hello_lshared real    0m0.844s user    0m0.027s sys    0m0.047s в вдогонку к нелепому высказыванию про - "libre office будет стартовать быстрее чем такие программы" # sync && echo 3 > /proc/sys/vm/drop_caches % time libreoffice real    0m31.898s user    0m0.047s sys    0m0.113s
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	74. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним32 on 24-Апр-16, 18:25
	ты наверное просто не совсем вгрузил, это ВСЕ стандартные динамические библиотеки, понятно что для одного приложения её тащить не кто не будет в этом смысле статическая линковка вполне себе нормально, а если их уже перевалило за десяток или два то почему бы и нет, тогда и хеловорд будет весить: % lh                       итого 732K -rwxr-xr-x 1 admin admin 720K апр 24 18:11 hello -rwxr-xr-x 1 admin admin 7,7K апр 24 18:10 hello_lshared -rw-r--r-- 1 admin admin   75 апр 24 18:08 main.go в первом статическая во втором динамическая, разница ощутима
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

2. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
Сообщение от Аноним (??) on 24-Апр-16, 11:15
nginx не?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+8 +/–
	Сообщение от nginx on 24-Апр-16, 11:25
	не. :)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	22. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+3 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 14:01
	nginx по мнению некоторых экспертов уже обрюзг
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	24. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 14:02
	nginx старпёрит вместе с апачем
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	69. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Firefoxic (ok) on 24-Апр-16, 18:13
	>> Lwan поддерживает протоколы HTTP/1.0, HTTP/1.1 (с поддержкой keep-alive и pipelined) и PROXY, для перенаправления запросов применяется сопоставление по шаблонам Lua (http://www.lua.org/manual/5.2/manual.html#6.4.1). Ну да, Lwan совсем не старпёрит со своими HTTP/1.0, HTTP/1.1. При том что HTTP/2 уже давно в релизе, и старпёрные NginX и Apache его на столько же давно умеют (после замены пары строк в конфиге).
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	119. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+2 +/–
	Сообщение от Аноним (??) on 25-Апр-16, 16:21
	Минутку, nginx умеет HTTP/2 без году неделю. В "mainline" ветке 1.9 только, которая еще не "stable" ни разу. Зато уже успели там посадить crash bug. Качество кода? "Потестируем на пользователях беспатной версии" - вот и все качество.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	53. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:22
	> nginx не? А там вообще можно "Handlers can be written in C and Lua"? Как раз такое было надо. Там аж пример есть, менее полкило колда, при том что это будет скростной обрабтотчик на си. EPIC WIN, ща прикрутим полезняку. Для полного кайфа - еще б json он заумел, была бы просто песня.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	71. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Firefoxic (ok) on 24-Апр-16, 18:18
	Ещё б HTTP/2 он заумел.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	97. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 25-Апр-16, 01:54
	Это который бинарный? Не нужно его уметь. Совсем
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	111. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Никто (??) on 25-Апр-16, 13:21
	Аллергия на двоичность? А ведь это, вкупе с другими особенностями HTTP/2 - ускорение интернета, построенном на более рациональном использовании железа. Разве не прекрасно?
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	117. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от tikitak on 25-Апр-16, 16:13
	Не с той стороны ускоряют. Впрочем очередная корполапша из серии системд.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	120. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 25-Апр-16, 16:22
	> Это который бинарный? Не нужно его уметь. Совсем В байте 8 битов, это дает 256 возможных значений. И все машины на самом деле работают вот так. Если тебя это не устраивает - ну не знаю, иди водителем такси. Там надо только красный, желтый и зеленый отличать.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	132. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Moomintroll (ok) on 26-Апр-16, 09:49
	> В байте 8 битов Ну кто ж так умничает? https://ru.wikipedia.org/wiki/Байт И 6, и 7, и 9, и даже 36!
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	140. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 26-Апр-16, 22:37
	Системы с байтами где другое количество битов сейчас там же где и динозавры, т.е. в Вальхалле.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

4. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+2 +/–
Сообщение от Аноним (??) on 24-Апр-16, 11:43
Код проекта написан на языке Си и распространяется под лицензией GPLv2+.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	43. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 16:37
	Потому и лучше бздунского nginx'а.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	48. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:04
	> Потому и лучше бздунского nginx'а. Nginx, к сожалению, скатываеся. Появилась коммерческая версия, в опенсорсную версию коммитят по остаточному принципу, полтора человека. И репы в каком-то hg. Где гит? Ах, у lwan? Ок. А загружаемые модули, которые в nginx до сих пор только в экспериментальной версии, в форке от tencent уже пять лет как есть. И наверное форк сделали не от хорошей жизни.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	80. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 21:52
	>> Появилась коммерческая версия это плохо? >> в опенсорсную версию коммитят по остаточному принципу, полтора человека. Да ну?                                                                                                                                                            $ hg log -r "date('2015-04-25 to 2016-04-25')" | grep user:| sort -u | wc -l                                                                                      2015-2016: 18                                                                   2014-2015: 25                                                                   2013-2014: 25                                                                   2012-2013: 8                                                                     2011-2012: 7                                                                     2010-2011: 7                                                                                                                                                      Для справки: NGINX, Inc. was founded in July 2011                                                                                                                Теперь взглянем на количество изменений:                                                                                                                          $ hg diff --stat -r "first(date('2015-04-24'))" -r "last(date('2016-04'))"                                                                                        2015-2016: 244 files changed, 22163 insertions(+), 9749 deletions(-)             2014-2015: 196 files changed, 12974 insertions(+), 6473 deletions(-)             2013-2014: 187 files changed, 11129 insertions(+), 3153 deletions(-)             2012-2013: 189 files changed, 17002 insertions(+), 3224 deletions(-)             2011-2012: 385 files changed, 18776 insertions(+), 6388 deletions(-)             2010-2011: 141 files changed, 10195 insertions(+), 2647 deletions(-)                                                                                              выводы делаем сами   >> И репы в каком-то hg. Вам шашечки или ехать?
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	91. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 23:47
	> это плохо? Да. Открытая версия стала развиваться по остаточному принципу и рассматриваться как тестовая площадка для плюса, с искусственным созданием неудобств и недоделок, чтобы плюс покупали. Который к тому же проприетарный. Чтобы в 2016 году вляпываться в проприетарный вебсервер - надо быть совсем больным на голову. Тут вон HTTP/2 размахивают. Nginx был не первый кто это реализовал. > Да ну? Там по жизни коммиты от 2 лиц: Дунин и Сысоев. Остальные случайно залетели, хотя в nginx, inc пару индусов и набрали для разбавки. > Для справки: NGINX, Inc. was founded in July 2011 После чего nginx как апстрим стал враждебным и кривым. Хотя он таким всегда и был, но хорошо маскировался за отсутствием альтернатив. > выводы делаем сами Особенно глядя на то кто первым сделал HTTP/2 или кто отфокал nginx и запилил загружаемые модули. >>> И репы в каком-то hg. > Вам шашечки или ехать? Нормальные девтулы - плюс для проекта. Но у nginx с этим даже не плохо. У них с этим никак.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	128. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Valentin V. Bartenev on 25-Апр-16, 23:03
	Привет от "случайно залетевшего" разработчика nginx. На всякий случай, репозиторий находится тут: http://hg.nginx.org/nginx/ - рекомендую пройти по ссылке и найти там "по жизни коммиты от 2 лиц". Хотелось бы, в свою очередь, увидеть ваши патчи и какое-либо подтверждение словам про "остаточный принцип". Но могу разочаровать, открытая версия разрабатывается гораздо интенсивней, чем в годы до создания компании, и только наращивает обороты, в чем не сложно убедиться посмотрев на статистику коммитов. О качестве кода и тестировании уже писал ниже в комментариях: http://www.opennet.me/openforum/vsluhforumID3/107676.html#126 Особая забота о качестве кода не позволяет нам реализовывать некоторые возможности с той же скоростью, которая доступна тем, кто "отфоркал nginx" или "запилил HTTP/2 первым". Прошу отнестись с пониманием.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	129. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от . on 26-Апр-16, 02:38
	WoW! Чуваки! Спасибо вам за nginx, прям вот поклон до пояса! Я жадных детей не слушайте, пусть себе песочком побросаются, это только их мамку (которой чад и отмывать) волновать должно :)
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	151. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 28-Апр-16, 11:53
	> Привет от "случайно залетевшего" разработчика nginx. Глядя на вектор тяги нжинкса - я опасаюсь что залетать могут начать пользователи. > На всякий случай, репозиторий находится тут: http://hg.nginx.org/nginx/ - Спасибо что не Bazaar. > рекомендую пройти по ссылке и найти там "по жизни коммиты от 2 лиц". Действительно, мои сведения несколько протухли. > Хотелось бы, в свою очередь, увидеть ваши патчи и какое-либо подтверждение словам > про "остаточный принцип". Патчи в коммерческий проект с проприетарной версией? С такими девтулами? Еще и бесплатно поди? ИМХО пусть это делают сотрудники nginx, inc. > интенсивней, чем в годы до создания компании, и только наращивает обороты, > в чем не сложно убедиться посмотрев на статистику коммитов. Да я уже заметил что там 4 метра кода вымахало. Но документация по нему хилая, на nginx.org вообще похоже все забили. Вменяемых примеров написания модулей - нет. В целом впечатление такое что компания "для галочки" вываливает исходник урезанной версии. Это в нжинксе и называют "опенсорц". Ощутить драматическую разницу в подходах можно просто зайдя на https://lwan.ws > О качестве кода и тестировании уже писал ниже в комментариях: Согласен, мнение возможно занижено. Но никаких поводов для того чтобы это было иначе у меня не было. Народ из нжинкса постеснялся рассказать о своих методиках. А когда я вижу crash bugs и не вижу как с ними борятся - что я должен подумать? Хотя мое упущение тоже есть: я не учел что код нжинкса сильно распух в последнее время. Поскольку больше кода означает больше багов, это же означает что на самом деле метрики качества кода очень даже. > Особая забота о качестве кода не позволяет нам реализовывать некоторые возможности с > той же скоростью, которая доступна тем, кто "отфоркал nginx" FAIL состоит в том что эту заботу окружающим вообще не видно. > или "запилил HTTP/2 первым". Прошу отнестись с пониманием. Я бы понял, если бы кое-кто не повесил в этом коде крашер. А показать как появляется качество те полтора разработчика из lwan.ws почему-то могут сильно убедительнее. Статус coverity вывешенный в вебе выглядит убедительнее чем рассказы о десятках виртуалок, бороздящих просторы, но мне совершенно невидимых.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

5. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–9 +/–
Сообщение от robux (ok) on 24-Апр-16, 11:52
> новый высокопроизводительный HTTP-сервер Шёл 2016 год, а они всё ещё веб-сервера клепают... неандертальцы!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+22 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 12:03
	> Шёл 2016 год, а они всё ещё веб-сервера клепают... неандертальцы! Ага, все уже давно переключились на веб-браузеры. Ведь, согласно статистике, веб-браузеры гораздо популярнее веб-серверов, и доля последних продолжает снижаться. Скоро только браузеры и останутся.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	14. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+4 +/–
	Сообщение от анонимоус7657 on 24-Апр-16, 12:36
	А нельзя ли запустить вебсервер из браузера?
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	18. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от sage (??) on 24-Апр-16, 13:23
	Opera Unite!
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	44. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 16:42
	Ну если эмулятор архитектуры x86 смогли на JS написать, то почему бы на нём не написать вебсервер?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	49. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:06
	> Ну если эмулятор архитектуры x86 смогли на JS написать, то почему бы > на нём не написать вебсервер? Запускаешь jslinux от bellard'а, компилишь там http сервер... только как на него конектиться снаружи то?
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	102. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от nonecto on 25-Апр-16, 09:00
	> Запускаешь jslinux от bellard'а, под ним виртуальную машину с виндовсом, а уже там иис. Вуаля.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	152. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 28-Апр-16, 11:57
	> под ним виртуальную машину с виндовсом, а уже там иис. Вуаля. Вместо шахмат можно будет играть в настройку IIS. Двадцать минут на обдумывание очередного хода у тебя точно будет.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	29. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–3 +/–
	Сообщение от Kodir (ok) on 24-Апр-16, 14:55
	> Шёл 2016 год, а они всё ещё веб-сервера клепают... неандертальцы! Юниксвэй же, ну! 1. Должно быть 100500 маленьких программ, каждая из которых умеет делать элементарную операцию, но делать её хорошо. Например, заменять букву "ё" на ":e". Программы соединяются в километровые трубы, по которым текут данные. Nirvana! 2. Каждый ЮНИКС-прогер (с ЛЮБОЙ квалификацией) обязан создать как минимум 5 клонов существующих программ с объяснением, почему "дальше так жить нельзя". Желательно при этом использовать самые маргинальные языки, библиотеки и форматы, чтобы вдохнуть оптимизм в их авторов "вашим г... ещё кто-то пользуется". Через год пиления гирь, забросить проект и ждать емэйлов с пожеланиями счастья. В принципе, я сам не против "пересоздать" какое-нть гуано, но уже на человеческой архитектуре, но для этого нужно удостовериться, что ни один существующий проект негоден для развития. Удостоверяться, несомненно, сложнее, чем сесть и "побырому" сваять очередной "многоплатформенный тулкит". Велкам ту опенсорс! :)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	55. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:36
	Сабж кажется будет ОЧЕНЬ кстати. А этот ваш IIS в моей задаче совсем не годится. Хорошо что есть опенсорс.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

6. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
Сообщение от Аноним (??) on 24-Апр-16, 12:00
> Размер исполняемого файла составляет 110 Кб. $ ls -l /bin/cp -rwxr-xr-x 1 root root 79968 Sep  5  2015 /bin/cp А очень даже неплохо. Всего чуть больше утилиты копирования файлов :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 12:28
	И даже меньше $ ls -l /bin/cp -rwxr-xr-x. 1 root root 155136 Nov 25 15:55 /bin/cp $ cat /etc/system-release Red Hat Enterprise Linux Server release 7.2 (Maipo)
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	26. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 14:26
	> $ ls -l /bin/cp > -rwxr-xr-x 1 root root 79968 Sep  5  2015 /bin/cp > А очень даже неплохо. Всего чуть больше утилиты копирования файлов :) *присоединяется к замеру и достает свой* $ ls -l /bin/cp       -r-xr-xr-x  1 root  wheel  20488 3 Jan 18:22 /bin/cp $  readelf -h /bin/cp|grep Mach     Machine:                           Advanced Micro Devices X86-64
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	56. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:38
	> 20488 Ого! FreeBSD? Busybox? RedHat 3.0? Нет, серьёзно, в чём секрет?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	73. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 18:21
	> Ого! FreeBSD? Busybox? RedHat 3.0? FreeBSD 10.3 amd64 > Нет, серьёзно, в чём секрет? Вангую, что в урезанных фичах – сравните маны http://www.freebsd.org/cgi/man.cgi?cp Гнутая версия размером особо не отличается: >  141024 27 Feb 18:15 /usr/local/bin/gcp
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	79. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 21:35
	> FreeBSD 10.3 amd64 Понятно. Ещё один плюс в копилку FreeBSD в плане качества кода. > Вангую, что в урезанных фичах – сравните маны Есть большие сомнения в том, что во FreeBSD-версии НАСТОЛЬКО меньше функций. И в том, так ли нужны эти "урезанные" фичи, или это что-то уровня цветовой подсветки вывода в GNU grep.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	92. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 23:50
	> Понятно. Ещё один плюс в копилку FreeBSD в плане качества кода. В отсутствии фич. В линухе на btrfs делаем cp --reflink и получаем 10 виртуалок за 10 секунд. В фрибзде .. так вообще нельзя. Можете копировать пятигиговые файлы десятками обычным способом. Но это займет множество времени. Линуксоид всю группу развернет и запустит быстрее чем бздун копирование завершит...
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	96. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–3 +/–
	Сообщение от Аноним (??) on 25-Апр-16, 00:40
	В целом, вы, вероятно, правы, в рамках текещуго обсуждения. Но что касается качества современного линукса в целом, извините, не могу удержаться и не добавить свои пять копеек. > на btrfs Наслышаны, спасибо. > cp --reflink Перепись проведём, кто из линуксоидов СХОДУ знает о такой опции? Думаете, кто-то из них станет маны читать, когда придёт начальство и скажет "Хочу 10 виртуалок ПРЯМОСЕЙЧАС"? А большинство СОВРЕМЕННЫХ линуксоидов к тому моменту, как у бздунов уже скопируются пятигиговые образы, только-только закончат третий гном ставить на сервер, чтобы команды вручную не вводить (XXI век на дворе как-никак), а если в диалоге копирования не окажется галочки "reflink", то копирование запустят обычным образом. Попутно, конечно, зарепортив кучу багов в диалоге копирования, неработающих темах, файловой системе и установщике гнома. > Линуксоид всю группу развернет и запустит А любовью с ней заниматься будет уже клиент, ага, причём с первых дней работы.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	121. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+2 +/–
	Сообщение от Аноним (??) on 25-Апр-16, 16:36
	> Наслышаны, спасибо. Бабка на лавочке сказала? А мы им пользуемся. Позволяет разворачивать виртуалки мгновенно. >> cp --reflink > Перепись проведём, кто из линуксоидов СХОДУ знает о такой опции? Любой кто дошел до чтения man или --help. Ну или теперь вот опеннета. > из них станет маны читать, когда придёт начальство и скажет "Хочу > 10 виртуалок ПРЯМОСЕЙЧАС"? Почитать ман и сделать cp --reflink будет быстрее чем скопировать 10 машин вотпрямща. Ну разве что если ты по слогам читаешь. > на сервер, чтобы команды вручную не вводить (XXI век на дворе > как-никак), а если в диалоге копирования не окажется галочки "reflink", Я разве говорил про какие-то "диалоги" и "галочки"? Так и скажи что крыть нечем. Чего демагогию разводить? >> Линуксоид всю группу развернет и запустит > А любовью с ней заниматься будет уже клиент, ага, причём с первых дней работы. Любовь, при том садомазохистичная, будет если попытаться запустить виртуалки в бзде. А в линухе это уже давно отлаженная технология.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	138. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 26-Апр-16, 20:53
	> Бабка на лавочке сказала? Да, бабка на лавочке с btrfs. > А мы им пользуемся. А вы им везде пользуетесь, или только когда надо вируталку за 10 минут развернуть? Бэкапы, например, тоже на btrfs храните? А фоточки семейные? Или в облака сливаете, чтобы, когда btrfs случайно упадёт, ничего не пропало? > Почитать ман и сделать cp --reflink будет быстрее Если админ даже не догадывается о существовании чего-то подобного reflink, то какие умозаключения он должен провести, которые подсказали бы ему, что "почитать маны" даст эффект (особенно, если он изучал unix по какой-нибудь классической книге, где о линукс-специфичные особенности не упоминаются)? > Так и скажи что крыть нечем. Что "крыть"-то? Что существуют админы, которые кучу времени тратят на чтение changelog-ов и всегда в курсе последних изменений? Это я и не собирался оспаривать. Но возьми среднего linux-админа в небольшой или средней компании, и окажется, что он без гнома и файл скопировать не может. > Чего демагогию разводить? Где ты демагогию-то увидел? > давно отлаженная технология Если ею правильно пользоваться. А не "за 10 минут разверну, а там пусть другие разбираются".
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	153. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 28-Апр-16, 13:14
	> Да, бабка на лавочке с btrfs. Крутая бабка, где такая лавочка? > А вы им везде пользуетесь, или только когда надо вируталку за 10 > минут развернуть? Бэкапы, например, тоже на btrfs храните? А фоточки семейные? Бэкапы должны лежать на отдельных ФС. Желательно географически разнесенных. Btrfs сейчас дохнет не больше других ФС, а вероятность отказа сразу двух/трех/... > Или в облака сливаете, чтобы, когда btrfs случайно упадёт, ничего не пропало? У btrfs есть "btrfs restore" (оффлайн вычитка, прогой, без монтирования). Крутейший data recovery тул для доставания файлов с убитых дисков. У ZFS например ничего сравнимого нет. Если ZFS развалится - файлы дискэдитором придется доставать. Можешь посмотреть сколько это стоит в data recovery лабах, только валидол возьми. > Если админ даже не догадывается о существовании чего-то подобного reflink, Если админ не интересуется эффективностью рабочих процессов, я не очень понимаю зачем ему платить деньги. > даст эффект (особенно, если он изучал unix по какой-нибудь классической книге, В этом случае он много не наадминит. Там много чего еще нет, от systemd до управления пакетами. Можно пойти дальше. Разучить K&R C "в оригинале". Сможешь заниматься системным программированием под вымершие системы. Под существуюшие не сможешь, там диалект языка другой. > где о линукс-специфичные особенности не упоминаются)? Если кто полез админить Linux, ему придется подучить специфику, чтобы быть эффективным. А если кто будет полдня делать то что делается за 10 минут - извините, но... > Что "крыть"-то? Что существуют админы, которые кучу времени тратят на чтение changelog-ов Нормальный админ знает что творится в его системе и умеет пользоваться улучшениями и фичами. Иначе он будет тратить много лишнего времени. Это вообще не админ а эникей. > оспаривать. Но возьми среднего linux-админа в небольшой или средней компании, и > окажется, что он без гнома и файл скопировать не может. Это существо называется эникейщиком и занимается чисткой мышек, починкой принтера и что там еще. Если это существо "админит" линукс хотя-бы через гном - это уже достижение, спасибо что хоть не винда. > Если ею правильно пользоваться. А не "за 10 минут разверну, а там > пусть другие разбираются". А оно как раз не создает никаких проблем в этом плане. Как раз никаких разборок с снапшотами и клонами где-то сбоку. Просто файловые операции. Немного на стероидах, только и всего. Ну там удалить виртуалки можно хоть гномовским файлменеджером, если уж так хочется. То что они при создании вновь займут в 5 раз больше места и это будет намного дольше - так этим специалист от эникея и отличается.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	100. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 25-Апр-16, 03:25
	> В отсутствии фич. В линухе на btrfs делаем cp --reflink и получаем > 10 виртуалок за 10 секунд. А что с ext4? А с F2FS? А с …? А зачем тогда пихать поддержку ФС-специфичных вещей в cp? А давайте тогда, в лучших традициях комбайнерства еще и распаковку сжатых файлов и копирование из tar добавим, вдруг кому-то понадобится? > Можете копировать пятигиговые файлы десятками обычным способом. Но это займет множество > времени. Опять традиционное "не, не слышал, но мнение имею!"? Ну да, эти ретрограды продолжают делать ФС-специфичные вещи ФС специфичными утилитами: zfs snapshot zfs clone https://www.freebsd.org/cgi/man.cgi?format=html&manpath=FreeBSD 8.3-RELEASE&query=zfs > creating  a  clone  is  nearly instantaneous, and initially consumes no additional space.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	104. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–2 +/–
	Сообщение от nonecto on 25-Апр-16, 09:17
	> zfs snapshot > zfs clone > https://www.freebsd.org/cgi/man.cgi?format=html&manpath=FreeBSD 8.3-RELEASE&query=zfs >> creating  a  clone  is  nearly instantaneous, and initially consumes no additional space. yezz. FreeBSD is ZFS. Линуха тоже зфс умеют. Жаль, что все эти придурошные лицензии разделяют всё на всё и правят миром.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	110. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 25-Апр-16, 12:50
	> Линуха тоже зфс умеют. Да ну, не верю! Если линуховский ср не может в --reflink для zfs, то нормальной поддежки считай что нет и все умение для галочки!
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	154. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 28-Апр-16, 13:28
	> Если линуховский ср не может в --reflink для zfs, то нормальной поддежки > считай что нет и все умение для галочки! Из зала подсказывают что это какие-то проблемы в архитектуре ZFS. У ZFS дисковые структуры очень специфично сделаны и накладывают много странных ограничений на то как могут выглядеть блочные операции и много чего еще.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	123. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+2 +/–
	Сообщение от Аноним (??) on 25-Апр-16, 17:05
	> А что с ext4? А с F2FS? А с …? А ничего, они это не умеют. А ubifs и вовсе только на raw NAND работает. В линухе много файлух, можно выбрать. > А зачем тогда пихать поддержку ФС-специфичных вещей в cp? Затем что должен быть механизм вызова возможностей файловой системы. Это действие больше всего похоже на мгновенное копирование. Так почему бы нет? Со временем и другие CoW-based могут реализовать, если их внутренняя структура не противоречит ссылкам на одни блоки несколько раз и CoW при изменении shared блоков. > zfs snapshot > zfs clone Это прекрасно, но cp --reflink - не снапшот, а просто способ указать ФС что все 10 машин изначально используют одинаковые блоки. Хочется ли сохранять их состояние в снапшоте ФС - совершенно отдельный вопрос, не пересекающийся с желанием сделать 10 копий большого файла быстро и эффективно. Снапшотами аналог этого сделать можно. Но сложно и криво, cp с одним флагом сильно проще. А если мне надо будет именно снапшот, который я понимаю как некое состояние имеющее некую ценность, так что его сохраним на память, это можно уже явно заказать. Но группа виртуалок может быть и временной, когда запускается какой-то эксперимент, а через 10 минут получен результат и виртуалки не требуются. Стереть их обычным rm'ом, F8 в миднайте или что там у кого - будет как-то сильно проще чем лезть ворочать снапшоты. > https://www.freebsd.org/cgi/man.cgi?format=html&manpath=FreeBSD 8.3-RELEASE&query=zfs >> creating  a  clone  is  nearly instantaneous, and initially consumes no additional space. У фрибсдшников все так - вроде можно, но только через хитро закрученную ж. Btrfs вообще отличается тем что к администратору он повернут лицом, а не другими частями тела. Им пользоваться просто и приятно.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	130. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от . on 26-Апр-16, 02:43
	>Им пользоваться просто и приятно. Это только до тех пор, пока терять, кроме развалов с порнухой - нечего :)))))
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	142. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Анонис on 27-Апр-16, 09:40
	> Это только до тех пор, пока терять, кроме развалов с порнухой - нечего :))))) Где массовый писк пользователей фэйсбука о потере фотографий котят?
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	134. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 26-Апр-16, 15:22
	>> А что с ext4? А с F2FS? А с …? > Так почему бы нет? Со временем > и другие CoW-based могут реализовать, если их внутренняя структура не противоречит > ссылкам на одни блоки несколько раз и CoW при изменении shared > блоков. Ну а что с распаковкой-то? И копированием из tar? Как же жить без этих фич? > Это прекрасно, но cp --reflink - не снапшот, а просто способ указать > ФС что все 10 машин изначально используют одинаковые блоки. Хочется ли > сохранять их состояние в снапшоте ФС - совершенно отдельный вопрос, не > пересекающийся с желанием сделать 10 копий большого файла быстро и эффективно. Очень похоже на попытку обосновать, почему использование cp – Ъ-вей, а все остальное  костыль. > Снапшотами аналог этого сделать можно. Но сложно и криво, cp с > одним флагом сильно проще. Ну да, ну да. snapshot + clone = сложность неимоверной жырн^W кривости! Очень убедительно! > будет > как-то сильно проще чем лезть ворочать снапшоты. Ага, zfs destroy так сложен, так сложен … > У фрибсдшников все так - вроде можно, но только через хитро закрученную ж. Вы уж определитесь, то у вас > ... так вообще нельзя то теперь > через хитро закрученную ж может просто по другому, а все остальное – синдром лапчатого^W утенка? > Btrfs вообще отличается тем что к администратору он повернут лицом, > а не другими частями тела. Главное, почаще повторять, тогда и аргументиков никаких не надо!
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	143. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 27-Апр-16, 10:15
	> Ну а что с распаковкой-то? И копированием из tar? Как же жить без этих фич? Упаковка/распаковка файлов у btrfs в дефрагер встроена. Можно сжать/распаковать прозрачным сжатием файло в процессе дефрагментации. Тоже прикольная фича, я ей пользуюсь иногда. > Очень похоже на попытку обосновать, почему использование cp – Ъ-вей, а все остальное  костыль. Очень похоже на попытку юлить. Дернуть cp с одним флагом - это просто. Лезть ворочать снапшоты - по сравнению с вызовом cp как-то не очень. Особенно если учесть что reflink'нутые файлы - удаляются "обычно", без специальных утилит, rm'ом, F8 в mc или как вы там unlink() предпочитаете. Это НЕ управление состояниями как снапшоты а простой и эффективный способ копирования. > Ну да, ну да. snapshot + clone = сложность неимоверной жырн^W кривости! По сравнению с cp с одним дополнительным флагом и удалением обычным rm или миднайтом? Как-то сложновато и кривовато, если сравнивать. > Очень убедительно! Да нормально, мгновенное копирование. За счет откладывания фактического переноса блоков до момента когда они станут отличаться от предка. Очень логичное использование CoW. Самое странное что ZFS on linux так почему-то не умеет, хотя тоже вроде CoW и даже дедуп вроде делает. > Ага, zfs destroy так сложен, так сложен … По сравнению с F8 на вон тех 5 файлах которые я в mc глазами вижу и выделил как обычно? Как-то менее удобно и более канительно. >> через хитро закрученную ж > может просто по другому, а все остальное – синдром лапчатого^W утенка? У фрибзды нет аналога --reflink и именно так - там нельзя. Но если очень хочется что-то подобное - приблизительный аналог можно сколхозить из снапшотов. Или дедупом на лету. Только первое - как-то неудобно с точки зрения управления. Желание эффективно скопировать 5 одинаковых файлов ортогонально управлению состониями, поэтому делать это снапшотами сложно и криво. Второе - ресурсы жрет. А чтобы как белый человек порулить - ну это не про вас. >> Btrfs вообще отличается тем что к администратору он повернут лицом, >> а не другими частями тела. > Главное, почаще повторять, тогда и аргументиков никаких не надо! Тот же --reflink служит очень хорошим примером этого самого. Или добавление девайсов в пул на ходу. С ребалансом и даже рестрайпом на лету. Не говоря про возможность вынуть девайс и отсутствие доставшей уже всех канители с выравниванием размеров девайсов, это безобразие мы оставим мамонтам из прошлого тысячелетия, с их примитивными блочными подходами, отливающимися в жестокие проблемы администрирования, когда надо носиться колбасой, экстренно разыскивая N одинаковых девайсов. Вмесо того чтобы просто воткнуть в пул то что по факту есть здесь и сейчас, блин.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	144. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 27-Апр-16, 14:39
	> Упаковка/распаковка файлов у btrfs в дефрагер встроена. Можно сжать/распаковать прозрачным > сжатием файло в процессе дефрагментации. Тоже прикольная фича, я ей пользуюсь > иногда. Это конечно отлично, но тайна неумения cp  в сжатие/распаковку и копирование из tar, все еще не раскрыта! >> Очень похоже на попытку обосновать, почему использование cp – Ъ-вей, а все остальное  костыль. > Очень похоже на попытку юлить. Не более, чем "нам срочно нужно сварганить с ноля 10 виртуалок на 10 минут, а потом все без следа удалить!" > У фрибзды ... Но если очень хочется что-то подобное - приблизительный аналог можно сколхозить из > снапшотов. Или дедупом на лету. То вообще нельзя, то уже оказывается, что если сильно хочется, то можно … В общем, не хватает в конце дополнения типа "Слава Пингвину, Смерть Неверным!"
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	155. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 28-Апр-16, 14:19
	> Это конечно отлично, но тайна неумения cp  в сжатие/распаковку и копирование > из tar, все еще не раскрыта! Так раскрой, если видишь какой-то сценарий использования и это будет чем-то лучше tar. > Не более, чем "нам срочно нужно сварганить с ноля 10 виртуалок на > 10 минут, а потом все без следа удалить!" Такие вещи сейчас экзотика только для пользователей *bsd, у которых с виртуалками все печально. > То вообще нельзя, то уже оказывается, что если сильно хочется, то можно А оно как-то так в опенсорсе и работает. Просто сильнота хотения и полученный результат очень уж варьируются. Теоретически можно даже новую файловую систему написать, еще лучше прежних. Практически - это будет целая эпопея. Но так можно. > В общем, не хватает в конце дополнения типа "Слава Пингвину, Смерть Неверным!" Нет никакого смысла геноцидить динозавров. Они сами вымрут.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	103. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от бедный буратино (ok) on 25-Апр-16, 09:10
	-r-xr-xr-x  1 root  bin  130672 Apr 23 20:38 /bin/cp
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	106. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 25-Апр-16, 10:27
	% ls -l /bin/cp -r-xr-xr-x  1 root  wheel  16664 Jul 21  2015 /bin/cp % uname -a DragonFly rabbitmq.domain.loc 4.3-DEVELOPMENT DragonFly v4.3.0.291.g96acd-DEVELOPMENT #0: Mon Jul 20 23:05:15 UTC 2015     root@pkgbox64.dragonflybsd.org:/usr/obj/usr/src/sys/X86_64_GENERIC  x86_64
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

11. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
Сообщение от Аноним (??) on 24-Апр-16, 12:28
не одного преимущества перед nginx, в могильник апатча
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+5 +/–
	Сообщение от NoName on 24-Апр-16, 13:34
	Лицензия лучше.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	23. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Crazy Alex (ok) on 24-Апр-16, 14:02
	Это нгинксу туда дорога в итоге - совсем в монстра превратился. А здесь - понятная функциональность, компактность и правильная лицензия.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	25. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 14:06
	Wall-Mart тоже когда-то был маленьким магазином
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	37. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Crazy Alex (ok) on 24-Апр-16, 15:31
	Отличное сравнение - магазин для домохозяек. А практически по любой тематике есть специализированные торговцы, от которых толку куда больше. Верной дорогой апача идут товарищи.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	58. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:42
	> Отличное сравнение - магазин для домохозяек. Инкубатор апача - задворки магазина секонд хэнд. Место где бесплатно вываливают то что совсем безнадежно продать, но выкидывать вроде жалко.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	61. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Crazy Alex (ok) on 24-Апр-16, 17:48
	А с этим никто и не спорил
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	32. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от анонимчик on 24-Апр-16, 15:05
	ты плагины пробовал под nginx делать? с lwan все попроще.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	57. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:39
	> не одного преимущества перед nginx, в могильник апатча Ты видел пример обработчика на сях в этой штуке? Сравни с нжинксом, да?!
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	157. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от анонимчик on 24-Окт-17, 09:20
	>не одного преимущества перед nginx, в могильник апатча - для nginx ты пишешь плагины, а эту либу встраиваешь в свой совт - в nginx процессы, а тут потоки - можно использовать много-поточные инструменты, в nginx надо городить ipc - nginx большой, lwan маленький - api nginx мутное, тут прозрачное
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

20. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
Сообщение от Аноним (??) on 24-Апр-16, 13:58
Is there a stable release? There's just one release: the current. This might or might not change in the future. Ok
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
Сообщение от Аноним (??) on 24-Апр-16, 14:31
Где сравнение с собранным в минимальной конфигурации nginx?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
Сообщение от Kodir (ok) on 24-Апр-16, 14:46
"векторизированный ввод/вывод"? Кто-нибудь в мире кроме этого проекта применяет подобную терминологию? О каких векторах речь?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	39. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от lv7e on 24-Апр-16, 16:06
	Думаю, имеется в виду применение векторных инструкций процессора. В теории это может в десятки раз ускорить обработку.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	50. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+5 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:10
	Векторизированный ввод-вывод - это io, использующее readv/writev функции, которые работают с векторами (читай массивами) указателей на участки памяти, откуда/куда надо прочитать/записать данные. Это позволяет за один системный вызов совершить сразу несколько операций ввод-вывод, сэкономив на переключениях контекста.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	52. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:20
	src/os/unix/ngx_readv_chain.c src/os/unix/ngx_writev_chain.c
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	62. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:48
	> src/os/unix/ngx_readv_chain.c > src/os/unix/ngx_writev_chain.c У нжинкса все сильно хуже c качеством кода при огромном размере, у них вообще не замечено fuzzing, использования asan/ubsan, а если их и проверял когда-то coverity то это было давно и неправда. И вместо coverity score = 0.0 они получают сразу CVE. Более того, код nging полон архаизмов и костылей. А написать модуль - можно, но - неоправданно сложно и криво.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	75. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 18:42
	Недавно их проверяли парни из google/cloudflare так что вы обманываете.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	93. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 23:53
	> Недавно их проверяли парни из google/cloudflare так что вы обманываете. Надавно у них пачка CVE была. Вплоть до remode code execution. А еще кодовая база накопила хаков и костылей на все случаи жизни. И все бы ничего, но например свой модуль написать - очень геморно. JS в конфиге? Спасибо. Но написать "обработчик" сабжу будет куда быстрее и проще.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	126. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Valentin V. Bartenev on 25-Апр-16, 22:43
	Привет эксперту по качеству кода от разработчика nginx. Смею заверить, что качество кода является одним из первостепенных критериев, по которому принимается решение о включении того или иного кода в проект. Отсутствие предупреждений различных компиляторов при сборке для нас является стандартом, опция -Werror используется по умолчанию. Помимо предварительного тестирования, по каждому коммиту запускается автоматическая сборка и тестирование на десятках виртуальных машин с различными операционными системами, архитектурами, компиляторами и параметрами сборки. Мы активно разрабатываем и поддерживаем набор функциональных тестов. Счет тестам идет на тысячи. Можете свободно пользоваться и принять участие в разработке: http://hg.nginx.org/nginx-tests/  Покрытие кода тестами мониторится с помощью специального анализатора. На регулярной основе и в автоматическом режиме код проверяется всевозможными статическими анализаторами, в том числе упомянутым вами Coverity еженедельно. Обнаруженные проблемы тут же рассматриваются и устраняются. Для проверки соответствия формата типу переменных в функциях логгирования был написан и используется специальны плагин к clang. 24x7 трудится несколько машин с фаззингом и ASan-ом. О том, что несколько проблем было найдено таким способом можно узнать из коммит логов и на сайте afl-fuzz. Периодически нас пытаются проверять ребята из PVS-Studio, о чем даже писали статью: http://www.viva64.com/ru/b/0246/ Буду очень благодарен, если эксперт соизволит также предоставить список "архаизмов и костылей", которые по его мнению мешают nginx быть надежным, безопасным, производительным и функциональным веб-сервером. Жду также советов по улучшению качества кода и совершенствованию методов тестирования. Спасибо.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	141. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 27-Апр-16, 04:25
	> Привет эксперту по качеству кода от разработчика nginx. Привет, эксперты по проприетари и секретам. > Смею заверить, что качество кода является одним из первостепенных критериев, В сабже это как-то сильно заметнее. Идем на https://github.com/lpereira/lwan (большая кнопка на их сайте на главной страничке). Там висит 4 билдстатуса. Статусы апдейтятся ботами, близко к реалтайму. Там и сканы coverity и прогон юнит-тестов. А на сайте расскажут про afl и asan/ubsan. Там сразу понятно что люди этим занимаются, а кто не знал - получит отсыл к паре хороших инструментов. > опция -Werror используется по умолчанию. Как остальные должны догадываться о том что у вас разработчики делают? Не говоря о том что у nginx самопальная система сборки и чтобы найти где это - надо отдельно повозиться. > сборка и тестирование на десятках виртуальных машин Где все это видно? Как это заявление проверить? > Мы активно разрабатываем и поддерживаем набор функциональных тестов. Счет тестам идет на тысячи. Но об этом только вы и знаете. Остальные об этом в лучшем случае могут догадываться. > Можете свободно пользоваться и принять участие в разработке: http://hg.nginx.org/nginx-tests/ У меня на прицеле под пушистым кроликом и asan'ом уже есть парочка интересных мне проектов. Без коммерческих версий, зато с git'ом. Мне так больше нравится. >  Покрытие кода тестами мониторится с помощью специального анализатора. Где это видно окружающим? > анализаторами, в том числе упомянутым вами Coverity еженедельно. Обнаруженные проблемы > тут же рассматриваются и устраняются. Бэджик coverity в вебе который апдейтится околореалтаймно, как у сабжа - сильно убедительнее. > Для проверки соответствия формата типу переменных в функциях логгирования был написан и > используется специальны плагин к clang. Вообще, на удивление неплохо. Признаю: я недооценил используемые в nginx методы разработки. Потому что вы это как-то очень хорошо запрятали. А я не имею ресурсов производить археологические раскопки. > 24x7 трудится несколько машин с фаззингом и ASan-ом. О том, что несколько > проблем было найдено таким способом можно узнать из коммит логов и на сайте afl-fuzz. Для меня hg означает "пусть логи коммитов почитает кто-нибудь другой". Хотя у вас вроде и зеркало в гите есть. Но, как обычно, об этом никто не узнает. > Периодически нас пытаются проверять ребята из PVS-Studio, о чем даже писали статью: > http://www.viva64.com/ru/b/0246/ ... > которые по его мнению мешают nginx быть надежным, безопасным, производительным и > функциональным веб-сервером. Ок! Если все перечисленное правда - я пожалуй был неправ в моей оценке. Однако я нахожу такую конспирацию странной. Вроде все нормально делаете. А почему стесняетесь об этом рассказать? > Жду также советов по улучшению качества кода и совершенствованию методов тестирования. Из того что под руку попалось, разное: 1) Дайте задание вашим тестировщикам попробовать найти зеркало в git, зайдя на nginx.org и послушайте что они скажут. Опенсорс начинается с кода, так? Желательно в нормальной VCS. Но это - не про nginx, найти его исходник целый отдельный гемор. Для сравения, на https://lwan.ws кнопка с исходниками в нормальной vcs светится на самом видном месте. 2) Кстати, на https://nginx.org/ у вас вообще кто-нибудь пробовал заходить? Или вы своими сайтами не пользуетесь? Почему я спрашиваю? Спросите ваших QA. Они у вас есть? Их ничего не смущает? А у той командочки из полутора человек с этим все оки. Парадокс качества. Хоть и не кода. 3) Скажите, разработчикам nginx лениво набрать несколько букв? Или у них редактор автодополнение не умеет? Кто такие u, c, b, s и что там еще? Если это следует какому-то сильно местному convention - может хотя-бы это документировать на видном месте? А лучше бы называть переменные так чтобы было понятно что это. Ну то-есть если это вопрос жизни и смерти - в этом конечно можно разобраться, но... 4) Ну вот допустим нужно мне кастомно обработать запрос и что-то дернуть в системе, etc. Это немного специфичное желание, но бывает что "глупого" сервера чуть-чуть не хватило, сервер приложений - перебор, а у сабжа код который делает именно так, на сях, занимает половинку экрана, просто эпично. В гите есть более крутой пример, с sql и json, странички полторы. Nginx'у бы не помешал пример какого-нибудь максимально тривиального модуля в том же духе на видном месте. 5) Может быть я глупый, но все-таки. Nginx использует каую-то самобытную систему сборки. И я бы не сказал что мне очевидно как в нее добавить сборку какого-нибудь своего довеска. 6) Я не знаю как ваша политика партии относится к такому, но CI'ные статусы на публику вывесить и опубликовать как вы тестируетесь по моему было бы хорошей идеей. А из-за 4) и 5) nginx вроде как бы и позволяет модули писать, но порог вхождения в десятки раз выше сабжа. Где пример не страшно выложить прямо на главной. > Спасибо.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	146. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–2 +/–
	Сообщение от Аноним (??) on 27-Апр-16, 17:26
	Я никак не связан с нгинкс, но с некоторыми из ваших претензий не согласен (хотя глубоко в исходники nginx не лазал, а только несколько раз собирал из исходников со сторонними модулями типа http_nginx_push_stream_module). > Дайте задание вашим тестировщикам попробовать найти зеркало в git Mercurial-версия есть на странице download (ссылка с главной). У вас проблемы с mercurial и вы хотите именно git? Горжусь вами, но у вашего wlan.ws та же проблема - я не вижу там ссылок на bazaar и svn. Кстати, на сайте нгинкс есть ссылки на скачивание релиза в архиве, позволяющего собрать nginx без установки dev tools. На wlan.ws я такого не нашёл. Я правильно понимаю, что это сервер исключительно для разработчиков, а никак не пользователей? > Или у них редактор автодополнение не умеет? Если для вас это настолько важно, попробуйте tomcat вместо nginx. Там хорошие идентификаторы, и тамошняя среда разработки умеет автодополнение. Как раз как вам нравится. Только не надо испражняться в nginx вашими AbstractVirtualDatabaseEntityProtocolInterfaceManager. А те, кто активно используют автодополнения, сначала используют memcpy вместо memmove, потому что им редактор так предложил, а потом обижаются, что в glibc отказываются принимать патчи, исправляюющие их криворукость. И что именно вам не понятно? b вместо buffer (притом, что пятью строками выше делается b = c->buffer и если читать код целиком, а не построчно, то всё будет ясно), или ctx вместо context?
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	148. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 27-Апр-16, 23:38
	> не согласен (хотя глубоко в исходники nginx не лазал, Иногда возникнет желание прикрутить немного логики, желательно с нативной производительностью и без уймы зависимостей. Сабж в этом явно дружественнее нжинкса. > Mercurial-версия есть на странице download (ссылка с главной). Download подразумевает скачку. Смотрение коммитов - не скачка. Еще более странно отсутствие ссылок на гит-зеркало, при том что оно есть. > wlan.ws та же проблема - я не вижу там ссылок на bazaar и svn. А еще он недоступен по протоколу gopher'а. Но это фигня, потому что у nginx сайт оказался недоступен по протоколу https. > Кстати, на сайте нгинкс есть ссылки на скачивание релиза в архиве, Если разработчик ссылается на логи коммитов - архивы не помогут. > позволяющего собрать nginx без установки dev tools. На гитхабе скачка того что видишь как архив тоже есть. > На wlan.ws я такого не нашёл. Я правильно понимаю, что это сервер исключительно > для разработчиков, а никак не пользователей? Меня он чем-то таким и заинтересовал. Судя по 3000+ звезд на GH (раза в 2 больше чем у того секретного зеркала nginx, btw) - эта штука уже много кого интересует, а я - слоупок! > Если для вас это настолько важно, Возможность въехать в код, если его пытаешься менять - имхо важна. > попробуйте tomcat вместо nginx. Ява? Это не ко мне. > AbstractVirtualDatabaseEntityProtocolInterfaceManager. Крайности плохи. Что Abstract..., что неинформативные имена. > glibc отказываются принимать патчи, исправляюющие их криворукость. Не очень понятно при чем тут я. Или нжинкс. Или сабж. > строками выше делается b = c->buffer и если читать код целиком, > а не построчно, то всё будет ясно), или ctx вместо context? Ctx - популярный convention для контекста. А вот к-е им пе то-т ч на г д-ие ctx.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	82. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Андрей (??) on 24-Апр-16, 22:15
	> "векторизированный ввод/вывод"? Кто-нибудь в мире кроме этого проекта применяет подобную терминологию? Ага. VLC. tls: use I/O vector for sending https://mailman.videolan.org/pipermail/vlc-commits/2016-Janu... gnutls: use vectorized sends on all platforms https://mailman.videolan.org/pipermail/vlc-commits/2016-Janu... tls: use I/O vector for receiving https://mailman.videolan.org/pipermail/vlc-commits/2016-Janu...
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

31. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
Сообщение от анонимчик on 24-Апр-16, 15:04
там корутины на стероидном ассемблере - есть ограничение на размер данных в стеке. при попытке разместить 8КБ - падало.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	149. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 28-Апр-16, 07:13
	> там корутины на стероидном ассемблере - есть ограничение на размер данных в > стеке. при попытке разместить 8КБ - падало. Стэк всегда ограничен. Даже без корутин. При попытке разместить 8МБ данных все падало.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	158. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от анонимчик on 24-Окт-17, 09:25
	>> там корутины на стероидном ассемблере - есть ограничение на размер данных в >> стеке. при попытке разместить 8КБ - падало. > Стэк всегда ограничен. Даже без корутин. При попытке разместить 8МБ данных все > падало. не МБ, а КБ
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

36. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
Сообщение от Аноним (??) on 24-Апр-16, 15:27
Когда планируется поддержка HTTP2?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

38. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
Сообщение от angra (ok) on 24-Апр-16, 16:04
Интересно почему столько людей пытается его сравнить с nginx, когда сравнивать его надо с другими либами и минифреймворками, реализующими http сервер.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от A.Stahl (ok) on 24-Апр-16, 16:16
	Потому что это стильно-модно и т.п. А ткни в таких крикунов пальцем и предложи назвать хоть одно преимущество nginx перед рассматриваемым мини-сервером, так они сразу и в другую сторону смотреть начинают.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	51. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:11
	сало уровнил, https://github.com/nemasu/asmttpd
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	63. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:49
	> Интересно почему столько людей пытается его сравнить с nginx, когда сравнивать его > надо с другими либами и минифреймворками, реализующими http сервер. В nginx можно свой модуль написать. Только это сложно.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

42. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
Сообщение от Аноним (??) on 24-Апр-16, 16:36
Чем оно лучше mongoose. inb: от встроенного шедулера больше проблем, чем пользы, когда дело касается интеграции с внешними либами
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	64. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+1 +/–
	Сообщение от Аноним (??) on 24-Апр-16, 17:51
	> Чем оно лучше mongoose. inb: от встроенного шедулера больше проблем, чем пользы, > когда дело касается интеграции с внешними либами Ага, тоже интересно выглядит. Только вот "Dual license: GPLv2 and commercial license" означает что коммитить туда будет только сама фирмочка.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	77. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
	Сообщение от Андрей (??) on 24-Апр-16, 19:16
	Да, нет же. Фирмочка заставит контрибьютора подписать CLA и будет использовать и его коммиты в том числе в своей закрытой версии. Вот так с помощью CLA можно обойти GPL для фирмы, первоначально опубликовавшей код. Кстати, Столлман ещё не выступал по этому поводу?
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	95. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от Аноним (??) on 25-Апр-16, 00:00
	> Да, нет же. Фирмочка заставит контрибьютора подписать CLA Поэтому контрибьютеров не будет. Каноникала хорошо проучили с апстартом на этом деле. За CLA им отлилось, вырос сильный конкурент (systemd) и просто растоптал их. В том числе и в этом аспекте. Не говоря про отсутствие глупых технических и архитектурных проблем своего предка. Если кому-то урок не в прок - они в своем праве набить шишки лично. А еще - не знаю что там насчет Столлмана, но там у этой фирмочки как-то ничего не говорится про производительность и сеьезную оптимизацию системных вызовов. Если нужен совсем мелкий, совсем embedded микросервер - есть libmicrohttpd, наконец. Но эта совсем-мелочь с неважной нагрузочной способностью (все и вся в пользу простоты и мелкого кода). Сабж в своем балансе достаточно уникален: он запилен ВЫСОКОПРОИЗВОДИТЕЛЬНЫМ, при этом немного-фреймворк наступая на хвост нжинксу с модуями, но и близко не такое монстрило с кучей исторически накопленных подпорок. Но по ресурсам влезет даже во многое из эмбедовки. Крутое сочетание.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	159. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
	Сообщение от анонимчик on 24-Окт-17, 09:26
	> Чем оно лучше mongoose. inb: от встроенного шедулера больше проблем, чем пользы, > когда дело касается интеграции с внешними либами в mongoose - вроде допотопный select?
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

76. "В рамках проекта Lwan развивается новый высокопроизводительн..."	+/–
Сообщение от lucentcode (ok) on 24-Апр-16, 18:49
Шаблоны и Lua - это интересно. То, что его можно использовать в качестве втраиваемой библиотеки - тоже весьма неплохо. В качестве замены nginx-у он пока не годится, но я думаю что в ближайшее время он и не будет с nginx конкурировать. Если прикрутят ещё поддержку скриптов на JS в дополнение к Lua - будет вообще шикарно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

131. "В рамках проекта Lwan развивается новый высокопроизводительн..."	–1 +/–
Сообщение от bOOster (ok) on 26-Апр-16, 06:19
Ну че, концепция UNIX систем разваливается? И Линуксоиды тут прикладывают максимальные усилия...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема