Rust 1.24

Динамическая же

https://play.rust-lang.org/?gist=1f266b609d156ed38b6541d6d0b459a9&version...

Насколько я понимаю, тут статически компонуются всего лишь библиотеки ввода и вывода, но почему компилятор раста создаёт бинарник, который весит в 6 раз больше?

Потому, что бинарники таскают батарейки в себе. jemalloc, libbacktrace, отладочные символы... Всё это, правда, можно выкинуть, если очень нужно.

Пока я ковырял в носу, продвинутые ребята оказались не так уж и заняты. Меня тем временем мучает вопрос, в чём соль вопроса:

Вот как получить экземпляр типажа из ARC, чтобы можно было вызвать его метод?

если объект из Arc вытаскивается обычным разыменованием.

У Си он составляет 15 Килобайт, у Раста 3,3 Мегабайт.
весит в 6 раз больше

Шта?

https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html

Затык на 220 строке. Код: https://github.com/sinitcin/poll_engine

Если я правильно понял, то нужно:

        let parent = self.parent();
        let mut parent_borrowed = parent.borrow_mut();
        parent_borrowed.read();

По другому никак: описав у функции read self как мутабл, вы потребовали, чтоб раст гарантировал, что рид вызовется только в эксклюзивном режиме. Арк - это многопоточная хрень, никаких гарантий от состояния гонки нет. Соответственно, нужно запаковать в рефцелл и проверять правила займа динамически. Ну и да, читайте доку к refcell'у, этот код может запаниковать. Возможно, стоит поменять на мутекс какой.

Ну или игнорировать ее, поставить иксы и забыть.

есть опция ядра quiet

Спустя пол года эта фигня пропала, сейчас поставил Devuan и ничего не писало.

Возможно, стоит поменять на мутекс какой.

Не «возможно», а нужно. RefCell работает только в одном потоке. Если попробовать передать Arc<RefCell<T>> в другой поток, будет ошибка компиляции.

Вы правы, я конкретно протупил. Конечно, или мутекс внутри арка, или рефцел внутри рц.

Если я правильно понял, то нужно:

Ёшкин кот, ты просто красавчик!!!!! Я себе неделю мозг ломал, даже Cell использовал по аналогии с твоим примером, но не допёр заюзать RefCell итить колотить как всё сложилось хорошо =) Огромное спасибо)))

Да в целом это будет работать внутри одного потока, но не в главном.

vblats ★ (17.02.2018 18:25:07) «Я рад что ты гуру питона, и рад что у питона есть свой синтаксис и парадигма, но я создал тему, ПОТОМУ ЧТО МЛЯТЬ НЕ ПРОГРАММИСТ, с целью спросить НА КАКОМ ЯЗЫКЕ ЛУЧШЕ ВСЕГО ПИСАТЬ GTK.»

В итоге получаем поиск по ключу (основная операция для хэштаблицы!) O(n), притом насилующий кэши

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

http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

Слышали когда-нибудь про UNIX, про его культуру разработки?

А ты не забыл удалить отладочную информацию командой strip?

Ты о чём? Просмотрел

man rustc[/rust], там нет ключа типа [strip]--strip[/strip] Там наоборот написано, для того чтобы дебажная инфа вставлялась в бинарь надо доплнительно прописать ключик -g. Хотя, если честно, компиляция с ключиком -g даёт тот же размер бинарника.

Видимо размер бинарника 3.3 Мегабайта из-за того, что в rust 

println![/rust] -- это макрос. В Си же 

printf[/rust] -- это библиотека.

Кто-нибудь сравнивал размеры бинарников Си и Rust работающих как демоны скомпилированных без функций и макросов ввода-вывода?

Извини совесем запутался в лоркоде. Я надеюсь ты понял о чём я

Я о том что берешь программу strip из пакета binutis и даешь ей бинарь:

$ cargo build --release
$ strip target/release/helloworld
$ ls -lh target/release/helloworld
-rwxr-xr-x 2 user user 440K Feb 19 11:48 target/release/helloworld

Еще можно динамически слинковаться со стандартной библиотекой:

$ RUSTFLAGS="-C prefer_dynamic" cargo build --release
$ ls -lh target/release/helloworld
-rwxr-xr-x 2 user user 15K Feb 19 11:43 target/release/helloworld

Странно, про RefCell упоминается прямо на странице доков к Arc, в секции `Thread Safety`.

Спасибо, но это как-бы «внештатные рецепты» облегчения.

Должно быть честно. Только: исходник --> трансляция ---> связывание ---> бинарь. И всё!

Выше видел ссылку на английском языке. Честно говоря я не очень в этот язык вхож. Там вроде тоже описаны рецепты облегчения бинарей.

Вот только мой фундаментальный вопрос так и остался без ответа. Почему по-умолчанию хелоуворд бинарника весит 3,3 Мегабайта? Да, println! — это макрос, но ведь не до такой же степени надо разбухать. Я тут не для того чтобы тролить, но когда увидел размер бинари я просто офигел.

Потому, что в расте по умолчанию std линкуется статически, а в C/C++ - динамически.

Так он не три мегабайта весит, а 400 килобайт. Три мегабайта это отладочная информация стандартной библиотеки которая не нужна если не будешь отладчиком подключаться. Эта инфа позволяет заходить отладчиком внутрь стандартной библиотеки и ходить там по шагам.

Когда-то давно релизные сборки не содержали отладочную инфу, но разработчики фаерфокса попросили чтобы она всегда была. Если пользователь этого не хочет, то он может вырезать ее командой strip, и это не будет «внештатным рецептом» а официальной рекомендацией.

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

И печатать красивые трейсы.

Для трейсов можно оставить только символы командой strip -d, они занимают всего 100 килобайт.

Я почему-то думал, что RefCell даёт возможность изменять не мутабельный объект и не обращал на него внимание

Я почему-то думал, что RefCell даёт возможность изменять не мутабельный объект и не обращал на него внимание

а для чего еще RefCell нужен?

Ну я всё же немного ошибался т.к. Rc/Arc - реализует изменяемость содержимого при неизменяемости самой ячейки.

Arc<RefCell<MyTrait>> - позволил при динамической диспетчеризации дёргать методы объектов реализующих MyTrait.

Арк - это многопоточная хрень, никаких гарантий от состояния гонки нет. Соответственно, нужно запаковать в рефцелл

Плохой совет: это тоже никак не гарантирует отсутствие состояния гонки.

В этом случае либо многопоток не нужен и можно использовать Rc<RefCell<T>> либо он нужен, и надо использовать Sync контейнер, обеспечивающий внутреннюю мутируемость, например Mutex. Полный тип то есть будет Arc<Mutex<T>>.

А, уже пояснили :)

Тред не читай @ сразу отвечай

Штоэта?

Штоэта?

Гугл говорит, что вот: Программирование под GTK3 (комментарий)

И че ?

И рассуждения о том, как надо разрабатывать программные продукты, от МЛЯТЬ НЕ ПРОГРАММИСТА выглядят тупым троллингом.

И рассуждения о том, как надо разрабатывать программные продукты, от МЛЯТЬ НЕ ПРОГРАММИСТА выглядят тупым троллингом.

Нет, скорее твоя апелляция к «сперва добейся» выглядит тупым троллингом.

Или ты когда тыкаешь официанта в недожаренный шашлык, или в салат куда забыли положить майонез - ты светишь корочкой повара-профессионала ? Сомневаюсь.

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

Или ты когда тыкаешь официанта в недожаренный шашлык, или в салат куда забыли положить майонез - ты светишь корочкой повара-профессионала?

vblats> При реализации крупного проекта, его вначале проектируют на бумаге, учитывают все риски и целесообразности, а только затем начинают воплощать в жизнь. Сразу видно что ты бездельник, никогда не работал в организации крупнее ООО «Вектор».

Ты учишь повара жарить шашлык.

мое утверждение не относится к программированию аж никак.

Вот здесь ты прав.

Ты учишь повара жарить шашлык.

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

Но тебе ведь главное бесплатность, а не качество, поэтому ты будешь такое кушать, и просить добавки.

Чем это чревато - посмотришь сам спустя некоторое время.

я констатирую факт, что если повар [...]

Твоя «константация» не имеет ровно никакого отношения к разработке программ. Думаю, что и к кулинарии - тоже.

Arc<RefCell<ILinkChannel>>

А может ктото сказать как такая конструкция размещается в памяти ? Сколько там malloc-ов и что ложится на стек ?

Насколько я понимаю Arc<T> - это уже два объекта + ссылка на стеке. Но вот как эти объекты хранятся ? В одном heap блоке композицией или в двух разных?

Анологичный вопрос по RefCell<T>?

https://docs.google.com/presentation/d/1q-c7UAyrUlM-eZyTo1pd8SZ0qwA_wYxmPZVOQ...

Здесь не алгоритмическая сложность, здесь неучет особенностей современного x86 железа. Алгоритмическая сложность оценивается на абстрактной машине Тьюринга, а на реальном железе, например, пузырек работает быстрее quicksort на малых массивах.

unordered_map плохой потому что он не cache-friendly и легко разбрасывается по памяти и вырождается в односвязный список. Есть презентация от гуглера, «Efficiency with Algorithms, Performance with Data Structures», где он рассказывает, почему standard library плохой для задач, где нужна производительность.

Все, что не вектор - не работает в тесных циклах, потому как убивает кэш. Сейчас сам сижу, оптимизирую high-perf/low-latency софтину и на неправильном использовании кэша можно легко потерять половину производительности.

Даже в цпп, в котором мувы через жопу и есть возможность конструкции шаредптра из готового указателя, при нормальной практике (make_shared) выделяется только один блок и для счётчиков и для самого объекта. В расте все объекты перемещаемы простым побитовым копированием и рк/арк при создании просто перемещают объект внутрь управляющего блока. Таким образом, rc - это указатели «на стеке» + блок в хипе, содержащий кроме объекта ещё 2 счётчика (сильных и слабых ссылок). RefCell, вопреки названию, не содержит ссылку. *Cell в расте - это аналог mutable поля в cpp. Простой Cell - это просто обёртка, позволяющая только помещение/извлечение/замену значения целиком, а RefCell - получение указателя на внутренность для изменения на месте. По идее RefCell должен быть просто блоком, содержащим структуру + один счётчик. 0 означает RefCell свободен, -1 - эксклюзивно позаимствован, положительное число - количество шаредных заимствований. Как-то так.

Для такого кода:

trait ILinkChannel {
}

struct X {
    x: i64,
}

impl ILinkChannel for X {
}

fn main() {
    let a: Arc<RefCell<ILinkChannel>> = Arc::new(RefCell::new(X {x:13}));
    foo(&a);
}

Будет лежать два указателя на стеке (один на кучу а второй на vtable) и одна аллокация на куче размером 32 байта.

Благодарю за полный ответ.

В расте все объекты перемещаемы простым побитовым копированием

Разве не только те, которые Copy?

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

Все перемещаются/копируются побитовым копированием. Те, которые Copy, с точки зрения компилятора, не умирают после снятия копии.

7 лет уже, время подводить какие-никакие итоги...

Почему 7? Давай уже 12.

Гуня, а Гуня, таки почему тебе так нравится цифра 12? Она для тебя какая-то сакральная? 2011 год легко ищется на этом сайте в поиске новостей о язычке rust. (Да, семь лет - это много, и пора подводить неутешительные итоги.)

Перемещаемы все (из-за этого, кстати, нельзя сделать структуру, содержащую ссылку на свою часть)

На самом деле (но это тонкая деталь) как раз не все, и можно:

struct SelfRef<'a>  // подсветка ' на LOR сломана
{
    foo: i32,
    self_ref: Cell<Option<&'a SelfRef<'a>>>
}

let s = SelfRef { foo: 12, self_ref: Cell::new(None) };
s.self_ref.set(Some(&s));

// нельзя переместить s
// drop(s);

Playground

Ага, просто потом LLVM ненужные копирования выкидывает.

Вот бы кто-нибудь такой же умный, подвёл бы неутешительные итоги о C++ в 90м году.