forum.opennet.ru

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

Оглавление

Выпуск утилиты для резервного копирования rclone 1.35, opennews (?), 03-Янв-17, (0) [смотреть все]

А главное то, что написано оно на Go распространяется одним бинарём и под хоро, Фанатик (?), 10:12 , 03-Янв-17, (1) //

И поэтому пермиссивно лочит любителей свободы на считанные единицы провайдеров о, Аноним (-), 15:53 , 03-Янв-17, (21) +6

И сколько он вешает в результате , Аноним (-), 10:50 , 03-Янв-17, (2) //

12568032, стрипнутый, амд64в чем вопрос то , Аноним (-), 11:10 , 03-Янв-17, (4) –1 //

12М - это немало Тот же rsync весит 500K , freehck (ok), 15:11 , 03-Янв-17, (17) +5 //

А ничего, что rsync зависит, как минимум, от libc, popt и еще чего-то , фыв (??), 20:36 , 03-Янв-17, (39) –3

Так он же не целиком их включает, а только используемые функции В итоге весит 9, Mihail Zenkov (ok), 02:03 , 04-Янв-17, (44) +1

А его с LTO собрали А то LTO может вышибить то что не используется и в случае т, Аноним (-), 10:42 , 04-Янв-17, (47) –1

configuremake CFLAGS -static EXEEXT -static strip rsync-staticДа, с LTO как, Mihail Zenkov (ok), 14:26 , 04-Янв-17, (53) –1

Это что, вообще без оптимизаций oO А в чем пойнт Он и большой и не оптимальный, Аноним (-), 15:59 , 04-Янв-17, (56) –1

Вообще-то обычно все исходники содержат оптимизацию в системах сборки Обычно эт, Mihail Zenkov (ok), 16:43 , 04-Янв-17, (57) –2

Но если кто вкатал свои CFLAGS то как они применятся в билдсистеме это отдельный, Аноним (-), 20:51 , 04-Янв-17, (61) –2

На самом деле не так уж много если код адекватный - отдельные части функций, к, Mihail Zenkov (ok), 22:29 , 04-Янв-17, (66)

Слушай, лучше не пиши ничего про LTO Ты ж в этом мягко говря - плаваешь ж, Led (ok), 20:58 , 05-Янв-17, (69)
И в чем я не прав Напиши конкретно, по пунктам, с ссылками и примерами Будет п, Mihail Zenkov (ok), 21:51 , 05-Янв-17, (70)
Я проверял на разном софте 1 Упомянутый мной tweetnacl-lite, с которым я развле, Аноним (-), 20:50 , 10-Янв-17, (80) +1
OK, я не верно сказал LTO может вынести и функции целиком Просто затраты как , Mihail Zenkov (ok), 01:09 , 11-Янв-17, (81) –1
Это его нормальное состояние, я бы сказал А это другой вопрос В свежих gcc, кст, Аноним (-), 08:16 , 13-Янв-17, (82)

Ага, от BIOS с EFI ещё зависит , Аноним (-), 07:42 , 04-Янв-17, (45)
О, а это Go-вно не зависит от libc Т е оно у меня под BSD запустится , anoni (?), 00:24 , 06-Янв-17, (73)

Что за BSD без libc , Nas_tradamus (ok), 18:31 , 09-Янв-17, (76) –1

Лол, его самого такой в пору инкрементально синхронизировать Скоро на сидюк пом, Аноним (-), 15:55 , 03-Янв-17, (22) +5 //

двоим-обоим сверхуничего что он статик собери гцц в динамике, а не родным и буд, Аноним (-), 16:31 , 03-Янв-17, (23)

Ммм, как своевременно Нет, чтобы написать об этом сразу , freehck (ok), 16:48 , 03-Янв-17, (24)

ути путиесли влез в обсуждение то хотя бы знай особенности языка о котором рассу, Аноним (-), 16:54 , 03-Янв-17, (25)

А оно уже осилило динамическую линковку Или как обычно не работает - значит не, Аноним (-), 17:46 , 03-Янв-17, (29) –2

Ручками - да Обеща т как нить сделать Видимо из тех кто может сделать, а не ны, _ (??), 18:14 , 03-Янв-17, (33)

fxd , Аноним (-), 22:41 , 03-Янв-17, (42)

Бинарь на 12 метров даже статиком не каждый день увидишь Да мне и с rsync хорошо, Аноним (-), 10:40 , 04-Янв-17, (46) +2

Яндекс Диск же, Аноним (-), 11:07 , 03-Янв-17, (3) –2
Прикольная игрушка, но1 где ownCloud 2 все эти разношёрстные костыли не решают, Аноним (-), 12:55 , 03-Янв-17, (5) +2 //

Самопальные скрипты на базе rsync решают обычно Кстати, что ужасного в скриптах, Crazy Alex (ok), 13:05 , 03-Янв-17, (7) //

- Нужно время на разработку, тестирование и сопровождение, на каждый проект, на , Аноним (-), 14:20 , 03-Янв-17, (12) –1 //

Я, конечно, с бакулой давненько дела не имел, но насколько я помню он по неудобс, Crazy Alex (ok), 15:02 , 03-Янв-17, (16) –1

Поэтому всякие симантеки с своими backup exec и будут получать копеечку Твоя на, Аноним (-), 17:02 , 03-Янв-17, (26) +1

Плюйся ядом меньше Можно сколько угодно пытаться бэкапить раздел или даже базу, Crazy Alex (ok), 20:00 , 03-Янв-17, (38)

Да какой это яд Так, капитанинг и констатация того факта что благодаря такой си, Аноним (-), 11:46 , 04-Янв-17, (50) +1

упырьте мел, коллега в моих отрыжках на помеси гадюки с верблюдом, как вы поэти, Михрютка (ok), 22:47 , 03-Янв-17, (43) –1

Таки более-менее крупные компании усвоили некоторые простые вещи Кто по хорошем, Аноним (-), 14:18 , 04-Янв-17, (52)

работают и хлеба не просят в самом страшном случае их нельзя легально обнови, Михрютка (ok), 00:34 , 05-Янв-17, (68) –1

Через vscsc зато умеет , commiethebeastie (ok), 14:08 , 04-Янв-17, (51)

Bareos , Аноним (-), 15:21 , 03-Янв-17, (19) //

То же самое, вид сбоку С незначительными улучшениями в виде пассиовного режима, Аноним (-), 17:48 , 03-Янв-17, (30)

http burp grke org, Аноним (-), 17:50 , 03-Янв-17, (31) //

О, забавная штука Кто-то решил таки запилить более-менее нормальную бэкапалку и, Аноним (-), 20:55 , 04-Янв-17, (62)

Частично враньё Аманда это tar и все, что вокруг него вертится Руками вытащить, bac (?), 23:19 , 04-Янв-17, (67)

Так себе штуковина Оно работает, да, но, как минимум, для Amazon Cloud там алго, Crazy Alex (ok), 13:08 , 03-Янв-17, (8) +2 //

https minio io , Плохой Клоун (?), 13:43 , 03-Янв-17, (11) –1 //

И при чём здесь эта хрень , Crazy Alex (ok), 15:35 , 03-Янв-17, (20)

1 Сливаем все что нужно с удалённых серверов с использованием rsync на централь, CHERTS (??), 13:15 , 03-Янв-17, (9) +4 //

Так оно примерно с теми же трудозатратами и самим rsync делается же с --link-des, Crazy Alex (ok), 13:20 , 03-Янв-17, (10) //

Если файл в бекапе кто-то намеренно поправит, поплывут все залинкованные бекапы , Аноним (-), 14:40 , 03-Янв-17, (15) +1 //

Здесь чуть поправлю, т к сам эксплуатирую подобное на несколько ТБ Онлайн-дедуп, PnDx (ok), 11:43 , 09-Янв-17, (75) –1

В целом солюшн самый адекватный, но пока не получится на него соскочитьДля неадм, Аноним (-), 14:30 , 03-Янв-17, (14) //

Зачем Кстати безопасность тоже будет против А для списка авторизованных - ну и , _ (??), 18:38 , 03-Янв-17, (34) +1
У вас там любят раздавать гранаты обезьянам, чтобы посмотреть что получится Нет, Аноним (-), 20:09 , 04-Янв-17, (58)

Имеем радость жизни Когда под блоком который расшарен на все 100500 снапшотов к, Аноним (-), 17:15 , 03-Янв-17, (28) //

В случае с ZFS контрольная сумма не сойдётся и тебе напишет мол так и так - файл, Аноним (-), 20:37 , 03-Янв-17, (40) –1 //

Ага Файл помер Смотрим мы - а он такой дохлый разом во ВСЕХ снапшотах, наприме, Аноним (-), 14:50 , 04-Янв-17, (54) –2

От повреждения файла или чанка в диф бэкапах спасает только полное его копирова, Аноним (-), 21:29 , 04-Янв-17, (63) +1

Просто нормальный бэкапный софт все это умеет вообще без приявзки к файлухе и ка, Аноним (-), 16:30 , 13-Янв-17, (83)

Очень интересно общаться с человеком, которому пишешь про схему 3-2-1 которая п, Твой факапчик (?), 21:49 , 04-Янв-17, (64) +1

Хм, я как-то пропустил этот момен Да ничего я не продаю Просто констатирую что , Аноним (-), 16:36 , 13-Янв-17, (84)

Чувак, ты не прав Если ZFS пулл собран админом на нескольких дисках, например, Аноним (-), 22:06 , 06-Янв-17, (74) //

то мы вспоминаем что бэкапы нужны раз в сто лет а хоанилка начинает удорожать, Аноним (-), 16:57 , 13-Янв-17, (85)

Что будете делать, если центральный сервер поломается , XoRe (ok), 10:45 , 04-Янв-17, (48) //

А это как в анекдоте про поимку льва голыми руками - А если это будет львица - Н, Аноним (-), 15:07 , 04-Янв-17, (55)

Freenas, NEXENTA, ananim (?), 15:18 , 03-Янв-17, (18) –1 //

В каком месте они - решения для бэкапа и синхронизации , Аноним (-), 17:08 , 03-Янв-17, (27) //

Вон в том выше по топику И не решение, конечно, а часть решения , _ (??), 18:45 , 03-Янв-17, (37) –1

doh и еще экспортированные, как блочный девайс, чтобы усугубить ситуацию вконец, Михрютка (ok), 21:18 , 03-Янв-17, (41)
NAS - это обычно железка размером меньше чем рабочее место бородача Указанное в, Твой факапчик (?), 22:01 , 04-Янв-17, (65)

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

2. "Выпуск утилиты для резервного копирования rclone 1.35" +/–

Сообщение от Аноним (-), 03-Янв-17, 10:50

> распространяется одним бинарём
И сколько он вешает в результате?

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

4. "Выпуск утилиты для резервного копирования rclone 1.35" –1 +/–

Сообщение от Аноним (-), 03-Янв-17, 11:10

12568032, стрипнутый, амд64
в чем вопрос то ?

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

17. "Выпуск утилиты для резервного копирования rclone 1.35" +5 +/–

Сообщение от freehck (ok), 03-Янв-17, 15:11

> 12568032, стрипнутый, амд64
12М - это немало.
Тот же rsync весит ~500K.

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

39. "Выпуск утилиты для резервного копирования rclone 1.35" –3 +/–

Сообщение от фыв (??), 03-Янв-17, 20:36

А ничего, что rsync зависит, как минимум, от libc, popt и еще чего-то?

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

44. "Выпуск утилиты для резервного копирования rclone 1.35" +1 +/–

Сообщение от Mihail Zenkov (ok), 04-Янв-17, 02:03

Так он же не целиком их включает, а только используемые функции. В итоге весит 905.7K
http://communities.vmware.com/servlet/JiveServlet/download/1...

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

47. "Выпуск утилиты для резервного копирования rclone 1.35" –1 +/–

Сообщение от Аноним (-), 04-Янв-17, 10:42

> Так он же не целиком их включает, а только используемые функции. В
> итоге весит 905.7K
А его с LTO собрали? А то LTO может вышибить то что не используется и в случае типовой програмы она может еще примерно на четверть сдуться. Хотя от программы зависит.

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

53. "Выпуск утилиты для резервного копирования rclone 1.35" –1 +/–

Сообщение от Mihail Zenkov (ok), 04-Янв-17, 14:26

> А его с LTO собрали?
./configure
make CFLAGS="-static" EXEEXT="-static"
strip rsync-static
> А то LTO может вышибить то что не используется и в случае типовой програмы она может еще примерно на четверть сдуться. Хотя от программы зависит.
Да, с LTO как повезет - может меньше стать, а может и больше - если компилятор inline активно использовать начнет.

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

56. "Выпуск утилиты для резервного копирования rclone 1.35" –1 +/–

Сообщение от Аноним (-), 04-Янв-17, 15:59

> make CFLAGS="-static" EXEEXT="-static"
> strip rsync-static
Это что, вообще без оптимизаций? oO А в чем пойнт? Он и большой и не оптимальный по скорости. Смысл в таком виде компилить - разве что злостный дебагбилд. В половине случаев можно отдебажить прямо оптимизированый btw :)
> Да, с LTO как повезет - может меньше стать, а может и
> больше - если компилятор inline активно использовать начнет.
LTO на фазе линковки случается (link-time optimization же). И на генерацию кода стало быть не влияет. Как я понимаю, линкер делает отдельный pass при котором он агрессивно изучает какой код не используется и его можно убить. И все неиспользуемые функции и проч отправляются нафиг. Увеличить программу сие как я понимаю не может by design. Но вот время линковки заметно увеличивается + проход с анализом что можно выкинуть требует на финальной фазе линковки довольно много памяти, если программа большая.
Случаев чтобы LTO _увеличил_ программу я вообще ни разу не встречал. Но вот насколько уменьшение бинаря vs увеличение времени линковки и потребления памяти порадует - может варьироваться для разных программ.

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

57. "Выпуск утилиты для резервного копирования rclone 1.35" –2 +/–

Сообщение от Mihail Zenkov (ok), 04-Янв-17, 16:43

> Это что, вообще без оптимизаций?
Вообще-то обычно все исходники содержат оптимизацию в системах сборки. Обычно это -O2.
> Как я понимаю, линкер делает отдельный pass при котором он агрессивно изучает какой код не используется и его можно убить.
Это его побочное действие. Основное как раз inline и прочие подобные оптимизации.
man gcc:
Since both foo.o and bar.o are merged into a single image, this causes all the interprocedural analyses and optimizations in GCC to work across the two files as if they were a single one. This means, for example, that the inliner is able to inline functions in bar.o into functions in foo.o and vice-versa.
> Случаев чтобы LTO _увеличил_ программу я вообще ни разу не встречал.
Я специально не проверял, но думаю это вполне вероятно при агрессивной оптимизации и большом количестве мелких функций.

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

61. "Выпуск утилиты для резервного копирования rclone 1.35" –2 +/–

Сообщение от Аноним (-), 04-Янв-17, 20:51

> Вообще-то обычно все исходники содержат оптимизацию в системах сборки.
Но если кто вкатал свои CFLAGS то как они применятся в билдсистеме это отдельный вопрос. В результате пример какой-то не очень иллюстративный, чтоли: не видно что фактически получил компилер.
> Обычно это -O2.
Сейчас и -O3 в принципе попадается. Он быстрее, но более грабельный.
> Это его побочное действие.
Это "побочное" действие имеет свойство выносить туеву хучу кода.
> Основное как раз inline и прочие подобные оптимизации.
Я так понимаю что он может угрохать всякие сохранения регистров и проч которые как бы нужны, если это совсем независимый модуль вызываемый совсем без допущений. А тут появляется full view как оно вызывается и можно обрубить сохранение регистров которые caller'ам были пофиг. Оно в результате более уже не независимый модуль и как попало вызывать уже не того. Ну и да, инлайнить можно, более информированно чем ранее. А почему нет?
> one. This means, for example, that the inliner is able to
> inline functions in bar.o into functions in foo.o and vice-versa.
Ну да. И как я понимаю перегрузки регистров можно глобально обкусить, т.к. известно кто и как вызывает. А если перегрузки обкусить - объем кода, очевидно, убавится.
> Я специально не проверял, но думаю это вполне вероятно при агрессивной оптимизации
> и большом количестве мелких функций.
В мелких функциях по идее инлайнинг как раз хорошая штука? Экономия на всяких прологах-эпилогах, никаких сохранений регистров. Сэкономили на сохранениях-восстановлениях, растратили на коде. Выполняется быстрее и полезнее. Если код мелкий то хорошо работает: код не пухнет но ускоряется. И у gcc вроде есть анализы когда и что выгоднее. На больших функциях выгода от инлайна незначительна т.к. оверхед на сопутствующие приседания небольшой, а пухнет сильно. А для мелочи как раз критично - время служебных операций может стать сравнимо с временем в функции. И сишники такое по жизни костыляли #define'ами. Но у них читаемость и форматирование на любителя, и вообще костыль.

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

66. "Выпуск утилиты для резервного копирования rclone 1.35" +/–

Сообщение от Mihail Zenkov (ok), 04-Янв-17, 22:29

> Это "побочное" действие имеет свойство выносить туеву хучу кода.
На самом деле не так уж много (если код адекватный) - отдельные части функций, которые не используются.
Больше всего выбрасывает -ffunction-sections -fdata-sections + -Wl,--gc-sections так как выкидывает неиспользуемые функции и данные целиком.
>> Я специально не проверял, но думаю это вполне вероятно при агрессивной оптимизации
>> и большом количестве мелких функций.
> Если код мелкий то хорошо работает: код не пухнет но ускоряется.
Зависит от того какой код. Допустим 10% уходило на вызов + сохранение + восстановление регистров. Мы инлайним эту функцию  10-100 раз - код растет.
> И у gcc вроде есть анализы когда и что выгоднее.
AFAIK зависит от агрессивности оптимизации, сам он точно рассчитать и предсказать не может. Для этого нужно исполнить код с типичными данными на входе. У gcc есть и такой режим (забыл как он называется).
> На больших функциях выгода от
> инлайна незначительна т.к. оверхед на сопутствующие приседания небольшой, а пухнет сильно.
Не всегда. Например большая функция на несколько страниц с switch на кучу case. Она может быть разбита и преобразована в десятки мелких функций.

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

69. "Выпуск утилиты для резервного копирования rclone 1.35" +/–

Сообщение от Led (ok), 05-Янв-17, 20:58

>> Это "побочное" действие имеет свойство выносить туеву хучу кода.
> На самом деле не так уж много (если код адекватный) - отдельные
> части функций, которые не используются.
> Больше всего выбрасывает -ffunction-sections -fdata-sections + -Wl,--gc-sections так
> как выкидывает неиспользуемые функции и данные целиком.
Слушай, лучше не пиши ничего про LTO. Ты ж в этом... мягко говря - плаваешь... жалко выглядишь. Пиши лучше про roxbox, паяльник и работу под root'ом.

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

70. "Выпуск утилиты для резервного копирования rclone 1.35" +/–

Сообщение от Mihail Zenkov (ok), 05-Янв-17, 21:51

И в чем я не прав? Напиши конкретно, по пунктам, с ссылками и примерами. Будет полезно и мне и другим. А то только переходить на личности и ср*ть на форуме горазд. За последний год ни одного поста конструктивного от тебе не увидел.

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

80. "Выпуск утилиты для резервного копирования rclone 1.35" +1 +/–

Сообщение от Аноним (-), 10-Янв-17, 20:50

> части функций, которые не используются.
Я проверял на разном софте.
1) Упомянутый мной tweetnacl-lite, с которым я развлекаюсь засовывая его в cortex-M. Если с LTO собрать, но нигде не вызвать, LTO его выносит целиком. Ну то-есть от него ничего не остается. Если другого кода не было - я получаю пустой бинарь, состоящий из дефолтных vectors. Как еще эффективнее код выносить я даже и не знаю :)
2) В большом сложном бинаре на плюсах LTO вырубил примерно четверть кода.
Как по мне так там с -flto -fwhole-program (whole-program имеет некие особенности, ахтунг) dead code вырубается очень даже.
> Больше всего выбрасывает -ffunction-sections -fdata-sections + -Wl,--gc-sections так
> как выкидывает неиспользуемые функции и данные целиком.
Упомянутое вроде бы вырубает неиспользуемые функции просто в ноль. И особенности особенностями, а в типовых случаях не вижу никаих проблем. Законы мерфи не отменяли.
> Зависит от того какой код. Допустим 10% уходило на вызов + сохранение
> + восстановление регистров. Мы инлайним эту функцию  10-100 раз - код растет.
Если мы вместо 10% на сохранение потратим это на инлайн - какая, собственно, разница? Единственным достижением станет более шустрый код, где прологи-эпилоги заменятся на мелкую функцию. А так там эвристика есть, IIRC, на предмет что выгоднее. Все это если не указан явно инлайн или ноинлайн, конечно же, там компилер будет следовать указаниям програмера.
>> И у gcc вроде есть анализы когда и что выгоднее.
> AFAIK зависит от агрессивности оптимизации, сам он точно рассчитать и предсказать не может.
Не знаю как насчет точности но при решении инлайнить или нет если не было явного хинта, оценивается размер кода функции vs экономия от отсутствия пролога-эпилога и принимается решение, инлайнить или нет. На первый взгляд вполне разумно сделано. Пардон не помню где читал описание уровней и lto.
> Для этого нужно исполнить код с типичными данными на входе.
> У gcc есть и такой режим (забыл как он называется).
Вы про profile-guided optimization чтоли? Это несколько другое. Они как-то геморно делаются и настолько круто мне, имхо, не надо.
> Не всегда. Например большая функция на несколько страниц с switch на кучу
> case. Она может быть разбита и преобразована в десятки мелких функций.
Вполне возможно, но я не знаю насколько анализатор это умеет. Он умеет настолько много что всех его умений я не знаю.

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

81. "Выпуск утилиты для резервного копирования rclone 1.35" –1 +/–

Сообщение от Mihail Zenkov (ok), 11-Янв-17, 01:09

>> части функций, которые не используются.
> Я проверял на разном софте.
> 1) Упомянутый мной tweetnacl-lite, с которым я развлекаюсь засовывая его в cortex-M.
> Если с LTO собрать, но нигде не вызвать, LTO его выносит
> целиком.
OK, я не верно сказал. LTO может вынести и функции целиком. Просто затраты (как CPU, так и RAM) на это будут гораздо большими, чем с -ffunction-sections -fdata-sections + -Wl,--gc-sections. Точно не помню, сколько памяти надо для сборки FF с LTO, но за 4GB перевалило давно. Если цель уменьшить бинарник - то и gc-sections хватит. Если цель скорость исполнения - однозначно LTO, но бинарник из-за inline может стать и больше.
> Как по мне так там с -flto -fwhole-program (whole-program имеет некие особенности,
> ахтунг) dead code вырубается очень даже.
Ну на AVR я как раз -fwhole-program и использую. Она несовместима с LTO - используется вместо LTO.
>> Зависит от того какой код. Допустим 10% уходило на вызов + сохранение
>> + восстановление регистров. Мы инлайним эту функцию  10-100 раз - код растет.
> Если мы вместо 10% на сохранение потратим это на инлайн - какая,
> собственно, разница?
Выигрываем 10% по скорости, проигрываем 900% - 9000% по памяти/кэшу.
> Единственным достижением станет более шустрый код, где прологи-эпилоги
> заменятся на мелкую функцию. А так там эвристика есть, IIRC, на
> предмет что выгоднее.
ХЗ как оно может оценить пользу от inline, не имея на входе типичных данных. Может эта функция вызывается раз в году? А память будет расходоваться всегда.
> Не знаю как насчет точности но при решении инлайнить или нет если
> не было явного хинта, оценивается размер кода функции vs экономия от
> отсутствия пролога-эпилога и принимается решение, инлайнить или нет.
Если я правильно понял из мана - то в основном все сводится к длине функции (можно подрегулировать руками) - если функция больше определенной длинны - inline не используется.
> Вы про profile-guided optimization чтоли?
Да оно.
> Это несколько другое. Они как-то геморно делаются
> и настолько круто мне, имхо, не надо.
Зависит от задачи. В теории - имея типичные входные данные компилятор значительно лучше сможет выполнить оптимизацию.
> Вполне возможно, но я не знаю насколько анализатор это умеет. Он умеет
> настолько много что всех его умений я не знаю.
Да, и постоянно новые способы добавляют. С циклами он вообще много интересного умеет. При выходе новых версий gcc часто примеры кода показывают и как он его хорошо разбирает и перекомпоновывает.

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

82. "Выпуск утилиты для резервного копирования rclone 1.35" +/–

Сообщение от Аноним (-), 13-Янв-17, 08:16

> OK, я не верно сказал. LTO может вынести и функции целиком.
Это его нормальное состояние, я бы сказал.
> Просто затраты (как CPU, так и RAM) на это будут гораздо большими,
> чем с -ffunction-sections -fdata-sections + -Wl,--gc-sections.
А это другой вопрос. В свежих gcc, кстати, LTO основательно разогнали а потребление RAM убавили.
> Точно не помню, сколько памяти надо для сборки FF с LTO, но за 4GB перевалило давно.
Вот это не знаю, не пробовал такого монстра. На 5-меговой софтине на плюсах лопало около гига памяти, чтоли. Кстати LTO агрессивно оптимизировали по ресурсам в gcc 5.x/6.x, да и скорость компиляции прилично подтянули, особенно на уровнях с оптимизацией.
> цель скорость исполнения - однозначно LTO, но бинарник из-за inline может
> стать и больше.
В среднем по больнице результат таков что прога сдувается по размеру а скорость такая же или чуть лучше. Т.е. я бы больше радовался уменьщению кода.
> Ну на AVR я как раз -fwhole-program и использую. Она несовместима с LTO - используется вместо LTO.
Насколько я помню -fwhole-program это какой-то хинт LTO-оптимизатору на самом деле, что надо полный анализ по всей программе и можно сделать небезопасные маневры, так что снаружи функции вызывать будет нельзя. Но я не знаю что там на авр сейчас. У убунтуев и дебиана для них почему-то gcc древний, 4.9 чтоли. Для ARM у меня такой же версии как и системный.
> Выигрываем 10% по скорости, проигрываем 900% - 9000% по памяти/кэшу.
Не вижу, опять же. Если проигрыш по кэшу - должны быть просадки скорости как раз? Да и раз кода меньше - то и кэш свободнее? Можно конечно perf-ом потыкаться если принципиально.
А еще - у cortex M кэша нет, микроконтроллеры же.
> ХЗ как оно может оценить пользу от inline, не имея на входе типичных данных.
Прикинув как этот размер кода vs заскипаный на этом пролог/эпилог соотносится?
> Может эта функция вызывается раз в году? А память будет расходоваться всегда.
Опять же - не вижу раздувания кода от LTO.
> к длине функции (можно подрегулировать руками) - если функция больше определенной
> длинны - inline не используется.
Значит мой склероз мне не врет, как-то так.
>> Вы про profile-guided optimization чтоли?
> Да оно.
Вот с ним я не разбирался.
> Зависит от задачи. В теории - имея типичные входные данные компилятор значительно
> лучше сможет выполнить оптимизацию.
Оно как бы да, но возни много. Ну его такое кроме крайних случаев.
> Да, и постоянно новые способы добавляют. С циклами он вообще много интересного
> умеет. При выходе новых версий gcc часто примеры кода показывают и
> как он его хорошо разбирает и перекомпоновывает.
У gcc нынче один только ман на командлайн читать можно устать :)
зы мне надоели местные модеры, меня они потерли раза три а красования леда по жизни не трогают, давайте может куда-нибудь на ресурс с более комфортной атмосферой, а? я от такой модерации устал, она не способствует конструктивным дискуссиям, вообще совсем.

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

45. "Выпуск утилиты для резервного копирования rclone 1.35" +/–

Сообщение от Аноним (-), 04-Янв-17, 07:42

Ага, от BIOS с EFI ещё зависит.

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

73. "Выпуск утилиты для резервного копирования rclone 1.35" +/–

Сообщение от anoni (?), 06-Янв-17, 00:24

> А ничего, что rsync зависит, как минимум, от libc, popt и еще чего-то?
О, а это Go-вно не зависит от libc? Т.е. оно у меня под BSD запустится?

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

76. "Выпуск утилиты для резервного копирования rclone 1.35" –1 +/–

Сообщение от Nas_tradamus (ok), 09-Янв-17, 18:31

Что за BSD без libc? :)

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

22. "Выпуск утилиты для резервного копирования rclone 1.35" +5 +/–

Сообщение от Аноним (-), 03-Янв-17, 15:55

> 12568032, стрипнутый, амд64
> в чем вопрос то ?
Лол, его самого такой в пору инкрементально синхронизировать. Скоро на сидюк помещаться перестанет :)

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

23. "Выпуск утилиты для резервного копирования rclone 1.35" +/–

Сообщение от Аноним (-), 03-Янв-17, 16:31

двоим-обоим сверху
ничего что он статик ?
собери гцц в динамике, а не родным и будет тебе счастье
потому повторю
> в чем вопрос то ?

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

24. "Выпуск утилиты для резервного копирования rclone 1.35" +/–

Сообщение от freehck (ok), 03-Янв-17, 16:48

> двоим-обоим сверху
> ничего что он статик ?
Ммм, как своевременно. Нет, чтобы написать об этом сразу.

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

25. "Выпуск утилиты для резервного копирования rclone 1.35" +/–

Сообщение от Аноним (-), 03-Янв-17, 16:54

ути пути
если влез в обсуждение то хотя бы знай особенности языка о котором рассуждаешь

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

29. "Выпуск утилиты для резервного копирования rclone 1.35" –2 +/–

Сообщение от Аноним (-), 03-Янв-17, 17:46

А оно уже осилило динамическую линковку? Или как обычно "не работает - значит не нужно"?

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

33. "Выпуск утилиты для резервного копирования rclone 1.35" +/–

Сообщение от _ (??), 03-Янв-17, 18:14

Ручками - да. Обеща.т как нить сделать. Видимо из тех кто может сделать, а не ныть не нашлось таких кому вот прямо позарез ... :-)

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

42. "Выпуск утилиты для резервного копирования rclone 1.35" +/–

Сообщение от Аноним (-), 03-Янв-17, 22:41

> Обещают как нить сделать. Видимо из тех кто может сделать, а не обещать не нашлось таких кому вот прямо позарез нужен go ... :-)
fxd.

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

46. "Выпуск утилиты для резервного копирования rclone 1.35" +2 +/–

Сообщение от Аноним (-), 04-Янв-17, 10:40

> ничего что он статик ?
Бинарь на 12 метров даже статиком не каждый день увидишь.
> собери гцц в динамике, а не родным и будет тебе счастье
Да мне и с rsync хорошо, он даже на 8Мб флеху роутера умещается. Там в 8 мегах вся система живет. Ну и пакет с рсинком до кучи чтобы на usb-хард бэкапаться. Телефон, понимаешь, рсинком сливает нафотканое когда замечает нужную сеть.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

2. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
Сообщение от Аноним (-), 03-Янв-17, 10:50
> распространяется одним бинарём И сколько он вешает в результате?
Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Аноним (-), 03-Янв-17, 11:10
	12568032, стрипнутый, амд64 в чем вопрос то ?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Выпуск утилиты для резервного копирования rclone 1.35"	+5 +/–
	Сообщение от freehck (ok), 03-Янв-17, 15:11
	> 12568032, стрипнутый, амд64 12М - это немало. Тот же rsync весит ~500K.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	39. "Выпуск утилиты для резервного копирования rclone 1.35"	–3 +/–
	Сообщение от фыв (??), 03-Янв-17, 20:36
	А ничего, что rsync зависит, как минимум, от libc, popt и еще чего-то?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Выпуск утилиты для резервного копирования rclone 1.35"	+1 +/–
	Сообщение от Mihail Zenkov (ok), 04-Янв-17, 02:03
	Так он же не целиком их включает, а только используемые функции. В итоге весит 905.7K http://communities.vmware.com/servlet/JiveServlet/download/1...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Аноним (-), 04-Янв-17, 10:42
	> Так он же не целиком их включает, а только используемые функции. В > итоге весит 905.7K А его с LTO собрали? А то LTO может вышибить то что не используется и в случае типовой програмы она может еще примерно на четверть сдуться. Хотя от программы зависит.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	53. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Mihail Zenkov (ok), 04-Янв-17, 14:26
	> А его с LTO собрали? ./configure make CFLAGS="-static" EXEEXT="-static" strip rsync-static > А то LTO может вышибить то что не используется и в случае типовой програмы она может еще примерно на четверть сдуться. Хотя от программы зависит. Да, с LTO как повезет - может меньше стать, а может и больше - если компилятор inline активно использовать начнет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Аноним (-), 04-Янв-17, 15:59
	> make CFLAGS="-static" EXEEXT="-static" > strip rsync-static Это что, вообще без оптимизаций? oO А в чем пойнт? Он и большой и не оптимальный по скорости. Смысл в таком виде компилить - разве что злостный дебагбилд. В половине случаев можно отдебажить прямо оптимизированый btw :) > Да, с LTO как повезет - может меньше стать, а может и > больше - если компилятор inline активно использовать начнет. LTO на фазе линковки случается (link-time optimization же). И на генерацию кода стало быть не влияет. Как я понимаю, линкер делает отдельный pass при котором он агрессивно изучает какой код не используется и его можно убить. И все неиспользуемые функции и проч отправляются нафиг. Увеличить программу сие как я понимаю не может by design. Но вот время линковки заметно увеличивается + проход с анализом что можно выкинуть требует на финальной фазе линковки довольно много памяти, если программа большая. Случаев чтобы LTO _увеличил_ программу я вообще ни разу не встречал. Но вот насколько уменьшение бинаря vs увеличение времени линковки и потребления памяти порадует - может варьироваться для разных программ.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Выпуск утилиты для резервного копирования rclone 1.35"	–2 +/–
	Сообщение от Mihail Zenkov (ok), 04-Янв-17, 16:43
	> Это что, вообще без оптимизаций? Вообще-то обычно все исходники содержат оптимизацию в системах сборки. Обычно это -O2. > Как я понимаю, линкер делает отдельный pass при котором он агрессивно изучает какой код не используется и его можно убить. Это его побочное действие. Основное как раз inline и прочие подобные оптимизации. man gcc: Since both foo.o and bar.o are merged into a single image, this causes all the interprocedural analyses and optimizations in GCC to work across the two files as if they were a single one. This means, for example, that the inliner is able to inline functions in bar.o into functions in foo.o and vice-versa. > Случаев чтобы LTO _увеличил_ программу я вообще ни разу не встречал. Я специально не проверял, но думаю это вполне вероятно при агрессивной оптимизации и большом количестве мелких функций.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Выпуск утилиты для резервного копирования rclone 1.35"	–2 +/–
	Сообщение от Аноним (-), 04-Янв-17, 20:51
	> Вообще-то обычно все исходники содержат оптимизацию в системах сборки. Но если кто вкатал свои CFLAGS то как они применятся в билдсистеме это отдельный вопрос. В результате пример какой-то не очень иллюстративный, чтоли: не видно что фактически получил компилер. > Обычно это -O2. Сейчас и -O3 в принципе попадается. Он быстрее, но более грабельный. > Это его побочное действие. Это "побочное" действие имеет свойство выносить туеву хучу кода. > Основное как раз inline и прочие подобные оптимизации. Я так понимаю что он может угрохать всякие сохранения регистров и проч которые как бы нужны, если это совсем независимый модуль вызываемый совсем без допущений. А тут появляется full view как оно вызывается и можно обрубить сохранение регистров которые caller'ам были пофиг. Оно в результате более уже не независимый модуль и как попало вызывать уже не того. Ну и да, инлайнить можно, более информированно чем ранее. А почему нет? > one. This means, for example, that the inliner is able to > inline functions in bar.o into functions in foo.o and vice-versa. Ну да. И как я понимаю перегрузки регистров можно глобально обкусить, т.к. известно кто и как вызывает. А если перегрузки обкусить - объем кода, очевидно, убавится. > Я специально не проверял, но думаю это вполне вероятно при агрессивной оптимизации > и большом количестве мелких функций. В мелких функциях по идее инлайнинг как раз хорошая штука? Экономия на всяких прологах-эпилогах, никаких сохранений регистров. Сэкономили на сохранениях-восстановлениях, растратили на коде. Выполняется быстрее и полезнее. Если код мелкий то хорошо работает: код не пухнет но ускоряется. И у gcc вроде есть анализы когда и что выгоднее. На больших функциях выгода от инлайна незначительна т.к. оверхед на сопутствующие приседания небольшой, а пухнет сильно. А для мелочи как раз критично - время служебных операций может стать сравнимо с временем в функции. И сишники такое по жизни костыляли #define'ами. Но у них читаемость и форматирование на любителя, и вообще костыль.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Mihail Zenkov (ok), 04-Янв-17, 22:29
	> Это "побочное" действие имеет свойство выносить туеву хучу кода. На самом деле не так уж много (если код адекватный) - отдельные части функций, которые не используются. Больше всего выбрасывает -ffunction-sections -fdata-sections + -Wl,--gc-sections так как выкидывает неиспользуемые функции и данные целиком. >> Я специально не проверял, но думаю это вполне вероятно при агрессивной оптимизации >> и большом количестве мелких функций. > Если код мелкий то хорошо работает: код не пухнет но ускоряется. Зависит от того какой код. Допустим 10% уходило на вызов + сохранение + восстановление регистров. Мы инлайним эту функцию 10-100 раз - код растет. > И у gcc вроде есть анализы когда и что выгоднее. AFAIK зависит от агрессивности оптимизации, сам он точно рассчитать и предсказать не может. Для этого нужно исполнить код с типичными данными на входе. У gcc есть и такой режим (забыл как он называется). > На больших функциях выгода от > инлайна незначительна т.к. оверхед на сопутствующие приседания небольшой, а пухнет сильно. Не всегда. Например большая функция на несколько страниц с switch на кучу case. Она может быть разбита и преобразована в десятки мелких функций.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Led (ok), 05-Янв-17, 20:58
	>> Это "побочное" действие имеет свойство выносить туеву хучу кода. > На самом деле не так уж много (если код адекватный) - отдельные > части функций, которые не используются. > Больше всего выбрасывает -ffunction-sections -fdata-sections + -Wl,--gc-sections так > как выкидывает неиспользуемые функции и данные целиком. Слушай, лучше не пиши ничего про LTO. Ты ж в этом... мягко говря - плаваешь... жалко выглядишь. Пиши лучше про roxbox, паяльник и работу под root'ом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	70. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Mihail Zenkov (ok), 05-Янв-17, 21:51
	И в чем я не прав? Напиши конкретно, по пунктам, с ссылками и примерами. Будет полезно и мне и другим. А то только переходить на личности и ср*ть на форуме горазд. За последний год ни одного поста конструктивного от тебе не увидел.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Выпуск утилиты для резервного копирования rclone 1.35"	+1 +/–
	Сообщение от Аноним (-), 10-Янв-17, 20:50
	> части функций, которые не используются. Я проверял на разном софте. 1) Упомянутый мной tweetnacl-lite, с которым я развлекаюсь засовывая его в cortex-M. Если с LTO собрать, но нигде не вызвать, LTO его выносит целиком. Ну то-есть от него ничего не остается. Если другого кода не было - я получаю пустой бинарь, состоящий из дефолтных vectors. Как еще эффективнее код выносить я даже и не знаю :) 2) В большом сложном бинаре на плюсах LTO вырубил примерно четверть кода. Как по мне так там с -flto -fwhole-program (whole-program имеет некие особенности, ахтунг) dead code вырубается очень даже. > Больше всего выбрасывает -ffunction-sections -fdata-sections + -Wl,--gc-sections так > как выкидывает неиспользуемые функции и данные целиком. Упомянутое вроде бы вырубает неиспользуемые функции просто в ноль. И особенности особенностями, а в типовых случаях не вижу никаих проблем. Законы мерфи не отменяли. > Зависит от того какой код. Допустим 10% уходило на вызов + сохранение > + восстановление регистров. Мы инлайним эту функцию 10-100 раз - код растет. Если мы вместо 10% на сохранение потратим это на инлайн - какая, собственно, разница? Единственным достижением станет более шустрый код, где прологи-эпилоги заменятся на мелкую функцию. А так там эвристика есть, IIRC, на предмет что выгоднее. Все это если не указан явно инлайн или ноинлайн, конечно же, там компилер будет следовать указаниям програмера. >> И у gcc вроде есть анализы когда и что выгоднее. > AFAIK зависит от агрессивности оптимизации, сам он точно рассчитать и предсказать не может. Не знаю как насчет точности но при решении инлайнить или нет если не было явного хинта, оценивается размер кода функции vs экономия от отсутствия пролога-эпилога и принимается решение, инлайнить или нет. На первый взгляд вполне разумно сделано. Пардон не помню где читал описание уровней и lto. > Для этого нужно исполнить код с типичными данными на входе. > У gcc есть и такой режим (забыл как он называется). Вы про profile-guided optimization чтоли? Это несколько другое. Они как-то геморно делаются и настолько круто мне, имхо, не надо. > Не всегда. Например большая функция на несколько страниц с switch на кучу > case. Она может быть разбита и преобразована в десятки мелких функций. Вполне возможно, но я не знаю насколько анализатор это умеет. Он умеет настолько много что всех его умений я не знаю.
	Ответить \| Правка \| К родителю #66 \| Наверх \| Cообщить модератору


	81. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Mihail Zenkov (ok), 11-Янв-17, 01:09
	>> части функций, которые не используются. > Я проверял на разном софте. > 1) Упомянутый мной tweetnacl-lite, с которым я развлекаюсь засовывая его в cortex-M. > Если с LTO собрать, но нигде не вызвать, LTO его выносит > целиком. OK, я не верно сказал. LTO может вынести и функции целиком. Просто затраты (как CPU, так и RAM) на это будут гораздо большими, чем с -ffunction-sections -fdata-sections + -Wl,--gc-sections. Точно не помню, сколько памяти надо для сборки FF с LTO, но за 4GB перевалило давно. Если цель уменьшить бинарник - то и gc-sections хватит. Если цель скорость исполнения - однозначно LTO, но бинарник из-за inline может стать и больше. > Как по мне так там с -flto -fwhole-program (whole-program имеет некие особенности, > ахтунг) dead code вырубается очень даже. Ну на AVR я как раз -fwhole-program и использую. Она несовместима с LTO - используется вместо LTO. >> Зависит от того какой код. Допустим 10% уходило на вызов + сохранение >> + восстановление регистров. Мы инлайним эту функцию 10-100 раз - код растет. > Если мы вместо 10% на сохранение потратим это на инлайн - какая, > собственно, разница? Выигрываем 10% по скорости, проигрываем 900% - 9000% по памяти/кэшу. > Единственным достижением станет более шустрый код, где прологи-эпилоги > заменятся на мелкую функцию. А так там эвристика есть, IIRC, на > предмет что выгоднее. ХЗ как оно может оценить пользу от inline, не имея на входе типичных данных. Может эта функция вызывается раз в году? А память будет расходоваться всегда. > Не знаю как насчет точности но при решении инлайнить или нет если > не было явного хинта, оценивается размер кода функции vs экономия от > отсутствия пролога-эпилога и принимается решение, инлайнить или нет. Если я правильно понял из мана - то в основном все сводится к длине функции (можно подрегулировать руками) - если функция больше определенной длинны - inline не используется. > Вы про profile-guided optimization чтоли? Да оно. > Это несколько другое. Они как-то геморно делаются > и настолько круто мне, имхо, не надо. Зависит от задачи. В теории - имея типичные входные данные компилятор значительно лучше сможет выполнить оптимизацию. > Вполне возможно, но я не знаю насколько анализатор это умеет. Он умеет > настолько много что всех его умений я не знаю. Да, и постоянно новые способы добавляют. С циклами он вообще много интересного умеет. При выходе новых версий gcc часто примеры кода показывают и как он его хорошо разбирает и перекомпоновывает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	82. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (-), 13-Янв-17, 08:16
	> OK, я не верно сказал. LTO может вынести и функции целиком. Это его нормальное состояние, я бы сказал. > Просто затраты (как CPU, так и RAM) на это будут гораздо большими, > чем с -ffunction-sections -fdata-sections + -Wl,--gc-sections. А это другой вопрос. В свежих gcc, кстати, LTO основательно разогнали а потребление RAM убавили. > Точно не помню, сколько памяти надо для сборки FF с LTO, но за 4GB перевалило давно. Вот это не знаю, не пробовал такого монстра. На 5-меговой софтине на плюсах лопало около гига памяти, чтоли. Кстати LTO агрессивно оптимизировали по ресурсам в gcc 5.x/6.x, да и скорость компиляции прилично подтянули, особенно на уровнях с оптимизацией. > цель скорость исполнения - однозначно LTO, но бинарник из-за inline может > стать и больше. В среднем по больнице результат таков что прога сдувается по размеру а скорость такая же или чуть лучше. Т.е. я бы больше радовался уменьщению кода. > Ну на AVR я как раз -fwhole-program и использую. Она несовместима с LTO - используется вместо LTO. Насколько я помню -fwhole-program это какой-то хинт LTO-оптимизатору на самом деле, что надо полный анализ по всей программе и можно сделать небезопасные маневры, так что снаружи функции вызывать будет нельзя. Но я не знаю что там на авр сейчас. У убунтуев и дебиана для них почему-то gcc древний, 4.9 чтоли. Для ARM у меня такой же версии как и системный. > Выигрываем 10% по скорости, проигрываем 900% - 9000% по памяти/кэшу. Не вижу, опять же. Если проигрыш по кэшу - должны быть просадки скорости как раз? Да и раз кода меньше - то и кэш свободнее? Можно конечно perf-ом потыкаться если принципиально. А еще - у cortex M кэша нет, микроконтроллеры же. > ХЗ как оно может оценить пользу от inline, не имея на входе типичных данных. Прикинув как этот размер кода vs заскипаный на этом пролог/эпилог соотносится? > Может эта функция вызывается раз в году? А память будет расходоваться всегда. Опять же - не вижу раздувания кода от LTO. > к длине функции (можно подрегулировать руками) - если функция больше определенной > длинны - inline не используется. Значит мой склероз мне не врет, как-то так. >> Вы про profile-guided optimization чтоли? > Да оно. Вот с ним я не разбирался. > Зависит от задачи. В теории - имея типичные входные данные компилятор значительно > лучше сможет выполнить оптимизацию. Оно как бы да, но возни много. Ну его такое кроме крайних случаев. > Да, и постоянно новые способы добавляют. С циклами он вообще много интересного > умеет. При выходе новых версий gcc часто примеры кода показывают и > как он его хорошо разбирает и перекомпоновывает. У gcc нынче один только ман на командлайн читать можно устать :) зы мне надоели местные модеры, меня они потерли раза три а красования леда по жизни не трогают, давайте может куда-нибудь на ресурс с более комфортной атмосферой, а? я от такой модерации устал, она не способствует конструктивным дискуссиям, вообще совсем.
	Ответить \| Правка \| К родителю #81 \| Наверх \| Cообщить модератору


	45. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (-), 04-Янв-17, 07:42
	Ага, от BIOS с EFI ещё зависит.
	Ответить \| Правка \| К родителю #39 \| Наверх \| Cообщить модератору


	73. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от anoni (?), 06-Янв-17, 00:24
	> А ничего, что rsync зависит, как минимум, от libc, popt и еще чего-то? О, а это Go-вно не зависит от libc? Т.е. оно у меня под BSD запустится?
	Ответить \| Правка \| К родителю #39 \| Наверх \| Cообщить модератору


	76. "Выпуск утилиты для резервного копирования rclone 1.35"	–1 +/–
	Сообщение от Nas_tradamus (ok), 09-Янв-17, 18:31
	Что за BSD без libc? :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Выпуск утилиты для резервного копирования rclone 1.35"	+5 +/–
	Сообщение от Аноним (-), 03-Янв-17, 15:55
	> 12568032, стрипнутый, амд64 > в чем вопрос то ? Лол, его самого такой в пору инкрементально синхронизировать. Скоро на сидюк помещаться перестанет :)
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	23. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (-), 03-Янв-17, 16:31
	двоим-обоим сверху ничего что он статик ? собери гцц в динамике, а не родным и будет тебе счастье потому повторю > в чем вопрос то ?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от freehck (ok), 03-Янв-17, 16:48
	> двоим-обоим сверху > ничего что он статик ? Ммм, как своевременно. Нет, чтобы написать об этом сразу.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (-), 03-Янв-17, 16:54
	ути пути если влез в обсуждение то хотя бы знай особенности языка о котором рассуждаешь
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Выпуск утилиты для резервного копирования rclone 1.35"	–2 +/–
	Сообщение от Аноним (-), 03-Янв-17, 17:46
	А оно уже осилило динамическую линковку? Или как обычно "не работает - значит не нужно"?
	Ответить \| Правка \| К родителю #23 \| Наверх \| Cообщить модератору


	33. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от _ (??), 03-Янв-17, 18:14
	Ручками - да. Обеща.т как нить сделать. Видимо из тех кто может сделать, а не ныть не нашлось таких кому вот прямо позарез ... :-)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	42. "Выпуск утилиты для резервного копирования rclone 1.35"	+/–
	Сообщение от Аноним (-), 03-Янв-17, 22:41
	> Обещают как нить сделать. Видимо из тех кто может сделать, а не обещать не нашлось таких кому вот прямо позарез нужен go ... :-) fxd.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Выпуск утилиты для резервного копирования rclone 1.35"	+2 +/–
	Сообщение от Аноним (-), 04-Янв-17, 10:40
	> ничего что он статик ? Бинарь на 12 метров даже статиком не каждый день увидишь. > собери гцц в динамике, а не родным и будет тебе счастье Да мне и с rsync хорошо, он даже на 8Мб флеху роутера умещается. Там в 8 мегах вся система живет. Ну и пакет с рсинком до кучи чтобы на usb-хард бэкапаться. Телефон, понимаешь, рсинком сливает нафотканое когда замечает нужную сеть.
	Ответить \| Правка \| К родителю #23 \| Наверх \| Cообщить модератору