The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

В рамках проекта Lwan развивается новый высокопроизводительн..., opennews (??), 24-Апр-16, (0) [смотреть все]

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


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

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

9. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +5 +/
Сообщение от Аноним (-), 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*

--

Иди ***зди в другом месте, школьник! Тебе здесь не рады.

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

60. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от angra (ok), 24-Апр-16, 17:46 
Если очень хочется, то держи
35236  hw_gccgo
Динамическая линковка Go

71884  hw_cpp
Динамическая линковка C++

1948696 hw_go
Статическая линковка Go

1415286 hw_cpp_static
Статическая линковка C++

При этом заметь, я вообще не сравнивал Go с С по возможностям или встроенный http модуль Go с сабжем. Просто указал на некоторые... неточности.

Ответить | Правка | Наверх | Cообщить модератору

85. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –2 +/
Сообщение от Аноним (-), 24-Апр-16, 22:34 
Крутое сравнение. Кода нет, флагов сборки нет, какие-то цифры. Видимо на слово предлагается поверить.

Ну так вот, эксперт: на encode.ru народ в секции оффтопика развлекался тем кто crush (упаковщик такой, lempel-ziv довольно сильный, С++) меньше соберет. Ну так вот, мистер: линуксовй ELF утрамбовали в 3 килобайта, а виндовый PE EXE - в 2 с чем-то. А там серьезный match finder, неплохо руливший в свое время и прочее. Я правда только до 12 килобайтов догнался стандартными средствами gcc, в основном за счет секций.

Так что если у тебя хелловорлд в 70 кил - у тебя рукожопие и ты не умеешь gcc пользоваться. От слова вообще.

Ответить | Правка | Наверх | Cообщить модератору

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

105. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 25-Апр-16, 10:16 
> Владелец encode.ru, проследуйте на свой ресурс.

Очень жаль что я не его владелец. Потому что специалистов там в отличие от - много. С мировыми именами. Там можно повстречать и Charles Bloom-а, и Matt Mahoney, известных своими "учебниками", Yann Collett известного своими алгоритмами, ряд россиян известных своими наработками. Кто интересовался сжатием - видел эти имена. В учебниках и вокруг.

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

Ответить | Правка | Наверх | Cообщить модератору

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

136. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +1 +/
Сообщение от Аноним (-), 26-Апр-16, 16:11 
> Когда грубо сравниваются разные программы, то умные и честные люди их сравнивают
> в дефолтных настройках.

А кто тебя знает что ты считаешь "дефолтными настройками". По дефолту сишный компилер обычно оптимизаций не делает (-O0), потому что так дебажить проще. Но никто в здравом уме не кладет дебажный билд в пакеты для юзеров.

> Можешь пойти и рассказать авторам gсс и ментейнерам debian, что у них всех рукожопие

Тут в пору говорить про скудоумие. Майнтайнеры дебиана билдуют с отличными от дефолтов gcc опциями. У кого -O2, а у кого -O3, как у LZ4, где скорость - его все, а может быть и -Os, как у лисообразных браузеров.

> и их дефолты не позволяют С++ однозначно выиграть у Go идиотское соревнование

Так gcc'ом никто не компилит с дефолтами, кроме ГОпников типа тебя. У дебиана и вовсе есть мощные механизмы для применения "недефолтных" флагов на автомате. Но такие как ты не в курсе этих вещей, но мнение уже имеют. За что и получают заслуженную репутацию ламерюг.

> Кстати, в приведенном примере динамической линковки для Go сборка выполнялась используя
> gccgo, то есть в конечном итоге через тот же gcc.

Какую практическую ценность представляет твое оторванное от жизни сравнение? Никто не билдует реальные программы gcc'ом без флагов. Особенно майнтайнеры дебиана при пакетировании.

Ответить | Правка | Наверх | Cообщить модератору

59. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +1 +/
Сообщение от Аноним (-), 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), 24-Апр-16, 17:54 
Поэтому я и сказал о необходимости продемонстрировать работоспособность без libc. А то некоторые не знают, что статически слинковать ее недостаточно и вообще делать это настоятельно не рекомендуется.
Справедливости ради там был приведен пример линковки не с glibc, а с musl, которая якобы более дружественна к статической линковке. Но во-первых, это был уход в сторону от поднятого вопроса, а во-вторых, опять таки требует доказательства полной работоспособности, так как musl сама по себе не полностью совместима с glibc.
Ответить | Правка | Наверх | Cообщить модератору

68. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 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 и прочее-прочее НЕ запустить. Бери сервер на асме, чо, запускай его на фряшке, если осилишь, ссыль внизу дали.

Ответить | Правка | Наверх | Cообщить модератору

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

72. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –2 +/
Сообщение от Аноним (-), 24-Апр-16, 18:20 
>Похоже ты так и не понял, о чем речь шла.

И о чем же? Что для тебя выражение "без libc"? Я так понял это когда прога собрана со статичной линковкой, а readelf/ldd и прочие пишут, что "нет динамических символов".

Для нормального программиста без libc это когда у тебя нету никаких заголовочных файлов в /usr/include из стандартной библиотеки Си и у тебя все компилируется, а бинарник работает. Да, в Си есть 32 встроенные функции и на них можно написать _любое_ приложение с 0 (НУЛЬ) зависимостями, даже stdio.h или string.h не понадобятся!

Объясни, что ты хотел мне донести, пожалуйста, слушаю.

Ответить | Правка | Наверх | Cообщить модератору

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

81. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 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. Вперед!

Ответить | Правка | Наверх | Cообщить модератору

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

84. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –2 +/
Сообщение от Аноним (-), 24-Апр-16, 22:20 
Давай мне утилиту для проверки как ты сказал всех моментов. Или слабо отвечать за свои слова?

Вот как ты узнал, что твой сервак на go работает "без libc"? Поверил? Продолжай и дальше верить. Чем больше человек верит, тем легче им управлять.

Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

86. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –2 +/
Сообщение от Аноним (-), 24-Апр-16, 22:36 
И что ты втираешь мне все про glibc? Как это связано с кодом lwan или с кодом golang? Что, только чуваки из golang умеют собирать бинари "без libc"? Да, точно. Они, наверное, боги. А кругом все остальные п****ры, и ты, самый главный из их числа.

Все что я тебе выдал собрано gcc + musl. И свои отговорки "musl это читерство, хны-хны" засунь себе куда подальше!

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

Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

87. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –2 +/
Сообщение от Аноним (-), 24-Апр-16, 22:45 
> Это значит, что приложениие будет работать при удалении _из системы_ glibc, например
> созданием контейнера, состоящего только из самого приложения.

Дядя, ты совсем дубак? Представь себе, если программа слинкована статически - она и libc в себя влинковывает! Статически!

Ответить | Правка | Наверх | Cообщить модератору

94. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +1 +/
Сообщение от Аноним (-), 24-Апр-16, 23:54 
>Представь себе, если программа слинкована статически - она и libc в себя влинковывает!

Не совсем. Ребята из glibc постарались сделать так, что librt требует рантайм либ даже при статической линковке. Просто чтобы код не воровали: они запихнули в него подобие dlopen()

Увы, аппонент не удосужился прочесть код lwan, чтобы увидеть, что никакие подобные вызовы он не содержит, но продолжает свято верить, что golang это божественное произведение, а все что не на golang написано по определению работает не так, криво и вообще там все сломано. Конечно, проверить, что он не прав -- лень.

Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

107. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от angra (ok), 25-Апр-16, 10:53 
> Не совсем. Ребята из glibc постарались сделать так, что librt требует рантайм
> либ даже при статической линковке.

Есть и другие проблемные функции.

> Увы, аппонент не удосужился прочесть код lwan, чтобы увидеть, что никакие подобные
> вызовы он не содержит

Можно узнать, зачем _мне_ нужно читать код lwan? Я никаких утверждений на его счет вообще не делал. Только указывал на глупости и вранье других по поводу линковки в С и Go.

, но продолжает свято верить, что golang это
> божественное произведение, а все что не на golang написано по определению
> работает не так, криво и вообще там все сломано.

Признайся честно, какие вещества употреблял, когда такое увидел в треде? Попробуй перечитать, когда тебя попустит.


Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

127. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 25-Апр-16, 22:49 
>Можно узнать, зачем _мне_ нужно читать код lwan? Я никаких утверждений на его счет вообще не делал.

Сообщение 4.13, цитирую:
>Ты забыл продемонстрировать главное - его работу без libc.

Ты это, завязывай с пустословием пока пацанов совсем не расстроил. Я тебе все продемонстрировал. Ты даже hello world не прочитал: а там всего лишь один GET используется и все мои тесты/замеры укладываются в твои "все возможные ситуации" и не вызывают функций, о которых ты трясешься. Как теперь будешь отмазываться, а? Снова скажешь, что я что-то не понял? Из нас двоих ты не понимаешь главное: за базар надо отвечать и если не прав, то извинятся, как мужик. Запомни ты не идеален, когда придет время камня или пули, ты же не увернешься, а всего-то нужно было извиниться.

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

114. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 25-Апр-16, 15:35 
> Не совсем. Ребята из glibc постарались сделать так, что librt требует рантайм
> либ даже при статической линковке.

В сях можно хоть -nostdlib сказать и дальше сам как хочешь реализуй. Можно также другой libc взять, если нужно.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

133. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –1 +/
Сообщение от Аноним (-), 26-Апр-16, 11:41 
> Не совсем. Ребята из glibc постарались сделать так, что librt требует рантайм
> либ даже при статической линковке. Просто чтобы код не воровали: они
> запихнули в него подобие dlopen()

Странное решение. Тем не менее, для "runtime-less" окружений в C навалом опций, поэтому если это становится принципиально - сишник всегда свое возьмет. Гопный хипстер напрасно полез быковать в этом плане. Пусть на своем гопнике напишет бутлоадер какй-нибудь, когда 40-метровую стандартную либу технически некуда впихнуть и нет ничего, ни printf ни malloc, пока сам не напишешь, если нужны. Технически, сишечка - что-то типа умного кроссплатформенного ассемблера, а любые либы - вообще опция. Чисто-алгоритмический код даже на системные вызовы не полагается. А что, гопники смогут написать код работаюший в окружении где syscalls вообще нету? Если да - ок, тогда мы с этим гопом будем говорить на равных. А до тех пор у него нос не дорос пальцы так растопыривать, он лишь показал себя некомпетентным бддлокодером.

> Увы, аппонент не удосужился прочесть код lwan, чтобы увидеть, что никакие подобные
> вызовы он не содержит, но продолжает свято верить, что golang это
> божественное произведение,

Язык нашел свою аудиторию - вебные бддлокодеры, которым эта смесь js и питона как раз самое оно.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

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

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

45. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 24-Апр-16, 16:48 
> "Hello world" с оф.сайт (первый) в статике весит меньше метра!

А тут весь сервак 110 кил. И без затуплений из-за GC :)

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

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

41. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 24-Апр-16, 16:21 
> А питон +500 мб. Нужно просто правильно инструмент выбирать.

Очередной "не слышал, не знаю, но мое мнение таково …"
Tinypy
> implementation of python in 64k of code

впрочем,  неясно, причем тут вообще питон …

Ответить | Правка | Наверх | Cообщить модератору

46. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +2 +/
Сообщение от Аноним (-), 24-Апр-16, 16:50 
>> implementation of python in 64k of code

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

Ответить | Правка | Наверх | Cообщить модератору

67. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –1 +/
Сообщение от Нимано (?), 24-Апр-16, 18:09 
> А он по славной питоновской традиции как обычно половину скриптов выполнять не
> сможет?

И че? Вам шашечки (выполнять любые скрипты) или ехать (конкретное приложение, т.е. в этом случае http)?

> А то что сможет - будет ползать с известной скоростью,

Анонимам не угодишь.

> Динамический язык вообще сложно скомпилить, только субсет.

Нет. Динамичный язык компилять не сложно. Сложно найти динамичный (не игрушечный) язык, который бы не компилялся как минимум в байткод.

Ну и сложно "втиснуть" динамичность в такие рамки, чтобы компиляция в "нативный код"  стала действительно эффективной, а не просто эдаким "захардкоженным" аналогом интерпретатора. Поэтому и получается "эффективная" (в смысле скорости выполнения конечного результата) компиляция в основном для подмножества языка.

> А если jit - годогенерация опять же тормозит и памяти много трескает.

Т.е. скомпилировать "классическим" методом невозможно, но зато Just In Time домкраты тормозят, память трескают, но исправно компиляют не только подмножество стремительных механизмов для подъема тяжестей? o_O.

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

Ответить | Правка | Наверх | Cообщить модератору

89. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +1 +/
Сообщение от Аноним (-), 24-Апр-16, 23:24 
> И че? Вам шашечки (выполнять любые скрипты) или ехать
> (конкретное приложение, т.е. в этом случае http)?

Только скорость и потребление ресурсов будет раз в 50 хуже. До оптимизации системных вызовов как в lwan дело не дойдет. Какой смысл уменьшать количество системных вызовов, если большинство команд идущих в проц - логика интерпретатора, а не программы?

> Анонимам не угодишь.

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

> Нет. Динамичный язык компилять не сложно. Сложно найти динамичный (не игрушечный) язык,
> который бы не компилялся как минимум в байткод.

Байткод может быть и всего лишь более компактной заменой ключевых слов. Это не отменяет нужды его интерпретировать. Проблемы начинаются когда хочется сгенерить машинный код (посмотри в вике что это). Поскольку язык ДИНАМИЧЕСКИЙ, заранее все рассчитать становится очень нетривиально и вместо компилятора начинает требоваться AI, способный осознать что делает эта программа. В частности как она может менять типы во всех возможных случаях, а если там еще и что-то типа eval() есть - надо к программе еще и компилятор весь подшить, бонусом. Как максимум - или jit делают, со своими проблемами, или компилируют статичски типизированный субсет, где все сильно упрощается.

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

Поздравляю, дошло. Более того - даже когда это нативный код (JIT например) - ему придется делать множество проверок не изменился ли тип и что там еще. Если речь зашла о оптимизации количества системных вызовов как в сабже - это априори не будет конкурентом такой штуке.  

> Т.е. скомпилировать "классическим" методом невозможно, но зато Just In Time домкраты тормозят,
> память трескают, но исправно компиляют не только подмножество стремительных механизмов
> для подъема тяжестей? o_O.

Jit делают достаточно сложный анализ в рантайме и кодогенерацию. Все это и проца прилично требует и памяти кушает очень даже. В скомпилированных программах все это тоже было, но 1 раз и на этапе компиляции. Которую, возвожно, вообще другой компьтер производил. А в jit сам изволь, еще и с превышением.

> Не, я понимаю, что одно упоминание питона вызывает у вас какие-то очень
> неприятные воспоминания и соответствующую реакцию, но все же – на счет
> питона, это вам все же в соседнюю ветку, в новость про пай-пай.

Это вы тут с какими-то "приложениями" приперлись. При том что на питоне они заведомо не конкурент штуке где дошло дело до оптимизации системных вызовов.

Ответить | Правка | Наверх | Cообщить модератору

98. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –1 +/
Сообщение от Нимано (?), 25-Апр-16, 03:00 
Сами что-то придумали, сам опровергли – молодца! )

> Байткод может быть и всего лишь более компактной заменой ключевых слов. Это
> не отменяет нужды его интерпретировать.

А может быть, вы определитесь – нельзя компилировать или все же генерировать "эффективный  машинный код"?
Как хорошо, что вы забыли (после того как не знали), иначе наверняка и микрокод приплели бы (посмотрите в вашей любимой википедии что это такое, причем тут интерпретация и каким боком все это относится к "машинному").
А то очень смахивает на попытку объяснить попадание пятой точки в лужу желанием принять грязевую ванну. )

> Проблемы начинаются когда хочется сгенерить машинный
> код (посмотри в вике что это).

Кстати, википедия в этом особо не поможет, тут желательно что-то типа
http://www.intel.com/content/www/us/en/architecture-and-tech...
ну, с поправкой на архитектуру. А то боюсь, что с помощью википедии вы много не нагенеруете.

> Поскольку язык ДИНАМИЧЕСКИЙ, заранее все
> ...
> проблемами, или компилируют статичски типизированный субсет, где все сильно упрощается.  
>> стала действительно эффективной, а не просто эдаким "захардкоженным" аналогом интерпретатора.
> Поздравляю, дошло.

А, классический Отвечатель  –  прочел кусочек, ответил. Прочел следующий, ответил. Это многое объясняет.

> Более того - даже когда это нативный код (JIT например)
> - ему придется делать множество проверок не изменился ли тип и
> что там еще.

Угу, "сторожей" приставляют, чтобы отлавливать все новые типы, присылаемые из параллельной вселенной. А так все верно, да!

>> Т.е. скомпилировать "классическим" методом невозможно, но зато Just In Time домкраты тормозят,
> Jit делают достаточно сложный анализ в рантайме и кодогенерацию.

Т.е. до кое-кого так и не дошло, что Just In Time компилятор таки все же компилятор? Н-да.


> Это вы тут с какими-то "приложениями" приперлись. При том что на питоне
> они заведомо не конкурент штуке где дошло дело до оптимизации системных
> вызовов.

Хорошо наверное быть Отвечателем –  взял и придумал себе что-то, а потом и ответил, позорно посрамив всех неведомых врагов! )

Ответить | Правка | Наверх | Cообщить модератору

116. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +1 +/
Сообщение от Аноним (-), 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. И даже так - из-за динамичности производительность оказывается ниже и к тому же не постоянная. Ну то-есть про реальное время, даже самое лажовенькое, можно сразу забыть.

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

> Хорошо наверное быть Отвечателем –  взял и придумал себе что-то, а
> потом и ответил, позорно посрамив всех неведомых врагов! )

Да зачем вас срамить? Вы сами гораздо лучше справляетесь.

Ответить | Правка | Наверх | Cообщить модератору

124. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –3 +/
Сообщение от Нимано (?), 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 в частности вполне подходит для использования в "реальном времени" ? Нормально.

> Да зачем вас срамить? Вы сами гораздо лучше справляетесь.

Пишите еще! Жду с нетерпением дальнейших "посрамлений" )

Ответить | Правка | Наверх | Cообщить модератору

135. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 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 еще и в проекте нет. Зарубиться с таким инструментарием в вопросе предсказуемости операций - ну попробуй.

> Пишите еще! Жду с нетерпением дальнейших "посрамлений" )

Ну если ты так настаиваешь...

Ответить | Правка | Наверх | Cообщить модератору

137. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –2 +/
Сообщение от Нимано_ (?), 26-Апр-16, 20:19 
О, четвертый (или пятый?) "другой аноним!" подключился.

> А еще анонимы могут подключаться к дискуссии если у них есть возражения.

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

>> Зайдите в  гугол и найдите всякие трансляторы питона в С++, Си и т.д.
> И узнайте о том что они умеют сильно урезаный поддиалект? ;)

Т.е. та же nuitka умеет уже только сильно урезанный диалект? Ну окай. ЧуЙствуется очередной Эксперт.

> Неудобно это -  динамически типизированный язык в статически типизированный транслировать.
> Теоретически возможно, практически …

О, хоть один из анонимов соизволил наконец прочитать мое первое сообщение и пересказать его мне же, своими словами? Гениально! Так держать!

> Зачем у них промежуточные коды - еще можно понять. Но это внутренние
> сущности. Они мало кого интересуют кроме авторов компилятра.

Т.е. все же толк (о чем, как бы, и была речь) от них есть?

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

Знатно вы свалили с темы и перевели стрелки, хотя с фантазией у вас все в порядке )
Или проблемы не только с чтением, но и с "думаньем"?
Повторяю для тех, у кого проблемы с восприятием, речь шла о
> подумайте на досуге, как можно поместить в один массив несколько различных типов данных

т.к. по мнению какого-то из анонимов, "динамичность" нельзя нормально скомпилировать и требуется ИИ.


> Идея напихать все в массивы, не адресуемые напрямую с такой же скоростью
> как регистры да еще и норовящие осесть в медленной RAM, агрессивно
> затирая кэш - гениально, чё.

Молодец, домашнее задание засчитываю (хотя у вас и слишком много отсебятины), минусы вы осознали хорошо, а теперь, главный вопрос: что насчет возможностей? Можно так делать в Си или нельзя? Ведь там нет ИИ!

> Вот и предлагаешь способы улучшения thrashing кэша.
> {много вумных слов}
> А ты предлагашь способы засорения
> кэша. Будет очень производительно, даже не сомневайся.
> Советовать заведомо фэйловые решения типа бреда с массивами - твоя привилегия.

Какие бурные фантазии на ровном месте – Чтение явно не так хорошо дается Отвечателю, хотя вроде бы подвижки есть. Зато с фантазией все в порядке – придумал что-то, опроверг, доволен.
Все в лучших традициях анонима )

>> анонимные выводы. Правда, начисто проигнорировав ключевое слово "cторож"/guard.
> Да хоть горшком называй проверки изменений типов, на результат не влияет.

Вообще, это был намек в сторону "появления новых типов". А то, если послушать анонимов, оные прям из ниоткуда берутся. Ну и заодно, простая и очевидная попытка подловить/проверка, наскольно анонимы "в теме" обсуждаемого – благо я тоже не первый раз на опеннет зашел.
И, как мы видим – вполне сработало, анонимы один за другим упорно лажались )

Разясняю:
Вот цитатка – в отличии от анонимов, у меня нет нужнды в подтасовках и бредовой отсебятины:

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

Нормальный человек, который хоть немного "в теме" –  или сразу ответил бы, что де, так он и писал. Или сперва глянул и уточнил, а потом ответил.
Благо, как уже упоминалось раннее, пройти мимо "guard"-ов  очень таки сложно.
А знающий аноним мог бы вообще замусолить тему …
Ну, или – вообще проигнорировать и не отвечать, даже если "в теме" – мало ли чему человек не придал значения, может ему влом перед очередным опеннетчкиком хлебные крошки метать. В общем, было бы вполне нормальное поведение.

Но увы, это не про Анонимов. Анонимы, ничтоже сумняшеся опять затянули свою песнь про  типы,  да еще и пытались Тюринга к выводу оных приплести. Эпично.

Т.е., как и подозревалось, нифига анонимы не знают, но пытаются пускать в глаза пыль умными словами. Вот и тут, у одного конкретного анонима guardы оказывается входят в более общее понятие "проверки типов".
Прям хоть *рукалицо.жпг* делай — анонимам походу все божья роса )

> Не только. Ты еще слился на полном непонимании стомости операций у современных
> CPU, что такое кэш и все такое.

...
> Зачем быть тонким с кадром, который не понимает основ кэширования но машет
> интеловским маном? Ты более тонко не заметишь с таким то умищем.

Что, анонимы совсем отчаялись и пытаются использовать любой призрачный шанс? =)
Хотя да, признаю, эпичная попытка перевода стрелок! Да и в фантазии вам не откажешь.
Кстати, а пруфец где? А то очень похоже на очередное "сам придумал, сам опроверг, сам доволен".

А так – только и остается задаться вопросом, как же у вас должно <эт-самое> пониже спины, чтобы так отчаянно пытаться высосать из домашнего задания для анонимов (для Отвечателей процитирую еще раз)
> разжевывать лень, но если вы хотя бы немного знаете тот же Си, подумайте на досуге,
> как можно поместить в один массив несколько различных типов данных, что для этого
> нужно и какие у такого подхода могут быть минусы

такую знатную и шикарную отсебятину )

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

> аудитория уже задолжала анонимам за билеты в цирк.

Не очень удивительно, коль анонимы с таким упорством строят из себя клоунов-Покорителей-Луж, знатно и по нескольку раз лажаясь в каждом ответе )

===========================

> А подумать головой о том что "сторож" было включен в более общее
> понятие "проверки типов" - это для таких как ты слишком сложно?

А вот мы и добрались до очередного перла^W шедевра! )

Во первых, "осознали" вы это только после жирного намека, а вернее, разжевывания.

И главное, во вторых:
включение в «более общее понятие 'проверки типов'» вообще-то отдает очередной, сугубо личной верованием^W терминологией очередного анонима.

Потому как у всех остальных, знакомых с темой не по википедии и собственным домыслам – проверка типов может входить в обязанность "сторожа". Но вот наоборот – ну никак нет.
До этого, в принципе, даже самому дотумкать не сложно, а уж упоминаний этого …
Но это же не про анонима, который мог  промолчать или быстренько уточнить – но предпочел <эт самое в лужу>. Зато с умным видом, да. Молодца!

Так что, увы, очередная попытка спрыгнуть не удалась и вы опять расслабляетесь в лечебной грязи =)


> Что-то слишком хорошо сыграл по части кэшей и прочих массивов. Не верю
> что ты настолько талантливый актер.

Давайте давайте, переводите стрелки, авось и получится разок )


>>> К тому же jit не может тратить столько же ресурсов как компилятор на компиляцию.
>> А мусью в курсе, зачем компиляют в байткод и какие это дает возможности?
> Да, однако в конечном итоге нас интересует качество машинного кода на энной
> платформе.
> много вумных слов
> Jit так не может.

Т.е. мусью как минимум про возможности не в курсе, но продолжает делать умный вид. Ясно.
То, что конкретный jit чего-то не может, как бы вообще не показатель. Вон, те же разработчики жабоскрипто-ВМок например отнюдь не зря и по капризу левой пятки хотят "заиметь" байткод.

>> А о разных "уровнях" оптимизации?
>> Хотя, откуда.
> Да куда нам, анонимам, чай пить.

Ну вон, выше, анонимы были не в курсе преимуществ, которые может дать байтод (как раз из-за различных уровней/вариантов оптимизаций, причем львиная доля этих самых ресурсоемких оптимизаций особо от целевой машины не зависит) и исправно заладили про что-то, что якобы jit ну никак не может, ну и про нагрев воздуха не забыли – видимо наболело )

> В си можно работать и без libc, и без выделения памяти malloc'ом.
> Как тебе такой оборот?

Опять свинчивание с темы. Анонимы такие анонимы! А glibc у нас теперь на динамичном языке, да?
Или почему его нельзя использовать?

> Зарубиться с таким инструментарием в вопросе
> предсказуемости операций - ну попробуй.

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

> Ну если ты так настаиваешь...

Спасибо, Маэстро Луж, вы опять были неповторимы!

ЗЫ: молодца, взял и зарегистрировал ник.
> Участник:    Нимано
> ФИО:    Лох Педальный

Ну да – крутой аргумент, прям слов нет. Знатно у вас припекает )

Ответить | Правка | Наверх | Cообщить модератору

150. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 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.

>  Знатно у вас припекает )

Уверен что у меня? :) Впрочем, если тебе нужен этот ник - напиши какую-нибудь ненужную почту в ответе - я тебе пароль туда вышлю, пока не забыл. Мне этот ник не требуется.

Ответить | Правка | Наверх | Cообщить модератору

156. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Нимано_ (?), 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), 24-Апр-16, 13:11 
> На гоу это занимало бы мегабайт 30.

Если тебе не хватает места на диске - могу выслать карту памяти. Как раз валялась одна RS-MMC на 32 мб. В общем, пиши адрес.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

34. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним32 (?), 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 +/
Сообщение от Аноним (-), 24-Апр-16, 16:57 
> а это размер всей стандартной динамической библиотеки языка Go.

Поэтому даже heдlo world будет жрать не менее 40 метров памяти, прикинь? Просто потому что библу вгрузил. Не в обиду гугелю, libre office будет стартовать быстрее чем такие программы.

Ответить | Правка | Наверх | Cообщить модератору

66. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от angra (ok), 24-Апр-16, 18:01 
$ time ./hw >/dev/null

real    0m0.002s
user    0m0.000s
sys    0m0.002s

Сегодня просто набег лжецов.

Ответить | Правка | Наверх | Cообщить модератору

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

108. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от angra (ok), 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 с его предварительной сборкой из исходников.

Ответить | Правка | Наверх | Cообщить модератору

118. "В рамках проекта Lwan развивается новый высокопроизводительн..."  –1 +/
Сообщение от Аноним (-), 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-метровую стандартную либу. А почему я должен компилять, а ты нет? Я либрофис компилирую настолько же часто как ты - стандартную гопную библиотеку.

Ответить | Правка | Наверх | Cообщить модератору

122. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от angra (ok), 25-Апр-16, 16:46 
Вообще-то это был вариант для статической линковки, которая по дефолту в Go используется. Вариант с динамической линковкой с 40метровой либой смотри ниже у  Аноним32.

Зачем мне пересобирать полностью 40 метровую либу, когда достаточно из нее взять и собрать лишь нужные данной программе части(благо в hello world! их немного)? При этом скорость сборки у Go настолько велика, что позволяет использовать программы на нем как скрипты, то есть хранить только исходный код и собирать из него бинарь на ходу при каждом запуске. Что и было продемонстрировано во втором тайминге.

И если ты вдруг не понимаешь, то динамическая линковка со всей стандартной либой используется только в случае, если используются одновременно множество программ на Go. Либа при этом загрузится всего один раз. Точно также как однократно загружаются либы для программ на С или С++. Но об этом ты конечно не подумал. Вместо этого как дурак требуешь динамическую линковку со всей стандартной либой Go ради hello world.

Интересно, если ты так уж не веришь моим таймингам, то что тебе мешает за пять минут поставить себе Go и их проверить?

Ответить | Правка | Наверх | Cообщить модератору

139. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним (-), 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 секунды - это заведомый ЛПП, или индикация того что индивид не знает что такое погрешность измерений, не может отсеивать явно кривые результаты и вообще не способен вменяемо что-либо измерять. Даже на уровне тривиальной вузовской лабы.

Ответить | Правка | Наверх | Cообщить модератору

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

109. "В рамках проекта Lwan развивается новый высокопроизводительн..."  +/
Сообщение от Аноним32 (?), 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 (?), 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ообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру