The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

В ОС Fuchsia начат приём изменений от представителей сообщества, opennews (??), 08-Дек-20, (0) [смотреть все]

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


19. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  –6 +/
Сообщение от Аноним (19), 09-Дек-20, 00:59 
С микроядром? У вас странное понимание "здоровья".
Ответить | Правка | Наверх | Cообщить модератору

38. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +4 +/
Сообщение от Аноним (38), 09-Дек-20, 06:41 
Микроядра на x86 не используются вовсе не из-за их невозможности:P а из-за тормозного переключения контекста. На других процессорных архитектурах этого может и не быть. Как на PPC к примеру. M$ кстати потому и использует гибридное ядро хотя изначально ядро виндовс задумывалось микроядерным.
Ответить | Правка | Наверх | Cообщить модератору

44. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +3 +/
Сообщение от Аноним (-), 09-Дек-20, 07:59 
> изначально ядро виндовс задумывалось микроядерным.

Однако рынок проблевался с NT3.5x и выбрал уродца win95. Пришлось забить на всякие глупости и еще пару релизов делать это. К винтукею оно не только не выделывалось с микроядрами, но и весь GDI в ядро втащило как win32k.sys, не говоря про видеодрова. Зато оно наконец смогло хоть как-то претендовать на замену 95-го досэкстендера.

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

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

56. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +4 +/
Сообщение от funny.falcon (?), 09-Дек-20, 10:51 
Забавно читается «Win95» и «у мобильных устройств процы маломощные» вместе. Сейчас у самого вшивого смартфона мощнее процессор, чем на котором Win95 нормально себя чувствовал. Да что там смартфоны, думаю и большинство смартчасов мощнее.

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

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

74. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +2 +/
Сообщение от Аноним (74), 09-Дек-20, 12:43 
Похожие проблемы хоть и по разным причинам. Там циклы экономили потому что процессоры убогие. А тут потому что на всем скаку этот многоядерный монстр даже с 6-амперным аккумулятором разделывается за полдня, если не спит.
Ответить | Правка | Наверх | Cообщить модератору

82. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  –7 +/
Сообщение от Gogi (??), 09-Дек-20, 13:38 
Проблема не в скорости, а в производительности! Можно делать хоть 5 команд за такт, но финальный выхлоп - копеечный. Кроме того, не так важна скорость проца, как автономность (которой никогда много не бывает).

БК-0010 работал на 250,000Гц процессоре и, поразительно, редактор в нём был БЫСТРЕЕ тех же 5МГц IBM XT. Удивительно, но факт - я работал с обоими и просто не верил глазам.

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

122. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +7 +/
Сообщение от Алеша (?), 10-Дек-20, 00:48 
где вы наслушались этих бредовых сказок? только не нужно заливать про "я сам работал", работавший на БК-0010 такой ереси никогда бы не написал.
хотя бы откройте википедию и посмотрите там на счет "250,000Гц процессоре".
или у вас какой-то самодельный БК был с самодельным же процессором? потому что заводские БК шли на процессоре К1801ВМ1 у которого частота, внезапно, 3 МГц.
или вот например, чудный видеоадаптер на 1801ВП1 давал нам возможность вдоволь поупражняться в написании и оптимизации кода на асме, потому что даже на заливку экрана символами нельзя было смотреть без слез - ее было видно невооруженным глазом. какие там 25 кадров/сек, там несчастные 256*256 пикселей полсекунды заливались!
Ответить | Правка | Наверх | Cообщить модератору

87. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +2 +/
Сообщение от Аноним (19), 09-Дек-20, 14:03 
> Микроядра на x86 не используются вовсе не из-за их невозможности:P а из-за тормозного переключения контекста.

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

> На других процессорных архитектурах этого может и не быть. Как на PPC к примеру.

Что такого есть в PPC, чего нет в x86 и от чего IPC (inter-process communication) становится сравнимым по скорости с обычным вызовом функций?

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

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

89. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +1 +/
Сообщение от n00by (ok), 09-Дек-20, 14:38 
>> На других процессорных архитектурах этого может и не быть. Как на PPC к примеру.
> Что такого есть в PPC, чего нет в x86 и от чего
> IPC (inter-process communication) становится сравнимым по скорости с обычным вызовом функций?

Скорее, оратор просто не знает, что такое таблица страниц, зачем она нужна, и откуда берётся "тормознутость".

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

106. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +2 +/
Сообщение от Аноним (106), 09-Дек-20, 20:53 
А тут ораторы знают что такое сохранение состояния CPU при переключении контекста? И сколько тактов все это счастье может занимать? При том что все это время процессор вообще совсем ничего полезного не делает, это просто обеспечение абстракции для другой задачи что типа процессор был целиком в ее распоряжении, а вовсе тут и не пахал кто-то еще, перевернувший состояние проца кверх дном.
Ответить | Правка | Наверх | Cообщить модератору

116. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +1 +/
Сообщение от Аноним (19), 09-Дек-20, 22:36 
Штука в том, что переключение контекста происходит реже при монолитном ядре, чем при микроядре. И на самом деле бо́льшую часть времени занимает не сохранение/загрузка состояния CPU, а перетасовка потоков в ядре, с учетом приоритетов, таймаутов, NUMA-локальности и всего остального, чем занимается планировщик. Плюс негативные последствия в виде холодного кеша или если в результате данные оказываются на чужой ноде.
Ответить | Правка | Наверх | Cообщить модератору

120. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от Аноним (120), 09-Дек-20, 23:48 
Есть ещё подход, когда переключений контекста вообще нет, вместо процессов гринтреды, а изоляция обеспечивается на уровне виртуальной машины с JIT. Например, в экспериментальной Microsoft Singularity так сделано.
Ответить | Правка | Наверх | Cообщить модератору

121. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от Аноним (19), 10-Дек-20, 00:42 
Переключения контекста есть везде, где количество потоков/процессов больше, чем логических ядер CPU. Про Singularity до этого не слышал, но судя по описанию, там переключения контекста таки должны быть, хотя и менее затратные за счет того, что адресное пространство общее для всех процессов. Что уже само по себе является утопией.
Ответить | Правка | Наверх | Cообщить модератору

126. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от n00by (ok), 10-Дек-20, 06:55 
С Сингулярностью в своё время бегали пророки, как ныне с микроядрами. Куда-то пропали.
Ответить | Правка | Наверх | Cообщить модератору

140. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от Аноним (-), 10-Дек-20, 19:08 
> С Сингулярностью в своё время бегали пророки, как ныне с микроядрами. Куда-то пропали.

Видимо, наступление сингулярности откладывается.

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

144. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от Аноним (120), 11-Дек-20, 09:05 
Идея никуда не делась, просто это совершенно другой подход, исключающий прямую работу с указателями. С вопросами производительности, обычно требующими unsafe, можно справиться, предоставив специальные api ядра под конкретные задачи, но вот переписать весь накопленный код с нуля - это скорее утопия.
Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

154. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от Аноним (-), 12-Дек-20, 01:03 
> Идея никуда не делась, просто это совершенно другой подход, исключающий прямую работу с указателями.

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

> С вопросами производительности, обычно требующими unsafe, можно справиться,
> предоставив специальные api ядра под конкретные задачи, но вот переписать весь
> накопленный код с нуля - это скорее утопия.

И кроме того все потуги "можно справиться" почему-то на практике выглядели "не очень".

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

131. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от Аноним (-), 10-Дек-20, 15:56 
> Штука в том, что переключение контекста происходит реже при монолитном ядре, чем при микроядре.

И поэтому на все это тратится меньше времени. В Linux так вообще сделали какую-то круть чтобы жевать за присест сразу блок сисколов, раз уж переключение дорогое.

> И на самом деле бо́льшую часть времени занимает не сохранение/загрузка состояния CPU,
> а перетасовка потоков в ядре, с учетом приоритетов, таймаутов, NUMA-локальности
> и всего остального, чем занимается планировщик.

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

> Плюс негативные последствия в виде холодного кеша или если в результате данные оказываются
> на чужой ноде.

Врядли нумапроблемы первоочередны для сабжа.

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

138. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от Аноним (19), 10-Дек-20, 18:33 
> В Linux так вообще сделали какую-то круть чтобы жевать за присест сразу блок сисколов, раз уж переключение дорогое.

Сам по себе syscall не приводит к переключению контекста, он лишь меняет привелегии потока. К переключению контекста приводит блокировка исполнения потока в ядре, например, в IO или futex. Ну и, очевидно, при истечении кванта времени, отведённого потоку на исполнение.

> Врядли нумапроблемы первоочередны для сабжа.

Да как сказать. AMD Zen принёс эти самые проблемы на десктоп и в мобильный сектор, и чем дальше в лес, тем будут слаще помидоры.

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

141. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от Аноним (-), 10-Дек-20, 19:15 
> Сам по себе syscall не приводит к переключению контекста, он лишь меняет
> привелегии потока. К переключению контекста приводит блокировка исполнения потока в ядре,
> например, в IO или futex. Ну и, очевидно, при истечении кванта
> времени, отведённого потоку на исполнение.

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

> Да как сказать. AMD Zen принёс эти самые проблемы на десктоп и
> в мобильный сектор, и чем дальше в лес, тем будут слаще помидоры.

Под мобильным сектором понимаются ноуты, чтоли? Врядли сабж сильно целит туда. Впрочем, +1 причина почему хипстеры могут пролететь с объявлеными целями. Окажется что на такую штуку надо было в 20 раз сложнее, при попытке что-то такое сделать окажется что "почти совсем нитармазит, переписали и вообще, это было давно и неправда", etc.

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

127. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от n00by (ok), 10-Дек-20, 06:59 
> А тут ораторы знают что такое сохранение состояния CPU при переключении контекста?
> И сколько тактов все это счастье может занимать?

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

> При том что
> все это время процессор вообще совсем ничего полезного не делает

Ага. А Hyper-threading - это просто волшебство, берущее прирост производительности из ниоткуда.

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

132. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от Аноним (-), 10-Дек-20, 16:03 
> Простите за бестактный вопрос: Вы так шутите, или намекаете, что прежде чем
> сохранить регистры в ячейки памяти, надобно сначала сопоставить виртуальному адресу тех
> ячеек физическую страницу?

Я намекаю что у современного проца состояние немеряное. И его тасовка, хоть там как - дорогая операция. О чем нормальные ядерные разработчики - давно в курсе. А эти вебмакаки узнают об этом когда их уродец сможет какой-нибудь бенч запустить и прос@сут пингвину оптом. Но это следующая часть балета.

> Ага. А Hyper-threading - это просто волшебство, берущее прирост
> производительности из ниоткуда.

Развейте мысль? Гипертрединг - фэйковые "ядра" для более плотной загрузки фактически имеющихся блоков выполнения. Которые не обязаны совпадать с "процессорными ядрами" 1 в 1 - и поэтому что там какой производитель вообще "процессорным ядром" называет - нехилая условность. Если в железе смотреть.

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

139. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +1 +/
Сообщение от Аноним (19), 10-Дек-20, 18:47 
> Развейте мысль?

Речь о том, что Hyper-Threading как раз и позволяет ядру продолжать выполнять полезную работу если один из потоков застрял на "дорогой" операции. Причем, не только дорогой, но еще и сериализующей, т.к. просто дорогие операции - обычно не проблема по причине OoO-исполнения.

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

142. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от Аноним (-), 10-Дек-20, 19:19 
Не отменяет того факта что сама по себе эта операция - бесполезное чисто техническое зло, не являющееся частью логики софта и не несущее никакой пользы. А при прочих равных чем этого больше, тем оно медленнее работать будет. Можно подумать, в современных ОС и софте без этого не найдется желающих те блоки прогрузить. А если не найдется - отлично, вообще проц и брякнуть в спячку, чтобы аккумулятор не сажал. Если кто не заметил, интел свой гипертрединг в мобилочном добре почему-то оторвал, и вообще ядро обкоцал. ARM все-равно догнать не смог, так что даром никому не вперся даже с доплатам OEMам.
Ответить | Правка | Наверх | Cообщить модератору

143. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от n00by (ok), 11-Дек-20, 07:02 
> Не отменяет того факта что сама по себе эта операция - бесполезное
> чисто техническое зло, не являющееся частью логики софта и не несущее
> никакой пользы.

Это "зло" позволяло выделить 8Мб памяти, когда физически в системе есть аж целых 4Мб, а вторые 4 мега (да, не гига) на дороге не валяются.

Сейчас оно решает задачи изоляции процессов, отображаемых в память файлов, overcommit и т.п. Даже когда кто-то написал realloc(), функция возвращает новый указатель, а старые данные при этом не копируются.


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

155. "В ОС Fuchsia начат приём изменений от представителей сообщес..."  +/
Сообщение от Аноним (155), 12-Дек-20, 01:45 
> Это "зло" позволяло выделить 8Мб памяти, когда физически в системе есть аж
> целых 4Мб, а вторые 4 мега (да, не гига) на дороге не валяются.

Операционка еще обеспечивает абстракцию что переключения не было. У x86 например с его FPU, SIMD и проч состояние развесистое. Корректно сохранить и восстановить занимает прилично времени. У других у кого как, но чем фичастее тем больше состояние обычно. Это ортогонально страничной памяти и жрет время само по себе, на бесполезную тасовку всего этого. Чтобы задачи не знали что процом кто-то попользовался помимо них.

> Сейчас оно решает задачи изоляции процессов, отображаемых в память файлов, overcommit и
> т.п. Даже когда кто-то написал realloc(), функция возвращает новый указатель, а
> старые данные при этом не копируются.

А также всякие любопытные выходки с copy on write (RCU) и проч. Когда форки процессов не жрут память по нескольку раз, реюзая образ процесса в памяти. А когда разъехалось - ок, вон те страницы ему отдельно будут. Впрочем вебмакаки с снапами и флатпаками довольно эффективно это натягивают.

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру