Объединение Entware-ng и Entware-3x. Теперь это просто Entware!!!

[Voxel]

Источник цитаты Компилятор go очень быстрый даже на embeded устройствах.

Все же C побыстрее будет. Для WireGuard автор при компиляции модуля ядра использует часть кодов из OpenSSL от Энди Полякова для АРМов. Т.е. neon, ассемблерная акселерация... С Go версией WG что-то делается с использованием ассемблера, но как я понял не настолько эффективно.

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

go version go1.13.6 linux/amd64



Voxel.

[Voxel]

Источник цитаты Первые пакеты на go собирались именно с помощью cgo

Как мне кажется, для wireguard-go использование CGO достаточно критично, так как он тогда использует libpthread - т.е. multithread. Будет пахать на всех ядрах процессора, в отличии от OpenVPN.

Voxel.

[Zyxmon]

Быстродействие бинарников cgo VS go я не сравнивал. Помню на хабре было такое сравнение. От cgo пришлось отказаться, т.к. не для всех платформ собирались бинарники судя по этому комиту - https://github.com/Entware/Entware/comm ... 7f6b277255
Сама компиляция на go (нативная и кросс очень быстрая - это однозначно).

[Voxel]

Источник цитаты Сама компиляция на go (нативная и кросс очень быстрая - это однозначно).

Согласен. Хотя пока с большими проектами под Go не сталкивался. Идея Go, конечно, интересная - особенно для кросс-платформенных проектов. Типа, сиди себе под PC и компилируй для чего хочешь без всяких тулчейнов...

Ну а быстродействие go vs cgo - тут гугл выдает победу за cgo.

Впрочем, я с Go только начинающий. Начал его смотреть только из-за wireguard-go. Сам WG - я тут реально в ауте. По моим тестам и моих пользователей скорость даже выше, чем обычный канал от провайдера без WG. Правда, и сам роутер мощный: 4-ядерный 1.7ГГц. Но с OpenVPN скорость выше 120 не поднималась при канале 200/200, человек имел 185/220, а с WG (нормальная, с модулями ядра) 189/230. Вот и стал думать, может Go версия тоже пошустрее будет...

Voxel.

[Voxel]

Добрый вечер,

Сейчас вожусь с выпуском Entware для Cortex-A15. Надо все же держать пользователей в тонусе. Несколько предложений для уважаемых товарищей (не побоюсь этого слова) из команды "Entware"

1. OpenVPN. Вижу, что тут изменения к лучшему, но все же там есть очень вредный патч, который убивает использование внешней liblz4:

package/network/services/openvpn/patches/210-build_always_use_internal_lz4.patch

ну из самого название патча все понятно... Желательно бы и репортировать это в OpenWRT. Пусть это убьют.

2. liblz4. Там есть возможность ускорения, если добавить в Makefile

TARGET_CFLAGS += -DLZ4_FORCE_MEMORY_ACCESS=1 -DXXH_FORCE_MEMORY_ACCESS=1

это для ARM-ов... Начиная с 6-ой версии ARM.

3. GCC 7.4.0 (feeds/packages/devel/gcc)

Тут при использовании float-abi=hard есть проблемка... Сборка libatomic вылетает. Там используются опции "-march=armv7-a". Чисто зашито в Makefile.am и в Makefile.in. Но в новых компиляторах по умолчанию это подразумевает soft для float. Т.е. если я использую что-то типа -float-abi=hard, то компиляция грохается... Пишет "selected processor lacks an FPU". В libatomic. Я на коленке патч для своей модели сделал, но все же это не есть хорошо... Я меняю в патче -march=armv7-a на -march=armv7-a+fp в Makefile.in и Makefile.am... Тогда срабатывает.

Я дико извиняюсь, но все же у вас более тесные контакты с группой OpenWRT. Если вас не затруднит, сообщите им issues...


Спасибо,
Voxel.

[Александр Рыжов]

Источник цитаты 1. OpenVPN. Вижу, что тут изменения к лучшему, но все же там есть очень вредный патч, который убивает использование внешней liblz4:

OpenWrt помешаны на размере пакетов и вряд ли согласятся.

[Voxel]

Источник цитаты OpenWrt помешаны на размере пакетов и вряд ли согласятся.

Хмм... Там всего-то 180KB - это как максимум. Я как-то тоже не могу размахиваться с размерами пакетов в прошивке. Но это реально дает прирост производительности. Тут какой-нибудь dnscrypt-proxy2 размером в 8MB, а тут всего-то 150-180KB...

Причем, liblz4 они все же обновили до 1.92. Ну а для чего еще эта библиотека нужна...

Спасибо за комментарий.

Voxel.

[Zyxmon]

Источник цитаты Сейчас вожусь с выпуском Entware для Cortex-A15.

Интересно какая сборка. То, что сейчас на github еще не выложено.

Источник цитаты Там используются опции "-march=armv7-a".

Сейчас флаги сборки (прежде всего для arm) поменялись. Изменения и в тулчейне и во флагах оптимизации. march не используется.

[Voxel]

Источник цитаты Интересно какая сборка. То, что сейчас на github еще не выложено.

Да, я так... Ну просто. Что у вас там сейчас в активе - то и вытащил. Ну чуть обновил кое-какие пакеты. Типа php7, wireguard-tools, nginx, что-то еще... Правлю на лету, с чем проблемы. Обновляю, что уже обновил в своих прошивках. Сейчас есть чуть времени. Потом его не найду.

Источник цитаты Сейчас флаги сборки (прежде всего для arm) поменялись. Изменения и в тулчейне и во флагах оптимизации. march не используется.

Это я заметил. march там в gcc зашит в libatomic в 7.4.0. Я тоже совсем не использую march - он конфликтует с -mcpu=cortex-a15, убивает расширенный набор инструкций. Для нативного gcc сойдет, лишь бы тот скомпилировался.

P.S. в очередной раз восхищен объемом работы, который тянете...

Voxel.

[Voxel]

Нда... 2573 пакета. Perfecto. Только вот собрал. Ну вы, блин, даете...

А вот вопрос: не будет проблем у пользователей с opkg update / opkg upgrade при переходе на новый компилятор при том же glibc? Или советовать все с нуля переустанавливать?

Voxel.