Почему так сильно может лагать stdlib?

0

1

./code/test/utils/bximemutils.c
    defines:
        defined: BX_MEM_NONE: 0x000000
        defined: BX_MEM_ZERO: 0x000001
    functions:
        checking: bxi_memopt_set
        checking: bxi_memerr_set
        checking: bxi_malloc_set
        checking: bxi_malloc
        checking: bxi_realloc_set
        checking: bxi_realloc
        checking: bxi_free_set
        checking: bxi_free
        checking: bxi_memset
            speedtest:     memset  :  0.01649
            speedtest: bxi_memset  :  0.04130
        checking: bxi_memcpy
            speedtest:     memcpy  :  0.01038
            speedtest: bxi_memcpy  :  0.04120
        checking: bxi_memmove
            speedtest:     memmove :  0.01202
            speedtest: bxi_memmove :  0.04034
        checking: bxi_memcmp
            speedtest:     memcmp  :  1.63799
            speedtest: bxi_memcmp  :  0.58350
        checking: bxi_memfrob
            speedtest:     memfrob :  0.07995
            speedtest: bxi_memfrob :  0.08031
        checking: bxi_memchr
        checking: bxi_memrchr
PASSED

tk@pro7:/tmp/git/codemeow/bixi/bin
$ head -10 /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 58
model name	: Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz
stepping	: 9
microcode	: 0x12
cpu MHz		: 3300.000
cache size	: 8192 KB
physical id	: 0
tk@pro7:/tmp/git/codemeow/bixi/bin
$ uname -a
Linux pro7 3.8.5 #4 SMP Mon Oct 9 18:48:32 MSK 2017 i686 Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz GenuineIntel GNU/Linux
$ ls -l /lib/libc-2.11.1.so
-rwxr-xr-x 1 root root 1649149 2010-05-13 10:55 /lib/libc-2.11.1.so*

Реп: https://github.com/codemeow/bixi (сборка ./scripts/build.sh release, бинари будут в bin)
Как это можно объяснить?

Ссылка

←	stdin и stdout

Красивый способ превращать числа в строки, заданные подобным #define IAC 0x01

→

Помочь не могу, но не вижу версии слаки. И не видно из текста, что собственно не так? А как должно быть так? Что-то должно быть быстрее, или какое-то число меньше чем сейчас есть?

I-Love-Microsoft ★★★★★
(10.11.17 15:01:49 MSK)

Объяснить что? Твоё желание поставить тег 32-бит для процессора с 64-битным набором команд?

P.S. Сомневаюсь, что кто-то на этом форуме пойдёт изучайть твои исходники, какие бы красивые и понятные они не были бы :)

mky ★★★★★
(10.11.17 15:07:12 MSK)

Ответ на: комментарий от I-Love-Microsoft 10.11.17 15:01:49 MSK

И не видно из текста, что собственно не так?

memcmp из stdlib ВНЕЗАПНО в три раза медленнее самописной версии. На х64 он обгоняет меня раза в 2.

PPP328 ★★★★★
(10.11.17 15:11:46 MSK) автор топика

Ответ на: комментарий от mky 10.11.17 15:07:12 MSK

Желание не мое. Дистрибутив был подготовлен для софта. Обновить его до х64 не выйдет - поломается все окружение (скрипты, программы и пр, все надо портировать).

PPP328 ★★★★★
(10.11.17 15:26:43 MSK) автор топика

Ответ на: комментарий от PPP328 10.11.17 15:26:43 MSK

Просто мысль, как помочь твоей беде: есть ли возможность опробовать этот тест на каком-нибудь самом современном из доступных 32-битных дистрибутивов? А то может конкретно с этой версией трабла. Ну или собрать stdlib последней версии в окружении этого дистрибутива хотя бы чисто для теста.

I-Love-Microsoft ★★★★★
(10.11.17 15:28:42 MSK)

Ответ на: комментарий от I-Love-Microsoft 10.11.17 15:28:42 MSK

Ну или собрать stdlib последней версии в окружении этого дистрибутива хотя бы чисто для теста.

Без вариантов, это production нода, там нельзя ничего ломать(

есть ли возможность опробовать этот тест на каком-нибудь самом современном из доступных 32-битных дистрибутивов?

Я уже все вокруг оббегал, у всех только х64 стоит.

PPP328 ★★★★★
(10.11.17 15:30:44 MSK) автор топика

Ответ на: комментарий от PPP328 10.11.17 15:11:46 MSK

А что, код stdlib уже закрыли, из-за чего вместо того чтобы туда посмотреть ты лезешь на форум? Вангую что stdlib собран, в отличие от твоего кода, без поддержки SIMD и/или древним компилятором не умеющим в оптимизации.

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

slovazap ★★★★★
(10.11.17 16:06:59 MSK)
Последнее исправление: slovazap 10.11.17 16:09:01 MSK (всего исправлений: 3)

Ответ на: комментарий от slovazap 10.11.17 16:06:59 MSK

Вы пробовали смотреть исходники glibc? Я - да. Там чертово наслоение из макросов, проверок архитектуры - а под самым низом ассемблер.

PPP328 ★★★★★
(10.11.17 16:10:07 MSK) автор топика

Ответ на: комментарий от PPP328 10.11.17 16:10:07 MSK

Вам что, не хватает квалификации раскрыть 2 уровня однострочных макросов и прочитать полстраницы ассемблерного кода? Или может вы считаете что это будут делать за вас?

slovazap ★★★★★
(10.11.17 16:12:38 MSK)
Последнее исправление: slovazap 10.11.17 16:13:30 MSK (всего исправлений: 1)

Ссылка

А тег «slackware» тут, простите, при чём?

Slackware		linux		glibc		gcc
2016-07-01 14.2		4.4.x		2.23		5.3.0
2013-11-07 14.1		3.10.x		2.17		4.8.2
2012-09-28 14.0		3.2.x		2.15		4.7.1
2011-04-28 13.37	2.6.37.x	2.13		4.5.2
2010-05-24 13.1		2.6.33.x	2.11.1		4.4.4

У вас:

			linux		glibc		gcc
			3.8.5		2.11		???

bormant ★★★★★
(10.11.17 16:20:47 MSK)
Последнее исправление: bormant 10.11.17 16:25:36 MSK (всего исправлений: 1)

Ответ на: комментарий от slovazap 10.11.17 16:06:59 MSK

ТС, интересно, может стянуть образ системы на целевой ноде и всё-таки попытаться собрать лапками, тоже мысль была про ключи оптимизации и т.п.

I-Love-Microsoft ★★★★★
(10.11.17 16:27:42 MSK)

Ссылка

Ответ на: комментарий от bormant 10.11.17 16:20:47 MSK

На узле стоит слака 13.1 с кастомным ядром.

PPP328 ★★★★★
(10.11.17 16:31:48 MSK) автор топика

Ответ на: комментарий от PPP328 10.11.17 16:31:48 MSK

Почему glibc не пропатчен, держите ханипот и коллекционируете уязвимости?
slackware-13.1/patches/packages/glibc-2.11.1-i486-9_slack13.1.txz

Wed Jan 28 19:23:00 UTC 2015
patches/packages/glibc-2.11.1-i486-9_slack13.1.txz:  Rebuilt.
  This update patches a security issue __nss_hostname_digits_dots() function
  of glibc which may be triggered through the gethostbyname*() set of
  functions.  This flaw could allow local or remote attackers to take control
  of a machine running a vulnerable version of glibc.  Thanks to Qualys for
  discovering this issue (also known as the GHOST vulnerability.)
  For more information, see:
    https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0235
  (* Security fix *)

Там много еще чего есть:
slackware-13.1/patches/packages/

bormant ★★★★★
(10.11.17 17:00:20 MSK)
Последнее исправление: bormant 10.11.17 17:03:32 MSK (всего исправлений: 3)

Ссылка

Ответ на: комментарий от PPP328 10.11.17 16:31:48 MSK

Пересобрать несложно, исходники и слакбилд здесь:
slackware-13.1/patches/source/glibc/

Не забыть про:

# NOTE!!!  glibc needs to be built against the sanitized kernel headers,
# which will be installed under /usr/include by the kernel-headers package.
# Be sure the correct version of the headers package is installed BEFORE
# building glibc!

Пакет в patches собран с OPTIMIZ="-O3 -march=i486 -mtune=i686". Возможно, оптимальными под ваш процессор будут иные ключи.

bormant ★★★★★
(10.11.17 17:10:05 MSK)
Последнее исправление: bormant 10.11.17 17:14:48 MSK (всего исправлений: 3)

Ссылка

Ответ на: комментарий от PPP328 10.11.17 15:26:43 MSK

А есть уверенность, что memcmp именно из библиотеки gnu libc, а не встраиваемая (builtin) функция от компилятора(gcc)?

Допустим это: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052

mky ★★★★★
(10.11.17 17:56:58 MSK)

Ответ на: комментарий от mky 10.11.17 17:56:58 MSK

Уверенности нет, как проверить?

PPP328 ★★★★★
(10.11.17 19:29:54 MSK) автор топика

Ответ на: комментарий от PPP328 10.11.17 19:29:54 MSK

Попробовать скомпилировать с опцией ″-fno-builtin-memcmp″ и сравнить. И ещё можно отдельно для сравнения скомпилировать без оптимизации ″O0″, тогда встроенных функций вобще не будет.

mky ★★★★★
(10.11.17 20:52:22 MSK)

Ссылка

Ответ на: комментарий от PPP328 10.11.17 15:30:44 MSK

Я уже все вокруг оббегал, у всех только х64 стоит.

Про мультилиб у вас не слышали?
-m32:

        checking: bxi_memcmp
            speedtest:     memcmp  :  0.13374
            speedtest: bxi_memcmp  :  0.69128

-m64 (по дефолту):

        checking: bxi_memcmp
            speedtest:     memcmp  :  0.09465
            speedtest: bxi_memcmp  :  0.31422

libc:

[d_a@home bixi]$ rpm -qa glibc
glibc-2.17-196.el7.i686
glibc-2.17-196.el7.x86_64

d_a ★★★★★
(10.11.17 21:04:56 MSK)

Ссылка

Ответ на: комментарий от mky 10.11.17 15:07:12 MSK

P.S. Сомневаюсь, что кто-то на этом форуме пойдёт изучайть твои исходники, какие бы красивые и понятные они не были бы :)

С чего бы? Здесь как бы Development. Я например, пошёл и изучил (и оплевался со школоскриптов вместо сборочной системы). И мой код тоже изучали.

d_a ★★★★★
(10.11.17 21:12:54 MSK)

Ответ на: комментарий от d_a 10.11.17 21:12:54 MSK

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

xmikex ★★★★
(10.11.17 21:24:49 MSK)

Ответ на: комментарий от xmikex 10.11.17 21:24:49 MSK

Makefile (самописный или генерируемый).

d_a ★★★★★
(10.11.17 21:28:42 MSK)

Ответ на: комментарий от mky 10.11.17 15:07:12 MSK

P.S. Сомневаюсь, что кто-то на этом форуме пойдёт изучайть твои исходники

Я честно у царя просмотрел несколько исходников. И Реактось почитывал.

~~redgremlin~~ ★★★★★
(10.11.17 21:40:43 MSK)

Ответ на: комментарий от d_a 10.11.17 21:28:42 MSK

С его инопланетным синтаксисом? Нет, спасибо.

PPP328 ★★★★★
(10.11.17 21:51:42 MSK) автор топика

Ответ на: комментарий от PPP328 10.11.17 21:51:42 MSK

То что автор не с Земли я уже понял.

d_a ★★★★★
(10.11.17 22:00:44 MSK)

Ссылка

Ответ на: комментарий от d_a 10.11.17 21:28:42 MSK

а генерируется у тебя Makefile не скриптом configure?

xmikex ★★★★
(10.11.17 23:03:54 MSK)

Товарищ! Бери да смотри сгенерированный машинный код. Зачем гадать?

~~dzidzitop~~ ★★
(10.11.17 23:07:55 MSK)

Ссылка

Ответ на: комментарий от xmikex 10.11.17 23:03:54 MSK

а генерируется у тебя Makefile не скриптом configure?

Вы отличаете сборочную систему от генератора сборочной системы?

И, чтобы не отвечать вопросом на вопрос, нет, у меня лично Makefile генерируется не скриптом configure.

d_a ★★★★★
(10.11.17 23:10:37 MSK)
Последнее исправление: d_a 10.11.17 23:12:40 MSK (всего исправлений: 1)

Ответ на: комментарий от d_a 10.11.17 23:10:37 MSK

вообще Makefile это тип сценариев (скриптов) для программы make

xmikex ★★★★
(10.11.17 23:16:52 MSK)

Ответ на: комментарий от xmikex 10.11.17 23:16:52 MSK

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

d_a ★★★★★
(10.11.17 23:32:59 MSK)

Ответ на: комментарий от d_a 10.11.17 23:32:59 MSK

как о неподходящей

Обоснуй. Может make автоматом сгенерить хедеры? Нет. Нужно его устанавливать на целевую систему - да.

PPP328 ★★★★★
(10.11.17 23:43:39 MSK) автор топика
Последнее исправление: PPP328 10.11.17 23:44:25 MSK (всего исправлений: 1)

Ответ на: комментарий от redgremlin 10.11.17 21:40:43 MSK

Месье знает толк в извpащениях! :)

И, на всякий случай, скобочка в моих фразах означает смайлик, а то мало ли что, Development, лисперы. И та фраза про красоту — это был намёк ТС, чтобы он как-то прокомментировал, что именно ему не нравится. Она была написана до того, как он написал про memcmp и про то, что не может сменить версии софта. Без этих его пояснений исходный пост выглядил странно.

Думаю, что d_a прочитает этот пост, но на всякий случай скастую.