Доступен (https://blog.rust-lang.org/2017/08/31/Rust-1.20.html) релиз языка программирования Rust 1.20 (http://www.rust-lang.org), развиваемого проектом Mozilla, обеспечивающего автоматическое управление памятью и предоставляющего средства для высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime. Параллельно с Rust совместно с компанией Samsung развивается экспериментальный браузерный движок Servo (https://www.opennet.ru/opennews/art.shtml?num=44712), написанный (https://github.com/servo/servo/) на языке Rust и отличающийся поддержкой многопоточного рендеринга web-страниц и распараллеливанием операций с DOM (Document Object Model). На Rust также разрабатывается (https://www.opennet.ru/opennews/art.shtml?num=46459) операционная система Redox (https://www.redox-os.org/), использующая концепцию экзоядра и продвигающая принцип "все есть URL".В подготовке нового выпуска приняли участие 118 разработчиков. Основные новшества (https://github.com/rust-lang/rust/blob/master/RELEASES.md):
- В дополнение к ранее доступной поддержке ассоциированных функций (функции, привязанные непосредственно к типу) в новом выпуске реализована возможность создавать ассоциированные константы (https://github.com/rust-lang/rfcs/blob/master/text/0195-asso.... Например, в примере ниже константа ID прикреплена к типу Struct:
struct Struct;
impl Struct {
const ID: u32 = 0;
}
fn main() {
println!("the ID of Struct is: {}", Struct::ID);
}Ассоциированные константы также могут быть использованы с типажами (https://ru.wikipedia.org/wiki/%D0%A2%D0%... (traits) и перечислениями (enum), при этом для типажей допускается определение ассоциированных констант без непосредственного присвоения значения (значение может быть присвоено во время привязки типажа):
trait Trait {
const ID: u32;
}
struct Struct;imp Trait for Struct {
const ID: u32 = 5;
}
fn main() {
println!("{}", Struct::ID);
}- В разряд стабильных переведена новая порция (https://github.com/rust-lang/rust/blob/master/RELEASES.md)&n...функций и методов, в том числе CString::as_c_str, Chain::get_ref,
Take::get_ref, f32/64::from_bits, f32/64::to_bits, slice::sort_unstable_*, str::as_bytes_mut, str::get_mut, str::get_* и т.п.- В макросе "unimplemented!" обеспечена возможность определения сообщений, информирующих что именно пока не реализовано;
- Поддержка Unicode обновлена до версии спецификации 10.0.0;
- Реализация функций min и max для типов с плавающей запятой переписана на языке Rust и больше не связана с cmath;
- Обеспечена дополнительная защита от атаки Stack Сlash (https://www.opennet.ru/opennews/art.shtml?num=46724), в результате которой содержимое переполненной кучи может оказаться в области стека или, наоборот, стек может переписать область кучи;
- В стандартной библиотеке представлены новые функции нестабильной сортировки: slice::sort_unstable_by_key, slice::sort_unstable_by и slice::sort_unstable, которые отличаются от стабильных тем, что работают быстрее, но не гарантируют сохранение порядка следования элементов в группе;
- Существенно увеличена (https://github.com/rust-lang/rust/pull/42533) скорость (до 29 раз) раскрытия макроподстановок в процессе работы компилятора rustc;
- В пакетном менеджере Cargo хранение параметров аутентификации к crates.io перенесено из общего файла с настройками ~/.cargo/config, который часто доступен на чтение всем пользователям, в специальный файл ~/.cargo/credentials;- В Cargo обеспечена сборка бинарных файлов main.rs, размещённых в подкаталогах src/bin, например, на базе src/bin/server/main.rs и src/bin/client/main.rs будут сгенерированы исполняемые файлы target/debug/server и target/debug/client;
- Добавлена возможность указания версии устанавливаемого исполняемого файла при указании опции "--vers" в "cargo install";
- Добавлена новая целевая сборочная платформа wasm32-experimental-emscripten, позволяющая организовать сборку в псевдокод WebAssembly при помощи бэкенда на базе LLVM.
Напомним, что язык Rust сфокусирован на безопасной работе с памятью и обеспечении высокого параллелизма выполнения заданий. При этом Rust обходится без использования сборщика мусора или runtime, что делает возможным создания на Rust библиотек, которые могут выступать в роли прозрачной замены библиотекам для языка Си. Для распространения библиотек на языке Rust, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo (http://blog.rust-lang.org/2014/11/20/Cargo.html), позволяющий получить нужные для программы библиотеки в один клик. Для размещения библиотек введён в строй репозиторий crates.io (https://crates.io/).
По структуре язык Rust напоминает C++, но существенно отличается в некоторых деталях реализации синтаксиса и семантики. Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Rust поддерживает смесь императивных, процедурных и объектно-ориентированных методов с такими парадигмами, как функциональное программирование, обобщённое программирование и метапрограммирование, в статических и динамических стилях.
URL: https://blog.rust-lang.org/2017/08/31/Rust-1.20.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=47113
чего только не придумают, лишь бы не писать на си-89.
89?
Ты точно знаешь как выглядит код на С89? Даже во времена борландовского турбо-си все смеялись над С89.
Ты сам, похоже, не знаешь, как выглядит код на С89. На нём, вообще-то, чуть менее чем полностью ядро написано. А смеялись вы, наверное, над K&R C. Ну и к слову, Турбо си появился когда никакого С89 ещё в помине не было.
> На нём, вообще-то, чуть менее чем полностью ядро написано.Это в том смысле, что если попытаться его скомпилировать с --std=c99, то компилятор будет ругаться менее чем на 5% строк? С тем же успехом можно для любой C'шной программы и любого C'шного стандарта начиная с K&R, сказать, что эта программа написана чуть менее чем полностью в рамках выбранного стандарта.
В ядре, мы видим, например, множество inline функций, мы видим, например, активное использование членов структур с неопределённым размером, то есть что-то в стиле:
struct dynarr {
size_t size;
uint8_t data[];
}Ядро активно использует фичи C99, и поэтому не надо натягивать сову на глобус и заявлять, что оно "чуть менее чем полностью написано на C89".
> Это в том смысле, что если попытаться его скомпилировать с --std=c99, то
> компилятор будет ругаться менее чем на 5% строк? С тем же
> успехом можно для любой C'шной программы и любого C'шного стандарта начиная
> с K&R, сказать, что эта программа написана чуть менее чем полностью
> в рамках выбранного стандарта.Чот не понял. Если взять любой стандарт и написать в нём программу, то она будет написана в этом стандарте чуть менее чем полностью, не вопрос :) Или ты хочешь сказать, что каждый предыдущий стандарт является подмножеством следующего?
> В ядре, мы видим, например, множество inline функций, мы видим, например, активное
> использование членов структур с неопределённым размером, то есть что-то в стиле:
> struct dynarr {
> size_t size;
> uint8_t data[];
> }Тогда это расширения GNU были. -std=gnu89 называется.
>> Это в том смысле, что если попытаться его скомпилировать с --std=c99, то
>> компилятор будет ругаться менее чем на 5% строк? С тем же
>> успехом можно для любой C'шной программы и любого C'шного стандарта начиная
>> с K&R, сказать, что эта программа написана чуть менее чем полностью
>> в рамках выбранного стандарта.
> Чот не понял. Если взять любой стандарт и написать в нём программу,
> то она будет написана в этом стандарте чуть менее чем полностью,
> не вопрос :) Или ты хочешь сказать, что каждый предыдущий стандарт
> является подмножеством следующего?Я хочу сказать, что фраза "чуть менее чем полностью" по отношению к стандарту звучит очень неопределённо. Я предложил выше один из способов формализовать и проверить, и заявляю, что этот способ любую программу на C сможет отнести к любому стандарту. Это не значит, что твои слова бессмысленны вообще, но они бессмысленн без уточнения, что именно ты имеешь в виду под "чуть менее чем полностью".
>> В ядре, мы видим, например, множество inline функций, мы видим, например, активное
>> использование членов структур с неопределённым размером, то есть что-то в стиле:
>> struct dynarr {
>> size_t size;
>> uint8_t data[];
>> }
> Тогда это расширения GNU были. -std=gnu89 называется.Так мы говорим о C89 или о GNU89? Мне казалось, что о первом, не?
> Я хочу сказать, что фраза "чуть менее чем полностью" по отношению к
> стандарту звучит очень неопределённо. Я предложил выше один из способов формализовать
> и проверить, и заявляю, что этот способ любую программу на C
> сможет отнести к любому стандарту. Это не значит, что твои слова
> бессмысленны вообще, но они бессмысленн без уточнения, что именно ты имеешь
> в виду под "чуть менее чем полностью".Ну ок, неудачно выразился. Я чо хотел сказать. Там чел выше пишет, типа, ты не знаешь, как С89 выглядит. А он выглядит как подавляющее большинство сишного кода, в т.ч. ядро. Редко когда С99 или K&R в исходниках встречаются.
> Так мы говорим о C89 или о GNU89? Мне казалось, что о
> первом, не?Так GNU89 и есть C89 + расширения ГНУ. Эти расширения потом в стандарт перешли.
>> Я хочу сказать, что фраза "чуть менее чем полностью" по отношению к
>> стандарту звучит очень неопределённо. Я предложил выше один из способов формализовать
>> и проверить, и заявляю, что этот способ любую программу на C
>> сможет отнести к любому стандарту. Это не значит, что твои слова
>> бессмысленны вообще, но они бессмысленн без уточнения, что именно ты имеешь
>> в виду под "чуть менее чем полностью".
> Ну ок, неудачно выразился. Я чо хотел сказать. Там чел выше пишет,
> типа, ты не знаешь, как С89 выглядит. А он выглядит как
> подавляющее большинство сишного кода, в т.ч. ядро. Редко когда С99 или
> K&R в исходниках встречаются.В ядре постоянно. Ты полистай хидеры. Не, ну ты прикинь, как писать на C без inline функций? Макросами их оформлять? Так и делали. Загляни в документацию к ncurses, где про 9 функций из 10 написано, что они могут быть макросами. Альтернатива -- писать вручную каждый раз.
Где-то в ядре я видел функцию типа memcpy, что ли, которая заточена на размеры областей памяти до 32 и константное значение для размера, и которая вся из себя inline, что сделано с мыслью о том, что компилятор заинлайнит код, развернёт циклы, и оптимизирует прочь параметр размера массива. В C++ такие штуки делаются через темплиты с целочисленным параметром, в C99 только вот таким вот образом, с надеждой на то, что пользователь этой функции будет понимать, что аргумент size должен быть вычислим на этапе компиляции, в C89 это сделать можно разве что заморочным макросом. То есть в C89 никто в здравом уме не будет заниматься такими оптимизациями, либо вручную скопирует, либо вызовет библиотечную универсальную реализацию memcpy.
Это разные стили написания программ, это разные стили проектирования API.>> Так мы говорим о C89 или о GNU89? Мне казалось, что о
>> первом, не?
> Так GNU89 и есть C89 + расширения ГНУ. Эти расширения потом в
> стандарт перешли.C89+расширения ГНУ -- это уже не C89. Это можно называть соответствием стандарту gnu89, можно называть соответствием c89+gnu-extensions, но называть это соответствием c89, значит, натягивать сову на глобус.
> Не, ну ты прикинь, как писать на C без inline функций? Макросами их оформлять? Так и делали.Я не делал. Те С89-компиляторы, которыми я пользовался, всегда поддерживали какие-нибудь расширения, и там был inline в каком-нибудь виде, __inline или там #pragma inline...
> C89+расширения ГНУ -- это уже не C89. Это можно называть соответствием стандарту gnu89, можно называть соответствием c89+gnu-extensions, но называть это соответствием c89, значит, натягивать сову на глобус.
Ради бога. Я о том, что все видели, как выглядит С89, но не все об этом знают.
Угу. После чего мы заглядываем в код ncurses и видим как выглядит код на c89. Без использования десятка макросов даже функцию объявить невозможно.
Это ж до чего же гoвнокод там, раз уж такие проблемы.
dq0s4y71, я вижу, ты гуру не только в жабке, но и в сях 8)))
> dq0s4y71, я вижу, ты гуру не только в жабке, но и в сях 8)))Указателем, маллоком, фри и интринсиком, заклинаю:
изыди, зелененький!
> Ядро активно использует фичи C99Ядро использует gnu89/gnu90 без всяких "активно"/"пассивно".
>> Ядро активно использует фичи C99
> Ядро использует gnu89/gnu90 без всяких "активно"/"пассивно".Ага. То есть ядро не написано в рамках стандарта C89, так?
Очевидно, что он не знает. Это же просто клоун, который срет в комментах под каждым постом.
Хотя казалось бы, уже вроде 1 сентября...
>> как выглядит код на С89. На нём, вообще-то, чуть менее чем полностью ядро написаноВ ядре почти каждый драйвер использует инициализацию полей структур по-умолчанию, что появилось только в 99
> чего только не придумают, лишь бы не писать на си-89.Ага, странные люди, хотят чтобы компилятор решал рутинные задачи,
вместо того чтобы отдать эту работу человеку, ведь это такое
удовольствие думать над каждой строчкой.
> чего только не придумают, лишь бы не писать на си-89.Особенно, говоря о С89, современные разработчики "любят" декларировать все переменные сразу после начала функции... как в Паскале....
> Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблемЗато создаёт проблемы с производительностью.
>> Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем
> Зато создаёт проблемы с производительностью.Что-то не сильно видно: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
Кстати, растовское "автоматическое" управление памятью немного не то, что под этим понимают в других ЯП.
По этой ссылке нет никаких тестов с управлением памятью.
> По этой ссылке нет никаких тестов с управлением памятью.Т.е. вы туда не ходили?
Да и, как я понимаю, ничего конкретного насчет "создавания проблем с производительностью" мы не увидим?
> Что-то не сильно видноА вы поближе к монитору подсядьте.
На одном тесте ржавый потребляет на 20% меньше памяти, чем C++, ещё на одном примерно столько же, ещё на четырёх на 50-80% больше, и ещё на 5 тестах - в 2-20 раз больше. При этом работает сравнимое время (кроме теста, где выигрывает 20%, - там и работает в 6 раз быстрее).
>>>> Автоматическое управление памятью избавляет разработчика
>>> Зато создаёт проблемы с производительностью.
>> Что-то не сильно видно
> А вы поближе к монитору подсядьте.
> На одном тесте ржавый потребляет на 20% меньше памяти,
> кроме теста, где выигрывает 20%, - там и работает в 6 раз быстрее
> где выигрывает 20%, - там и работает в 6 раз быстрееВы бы тоже подсели и прочитали внимательно, на что решили отвечать.
Производительность и потребление памяти - разные вещи (только не надо начинать про взаимосвязь и трейдоффы, конкретно тут ее, в идеальном случае, не должно быть).
А уж
> где выигрывает 20%, - там и работает в 6 раз быстреепротиворечит чуть более чем полностью гордому заявлению того самого анонимуса.
> Производительность и потребление памяти - разные вещиТо есть путать производительность и потребление памяти нельзя, а путать производительность и скорость работы - можно?
Как? Это же не GC или подсчет ссылок.
>> Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем
> Зато создаёт проблемы с производительностью.И какие проблемы? Это ведь не GC.
Подсчёт ссылок в рантайме.
> Подсчёт ссылок в рантайме.Вот! Экспертный тезка зрит в самый корень! Заморочки с временем жизни, владениями и прочим - для отвода глаз и накручивания ЧСВ, а на самом деле унутрях там неонка^W ссылки в рантайме считают! И как его только на ардуинах или в качестве ядра ОС использовать заставляют?
>>Заморочки с временем жизни, владениями и прочимЗачем, если есть тупо область видимости и нет глобальных указателей? Счетчик ссылок на пару порядков быстрее CG.
> Счетчик ссылок на пару порядков быстрее CG.Неа. Во-первых, даже полностью статическое управление памятью не на порядки быстрее сборщика мусора. Наверное можно создать искусственную ситуацию, когда разница будет достигать порядка, но достичь этой ситуации в реальном проекте со сборщиком будет не так просто. Особенно если избегать её. При этом довольно сложно сравнивать сборщик мусора со статическим управлением памятью, потому что тут всё сильно-сильно зависит от того, чем именно программа занимается и как она это делает. Но тем не менее, ждать что сборка мусора замедлит программу хотя бы на порядок -- это ждать слишком многого. Я удивлюсь, если она замедлит хотя бы в два раза.
Во-вторых, счётчик ссылок -- это существенно не бесплатная абстракция: элементарная передача указателя из одного места в другое требует разадресации указателя и кеш-промахов для того чтобы изменить значение счётчика ссылок. Это может дать такие пенальти к производительности, что счётчик ссылок покажется раем.
Лет двадцать назад счётчики ссылок выглядели очень неплохо. Но все эти двадцать лет память по скорости отставала от процессоров всё дальше и дальше. И скорость процессора и частота памяти растут экспоненциально, но там в основании экспоненты стоят разные значения. Поэтому разница в скорости тоже растёт экспоненциально по времени. Я -- увы -- ссылку найти не могу с красивыми графиками и пояснениями, но ты можешь попробовать поверить мне на слово.
Сегодня речь идёт о том, что все структуры данных, типа списков, деревьев, и прочие способы размазывания данных ровным слоем по куче -- это не вариант для производительной программы. Скажем, лет десять назад народ ещё радостно прыгал, при словах "красно-чёрное дерево", и втирал что это гораздо лучше хеш-таблички. Сегодня фонтаны восхищения иссякли -- нужен быстрый ассоциативный массив? значит хеш-табличка, всё остальное имеет разве что академическое значение в рамках курса "история структур данных XX века". Хотя может для программирования микроконтроллеров эти знания ещё могут пригодиться.
Динамический массив оказывается быстрее списка даже несмотря на стоимость операции insert, просто потому что он меньше греет кеш. То есть если размер массива увеличивать в бесконечность, то с определённой точки начиная список окажется быстрее, но если массив влезает в килобайт, то он будет быстрее списка на операции insert. Особенно если перелопатить алгоритмы и постараться избегать insert/remove произвольных позиций, например, заменяя это чем-нибудь типа swap_remove или позволяя массиву иметь "дыры" и иногда дефрагментируя его. Зато список будет невыносимо медленнее массива при итерации по элементам.
Сборщик мусора тоже занимается тем, что "трогает" всю память доступную по указателям, засирая таким образом кеши, но он это делает несколько иначе. Даже ещё интереснее, сборщик мусора может работать на разных алгоритмах и эти разные алгоритмы могут быть более или менее удачны для разных ситуаций. Даже более того, он может менять стратегию в рантайме, скажем, затачиваясь на меньшие latency в программе, когда есть свободное ядро для сборщика мусора, и на максимальный throughput, когда программа отжирает 100% процессорного времени, сглаживая таким образом пиковые нагрузки. Кроме того, работа сборщика мусора может уменьшать количество кеш-промахов в основном коде программы. Это уменьшение может происходить уже за счёт того, что память менее фрагментирована, но если сборщик мусора написан с мыслью о том, чтобы снижать количество кеш-промахов, то он не просто дефрагментирует память, он может из списка сделать массив, в том смысле, что для программы список будет именно списком, но в памяти элементы будут лежать последовательно, прямо как в массиве.
Короче, если зачем-то нужны счётчики ссылок и без них никак, то лучше подумать о языке с GC, нежели писать на C, C++, Rust и тому подобных языках.
Как расписал, прям можно подумать, что сборщик мусора — это альтернатива подсчёту ссылок.
> Как расписал, прям можно подумать, что сборщик мусора — это альтернатива подсчёту
> ссылок.
> можно подуматьНе можно, а нужно. Не обязательно выбирать именно эту альтернативу, но подумать нужно. Потому что если ты отказываешься от сборки мусора не подумав, то это нельзя называть выбором, это скорее предопределённость.
Ну давай расскажи как быстро сборщик мусора освободит пару гигов когда памяти уже совсем нет, а вот очень прям сейчас надо. Сборщик мусора порождает тормоза в любой непредсказуемый момент времени для тяжелых приложений.
> Ну давай расскажи как быстро сборщик мусора освободит пару гигов когда памяти
> уже совсем нет, а вот очень прям сейчас надо.А в ручную, когда кончилась память, ты делаешь волевым усилимем free(random)?
> Сборщик мусора порождает тормоза в любой непредсказуемый моментЕще один недоклоун, мнящий себя тонким знатоком и ценителем?
> А в ручную, когда кончилась память, ты делаешь волевым усилимем free(random)?в том то и дело, что память есть
> Еще один недоклоун, мнящий себя тонким знатоком и ценителем?
Высоконагруженное на java когда-либо писали?
>>> освободит пару гигов когда памяти уже совсем нет
>> А в ручную, когда кончилась память, ты делаешь волевым усилимем free(random)?
> в том то и дело, что память естьТак она есть или ее нет? Тут бы некоторая определенность не помешала.
>> Еще один недоклоун, мнящий себя тонким знатоком и ценителем?
> Высоконагруженное на java когда-либо писали?Еще раз, для ценителей - алгоритмов GC вагон и маленькая тележка. Копирующий, у которого могут быть проблемы с освобождением блоков при нехватке памяти и которому требуется приостановить "мир" - только один из них.
Причем, часть таких проблем может вылезать и в ручном аллокаторе. Их разновидностей тоже более 1 будет.
> Ну давай расскажи как быстро сборщик мусора освободит пару гигов когда памяти
> уже совсем нет, а вот очень прям сейчас надо.Если у тебя кончилась память, то тебе уже ничто не поможет. Ни сборщик мусора, ни его отсутствие. Причём обсуждая абстрактную программу нельзя даже сказать, когда быстрее кончится память -- в случае со сборщиком мусора или без него. Отсутствие сборщика мусора может сильно фрагментировать память, и кончаться тем, что половина 16 гигов памяти свободна, но невозможно выделить килобайт последовательной памяти.
> Сборщик мусора порождает тормоза в любой непредсказуемый момент времени для
> тяжелых приложений.Не в любой, а тогда когда программист позволит. И нельзя сказать, чтоб так уж в непредсказуемый: это от сборщика мусора зависит, его поведение может быть более или менее предсказуемым. Например, он может не останавливать мир в периоды пиковых нагрузок.
Кроме того, что в твоём понимании "тяжёлое приложение"? Это то, которые активно работает с кучей, выделяя и освобождая, при этом выделяет куски памяти очень разных размеров (различающихся на несколько порядков) и куски памяти очень разной продолжительности жизни (опять же с разницей в несколько порядков)? Такой программе, даже если ей очень хочется real-time'а, я бы очень порекомендовал задуматься о том, как бы так адаптировать сборку мусора и использовать её. Иначе придётся покупать оперативки на порядок больше, чем будет пиковая сумма размеров объектов. Статическое управление памятью дефрагментирует кучу -- есть техники, которые позволяют снизить фрагментацию, но -- хыхы, -- чем навороченнее эти техники, тем дороже будет вызов free. Причём непредсказуемо дороже, то есть не удастся заранее предсказать сколько по времени будет выполняться free.
>>>Заморочки с временем жизни, владениями и прочим
> Зачем, если есть тупо область видимости и нет глобальных указателей?Затем, что оперируя только областями видимости трудно будет передавать ссылочки на данные, а копирование для не примитивных типов будет заметным оверхедом.
Ну а совсем без передачи данных туда-сюда, в не совсем сферическом софте, будет несколько сложновато.> Счетчик ссылок на пару порядков быстрее CG.
Вообще-то, в общем случае - наоборот. Счетчик легче сделать, поведение предсказуемее, но зато есть постоянный оверхед на инкремент/декремент, что очень заметно на CPU-bound задачах.
Только вот в сабже основная фишка в том, что ни GC, ни счетчик по умолчанию не исользуется.
Можно угорать или возмущаться синтаксисом, отсутствием поддержки каких либо фич или кучей хипстоты, решивших, что это новая серебрянная пуля и нужно все переписать, но главное достижение раста уже есть - показать, что современный компилятор при некоторых ограничениях ЯП может вполне взять на себя отслеживание времени жизни и "кто сейчас владеет доступом на запись к этому куску данных" и все еще позволяет писать вполне реальный софт.
>> Счетчик ссылок на пару порядков быстрее CG.
> Вообще-то, в общем случае - наоборот. Счетчик легче сделать, поведение предсказуемее, но
> зато есть постоянный оверхед на инкремент/декремент, что очень заметно на CPU-bound
> задачах.Ты как себе представляешь GC, работающий без подсчёта ссылок, умник? Откуда он будет узнавать, что мусор, а что — нет?
> Ты как себе представляешь GC, работающий без подсчёта ссылок, умник? Откуда он
> будет узнавать, что мусор, а что — нет?Яснопонятно ...
Я то думал, сегодня количество знатоков на опеннете поубавится, а оно вот как вышло.
Ты б хотя бы википедию почитал сначала о том, что такое сборщик мусора, какие они бывают, и как они работают, прежде чем таким агрессивным тоном задавать вопросы.
1. Подсчет ссылок - один из вариантов GC :)
2. Хорош на тестах a la helloworld, но в реальности коллекция недостатков типа:
a) фрагментация памяти;
b) операции со ссылками только через инвалидацию кеша (или иные методы синхронизации) - или прощай многозадачность;
с) непредсказуемость времени выполнения операции (простенькое удаление ссылки может обернуться каскадом удалений);
d) циклические ссылки сами не обнуляются.Но идеальной системы, пока никто не придумал.
https://kgv.gitbooks.io/rust_book_ru/content/src/custom-allo...
> Зачем, если есть тупо область видимости и нет глобальных указателей? Счетчик ссылок
> на пару порядков быстрее CG.Экспертик ты мой сердешный, ничего, что GC по большей части работает в отдельных от основной программы потоках? :)
Кстати, счетчик ссылок дефрагментацию памяти делает? :)
> Экспертик ты мой сердешный, ничего, что GC по большей части работает в
> отдельных от основной программы потоках? :)Жабиный GC != единственная альтенратива счетчику.
> Кстати, счетчик ссылок дефрагментацию памяти делает? :)А это-то причем? Как сделаешь, так и будет - можешь хоть маллок/фри обернуть, хоть еще что-то сваять. Естественно, с компактирующим GC оно в шарообразных бенчах и рядом не стояло, но в реальной жизни в 64 битном адресном пространстве дефрагментация пока вообще не ощущается, да и нюансики у копирующих GC тоже есть.
>в реальной жизни в 64 битном адресном пространстве дефрагментация пока вообще не ощущаетсяЩито?!
Создала прожка 1000 объектов по мегабайту. Потом каждый второй удалила. Потом надо создать 500 объектов по 1.1 мегабайту. Расскажи сколько ОЗУ съест прожка у могучего прогера, который "я жи осилил NEW и DELETE, а GC для лузеров".
>>в реальной жизни в 64 битном адресном пространстве дефрагментация пока вообще не ощущается
> Щито?!
> Создала прожка 1000 объектов по мегабайту.Т.е. не общим куском на 1000 мегабайт, т.е. аж целы1 ГБ, а именно по мегабайту?
> Потом каждый второй удалила.
> Потом надо
> создать 500 объектов по 1.1 мегабайту. Расскажи сколько ОЗУ съест прожка
> у могучего прогера, который "я жи осилил NEW и DELETE, а
> GC для лузеров".
> Т.е. не общим куском на 1000 мегабайт, т.е. аж целы1 ГБ, а именно по мегабайту?Блин, ну откуда такие люди берутся. Вроде бы всё очевидно. Даже кэпуочевидности стыдно такое разжёвывать:
А откуда ты ЗАРАНЕЕ знаешь что именно на 1000 мегабайт будет через пол-дня работы программы? Или что всегда будут выделяться куски строго по одному мегабайту или кратно одному мегабайту? Ты экстрасенс? Прожка их создала не в один момент на старте, а в процессе работы как результат реакции на поступающие извне данные (недетерминированно поступающие). Ты не знаешь сколько именно там выделится памяти в процессе работы, например, из-за того, что не знаешь сколько клиентских запросов придет в твой сервис и каков размер данных тебе будет приходить с каждым запросом. Системы с менеджерами памяти без упаковывающих/перемещающих ранее выделенные области памяти механизмов вынуждены тащить кучки пулов памяти для разных по размеру данных, чтобы уменьшить фрагментацию, но и это не решает полностью проблему.
>>> Создала прожка 1000 объектов по мегабайту. Потом каждый второй удалила. Потом надо создать 500 объектов по 1.1 мегабайту. Расскажи сколько ОЗУ съест
>> Т.е. не общим куском на 1000 мегабайт, т.е. аж целы1 ГБ, а именно по мегабайту?
> Блин, ну откуда такие люди берутся. Вроде бы всё очевидно. Даже кэпуочевидности
> стыдно такое разжёвывать:
> А откуда ты ЗАРАНЕЕ знаешь что именно на 1000 мегабайт будет через
> пол-дня работы программы?Вам не угодишь.
У вас там случаем, не шиза? Или вы не помните, что сами же спрашивали? Или мне нужно было ткнуть вас носиком в сферо-вакуумность вашего же вопроса, на что я наверняка получил бы "так и скажи, что не осилил отверить!"?
> вынуждены тащить кучки пулов памяти для разных по размеру данных, чтобы уменьшить фрагментациюДа ну, правда? А теперь почитайте, на что вы отвечали
>> в реальной жизни в 64 битном адресном пространстве дефрагментация пока вообще не ощущаетсяи расскажите нам уже, причем тут ваши нелепые "срывы покровов".
>>в реальной жизни в 64 битном адресном пространстве дефрагментация пока вообще не ощущается
> Щито?!
> Создала прожка 1000 объектов по мегабайту.Т.е. не общим куском на 1000 мегабайт, т.е. аж целый 1 ГБ, а именно по мегабайту?
> Потом каждый второй удалила. Потом надо создать 500 объектов по 1.1 мегабайту.И в чем проблема? Как удалила, так и создала. Максимальный оверхед, помимо всяких мета-данных, зависит от аллокатора, но скорее всего будет +- размер страницы.
> Расскажи сколько ОЗУ съест прожка у могучего прогера,Т.е. ты, в лучших традицияж жабистов, не в курсе про виртуальную память/адресное пространство и как оно взаимодействет с реальной "физической" памятью?
Хотя да, оно видно уже по ответу абсолютно не в тему.
Приколись, если "объекты" (мы же о сишке и подобных, c зиро-кост-абстракциями, а не о жабке с "5КБ рантайминфы на один пустой объект"?) проинициализованы ноликами и к ним больше не обращались, то реальной памяти они займут 0 целых, 0 десятых (точнее, только метаинфа в ядре/аллокаторе).> который "я жи осилил NEW и DELETE, а GC для лузеров".
А, так ты еще и не в курсе, что аллокаторы для аллокации больших кусков памяти обычно используют системные вызовы?
> Т.е. ты, в лучших традицияж жабистов, не в курсе про виртуальную память/адресное
> пространство и как оно взаимодействет с реальной "физической" памятью?
> Приколись, если "объекты" (мы же о сишке и подобных, c зиро-кост-абстракциями, а
> не о жабке с "5КБ рантайминфы на один пустой объект"?) проинициализованы
> ноликами и к ним больше не обращались, то реальной памяти они
> займут 0 целых, 0 десятыхТут все школьники и запалились :) Во первых зааллокейтить все доступные 16TB можно легко и непринужденно за сутки активной работы прожки. Что потом, перезапускать сервис будешь? :)) Хотя очевидно, что это гогнокодинг, скорость работы с памятью будет очень несишная, а вы так любите рассуждать про скорость света 8))))) Дефрагментацию вы таки не делаете?
И напоследок, озвучь use case "проинициализованы ноликами и к ним больше не обращались", что твоя прожка делает, как называется? Наверное СферическиВакуумныйРазрывательЖабы? :)))
>> Т.е. ты, в лучших традицияж жабистов, не в курсе про виртуальную память/адресное
>> пространство и как оно взаимодействет с реальной "физической" памятью?
>> Приколись, если "объекты" (мы же о сишке и подобных, c зиро-кост-абстракциями, а
>> не о жабке с "5КБ рантайминфы на один пустой объект"?) проинициализованы
>> ноликами и к ним больше не обращались, то реальной памяти они
>> займут 0 целых, 0 десятых
> Тут все школьники и запалились :)
> Во первых зааллокейтить все доступные 16TB
> можно легко и непринужденно за сутки активной работы прожки.
> ... невнятный поток сознанияКласс! Сам что-то придумал, сам же опроверг, сам доволен!
А по теме что-то будет? Или хотя бы более связное, не подразумевающее у других наличия способности к мыслечтению? А то вначале сам же задал вопрос про "сколько ОЗУ будут занимать 1000 объектов", теперь вдруг уже 16 ТВ у него кем-то заалокейтены и только дефрагментация может спасти отца демократии ...> Дефрагментацию вы таки не делаете?
Дефрагментацию ОЗУ делаем только сертифицированной утилитой, ага.
Марш читать "computer architecture for javaists".
>"сколько ОЗУ будут занимать 1000 объектов"Если твои прожки работают по 3 минуты и заключаются в "проинициализованы ноликами и к ним больше не обращались" и "создали 1000 объектов и поскорее выключились", то молодец, поздравляю, дефрагментация тебе не нужна. Можешь и дальше во всех ветках про раст, го и жабку квакать про мощь си.
>>"сколько ОЗУ будут занимать 1000 объектов"
> Если твои прожки работают по 3 минуты и заключаются в "проинициализованы ноликами
> и к ним больше не обращались" и "создали 1000 объектов и
> поскорее выключились", то молодец, поздравляю, дефрагментация тебе не нужна. Можешь и
> дальше во всех ветках про раст, го и жабку квакать про мощь си.Т.е. Великий Дефрагментатор зафейлился на своем же примере и сказать ему хоть что-то осмысленное в тему нечего, но очень подгор^W хочется?
Почитал бы что ли, как работают современные аллокатры, что такое виртуальная память и как происходит взаимодействие с реальной ...
https://en.wikipedia.org/wiki/Allocator_(C%2B%2B)The default allocator uses operator new to allocate memory.[16] This is often implemented as a thin layer around the C heap allocation functions,[17] which are usually optimized for infrequent allocation of large memory blocks. This approach may work well with containers that mostly allocate large chunks of memory, like vector and deque.[15] However, for containers that require frequent allocations of small objects, such as map and list, using the default allocator is generally slow.[4][17] Other common problems with a malloc-based allocator include poor locality of reference,[4] and excessive memory fragmentation.
И дальше длинное описание как сделать крутой костыль, с буффером в котором хранить все не гигантские объекты. А то ой, сишечка тормозит.
> https://en.wikipedia.org/wiki/Allocator_(C%2B%2B)
> The default allocator uses operator new to allocate memory.[16]Подразумевалось чтение и ПОНИМАНИЕ прочитанного.
> И дальше длинное описание как сделать крутой костыль, с буффером в котором хранить все не гигантские объектыИ то ли дело жабка, ведь там все работает с помощью магии!
А это наверное неправилная жабо-машина!
https://github.com/dmlloyd/openjdk/tree/e7f494fc8232d207b7c2...
> И как его только на ардуинах или в качестве ядра ОС использовать заставляют?Заставляют??? Соболезнцую :)
> увеличена скорость (до 29 раз)Это, значит, так они его писали?
Нормально, чо. Make it Work, Make it Right, Make it Fast.
Ну вообще-то это нормально - сначала писать, потом оптимизировать. Да и это на скорость компиляции влияет, а не на результирующий код, так что это неприятно, но не критично.
Скажите, кто следит, оно по степени yпоротости уже перегнало кресты, или всё ещё только догоняет?
Что для Вас является степенью упoротости? И что в таком случае "отстаёт"?
Синтаксис через одно место
А чем именно вам не нравится синтаксис rust ?
6 операторов преобразования типа, например.
Степенью yпоротости для меня является избыточность возможностей (вроде тех же ассоциированных функций), создающая плодородную почву для написания совершенно нечитаемого кода. Отстаёт — в смысле туда уже запихали всё, что есть в C++, то есть примерно всё, что вообще встречается в разных языках программирования, или ещё не успели?
> Степенью yпоротости для меня является избыточность возможностейНу, ну... С такой логикой Вы скоро объявите Python вершиной эволюции языков программирования. :)
Если язык предоставляет избыток возможностей что-то сделать, надо помнить, что это далеко не всегда плохо. Всё зависит от сообщества, которое сформировалось вокруг данного языка.
Вот на том же Perl пишут вполне удобочитаемые программы, не смотря на TIMTOWDI. Хотя почва для написания нечитаемого кода настолько необычайна плодородна, что даже был период, когда устраивали соревнования обфусцированного кода на Perl.
Важно то, что когда программист работает на языке с широкими возможностями, ему надо в обязательном порядке выработать стиль. И тогда с его кодом можно работать. А когда всё подряд без стиля и культуры в одну коробку запихивают, получается Boost. :)
Целиком и полностью согласен. Но Rust — это не Perl, это попытка переделать C++ «правильно». И сообщество его состоит преимущественно из плюсовиков.
> Отстаёт — в смысле туда уже запихали всё, что есть в C++...Нет конечно. За rust'ом стоит другая идеология. Страуструп пихал в C++ всё, что он смог в zero-cost абстракции завернуть, потому что не знал ещё, как люди будут писать программы на C++. Когда же rust зародился, уже было понятно, как надо писать программы на C++. Что, например, наследование не нужно, что try/catch/throw не самая удачная штука для обработки ошибок, что UB в стандарте -- это плохо, что функциональное программирование -- это хорошо и вполне юзабельно, если не впадать в крайности, что обратная совместимость синтаксиса с C -- это недостижимо, но привносит кучу проблем, что utf8 -- это стандарт для представления строк. C++ был поиском новых путей для программирования в ширину, rust -- это скорее поиск в глубину.
> то есть примерно всё, что вообще встречается в разных языках программирования, или ещё не успели?
Да ну. В C++ нет и половины того, что встречается в разных языках программирования. Глянь, например, на CLOS, чтобы проникнуться тем, что такое ООП. Глянь на Ocaml, чтобы понять, что такое полиморфные типы. Или на хаскель, чтобы понять, что делают с языком immutable данные, pure функциональность и РЕАЛЬНЫЙ полиморфизм.
>> Глянь, например, на CLOS, чтобы проникнуться тем, что такое ООП. Глянь на Ocaml, чтобы понять, что такое полиморфные типы. Или на хаскель, чтобы понять, что делают с языком immutable данные, pure функциональность и РЕАЛЬНЫЙ полиморфизм.Ну как в каждом языке своё, а в c++ впихнули все и ввели еще режим совместимости, тк сверху вниз он не совместимы 90% компиляторов. Что уже говорить про разные реализации компиляторы.
Нормальное ООП и полиморфизм есть только в SmallTalk. В остальных ЯП идет скрещивание ужа с ежом.
> Ну как в каждом языке своё, а в c++ впихнули все...Повторюсь: не всё.
> Да ну. В C++ нет и половины того, что встречается в разных языках программирования. Глянь, например, на CLOS, чтобы проникнуться тем, что такое ООП. Глянь на Ocaml, чтобы понять, что такое полиморфные типы. Или на хаскель, чтобы понять, что делают с языком immutable данные, pure функциональность и РЕАЛЬНЫЙ полиморфизм.Примерно это я и имел в иду: в C++ оно как бы есть, но толку от этого чуть больше нуля.
Да, вероятно. Я не понимал как надо писать на C++, до тех пор пока не разобрался с Rust'ом. В C++ действительно очень много чего намешано и неясно, как именно всё это можно сочетать, без прочтения правильных гайдов, но какие из них правильные априорно непонятно.
> Скажите, кто следит, оно по степени yпоротости уже перегнало кресты, или всё
> ещё только догоняет?Т.к. C++ стартовал намного раньше не думаю что его возможно догнать.
Например о "move" авторы Rust думали с самого начала, поэтому там нет
такого сумасшествия как 4 спецальных функций чтобы экземпляры твоего типа
передавались туда сюда (имеется ввиду copy/move constructor и copy/move operator=).Также авторы Rust знали заранее к чему может привести простой функционал
замены "А" на "Б" в руках неокрепших умов, поэтому все применения макросов
помечены восклицательным знаком.В общем думаю еще лет 10-20 не то что не догонит, но и близко не будет по сложности синтаксиса.
бобит то как, чувствуют, чувствуют люди, что скоро Раст подвинет старичков из системного программирования, насиженного места.
Это вряд ли. Rust это очередная игрушка попиарится.
Не более.
> Это вряд ли. Rust это очередная игрушка попиарится.
> Не более.На которой, меж тем, пишутся вполне себе серьезные вещи уже.
Это просто попытка привлечь внимание, а не серьезные вещи.
>> Это вряд ли. Rust это очередная игрушка попиарится.
>> Не более.
> На которой, меж тем, пишутся вполне себе серьезные вещи уже.Эти "серьезные вещи" из целого одного браузера -начали падать в разы чаще и вчистую сливают конкурентам аудиторию.
Какая здесь роль именно хруста и сообщества восторженной школоты вокруг него - сказать сложно, но это было предсказуемо.
>>> Это вряд ли. Rust это очередная игрушка попиарится.
>>> Не более.
>> На которой, меж тем, пишутся вполне себе серьезные вещи уже.
> Эти "серьезные вещи" из целого одного браузераhttps://www.opennet.ru/opennews/art.shtml?num=46805
Это, конечно, далеко не браузерный движок, зато сама контора посолидней мозиллы.
>Эти "серьезные вещи" из целого одного браузера -начали падать в разы чаще и вчистую сливают конкурентам аудиторию.Это в ваших влажных хромоюзеровских фантазиях чтоли?
А ничего, что на Rust в Firefox пока ещё ничего нет в проде? Firefox Nightly — не прод, если что. Он как раз для того и создан, чтобы всякие баги отлавливали желающие новизны, которые ну явно Nightly ставили не ради «стабильности».Между прочим я всегда «стабильной» версией пользовался. И только с выходом Firefox Nightly 57 (Mark 57) я его поставил. Именно ради того, чтобы не иметь хоть и редкие падения, которые вызваны этим легаси-глюкодромом под названием XUL. Так и случилось — у меня ни разу Nightly не упал, не заглючил, не затормозил даже.
Что же касается Quantum CSS (aka Stylo), который является пока единственной частью Servo на Rust портированный в Firefox Nightly 57 (в Nightly, Карл! не в прод 55) — так это единственное, к чему у меня нет нареканий сейчас. Остальные части движка, которые не связаны с парсингом и обработкой CSS, всё так же чутка уступают Blink (у меня есть на чём это проверять).
Хотя… в чём-то вы правы. Ведь с выпуском Nightly 57 как и я очень многие на него перешли… так сказать, «слились» из пользователей «стабильного» Firefox, по крайней мере до выхода в ноябре Firefox 57 😉
> скоро Раст подвинет старичков из системного программированияНу нет, это вряд ли. :)
Ядро -- слишком масштабный проект, чтобы вот так вот запросто взять и переписать его на другом языке.
Скажу по секрету - как раз таки "старички", у которых кроме основного рабочего ЯП (того же C или жабы) пары ЯП "для разной мелочёвки" (например, awk - иногда груду текстового навоза перелопатить) есть ещё в анамнезе десяток ЯП, от тикля до эрланга, которые ему пришлось изучить для ковыряния чужогого кода - так вот именно такие "старички" быстрее освоят новый язык (если понадобится), чем свежевыпущенная с курсов макака, признающая только один ЯП - тот единственный, которому её научили.
Пока одни учат бесконечные япы, другие растут как профессионалы в своём направлении. К примеру, можно OpenGL освоить хорошенько, на это несколько лет нужно.
Яп - это просто инструмент, который мало чего решает. А времени у нас не так уж много в этой жизни.
> А времени у нас не так уж много в этой жизни.Естественно. Уроки учить...
> [...] обеспечивающего автоматическое управление памятью и предоставляющего
> средства для высокого параллелизма выполнения заданий
> ...
> Напомним, что язык Rust сфокусирован на безопасной работе с памятью и
> обеспечении высокого параллелизма выполнения заданий. [...]Спасибо за напоминание, но не слишком ли часто?
Ох уж эти змеи, как только не изовоються лишь бы не писать на С.
А ну бегом написал движок для firefox-next.
Заказчики заразы - требуют быстрее выпускать рабочие версии, не хотят ждать квартал, пока ищешь утечку в памяти, говорят php-шники и python-исты пишут гораздо быстрее и дешевле.
> Заказчики заразы... разные бывают.
Если ты планируешь строить свою карьеру на тех, кто ищет подешевле, то будь готов, что дешевле они хотят не только в собственно разработке, но и в организации рабочего процесса, оформлении официальных документов, переводе денег тебе, тестировании и дальнейшей поддержке софта и т.д. А ещё они хотят не просто "дешевле", а "дешевле для них", поэтому будут с радостью перекладывать на тебя часть своей работы, потому что "ну тут же тебе немного, а мне разбираться придётся. А вот знакомый похапешник сделал мне это бесплатно за то, что я заказал у него сайт".
Смешно, когда код питониста работает быстрее, чем код сишника. Ибо тот байтики перекладывать научился, а программировать - нет. Серьёзно, я после ассоциативного массива на связном списке уже ничему не удивляюсь.
>> защищает от проблем
>> в один клик
>> избавляет разработчика отПочему Firefix чем дальше, тем чаще крашится на ровном месте? На банальной закачке 500-мегового файла может упасть, сразу после открытия программы.
И почему я не удивлен? Видя восторг школоты по повобу "оно само безопасно" - почему я предполагал нечто подобное?
>> FirefixОчепятка по Фрейду :)
Наставил расширений небось. В ноябре они все отвалятся с приходом новой архитектуры запрещающей им глубоко внедряться в браузер.
У меня, наверное, более сотни расширений. Да, я плагиновый маньяк. Не крешится.
Зависит от самих расширений, а не от их количества. Сложно было догадаться? Иди ты думаешь в коде FF стоит if (ext_count < 100) do_crash()?
Наверное. ты - хозяин Оки "Моня"?
Сейчас в фаерфоксе на RUST написаны движок стилей (CSS), и парсер метаданных (mp3/4,...) "Закачка" файла к этим модулям на RUST не имеет никакого отношения
Если быть точнее, то не «сейчас». А в ноябре. Сейчас же только в Nightly.
На тому кренделю лишь бы слюной побрызгать 😂
Если используете 32-разрядную версию, попробуйте перейти на 64-разрядную.
я бы сказал, язык готов процентов на 30. К продаже. Adobe.
Хотя, это если у мазилы всё получится, нынче на этом рынке неплохая конкуренция.