Оно будет стоить ровно столько же сколько и проверка указателя на выходную ноду ( node->next ли, node->left/right ли) на null. Только в случае с линейной памятью компилятор вполне может сделать предположение о попадании в границы и выкинуть проверку, либо можно самому использовать unchecked версию. Ну и в C++ вполне существуют такие штуки как flat_map , которые для пользователя выглядят как std::map, но сами ноды при этом лежат последовательно в линейной памяти, снижая фрагментацию и как следствие уменьшая накладные расходы на выделение памяти.
это с каких пор доступ в линейную память стал аффектить производительность?
вырождается код при таких "разумных" требованиях языка.
тут было бы неплохо какие-то примеры привести ибо за всё время не сталкивался с подобными проблемами.
То есть переход на раст даёт невозможность писать интуитивно понятный код,
эта фраза вызывает ещё большее недоумение. Более интуитивного кода чем на расте не встречал в иных языках. JS в этом плане довольно похож, только в сотни раз медленее. Даже у питона больше квирков в этом плане. Тут похоже тоже нужны какие-то примеры. Пока у вас в коде не возникает необходимость теребить сырые указатели оно даже от C++ отличаться практически не будет, а это требуется на крайне специфичных задачах - едва ли вам каждый день требуется разворачивать односвязные списки.
Каждая библиотека имеет свой собственный edition и т.к. каждый крейт - отдельный юнит трансляции они не страдают из-за этой разницы. Есть ещё так называемая политика MSRV - минимальная поддерживаемая версия раста. Так что каждый может писать независимо пока версия компилятора позволяет это делать.
В 23 стандарте они выглядят ещё более похоже. LINQ емнип отлично встают в цепочку, в плюсах в новых стандартах можно делать похоже через пайплайн оператор (правда не для всех), либо использовать библиотеку вроде этой.
деревья-то понятно, один вошёл n вышло, но если это просто случайный граф да ещё и ориентированный, да ещё и с рёбрами из себя в себя, то там уже всплывают нюансы и возникает проблема "сложность" vs "количество" кода - либо будет сложно писать и убеждать компилятор, либо придётся реструктурировать код под более дата ориентированный подход с ECS и кверями, что легко и непринуждённо утроит сложную версию кода. Тут каждый решает сам по какому пути идти.
Interior mutability вполне может всплывать в многопоточном/асинхронном коде и его практически нереально исполнить как-то иначе, так что тренировка на котиках вполне оправдывает себя.
с гораздо большей уверенностью в том, что код делает тоже самое.
Это уже не столько про рефакторинг, сколько в принципе про некрасивый код, который уже оптимален по Парето - сделаешь красивее - получишь минус производительность, сделаешь быстрее - получишь нечитаемую и неподдерживаемую кашу. Говорят задачи с Advent Of Code отличный способ показать подобные ситуации, но сам не пробовал его решать.
Пока что самое сложное в Rust начинается, когда в коде появляются всякие Cell/RefCell/Rc/Arc. Работа с односвязными списками самая большая боль и считаю, что если односвязный список появился в коде, то с большой долей вероятности кто-то что-то делает не так.
Вторая сложность - аргументирование о производительности кода. Вот эти во проблемы выбора между .iter(), .into_iter() и .iter_mut() или передача аргумента по значению/по ссылке. В одних ситуациях идея об иммутабельности типов работает и ожидаемые оптимизации срабатывают, в иных случаях производительность становится неочевидной и необходимо профилировать код даже на относительно небольших программах.
Третья вещь которая связана с рефакторингом - пока ваша программа линейная и однопоточная, то проблем с ним практически никогда не возникнет, но как только появляется асинхронность или многопоточность, а в сигнатуры начинают подмешивать лайфтаймы и границы а ля Send+Sync, то производный код быстро начинает ими "отравляться" при неаккуратном использовании и рефакторить его становится кратно сложнее. Способов решения этой проблемы имеется несколько, но подозреваю, что существуют ситуации, когда "уродливый" всё равно неизбежен.
После приблизительно 200 задач порешанных на leetcode понял, что теперь могу писать на rust скрипты так же продуктивно, как и на Python, имея при этом кратно бОльшую производителность (даром компилируемый язык) и меньшую вербозность, как если бы делал это на плюсах.
Rust в этом плане просто быстрее внедряет желаемые вещи, пока С++ комитет решает завести новый функционал в стандарт или оставить до новой версии на подумать - в расте оно уже работает в достаточно эргономичном виде. Для примера взгляните на ту же библиотеку ренжей и вью - сколько лет до них добирались и до сих пор нет полного покрытия у всех компиляторов, в то время как в Rust часть синтаксиса языка. Причины понятны, но работать от этого легче не становится. Нормальные модули ждём по сей день.
Rust Embed вполне активен насколько мне известен и опять же эргономика и инструментарий этой экосистемы в среднем лучше чем альтернативы для C++, хотя эквивалентный код вполне можно было написать и на C++. Т.к. работа с платами в любом случае будет сопряжена с манипуляциеми с голой памятью, то на определённых уровнях так или иначе всплывёт unsafe и возможность скрафтить UB, так что с плюсами в этом плане различий меньше. Оно будет просто удобнее в среднем.
В случае с виртуальными частицами сдаётся мне оно получается не совсем так и энергия остаётся снаружи, придавая импульс одно из частиц в паре и уводя её за пределы системы, а вторая проаннигилировав в пределах ГС уменьшила общую энергию ЧД. Но тут я могу ошибаться.
Так испарение происходит в момент аннигиляции частицы попавшей за горизонт событий с частицей уже бывшей внутри этого горизонта, кажется ей не обязательно падать сильно глубже, чтобы как-то пострадать от искривления. Либо нужно какое-то квантовое представление ЧД, где все частицы в пределах горизонта событий находятся на непересекающихся траекториях, не?
Обычно перформанс показывают на всяких npm install vs bun install и оно действительно в десятки раз быстрее для разработчика. Сам код примерно настолько же производителен как у того же V8 и производительность растёт просто из-за уменьшения Memory Footprint. Ну и ко всему часть API у bun ещё пока нетронута и вполне может быть медленее, чем у node/deno. Кажется где-то на хабре была статья со сравнением 1.0 версии.
Это альтернатив C, все же. Zig слишком прост, чтобы быть на том же уровне что и вышеупомянутые языки и подходы как к управлению памятью, так и структурируванию кода ближе к C или Go.
Самый известный минус этого рантайма — Bun нет на Windows.
буквально на днях вышел 1.1 релиз, где оно теперь и под винду работает. Теперь можно
вроде того какие трейты для какой структуры реализованы не сохраняется
не совсем так. оно в том или ином виде будет ссылаться на некоторые виртуальные таблицы, которые можно отрефлексировать при желании, но из-за того язык компилируемый гарантии интерфейса намертво зашиваются в бинарь. У managed языков есть рантайм, который позволяет его расширять и работать с ним как будто рабочее окружение было таким всегда.
Это явно оксюморон на ровном месте. Затенение подразумевает наличие некой тени, затмевание светом - это уже небылица. В оригинале как раз и используется "outshine" - пересветить, переблистать, пересиять. Перекрыть яркостью излучения, если хочется быть чуть более научным.
Оно будет стоить ровно столько же сколько и проверка указателя на выходную ноду (
node->nextли,node->left/rightли) наnull. Только в случае с линейной памятью компилятор вполне может сделать предположение о попадании в границы и выкинуть проверку, либо можно самому использовать unchecked версию. Ну и в C++ вполне существуют такие штуки какflat_map, которые для пользователя выглядят какstd::map, но сами ноды при этом лежат последовательно в линейной памяти, снижая фрагментацию и как следствие уменьшая накладные расходы на выделение памяти.это с каких пор доступ в линейную память стал аффектить производительность?
тут было бы неплохо какие-то примеры привести ибо за всё время не сталкивался с подобными проблемами.
эта фраза вызывает ещё большее недоумение. Более интуитивного кода чем на расте не встречал в иных языках. JS в этом плане довольно похож, только в сотни раз медленее. Даже у питона больше квирков в этом плане. Тут похоже тоже нужны какие-то примеры. Пока у вас в коде не возникает необходимость теребить сырые указатели оно даже от C++ отличаться практически не будет, а это требуется на крайне специфичных задачах - едва ли вам каждый день требуется разворачивать односвязные списки.
а вот с этого места поподробнее. Кроме стандартных спецификаторов для алгориитмов и либы openmp ничего настолько же универсального не припоминаю.
Каждая библиотека имеет свой собственный edition и т.к. каждый крейт - отдельный юнит трансляции они не страдают из-за этой разницы. Есть ещё так называемая политика MSRV - минимальная поддерживаемая версия раста. Так что каждый может писать независимо пока версия компилятора позволяет это делать.
А как это проявляется?
В 23 стандарте они выглядят ещё более похоже. LINQ емнип отлично встают в цепочку, в плюсах в новых стандартах можно делать похоже через пайплайн оператор (правда не для всех), либо использовать библиотеку вроде этой.
деревья-то понятно, один вошёл n вышло, но если это просто случайный граф да ещё и ориентированный, да ещё и с рёбрами из себя в себя, то там уже всплывают нюансы и возникает проблема "сложность" vs "количество" кода - либо будет сложно писать и убеждать компилятор, либо придётся реструктурировать код под более дата ориентированный подход с ECS и кверями, что легко и непринуждённо утроит сложную версию кода. Тут каждый решает сам по какому пути идти.
Interior mutability вполне может всплывать в многопоточном/асинхронном коде и его практически нереально исполнить как-то иначе, так что тренировка на котиках вполне оправдывает себя.
Это уже не столько про рефакторинг, сколько в принципе про некрасивый код, который уже оптимален по Парето - сделаешь красивее - получишь минус производительность, сделаешь быстрее - получишь нечитаемую и неподдерживаемую кашу. Говорят задачи с Advent Of Code отличный способ показать подобные ситуации, но сам не пробовал его решать.
Пока что самое сложное в Rust начинается, когда в коде появляются всякие Cell/RefCell/Rc/Arc. Работа с односвязными списками самая большая боль и считаю, что если односвязный список появился в коде, то с большой долей вероятности кто-то что-то делает не так.
Вторая сложность - аргументирование о производительности кода. Вот эти во проблемы выбора между
.iter(),.into_iter()и.iter_mut()или передача аргумента по значению/по ссылке. В одних ситуациях идея об иммутабельности типов работает и ожидаемые оптимизации срабатывают, в иных случаях производительность становится неочевидной и необходимо профилировать код даже на относительно небольших программах.Третья вещь которая связана с рефакторингом - пока ваша программа линейная и однопоточная, то проблем с ним практически никогда не возникнет, но как только появляется асинхронность или многопоточность, а в сигнатуры начинают подмешивать лайфтаймы и границы а ля Send+Sync, то производный код быстро начинает ими "отравляться" при неаккуратном использовании и рефакторить его становится кратно сложнее. Способов решения этой проблемы имеется несколько, но подозреваю, что существуют ситуации, когда "уродливый" всё равно неизбежен.
После приблизительно 200 задач порешанных на leetcode понял, что теперь могу писать на rust скрипты так же продуктивно, как и на Python, имея при этом кратно бОльшую производителность (даром компилируемый язык) и меньшую вербозность, как если бы делал это на плюсах.
Rust в этом плане просто быстрее внедряет желаемые вещи, пока С++ комитет решает завести новый функционал в стандарт или оставить до новой версии на подумать - в расте оно уже работает в достаточно эргономичном виде. Для примера взгляните на ту же библиотеку ренжей и вью - сколько лет до них добирались и до сих пор нет полного покрытия у всех компиляторов, в то время как в Rust часть синтаксиса языка. Причины понятны, но работать от этого легче не становится. Нормальные модули ждём по сей день.
Rust Embed вполне активен насколько мне известен и опять же эргономика и инструментарий этой экосистемы в среднем лучше чем альтернативы для C++, хотя эквивалентный код вполне можно было написать и на C++. Т.к. работа с платами в любом случае будет сопряжена с манипуляциеми с голой памятью, то на определённых уровнях так или иначе всплывёт unsafe и возможность скрафтить UB, так что с плюсами в этом плане различий меньше. Оно будет просто удобнее в среднем.
В случае с виртуальными частицами сдаётся мне оно получается не совсем так и энергия остаётся снаружи, придавая импульс одно из частиц в паре и уводя её за пределы системы, а вторая проаннигилировав в пределах ГС уменьшила общую энергию ЧД. Но тут я могу ошибаться.
Так испарение происходит в момент аннигиляции частицы попавшей за горизонт событий с частицей уже бывшей внутри этого горизонта, кажется ей не обязательно падать сильно глубже, чтобы как-то пострадать от искривления. Либо нужно какое-то квантовое представление ЧД, где все частицы в пределах горизонта событий находятся на непересекающихся траекториях, не?
А есть какая-то разница с теорией категорий? Сущности вроде аналогичные, ну или как минимум изоморфные.
Будете ли добавлять свои теории в mathlib в lean?
У них как-то подозрительно мало ссылок на другие источники, плюс часть утверждений никак не доказаны.
Обычно перформанс показывают на всяких npm install vs bun install и оно действительно в десятки раз быстрее для разработчика. Сам код примерно настолько же производителен как у того же V8 и производительность растёт просто из-за уменьшения Memory Footprint. Ну и ко всему часть API у bun ещё пока нетронута и вполне может быть медленее, чем у node/deno. Кажется где-то на хабре была статья со сравнением 1.0 версии.
Это альтернатив C, все же. Zig слишком прост, чтобы быть на том же уровне что и вышеупомянутые языки и подходы как к управлению памятью, так и структурируванию кода ближе к C или Go.
буквально на днях вышел 1.1 релиз, где оно теперь и под винду работает. Теперь можно
и погнали
Это не считая того, что он просто Bun
По площади МО (~40k кв км) чуть поменьше половины Чехии (~70k кв км), а ЛенОбл чуть побольше (80 кв км).
Не очень понимаю как это соотносится с вопросом, "почему при освоении технологии Китай совершенно однозначно станет монополистом?"
не совсем так. оно в том или ином виде будет ссылаться на некоторые виртуальные таблицы, которые можно отрефлексировать при желании, но из-за того язык компилируемый гарантии интерфейса намертво зашиваются в бинарь. У managed языков есть рантайм, который позволяет его расширять и работать с ним как будто рабочее окружение было таким всегда.
Это явно оксюморон на ровном месте. Затенение подразумевает наличие некой тени, затмевание светом - это уже небылица. В оригинале как раз и используется "outshine" - пересветить, переблистать, пересиять. Перекрыть яркостью излучения, если хочется быть чуть более научным.