Rust vs C++

Кто-то писал на Rust? Стоит ли начинать учить? Насколько Rust хуже/лучше С++?

0

Сообщение от COKPOWEHEU Онлайн калькулятор предложил логарифмическую функцию -12330,1+1622,7877*ln(x), тоже неплохо описывает

Если данный онлайн-калькулятор не на С++, то его результаты не стоит учитывать.

0

COKPOWEHEU, разве это график полинома 3й степени?)

0

ReYalp, Калк утверждает, что формула такова:
= -0,002356837495*A1*A1*A1 + 14,184021696*A1*A1 - 28453,171276*A1 + 19024958,7
Хотя для отрицательный коэффициент при кубе выглядит странно, я бы скорее предложил аппроксимировать логарифмом

0

Сообщение от COKPOWEHEU Самому стало любопытно. Темп роста винды действительно хорошо описывается экспонентой, а для линукса - полиномом 3-й степени. Пытался натянуть логарифм, но Калк этого не сумел, а я не стал настаивать.

Вы сравниваете рост кода дистряка, у которого функиональность растет как на дрожжах, а код растет в том числе и за счет включения в него софта который существовал и ранее но предустановленным не был, и рост кода ядра, у которого функциональность не меняется, только дырки залатываются.

Добавлено через 12 минут
COKPOWEHEU, Т.е. - кривая роста у винды вообще никак не связана с ростом объема самой оси, а тем более ядра, и при этом повторяет рост функциональности. У ядра линухи - рост объема кода ядра на ровном месте, без прироста функциональности.

0

Сообщение от Fulcrum_013 Вы сравниваете рост кода дистряка

Это не я, это вот этот персонаж:

Сообщение от Fulcrum_013 COKPOWEHEU, https://ru.wikipedia.org/wiki/... строк_кода При этом показательны темпы роста. У винды рост объемов кода примерно линейный у линухи экспонента.

Сообщение от Fulcrum_013 у которого функиональность растет как на дрожжах, а код растет в том числе и за счет включения в него софта который существовал и ранее но предустановленным не был, и рост кода ядра, у которого функциональность не меняется, только дырки залатываются.

Честно сказать - я не знаю как оценить потенциальную функциональность именно ядра. То, что в дистрибутив винды вкручена куча абсолютно ненужного мусора вроде просмотровщика трехмерной графики, магазина, рекламы, телеметрии и тому подобного - не секрет. Ходят слухи, что туда встраивают и полезные вещи вроде драйверов или библиотек совместимости со старым софтом... еще бы они работали как следует.
А ядро линукса, как вы правильно сказали, разрастается за счет включения все большего количества драйверов и архитектур.
Видимая снаружи функциональность что там, что там годов с 2000-х сильно не изменилась.
О росте функциональности ядра можно судить по способности быть средой для разнообразного прикладного софта. Тут мы видим тотальный перевес Линукса. Во-первых, под ним можно запускать виндовые программы, иногда даже успешно. Во-вторых, гораздо более удачная модель разграничения прав и ресурсов подтверждается тем, что даже сами Майкрософты используют его для хоста виртуальных машин. Монолитное, но небольшое, ядро на практике оказывается более гибким, чем микро-, но с сильной связностью: можно и в роутер встроить, и в суперкомпьютер.
В результате видим быстрое разрастание за счет впихивания тонны бесполезного мусора в винде против медленного роста за счет увеличения количества драйверов и прочего функционала в линуксе.
И эта сильная связность виндового ядра удручает: становится крайне сложно выпилить весь этот мусор или заменить своим. Вспомните сколько они сами мучились с отдиранием InternetExplorer'а. Вспомните сколько было попыток сторонних разработчиков привести графическое окружение к вменяемому виду. Да что говорить, возможность нескольких рабочих столов там появилась совсем недавно, и то ущербная, возможности настроить произвольную комбинацию клавиш, кажется, вообще нет. В winXP-win7 хотя бы настройки были мало-мальски юзер-френдли сделаны (с этим у линуксов проблемы), но и то уже поломали. А то что они до сих пор не осилили такую простую концепцию как репозитории? Ладно для стороннего софта - там есть бюрократические проблемы - но хотя бы для своего и опенсорсного ничего им не мешало. Хотя бы скопировать механизм того же apt'а и предоставить к нему доступ для разработчиков - я вас уверяю, нашлись бы энтузиасты, готовые им воспользоваться. Это не запредельно сложно, вон ребята из AltLinux'а умудрились прикрутить apt к своему формату rpm. Да и производители железа наверняка бы не отказались от человеческого установщика для своих драйверов.

Сообщение от Fulcrum_013 без прироста функциональности

Какой конкретно функциональности ядра вам не хватает? Хорошо, если подстраиваться под винду с ее странными представлениями о ядре - чего конкретно вам не хватает в базовой поставке Убунты? А если в более общем случае - в Линуксе.

0

Сообщение от COKPOWEHEU Какой конкретно функциональности ядра вам не хватает?

Ему в джаве не хватает С++ и здесь ему не хватает ядра винды в ядре линукса.

0

Сообщение от COKPOWEHEU Какой конкретно функциональности ядра вам не хватает?

Вопос не в том что хватает ее или нет. Вопрос в том что она постоянна. В отличии от функциональности дистряка винды которая растет как на дрожжах, особенно для приведенных версий. К примеру рост между Win2K и XP обусловлен в первую очередь добавлением в дистряк Net FRamework, который в Win2K не был предустановленным.

Добавлено через 26 минут

Сообщение от COKPOWEHEU Честно сказать - я не знаю как оценить потенциальную функциональность именно ядра.

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

Сообщение от COKPOWEHEU То, что в дистрибутив винды вкручена куча абсолютно ненужного мусора вроде просмотровщика трехмерной графики, магазина, рекламы, телеметрии и тому подобного - не секрет

Дистрибутив это дистрибутив - это окромя самой оси (т.е. ядра, апи, драйвер-пака, десктопа, и утилит управления всем этим хозяйством) еще и куча предустановленного софта. И линуха а тем более ведро этом плане не исключение - тоже понапихано всего и вся. При этом даже в линуху для одноплатников. Причем в линуху для однаплатников понапихано такого чего в десктопной вообще нет от слова совсем.

Добавлено через 7 минут

Сообщение от COKPOWEHEU Хорошо, если подстраиваться под винду с ее странными представлениями о ядре - чего конкретно вам не хватает в базовой поставке Убунты? А если в более общем случае - в Линуксе.

Вернемся к нашим баранам. У нас сравнение продуктивности языков а не че там не так в убунте. Суть в том что у С при неизменной функциональности ядро разрослось гораздо больше чем у Майкрософта вся оська, вместе с тем что туда понатыкано. Т.е. банально смотрим количество строк ядра линухи - оно где то по середине между количеством строк кода в Win2K и XP. Вот вам и вывод о продуктивности С - на порядки ниже даже "С с классами" на которых написана винда и предустановленный софт тех времен.

0

Сообщение от Fulcrum_013 Вопос не в том что хватает ее или нет. Вопрос в том что она постоянна.

То есть раз функциональность винды постоянна, а объем растет - какой вывод мы можем сделать?
У линукса-то видно что меняется - как минимум, набор драйверов и архитектур плюс исправление ошибок.

Сообщение от Fulcrum_013 Ну о чем и речь. Вся проблема в вашем незнании азов специальности. Т.е. даже до уровня второго курса вы не доросли. А скорее всегов универе и дня не проучились.

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

Сообщение от Fulcrum_013 Дистрибутив это дистрибутив - это окромя самой оси (т.е. ядра апи десктопа и утилит управления всем этим хозяйством) еще и куча предустановленного софта. И линуха а тем более ведро этом плане не исключение - тоже понапихано всего и вся.

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

Добавлено через 2 минуты

Сообщение от Fulcrum_013 Т.е. банально смотрим количество строк ядра линухи - оно где то по середине между количеством строк кода в Win2K и XP. Вот вам и вывод о продуктивности С

Ну видим, что размер на уровне винды 2000 года, функционал намного выше винды 2020-го. Нет, это говорит не о продуктивности языка, а о продуктивности программистов. Что дальше?

0

Сообщение от COKPOWEHEU То есть раз функциональность винды постоянна,

Нет. У винды растет объем предустановленного софта, апи и доайвер пак. Размер же ядра примерно постоянен.

Сообщение от COKPOWEHEU линукса-то видно что меняется - как минимум, набор драйверов и архитектур плюс исправление ошибок.

Ну вот это закостыливание костылей (исправление ошибок) уже вылилось в объемы превосходящие по размерам кода все что входит в дистряки осей - т.е. весь предустановленный софт, десктоп, все апи которое даже у 2k на порядок обширнее чем у Linux 2020

Сообщение от COKPOWEHEU набор драйверов и архитектур

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

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Тем не менее один и тот же функционал достигается в линуксе в разы меньшими затратами, чем в винде.

Ну как бы статистика линий кода свидетельствует об абсолютно обратном.

Добавлено через 20 минут

Сообщение от COKPOWEHEU Нет, это говорит не о продуктивности языка, а о продуктивности программистов

О продуктивности языка говорит функционал вложенный в количество строк кода. На С в 26 мегастрок это смогли вложить только ядро. На "C c классами" всю ось с предустановленным софтом. При этом к примеру если смотреть дальше то рост размеров винды просто произошел скачком от 2000 к XP за счет включение в дистраяк огромного количества апи которое раньше поставлялось отдельно. Дальше же рост существенно замедлился - Vista порядка 40 мегастрок, Windows 7 - порядка 50.
А что касается линухи - то ее только ядро перевалило за весь объем кода Boeing 787 вкупе с Шаттлом Хабблом и марсоходом.

0

Сообщение от Fulcrum_013 Нет. У винды растет объем предустановленного софта, апи и доайвер пак. Размер же ядра примерно постоянен.

да, именно это я и написал: "растет набор бесполезного предустановленного мусора". А функционал растет довольно медленно.

Сообщение от Fulcrum_013 Ну вот это закостыливание костылей (исправление ошибок) уже вылилось в объемы превосходящие по размерам кода все что входит в дистряки осей - т.е. весь предустановленный софт, десктоп, все апи которое даже у 2k на порядок обширнее чем у Linux 2020

Исправление ошибок обычно не приводит к существенному увеличению кода. А соотношение объемов мы уже обсуждали: функционал, превышающий актуальную винду умещается в размер винды 20-летней давности.

Сообщение от Fulcrum_013 А насчет поддержки архитектур - она в основном выражается в изменении размера буфера под сохранение контекста при переключении потоков и больше ни в чем. Максимум в немного другом формате таблиц дескрипторов и т.п.

Но ведь... Ах да, вы же судите о программировании исключительно по рассказам. Если бы портирование софта на другие процессоры было таким простым как вы описываете, не было бы проблем с переносом той же винды с х86 на что-то другое. Говорят, правда, что на единственную другую архитектуру портировали, но почему-то не упоминается что поломалось. Для сравнения можете погуглить на сколько архитектур портирован линукс, и этим никто особо не хвастается.

Сообщение от Fulcrum_013 Ну как бы статистика линий кода свидетельствует об абсолютно обратном.

Поясните. Пока что я вижу экспоненциальный рост винды без видимог оприроста функционала и логарифимический - линукса, рост функционала которого очевиден.
Но подведу промежуточный итог по рассмотренным темам, чтобы не забыть:

Сравнение языков программирования: - почему божественные плюсики не вытеснили все остальные языки из всех ниш, если они их во всем превосходят? <<< ответа нет и не будет: Fulcrum_013 не слышал о других языках >>> - каков объем кода, реализующего асинхронный обмен данными между двумя потоками? Поскольку сложность реализации такого базового функционала, как каналы, вы уже и сами подозреваете, сжалюсь и оставлю выбор типа данных и способа обмена за вами. <<< Ответа нет и не будет: Fulcrum_013 считает что это не нужно никому и никогда >>> - почему парадигма ООП не вытеснила все остальные, если она так хороша? Почему до сих пор существуют процедурные, функциональные языки? Естественно, элементы ООП в них могут встречаться, все же это реальные языки, а не декоративные. <<< ответа нет и не будет: Fulcrum_013 не слышал о других парадигмах >>> Сравнение операционных систем: - признаете ли вы, что рост винды гораздо больше похож на экспоненту, чем линукса? Исключительно по вашим же данным. <<< ждем финала >>> - Каков объем и системные требования дистрибутива винды, решающего самый базовый класс задач - ползанье по интернету, работу в офисной программе, просмотр картинок, видео и pdf? <<< ждем финала >>>

Если вы с чем-то не согласны, лучше озвучьте свою позицию во избежание недопонимания.

Добавлено через 2 минуты

Сообщение от Fulcrum_013 Дальше же рост существенно замедлился - Vista порядка 40 мегастрок, Windows 7 - порядка 50.

Вы же понимаете, что на свое утверждение придется снова приводить ссылки? Которыми я, естественно, воспользуюсь в своих корыстных целях.

Сообщение от Fulcrum_013 А что касается линухи - то ее только ядро перевалило за весь объем кода Boeing 787 вкупе с Шаттлом Хабблом и марсоходом.

Это общая тенденция современного софта, увеличение объема и снижение эффективности. Ядро линукса на фоне остального софта (да, включающего винду) еще неплохо держится.

0

Сообщение от COKPOWEHEU каков объем кода, реализующего асинхронный обмен данными между двумя потоками?

Никакой.

Сообщение от COKPOWEHEU почему божественные плюсики не вытеснили все остальные языки из всех ниш, если они их во всем превосходят?

Давно вытеснили практически все.

Сообщение от COKPOWEHEU функционал, превышающий актуальную винду умещается в размер винды 20-летней давности

Сообщение от COKPOWEHEU Исправление ошибок обычно не приводит к существенному увеличению кода.

Еще раз - вы пытаетесь сравнить мягкое с холодным, пытаясь сравнивать оси подразумевая под линухой ядро оси. Ядро вообще никакой функциональностью видимой пользователю ОС не обладает. При этом функциональность апи линукса существенно уступает функциональности апи Windows 3.1

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Если бы портирование софта на другие процессоры было таким простым как вы описываете, не было бы проблем с переносом той же винды с х86 на что-то другое

А их и нет. Она спокойно се живет и на x64 и атомах и на ARM.

Добавлено через 2 минуты

Сообщение от COKPOWEHEU Пока что я вижу экспоненциальный рост винды без видимог оприроста функционала

Еще раз 2000 отдичается от XP к примеру тем что добавили в дистряк Net.Framework - т.е. по сути нечто превосходящее Java SDK вместе со всеми Java фреймверками вместе взятыми.
Ядро линухи за все время своего существования в функциональности ни прибавило вообще ничего. Ядро штука сама в себе - функциональность ни добавить ни убавить. Меняется только реализация

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Исправление ошибок обычно не приводит к существенному увеличению кода.

Обкостыливание костылей именно к этому и приводит.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU сли вы с чем-то не согласны, лучше озвучьте свою позицию во избежание недопонимания.

Плюсы в профессиональной разработке давно загнали по узким щелям абсолютно все остальные универсальные языки - т.е. по факту похоронили их как универсальные. Квалифицированные разработчики которые решают 99% задач индустрии используют при этом пеимущественно универсальные языки. Весь остальной зоопарк юзаемый неквалифицированными разрабами, коих в индустрии около 90% решает не более 1% задач.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU почему парадигма ООП не вытеснила все остальные, если она так хороша?

Давно вытеснила. Причем гораздо раньше чем появились ООП-языки. Смотрим те же сокеты беркли. Спроектированы по ООП методологии, реализация - костыленье ООП средствами процедурного языка. Смотрим абстракцию файл/поток ввода выводв в юниксе и последышах родственниках. То же самое. И так везде. Абсолютно все что сложнее табуляции функции спроектированно именно по ООП методологии.

0

Сообщение от Fulcrum_013 каков объем кода, реализующего асинхронный обмен данными между двумя потоками? Никакой. почему божественные плюсики не вытеснили все остальные языки из всех ниш, если они их во всем превосходят? Давно вытеснили практически все.

Ну да, именно это я в резюме и написал: вы считаете, что потокам обмениваться данными не нужно. А других языков кроме С++ нет.

Сообщение от Fulcrum_013 Еще раз - вы пытаетесь сравнить мягкое с холодным, пытаясь сравнивать оси подразумевая под линухой ядро оси.

Нет. Я их пытаюсь сравнить хоть с какой-то степенью достоверности. Если объем исходных кодов ядра винды официально узнать невозможно, предлагаю сравнить хотя бы объемы дистрибутивов, решающих сходные задачи.

Сообщение от Fulcrum_013 При этом функциональность апи линукса существенно уступает функциональности апи Windows 3.1

А что, обычная винда уже научилась в поддержку одновременно нескольких пользователей? Я ее, конечно, давненько палочкой не тыкал, но сколько помню там всегда с этим проблемы были.
Или, может быть, она научилась в централизованное управление софтом?
Да хотя бы приблизительно набор файловых систем перечислите!

Сообщение от Fulcrum_013 А их и нет. Она спокойно се живет и на x64 и атомах и на ARM.

Ну да, в 2008 примерно начали портировать (когда они там планшетную восьмерку задумали), вроде бы перенесли. Хотя я до сих пор не видел достоверной реализации. Вроде бы на RaspberryPi портировали какой-то огрызок десятки, вроде бы планируют какой-то планшет-трансформер. А вот с реальными устройствами и полноценной ОС туговато.
Я бы не сказал что вот это и называется "нет проблем".

0

Сообщение от COKPOWEHEU каков объем кода, реализующего асинхронный обмен данными между двумя потоками?

Никакой. Изучите сначала определение того что такое поток.

0

Сообщение от Fulcrum_013 Еще раз 2000 отдичается от XP к примеру тем что добавили в дистряк Net.Framework

... то есть вкрутили в ядро то, что к нему отношения не имеет. Допустим.

Добавлено через 1 минуту
Ах да, к предыдущим вопросам добавляется требование пруфа на объем кода Висты и семерки.

0

Сообщение от COKPOWEHEU ризнаете ли вы, что рост винды гораздо больше похож на экспоненту, чем линукса?

Нет. Данные приведены для винды по всей оси у которой рост функциональности соответсвует кривой, и только по ядру, у которого рост функциональности отсутствет по определению.
COKPOWEHEU,
Вас зациклило? Ваша безграмотность не дает вам понять то что вам говорят и пытаться как то аргументировать вашу точку зрения, поэтому просто пытаетеь повторят вопросы по сто раз? Вы настолько тупы что не понимаете что ответы на них не изменятся никогда?

Добавлено через 58 секунд

Сообщение от COKPOWEHEU то есть вкрутили в ядро то,

А при чем тут ядро? По винде данные приведены по всему дистряку, а не по ядру.
Объем бинарки ядра к примеру 10-ки - 3,5МБ. НУ и хотя конечно общего процента кода размера бинарки кразмеру дистряка общий объем кода не покажут но примерный порядок величин примерно соответсвует. Т.е. ядро винды занимает никак не более нескольких процентов от объема кода всего дистряка. При этом начиная с XP когда начали напихивать предустановленны софт доля ядра начала резко падать.

0

Сообщение от Fulcrum_013 рост функциональности отсутствет по определению.

Вам уже пару страниц назад советовали выкинуть ваши "определения" и "проценты" как не имеющие отношения к реальности.

Сообщение от Fulcrum_013 Данные приведены для винды по всей оси

Я продолжаю настаивать на сравнении объема и системных требований двух ОСей, способных решать одни и те же задачи. Хотя бы самые распространенные - просмотр веба, картинок, документов.
Свои данные я приводил, но они вас, кажется, не впечатлили, поэтому жду ваших.

Сообщение от Fulcrum_013 Объем бинарки ядра к примеру 10-ки - 3,5МБ

Нет-нет, те четыре библиотеки это модули ядра - а само ядро-то где? Что именно загружается загрузчиком при старте ОС?

Сообщение от Fulcrum_013 Т.е. ядро винды занимает никак не более нескольких процентов

Свои "проценты" выкидыв... а, уже говорилось... и не раз.

0

Сообщение от COKPOWEHEU Вам уже пару страниц назад советовали выкинуть ваши "определения" и "проценты" как не имеющие отношения к реальности.

С реальностью ничего общего не имеют ваши высказывания. Хотя бы потому что вы ни малейшего понятия не имеете о том что такое ядро ос и с чем его едят как вы это сами признали.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Я продолжаю настаивать на сравнении объема и системных требований двух ОСей, способных решать одни и те же задачи.

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

Добавлено через 15 минут
COKPOWEHEU, Для самых одаренных

Отличие от процессов[править | править код] Потоки выполнения отличаются от традиционных процессов многозадачной операционной системы тем, что: - процессы, как правило, независимы, тогда как потоки выполнения существуют как составные элементы процессов - процессы несут значительно больше информации о состоянии, тогда как несколько потоков выполнения внутри процесса - совместно используют информацию о состоянии, а также память и другие вычислительные ресурсы - процессы имеют отдельные адресные пространства, тогда как потоки выполнения совместно используют их адресное пространство - процессы взаимодействуют только через предоставляемые системой механизмы связей между процессами - переключение контекста между потоками выполнения в одном процессе, как правило, быстрее, чем переключение контекста между процессами.

Хотя бы вот эту мурзилку прочитайте для начала, осмыльте, тогда бред нести перестанете.

0

Сообщение от Fulcrum_013 С реальностью ничего общего не имеют ваши высказывания. Хотя бы потому что вы ни малейшего понятия не имеете о том что такое ядро ос и с чем его едят как вы это сами признали.

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

Сообщение от Fulcrum_013 Эта штука специально создавалась для того чтобы асинхронный обмен между ними был не нужен, а достаточно было только синхронизации доступа к памяти/ресурсам

Это не так. Как минимум, при создании потока, в отличие от процесса, отсутствуют накладные расходы на копирование адресного пространства, что приводит к чуть большей скорости создания и некоторым ограничениям на объем памяти.
Не буду утверждать про винду, но в линуксе это совершенно естественное событие: процесс делает fork(), после чего в его адресном пространстве появляется клон, практически забесплатно. Потом этот клон может вызывать exec(), что выделит для него персональное адресное пространство и новый исполняемый файл. Особенно учитывая что выделение нового участка памяти - довольно дорогая операция.
Иначе говоря, порождение потока это, можно сказать, порождение процесса, оборванное на полпути.
Насколько я слышал про windows, там эта технология появилась несколько позже и сопряжена с большими затратами. Вместо этого там пытались внедрять "нити" (fiber), но применяются ли они где-то на практике - не слышал.
tl;dr: задача потоков не столько в разделении ресурсов, сколько в более быстром создании.

Сообщение от Fulcrum_013 При этом обмен через каналы - ниаболее неэффективный способ обмена в принципе

И еще раз: не хотите через каналы - ладно, покажите код, который демонстрирует неблокирующий обмен хоть каким-нибудь способом. Уже даже плевать на эффективность, я лишь хочу полюбоваться насколько ваша хваленая winapi проигрывает "доисторической" линуксовой.
Напоминаю также что вы подписались предоставить доказательства следующим утверждениям:

Сообщение от Fulcrum_013 Дальше же рост существенно замедлился - Vista порядка 40 мегастрок, Windows 7 - порядка 50.

Сообщение от Fulcrum_013 [проблемы портирования windows на другие архитектуры] А их и нет. Она спокойно се живет и на x64 и атомах и на ARM.

Ну и про объем дистрибутива для базового класса задач что-то заглохло.

0

Сообщение от COKPOWEHEU Как минимум, при создании потока, в отличие от процесса, отсутствуют накладные расходы на копирование адресного пространства,

Какое вооще копиирование к глиняной маме? Оно если и есть то только при форке - т.е. создании копии процесса.Поток - это еще один контекст выполнения в том же процессе, а не отдельный процесс. Т.е. по определению живет в том же адресном пространстве.О каком обмене между потоками может идти речь если их данные по определению потока доступны друг другу?

Добавлено через 2 минуты

Сообщение от COKPOWEHEU Это не так.

Это именно так.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU но в линуксе это совершенно естественное событие: процесс делает fork(),

Это анахронизм времен юникса и это не разу не создание потока. Поток в линухе аналогичен виндовскому и создается через pthread_create. А анохронизм в духе fork()/запуск дочернего процесса - это не создание потока от слова совсем. Это создание/клонирование процесса.

0

Сообщение от Fulcrum_013 Оно если и есть то только при форке - т.е. создании копии процесса.Поток - это еще один контекст выполнения в том же процессе, а не отдельный процесс. Т.е. по определению живет в том же адресном пространстве.

Перечитайте мое сообщение еще раз. На этот раз глазами.

Сообщение от Fulcrum_013 [fork] Это анахронизм времен юникса и это не разу не создание потока.

Вот на эту тему даже не хочется пока спорить. Это же придется в документации рыться, доказывать что внутри реализации достаточно близкие. Лучше сначала добьем более простые темы:

Сообщение от Fulcrum_013 Vista порядка 40 мегастрок, Windows 7 - порядка 50.

Сообщение от Fulcrum_013 [проблемы портирования windows на другие архитектуры] А их и нет. Она спокойно се живет и на x64 и атомах и на ARM.

Сообщение от COKPOWEHEU - признаете ли вы, что рост винды гораздо больше похож на экспоненту, чем линукса? Исключительно по вашим же данным. - Каков объем и системные требования дистрибутива винды, решающего самый базовый класс задач - ползанье по интернету, работу в офисной программе, просмотр картинок, видео и pdf?

0