The OpenNET Project / Index page

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



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

"KVM: регрессии производительности и обсуждение поддержки 32-разрядных систем"  +/
Сообщение от opennews (??), 16-Дек-24, 15:25 
В состав ядра Linux 6.13-rc3 принято изменение,  устраняющее регрессию  производительности в гипервизоре KVM,  связанную с медленной обработкой  вызовов CPUID на новых CPU, например, на CPU Intel Emerald Rapids операции c CPUID выполняются в 3-4 раза медленнее, чем на CPU Intel Skylake. Подобная особенность привела к снижению производительности гипервизора KVM, который использует CPUID в процессе сохранения и восстановления состояния процессора при каждой передаче управления виртуальной машине, в случае использования вложенной виртуализации. Для решения проблемы в ветку ядра 6.13 принят сокращённый патч, позволивший до 40% сократить время операции даже CPU семейства SkyLake, благодаря кэшированию CPUID. В ядре 6.14 будет представлена полная версия патча, дополнительно улучшающая производительность...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62415

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

Оглавление

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


1. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (1), 16-Дек-24, 15:25 
Перешел на AMD, проблем не имею. lscpu наконец-то показывает желаемые значения в графе Vulnerabilities.
Ответить | Правка | Наверх | Cообщить модератору

4. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +3 +/
Сообщение от Аноним (4), 16-Дек-24, 15:31 
Этот патч и на AMD влияет, дело не процах, а в KVM.
Ответить | Правка | Наверх | Cообщить модератору

6. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +6 +/
Сообщение от Аноним (-), 16-Дек-24, 15:38 
> Этот патч и на AMD влияет, дело не процах, а в KVM.

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

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

14. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +5 +/
Сообщение от Аноним (14), 16-Дек-24, 16:36 
В анб передает айбишник хитреца, который решил повиртуализировать тут. Самый умный что-ли?
Ответить | Правка | Наверх | Cообщить модератору

31. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (4), 16-Дек-24, 18:21 
Видимо, это из-за разноядерности? CPUID зависит от контекста выполнения в P или E ядрях, не?
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

2. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +3 +/
Сообщение от Аноним (2), 16-Дек-24, 15:26 
Опять этот любитель rust'а Arnd Bergmann.

Все ему неймется.

Если консерватория не позволяет нормально обрабатывать разные варианты, то исправляете что-то в консерватории, а не варианты по живому отрезайте.

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

7. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +6 +/
Сообщение от Аноним (-), 16-Дек-24, 15:42 
> Опять этот любитель rust'а Arnd Bergmann.

Он так то - майнтайнер ARMов в основном, а вовсе не...

> Если консерватория не позволяет нормально обрабатывать разные варианты,
> то исправляете что-то в консерватории, а не варианты по живому отрезайте.

Так изучение показало что бобик давно сдох.
- ARM на KVM был но это никто не юзал и вынос KVM оказался всем просто пофиг. Никто даже в рассылку не пискнул. Слишком хилые железки чтоб VM на них запускать.
- x86 которые не умели 64 бита но умели аппаратную виртуализацию было буквально полтора античные уродца, типа CoreDuo чтоли. И конечно никто не запускает VM всерьез на таком, с 32 бит хостами.
- Все остальное из этого списка вы вероятно даже на картинке не видели. Если вдруг видели - ну, пискните в рассылку что так и сяк, еще живые и юзаете.

Иначе однажды они все же посчитают что таки - все с этим сдохли. А раз так - для кого работается работа? Ублажение /dev/null чисто по приколу?

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

13. "KVM: регрессии производительности и обсуждение поддержки 32-..."  –3 +/
Сообщение от Аноним (13), 16-Дек-24, 16:35 
Core Duo, полагаю, тоже мало кто в живую видел. Оно только на ноутах и было, чем, кстати, и объясняется отсутствие поддержки 64-бит - на ноуты в те времена не ставили столько оперативки, чтобы возникала потребность отказываться от 32-битной ОС.

Широкие массы познакомились с этим уже в виде десктопных Core2.

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

26. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (26), 16-Дек-24, 17:40 
> Core Duo, полагаю, тоже мало кто в живую видел. Оно только на
> ноутах и было, чем, кстати, и объясняется отсутствие поддержки 64-бит -
> на ноуты в те времена не ставили столько оперативки, чтобы возникала
> потребность отказываться от 32-битной ОС.
> Широкие массы познакомились с этим уже в виде десктопных Core2.

Ну так собственно пойнт той возни: множество (умеет HW Virt) && (не умеет 64 бита) - на x86 крайне маргинальное и являет собой буквально полторы малорпспостраненных уродца от интеля, докор2дубной эпохи ажно.

На ARM - при всем моем интересе к ARM я так ни разу KVM там и не заюзал на 32 битах. А кто еще из 32 бит остался в результате? А, ну вот те полтора экзота. Их кто-то видел хотя-бы на картинке? Я лично - нет. Тут у девов и вопрос - а для кого фича таскается? Они - есть?

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

178. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от xintrea (ok), 19-Дек-24, 14:07 
> Core Duo, полагаю, тоже мало кто в живую видел.

Аж чуть не поперхнулся. У меня это моя рабочая машина с 4Gb ОЗУ. Летом, наверно, займусь апгрейдом компа, поменяю на i3-4130, и вкорячу целых 8Gb! Даже не представляю, что буду со всей этой мощью делать.

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

183. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (-), 19-Дек-24, 23:01 
>> Core Duo, полагаю, тоже мало кто в живую видел.
> Аж чуть не поперхнулся. У меня это моя рабочая машина с 4Gb ОЗУ.

У вас до сих пор 32 битная машина для работы?

> Летом, наверно, займусь апгрейдом компа, поменяю на i3-4130, и вкорячу
> целых 8Gb! Даже не представляю, что буду со всей этой мощью делать.

Ну это смотря в чем работа состоит. Если например просто захотеть скомилять сабжевое ядро с другим конфигом - там и EPYC лишним не покажется. Почему-то.

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

184. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 19-Дек-24, 23:05 
> У вас до сих пор 32 битная машина для работы?

вот у меня, например, 32-битная ось, и 8гб памяти на рабочей машине.

> Ну это смотря в чем работа состоит. Если например просто захотеть скомилять
> сабжевое ядро с другим конфигом

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

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

195. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 23-Дек-24, 23:34 
>> У вас до сих пор 32 битная машина для работы?
> вот у меня, например, 32-битная ось, и 8гб памяти на рабочей машине.

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

>> Ну это смотря в чем работа состоит. Если например просто захотеть скомилять
>> сабжевое ядро с другим конфигом
> пересборка ядра занимает примерно шесть минут. не то чтобы мне это было
> постоянно надо, но вот так.

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

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

197. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 24-Дек-24, 02:17 
>>> У вас до сих пор 32 битная машина для работы?
>> вот у меня, например, 32-битная ось, и 8гб памяти на рабочей машине.
> Зашибись комбо когда нельзя даже аллоцировать доступную оперативу некоей программе.

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

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

для чего «остального»? ядра — ты тут удивишься, наверное — всегда на «локалхостах» работают. но, опять же, ты продолжаешь иллюстрировать Современное Ойте: «зачем делать быстро и экономично, если можно медленно и прожорливо?»

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

68. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +2 +/
Сообщение от Аноним (68), 17-Дек-24, 00:15 
64 бита были со времён 4 пней, мой юный друг.
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

107. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от IdeaFix (ok), 17-Дек-24, 11:02 
А в коре соло его не было... и в Xeon LV на той архитектуре тоже.
Ответить | Правка | Наверх | Cообщить модератору

106. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от IdeaFix (ok), 17-Дек-24, 11:01 
Оно было очень массово на серверах, звалось Xeon LV (https://theretroweb.com/chips/3393) и от ноутбучного действительно отличалось мало. Часто вижу такие системы в проде до сих пор в формате двухпроцессорных SBC в составе контроллеров видеостен, некоторого промышленного и реже медицинского оборудования. Возможно совпало/наложилось, но чаще всего это Хитачи. Т.е. был момент, когда оно было победителем в плане поерфоманс на ватт, да и расширялось не плохо. Но на машинах в основном конечно Windows.
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

117. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (-), 17-Дек-24, 11:57 
> Оно было очень массово на серверах, звалось Xeon LV (https://theretroweb.com/chips/3393)
> и от ноутбучного действительно отличалось мало.

Массово - по сравнению с чем? Сколько я себя помню энтерпрайзы очень быстро подсели на 64 бита и хардварную виртуализацию - а все вон то было крайне нишевой ситуацией еще 10 лет назад, а сейчас это как хост VM - ну, хоть 1 остался? Если вдруг - его владельцам и пищать в рассылке что мол они тут еще не померли. Хотя как по мне - могут LTS ядра просто юзать.

> Часто вижу такие системы в проде до сих пор в формате двухпроцессорных SBC
> в составе контроллеров видеостен, некоторого промышленного и реже медицинского оборудования.

Эти ископаемые даже если и юзали Linux то врядли что-то делали с виртуалками.

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

132. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от IdeaFix (ok), 17-Дек-24, 13:29 
Тут вопрос в другом вообще. Формулировка цели, для достижения которой ставится задача "пищать" не верна.

Много где отлично до сих пор на 2.6. Одно дело когда дропали HP-PA - просто разом убрали всю документацию, выкрутили руки всем кто официально контрибутил в чпукс, прямо поудаляли всё и везде и ничего не дали в плане документации после смерти. А тут... в 6.хх ядре сломают Коре дуо?:) Ха-ха... у нас на два шесть всё прекрасно.

А хосты на ESX 3i на х86 без vt таки да, до сих пор встречаются. Недавно такой хост в гиперв мигрировал :)

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

135. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (-), 17-Дек-24, 15:39 
> Тут вопрос в другом вообще. Формулировка цели, для достижения которой ставится задача
> "пищать" не верна.

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

> Много где отлично до сих пор на 2.6.

Они и продолжат на 2.6 фигачить, при чем тут майнлайн? Ядра 2.6 официально не поддерживаются много лет. Что и для кого в этой схеме меняется?

> не дали в плане документации после смерти. А тут... в 6.хх
> ядре сломают Коре дуо?:)

У кого-то еще осталось это барахло - и они там реально виртуалки гоняли? Ну пусть в рассылку пискнут, обрисовав свой сценарий. Это ж RFC пока.

> Ха-ха... у нас на два шесть всё прекрасно.

Так и пользуйтесь им дальше, при чем тут майнлайн? Для каких-то реально странных типов довольно свежие LTS - с этим всем - будут еще до минимум 2030 поддерживаться. А там, глядишь, или шах, или ишак...

> А хосты на ESX 3i на х86 без vt таки да, до
> сих пор встречаются. Недавно такой хост в гиперв мигрировал :)

Вот, прекрасно, делайте вон тем мозги майкрософту, интересно же насколько у них благодати хватит поддерживать кору даже не дуба. Может еще и нахаляву даже? Я совсем не против если майкам такой якорь вобьют :D

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

139. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от IdeaFix (ok), 17-Дек-24, 16:26 
Об том и речь, что ой ты Боже ты мой страшное выпиливание коре дуо из ядра похоронит коре дуо - это бред. Пользовтаели даже и не заметят. Хорошо что Вы это поняли, пусть и не сразу. Плохо что начали переобуваться в прыжке. Когда выпиливали арм, никто не пищал, потому что пищат те, кто сразу не понял, вот и пищат. А у кого рам работал - им и так норм :)
Ответить | Правка | Наверх | Cообщить модератору

159. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (159), 18-Дек-24, 16:08 
>Ну пусть в рассылку пискнут, обрисовав свой сценарий. Это ж RFC пока.

Кукарекнут, вы имели в виду.

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

41. "KVM: регрессии производительности и обсуждение поддержки..."  +4 +/
Сообщение от arisu (ok), 16-Дек-24, 19:16 
> И конечно никто не запускает VM всерьез на таком, с 32 бит хостами.

опять меня не существует, да что ж ты будешь делать-то!

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

50. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (50), 16-Дек-24, 20:47 
Ну так что ж ты на опеннет пишешь? Девелоперам писать надо.
Ответить | Правка | Наверх | Cообщить модератору

60. "KVM: регрессии производительности и обсуждение поддержки..."  +2 +/
Сообщение от arisu (ok), 16-Дек-24, 22:29 
> Ну так что ж ты на опеннет пишешь? Девелоперам писать надо.

а разве это они в паре комментариев выше написали на опеннете, что меня не существует?

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

74. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 17-Дек-24, 00:40 
> а разве это они в паре комментариев выше написали на опеннете, что меня не существует?

Ты им сообщил, что еще не вымер?
Как они должны были догадаться, что такие оригиналы еще существуют?
А вот написал бы, и они бы сразу же решили "не, ну раз arisu пользуется, то не будем дропать еще лет десять!"

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

75. "KVM: регрессии производительности и обсуждение поддержки..."  +1 +/
Сообщение от arisu (ok), 17-Дек-24, 00:52 
ещё раз спрошу: зачем мне это *им* сообщать? это они несколькими комментариями выше написали на опеннете, что меня не существует?
Ответить | Правка | Наверх | Cообщить модератору

82. "KVM: регрессии производительности и обсуждение поддержки..."  +1 +/
Сообщение от Аноним (-), 17-Дек-24, 01:39 
Так про то что таких как ты не существует написали не только местные комментаторы.

А непосредственно те, кто хочет дропнуть:
It probably makes sense to drop all of these at the same time, provided
there are no actual users remaining (not counting regression testing
that developers might be doing).
https://lore.kernel.org/kvm/3589ad69-13df-40f1-88c2-55d39790.../

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

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

83. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 17-Дек-24, 01:45 
> Так про то что таких как ты не существует написали не только
> местные комментаторы.

это, без сомнения, очень интересная информация. однако я обращался именно к местному комментатору. надеюсь, правилами ещё не указано, что для обращения к анонимусу на опеннете мне надо писать в lkml, чтобы они потом переслали сюда?

> или ничего не делать и наслаждать дропом поддержки того, чем ты пользуешься

будь любезен, приведи цитату, где я недоволен этим дропом. потому что я сам отчего-то её найти не смог.

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

86. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 17-Дек-24, 01:51 
> будь любезен, приведи цитату, где я недоволен этим дропом.

будь любезен, приведи цитату, где я написал что ты недоволен этим дропом.
там вроде написано "наслаждаться", а не "недоволен"
> потому что я сам отчего-то её найти не смог.

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

89. "KVM: регрессии производительности и обсуждение поддержки..."  +1 +/
Сообщение от arisu (ok), 17-Дек-24, 02:02 
>> будь любезен, приведи цитату, где я недоволен этим дропом.
> будь любезен, приведи цитату, где я написал что ты недоволен этим дропом.

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

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

108. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (108), 17-Дек-24, 11:04 
> то есть, твоё пожелание мне писать маинтайнерам было высказано просто так, чисто чтобы повысить уровень шума в сигнале?

Разумеется нет! А исключительно чтобы просветить тех темных и невежественных людей из мейнлайна:
"Динозавры существуют! Более того, они ходят среди нас!"

Может они будут в шоке, что такое все еще встречаются.
А может поржут и покрутят пальцем у виска.

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

112. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 17-Дек-24, 11:20 
я совершенно не понимаю, почему твоё желание кого-то просвещать вдруг должен исполнять я.
Ответить | Правка | Наверх | Cообщить модератору

114. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 17-Дек-24, 11:26 
> я совершенно не понимаю, почему твоё желание кого-то просвещать вдруг должен исполнять я.

Потому что мне они не поверят.
Скажут "не, такого быть не может. они все вымерли, вот что ты нам заливаешь!"
А ты пруфу предоставишь, скрины например. Скажешь "я сижу за компом - значит существую".
Все равно у тебя много свободного времени и явно нечего делать.
Иначе ты бы не писал такой длинный тред с безымянным аноном из инета)))

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

144. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 17-Дек-24, 19:58 
> Все равно у тебя много свободного времени и явно нечего делать.

это совершенно не значит, что мне интересно реализовывать твои хотелки, тем более бесплатно.

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

120. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (120), 17-Дек-24, 12:05 
> я совершенно не понимаю, почему твоё желание кого-то просвещать вдруг должен исполнять я.

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

И таки да, если кто будет смеяться что встретил дино на переходе - ну извините :)

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

146. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 17-Дек-24, 20:02 
а давай теперь я расскажу. как я уже писал выше — где я хоть словом возмутился супротив выкидывания чего-то там? я *удивился* тому, что комментатор на опеннете считает меня несуществующим. в ответ на что мне зачем-то сказали идти в lkml. вот я и пытаюсь выяснить, зачем, и почему моё удивление безапелляционностью здешнего комментария надо обязательно в lkml отправлять.
Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

161. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 18-Дек-24, 18:13 
> а давай теперь я расскажу. как я уже писал выше — где
> я хоть словом возмутился супротив выкидывания чего-то там? я *удивился* тому,
> что комментатор на опеннете считает меня несуществующим.

А, ну против такого удивления я не возражаю. Но я все же не понимаю - ты реально юзаешь KVM на 32 бит хостах, не умеющих в 64 бита?

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

172. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 18-Дек-24, 23:48 
> ты реально юзаешь KVM на 32 бит хостах, не умеющих в 64 бита?

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

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

185. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 19-Дек-24, 23:11 
> ну не выкидывать же рабочее железо. я вообще не люблю выкидывать железо,
> которое можно к делу приспособить.

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

> не то чтобы прямо уж юзаю и жить без этого не могу, но иногда и редко — случается.

И там вот реально виртуализация? oO А то я так и не сподвигся KVM потестить на ARM, большая часть одноплатников на 32 бит ARM как-то не вызывают острого желания там виртуалки запускать пачками. Сугубо по ресурсам.

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

187. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 19-Дек-24, 23:32 
> И там вот реально виртуализация?

kvm удобен в том числе для создания хорошо изолированых окружений. но в общем — да. хотя это был скорее эксперимент в бесполезном, чего скрывать. ;-)

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

196. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 23-Дек-24, 23:37 
> kvm удобен в том числе для создания хорошо изолированых окружений. но в
> общем — да. хотя это был скорее эксперимент в бесполезном, чего скрывать. ;-)

Ну как бы у меня он так и юзается. И вот гуесты иногда можно и 32 бита. Хотя 64 лучше по перфомансу крипто всякого и проч, а оперативы они у меня много не жрут - я умею минимальные дебианы фигарить.

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

119. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 17-Дек-24, 12:02 
> ещё раз спрошу: зачем мне это *им* сообщать? это они несколькими комментариями
> выше написали на опеннете, что меня не существует?

Ну так пискни в рассылку - и сообщи что существует. Ну, если это все реально надо. А то народ недоумевает зачем на /dev/null работать надо.

Ибо юзать виртуализацию на 32 бит хосте - это уже лет цать назад было как минимум странным чудачеством. Просто для понимания - я ни разу не сподвигся KVM на ARM попробовать, даже и не удобно было в рассылке высовыватся. Мол, офигенная фича, я правда ни разу не пробовал - но плиз оставьте? :D

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

157. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Роман (??), 18-Дек-24, 08:44 
> Как они должны были догадаться, что такие оригиналы еще существуют?

через телеметрию или хотя бы по проданным лицензиям..oh wait..

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

162. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 18-Дек-24, 18:14 
>> Как они должны были догадаться, что такие оригиналы еще существуют?
> через телеметрию или хотя бы по проданным лицензиям..oh wait..

Да не, спасибо, вы там таким жабогадюкингом в своей виндочке как-нибудь без нас занимайтесь. Как говорится - "хорошо там, где вас нет".

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

164. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 18-Дек-24, 18:27 
>>> Как они должны были догадаться, что такие оригиналы еще существуют?
>> через телеметрию или хотя бы по проданным лицензиям..oh wait..
> Да не, спасибо, вы там таким жабогадюкингом в своей виндочке как-нибудь без нас занимайтесь. Как говорится - "хорошо там, где вас нет".

Правильно!
И чтобы стало хорошо, мы делаем чтобы вас не было)
А то просто неудобно - прогрессивный проект и тут какие-то нищуки-луддиты с коре дуо (даже не с ДВА дуо!).
И ладно если бы они просто сидели на старой версии, бекпортили фиксы, которые им делают товарищи поумнее, и не чирикали.
Но нет! Они начинают вонять на форумах "нам должны! вы обязаны поддерживать наше некрожелезо пока последний некролюб не помрет!" и так далее.

И вот в таких случаях телеметрия супер полезна.
Просто тыкаешь хама мордочкой в статистику - где нет ни одного луддита (ну или 1%) и закрываешь issue как wont fix

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

169. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 18-Дек-24, 20:36 
> Правильно!
> И чтобы стало хорошо, мы делаем чтобы вас не было)

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

> А то просто неудобно - прогрессивный проект и тут какие-то нищуки-луддиты с
> коре дуо (даже не с ДВА дуо!).

Ну вот зачем запускать виртуализатор - на именно 32 бит хосте - при том что за всю историю человечества было полторы модели процов с таким сочетанием фич - я тоже не понимаю. Как видим - телеметрия для этого не требуется.

> И ладно если бы они просто сидели на старой версии, бекпортили фиксы,
> которые им делают товарищи поумнее, и не чирикали.

Да вообще-то так и делают. Вооон там LTSные кернелы пачками есть. Это ж не только им надо но и каким-нибудь индустриальным некромасерам и проч.

> Но нет! Они начинают вонять на форумах "нам должны! вы обязаны поддерживать
> наше некрожелезо пока последний некролюб не помрет!" и так далее.

Как по мне фаны телеметрии не лучше этих. Выпустить тех и других на арену, раздать мечи, и зрителей позвать, во.

> Просто тыкаешь хама мордочкой в статистику - где нет ни одного луддита
> (ну или 1%) и закрываешь issue как wont fix

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

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

171. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 18-Дек-24, 20:52 
> я врядли ваш  софт вообще увижу и тем более юзать буду.

фух, какое облегчение!

> Не пользуюсь крапом с телеметрией и со своей стороны считаю это малварью,

это твои проблемы, что чем считать.
вон некоторые считают, что земля плоская ¯\_(ツ)_/¯

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

де факто это твои больные фантазии, типа как "ИНН - число диявола".
есть закон который определяет какие данные персональные, какие паспортные, а какие нет.
а все что не запрещено - разрешено.


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

186. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 19-Дек-24, 23:17 
> фух, какое облегчение!

Держите нас в курсе.

>> Не пользуюсь крапом с телеметрией и со своей стороны считаю это малварью,
> это твои проблемы, что чем считать.
> вон некоторые считают, что земля плоская ¯\_(ツ)_/¯

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

> де факто это твои больные фантазии, типа как "ИНН - число диявола".
> есть закон который определяет какие данные персональные, какие паспортные, а какие нет.

ЧСХ такие м....ки и нарвались на вещи типа GDPR.

> а все что не запрещено - разрешено.

С другой стороны так и я не обязан юзать вон те какахи - и тем более говорить что-то позитивное о их авторах и таком софте. Какие-то проблемы? :)

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

141. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (50), 17-Дек-24, 18:12 
Они даже хуже местных комментаторов: сразу в коде решили задекларировать твоё несуществование через удаление нужных тебе вещей. Беги пиши, может ещё опомнятся.
Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

118. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 17-Дек-24, 11:59 
>> И конечно никто не запускает VM всерьез на таком, с 32 бит хостами.
> опять меня не существует, да что ж ты будешь делать-то!

Ты где-то отковырял именно семейство процов которое уже умело HW Virt но не умело 64 бита? Их за всю историю человечества - полторы наименования было.

И да, прости но x86-32 таки - по сути все. Это лютейшее легаси в 2024 году. Типа ARMv4 какого-нибудь - только костылей в 20 раз больше.

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

15. "KVM: регрессии производительности и обсуждение поддержки 32-..."  –3 +/
Сообщение от Аноним (15), 16-Дек-24, 16:40 
Отрезайте-отрезайте. Не должно сообщество платить за любителей музейных древностей, которые ещё и планету зря греюсь своим недожелезом.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

16. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +2 +/
Сообщение от Аноним (14), 16-Дек-24, 16:47 
Это ты планету зря греешь.
Ответить | Правка | Наверх | Cообщить модератору

19. "KVM: регрессии производительности и обсуждение поддержки 32-..."  –1 +/
Сообщение от Аноним (19), 16-Дек-24, 16:56 
Платящее сообщество - это оксюморон в чистом виде.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

22. "KVM: регрессии производительности и обсуждение поддержки 32-..."  –1 +/
Сообщение от Аноним (22), 16-Дек-24, 17:16 
В странах не третьего мира вполне могут платить.
Ответить | Правка | Наверх | Cообщить модератору

67. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (67), 17-Дек-24, 00:12 
Это в тренде зеленой повестки:
Наибольшего расцвета движение фриганов достигло в Швеции, США, Бразилии, Южной Корее, Великобритании.... В России нет сколько-нибудь заметной тенденции к фриганизму... (с) педевикия
Хоть граждане с коройдуба как-то ориентируют нас на передовые страны!
Ответить | Правка | Наверх | Cообщить модератору

98. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от 12yoexpert (ok), 17-Дек-24, 06:19 
скажи это создательнице octoprint, которая начала по фану и даже не на своём основном языке, а теперь живёт чисто на донатах
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

113. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (-), 17-Дек-24, 11:20 
> а теперь живёт чисто на донатах

Забавно что ты вспомнил именно ее.
Так вот - жила. Ну... или пока еще живет.

While OctoPrint’s usage numbers have steadily grown by 30% since 2021 to an all time high of now over 150000 active instances (and that’s just the ones I know about), financial support for my work on OctoPrint has dropped by over 30% over that same time, with most of this decline happening over the course of the past 12 months.

Денег стало меньше. Потому что донаты дело добровольное.

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

115. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от 12yoexpert (ok), 17-Дек-24, 11:33 
ну ладно, пойду задоначу. недавно же просто где-то в rss слышал её же слова (в видео-интервью) о том, что денег вроде как хватает и для неё было неожиданностью, что так много донатят
Ответить | Правка | Наверх | Cообщить модератору

40. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +2 +/
Сообщение от Аноним (-), 16-Дек-24, 19:04 
> любитель rust'а Arnd Bergmann.

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

> а не варианты по живому отрезайте.

Какому живому?
Этот хлам устарел еще во времена core 2 duo.

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

58. "KVM: регрессии производительности и обсуждение поддержки 32-..."  –1 +/
Сообщение от Аноним (58), 16-Дек-24, 21:24 
Кто продвигает везде Rust - тот ....
Ответить | Правка | Наверх | Cообщить модератору

158. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (2), 18-Дек-24, 14:50 
> Сразу видно что человек не заскостенелый, некролюбсвтом и луддизмом заниматься не хочет.

Хорошо что в ядре есть сторонники прогресса.

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

И то что выпиливают старое - ладно. Но вот то что не правят консерваторию - очень плохо.

Ибо как только rust обоснуется в ядре станет фактором приводящем к огромному количеству работу при добавлении каких-либо вариантов архитектурной функциональности.

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

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

99. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от 12yoexpert (ok), 17-Дек-24, 06:26 
зато ему потом меньше переписывать на раст
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +1 +/
Сообщение от Аноним (4), 16-Дек-24, 15:30 
> В ядре 6.14 будет представлена полная версия патча, дополнительно улучшающая производительность.

Я так понял, там еще будет третий патч, связанный с кэшированием всего CPUID. В данном только XSAVE закэшировали.

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

5. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +9 +/
Сообщение от Аноним (5), 16-Дек-24, 15:37 
> на CPU Intel Emerald Rapids операции c CPUID выполняются в 3-4 раза медленнее, чем на CPU Intel Skylake

Интел. 2024 год. Итоги.

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

8. "KVM: регрессии производительности и обсуждение поддержки 32-..."  –1 +/
Сообщение от Аноним (8), 16-Дек-24, 15:52 
Интересно, учитывают ли они это во всех этих CPU benchmark-ах где пишут число попугаев?
Ответить | Правка | Наверх | Cообщить модератору

9. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +1 +/
Сообщение от Аноним (9), 16-Дек-24, 16:03 
CPUID не такая уж часто выполняемая команда.
Ответить | Правка | Наверх | Cообщить модератору

10. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (-), 16-Дек-24, 16:20 
> CPUID не такая уж часто выполняемая команда.

Как оказалось - в ряде случаев достаточно часто выполняемая для того чтобы пришлось костылить.

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

30. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +2 +/
Сообщение от Аноним (4), 16-Дек-24, 18:19 
Кэширование CPUID, которое никогда не меняется - костылить? Однако...
Ответить | Правка | Наверх | Cообщить модератору

121. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +1 +/
Сообщение от Аноним (-), 17-Дек-24, 12:08 
> Кэширование CPUID, которое никогда не меняется - костылить? Однако...

Вообще-то иногда может и меняться. Например - при апдейте микрокода.

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

109. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от IdeaFix (ok), 17-Дек-24, 11:04 
просто к слову, 3дмарк 2005 на lga1700 не находит sse :)
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

23. "KVM: регрессии производительности и обсуждение поддержки 32-..."  –3 +/
Сообщение от Аноним (23), 16-Дек-24, 17:25 
Тут простая логика: если человек пользует старинное железо - значит он по характеру консерватор (нищих пока не рассматриваем). Если он консерватор - то наверняка пользует ядро 3, 4, ну максимум 5 версии.
Вывод - выкидывать можно. Если хозяин нищий - то есть workaround в виде старых ядер, многие из которых даже на LTS поддержке.
Ответить | Правка | Наверх | Cообщить модератору

24. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +2 +/
Сообщение от Аноним (24), 16-Дек-24, 17:33 
Нужна ли мне на 3 пеньтиуме KVM?
Ответить | Правка | Наверх | Cообщить модератору

32. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +1 +/
Сообщение от Аноним (14), 16-Дек-24, 18:25 
Да
Ответить | Правка | Наверх | Cообщить модератору

38. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +1 +/
Сообщение от Аноним (24), 16-Дек-24, 18:50 
ну ладо, тогда хорошо, что не удалили
Ответить | Правка | Наверх | Cообщить модератору

25. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (23), 16-Дек-24, 17:36 
А остались ли в свежих ядрах драйвера устройств, которые были типичны на компах с этими корами дуба (не дуо)? Сдается мне оно и так уже не пригодно для античного железа
Ответить | Правка | Наверх | Cообщить модератору

27. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (-), 16-Дек-24, 17:44 
> А остались ли в свежих ядрах драйвера устройств, которые были типичны на
> компах с этими корами дуба (не дуо)? Сдается мне оно и
> так уже не пригодно для античного железа

Да вроде остались пока. Ну не, EISA вроде таки - выпилили. А так ядро 6.10 вполне себе взлетело на каком-то атлон XP чтоли или как там его, даже без SSE2 который еще. Но это на правах научного курьеза.

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

28. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +2 +/
Сообщение от Аноним (24), 16-Дек-24, 17:54 
у меня 12 дебиан работает с Ati AGP видимокарточкой - даже ускорение есть и в 3d стрелялку-убивалку из реп можно поиграть
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

101. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от 12yoexpert (ok), 17-Дек-24, 06:31 
в свежем ядре gameport - вполне себе середнячок по древности
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

29. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от КО (?), 16-Дек-24, 18:10 
никогда и не были популярны. В числе процессоров, которые затрагивает патч: Intel Core Duo
Мне тоже отсыпьте там
Ответить | Правка | Наверх | Cообщить модератору

33. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +6 +/
Сообщение от Аноним (14), 16-Дек-24, 18:28 
Intel Core Duo != Intel Core 2 Duo
Ответить | Правка | Наверх | Cообщить модератору

56. "KVM: регрессии производительности и обсуждение поддержки 32-..."  –1 +/
Сообщение от Аноним (58), 16-Дек-24, 21:20 
Более того, Intel Core 2 Duo != Intel Core 2 Duo, как Intel Pentium 4 != Intel Pentium 4.
Ответить | Правка | Наверх | Cообщить модератору

57. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (58), 16-Дек-24, 21:23 
В смысле тут на опеннете есть тролли, которые берут самые последние ревизии - и используют их как аргумент в пользу дропа ("смотри, даже на пне завелось бы"!), намеренно игнорируя факты, что на предыдущих ревизиях все эти ништяки недоступны, а те, кто купили последние ревизии - просто лохи, купившие заведомо устаревшую железку, которая однако свежая и дорогая, когда могли купить сразу же Core i7.
Ответить | Правка | Наверх | Cообщить модератору

153. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Alladin (?), 17-Дек-24, 21:58 
ох, кору дуба 2 не тронули значит
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

35. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +1 +/
Сообщение от cheburnator9000 (ok), 16-Дек-24, 18:40 
Ну эксперты опеннета объясните мне почему CPUID нужно постоянно вызывать заново из раза в раз, вместо кеширования его один раз на старте VM? Потому что пользователь на лету меняет физический CPU в сервере???
Ответить | Правка | Наверх | Cообщить модератору

39. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (50), 16-Дек-24, 18:56 
Смотря какой пользователь. Один из основных контрибьюторов в успех Линукса как серверной платформы таки меняет в своих мейнфреймах CPU на лету штатным образом. Это одна из базовых фич, которые продают их продукты — замена компонентов на лету, без остановки всей машины. Другое дело, что случается это не каждый день, но согласись, такой примитивный запрос как CPUID не должен тормозить, это просто смешно.
Ответить | Правка | Наверх | Cообщить модератору

42. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 16-Дек-24, 19:24 
> но согласись, такой примитивный запрос как CPUID
> не должен тормозить, это просто смешно.

так и простая команда `xchg eax, edx` тормозить не должна, например. это ведь просто указание ремаперу регистров, правда? а вот нет, неправда. тормозит. более чем в два раза медленней, чем `mov ebx, eax / mov eax, edx / mov edx, ebx`. и вот так у интеля всё, за что ни ухватись. и вот так у нынешних процессоров всё, за что ни ухватись. почему `movups` по выравненым адресам всё ещё в полтора-три раза медленней, чем `movaps`? (потом Зоркие Глаза заметили, починили.) почему попытки избежать domain stall в SSE иногда (и непредсказуемо заранее где) всё замедляют в разы? почему, почему, почему…

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

48. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (50), 16-Дек-24, 20:09 
> почему, почему, почему…

Ну почему это как раз очень просто понять. Современный CPU штука весьма сложная, а делают их люди. Люди неизбежно будут ошибаться, и жаловаться на это так же бессмысленно как сетовать на дождь. Тем более что сложность CPU как раз того самого рода которая хуже всего поддаётся людям: сложность из-за количества. Нашего «7±2» явно недостаточно для того, чтобы осознать все взаимодействия внутри даже довольно простых схем, а тут миллионы транзисторов на околоквантовых расстояниях.

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

61. "KVM: регрессии производительности и обсуждение поддержки..."  +2 +/
Сообщение от arisu (ok), 16-Дек-24, 22:32 
если твои слова упростить, то получится очень интересный тезис: никто не понимает, как работают современные CPU. и я таки с ним согласен. неимоверно радует тот факт, что хумансы без проблем, например, доверяют свои жизни устройствам с непонятным принципом функционирования. один из основных отличительных признаков квазиразумных существ, кстати.
Ответить | Правка | Наверх | Cообщить модератору

64. "KVM: регрессии производительности и обсуждение поддержки..."  +1 +/
Сообщение от Аноним (-), 16-Дек-24, 23:53 
>  неимоверно радует тот факт, что хумансы без проблем, например, доверяют свои жизни устройствам с непонятным принципом функционирования

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

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

И это нормально - тк все знать не возможно, а специализация это основа нашей цивилизации.

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

76. "KVM: регрессии производительности и обсуждение поддержки..."  +1 +/
Сообщение от arisu (ok), 17-Дек-24, 00:55 
> Люди существа практичные

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

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

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

91. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (91), 17-Дек-24, 02:27 
Никакой он не дурак, товарищ Арису.

"Понимать" это, как ни странно, относительное явление. Можно "понимать" до какой-то степени, а до какой-то не понимать, и при этом вполне решать прикладные задачи.

Принципы перехода жидкости в пар и прочая молекулярно-кинетическая теория не особенно нужны производителям чайников со свистком.

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

92. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 17-Дек-24, 02:33 
> Никакой он не дурак, товарищ Арису.

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

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

116. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Ананимус (?), 17-Дек-24, 11:45 
> хумансы — существа неимоверно тупые прежде всего. я только не понимаю, зачем ты доказываешь этот очевидный факт своим комментарием.

У нас тут школьник-нигилист, лол.

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

122. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 17-Дек-24, 12:10 
>> хумансы — существа неимоверно тупые прежде всего. я только не понимаю, зачем ты доказываешь
>> этот очевидный факт своим комментарием.
> У нас тут школьник-нигилист, лол.

Он таки всего лишь капитан очевидность, как бы узнавшим себя в описании ни было обидно... :)

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

130. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Ананимус (?), 17-Дек-24, 13:26 
>>> хумансы — существа неимоверно тупые прежде всего. я только не понимаю, зачем ты доказываешь
>>> этот очевидный факт своим комментарием.
>> У нас тут школьник-нигилист, лол.
> Он таки всего лишь капитан очевидность, как бы узнавшим себя в описании
> ни было обидно... :)

Да нет, он обычный школьный edgelord -- все тупые, РЯЯЯЯ. То что мы, как вид, развиваемся с невиданной на планете скоростью и за несколько десятков тысяч лет прошли путь от швыряния друг в друга палкой до редактирования генома конечно же мелочи, главное что люди используют 64 бита для редактирования текста, когда хватило бы 32 :))))

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

133. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 17-Дек-24, 13:30 
> То что мы, как вид, развиваемся с невиданной на планете скоростью

Полностью согласен.

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

Полностью не согласен.
Палкой и какахами кидаемся до сих пор. Но технологии позволяют это делать даже через интернет!

> до редактирования генома конечно же мелочи,

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


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

136. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 17-Дек-24, 15:52 
> Да нет, он обычный школьный edgelord -- все тупые, РЯЯЯЯ.

Ну, вообще, между нами, этот дефолт - отлично работает! Вероятность угадать 95% примерно. Так что он угадывает в 95% случаев, и лажается в 5%. А это - на минуточку - почти провидец. Чисто технически. И вот на что в такой схеме жаловаться, а?

> То что мы, как вид, развиваемся с невиданной на планете скоростью и за
> несколько десятков тысяч лет прошли путь от швыряния друг в друга
> палкой до редактирования генома конечно же мелочи, главное что люди используют
> 64 бита для редактирования текста, когда хватило бы 32 :))))

Вообще - файлухи и файлы давно уже вымахали за пределы 2^32, так что сказать что их хватает - это несколько покривить душой.

Конечно при остром желании uint64_t можно наверное даже на AVR с его 8 бит регистрами посчитать, но вот эффективность этого кода будет в районе плинтуса.

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

138. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Ананимус (?), 17-Дек-24, 16:01 
> Ну, вообще, между нами, этот дефолт - отлично работает! Вероятность угадать 95% примерно. Так что он угадывает в 95% случаев, и лажается в 5%. А это - на минуточку - почти провидец. Чисто технически. И вот на что в такой схеме жаловаться, а?

Я понимаю что мы все травмированы луркмором в детстве, но сколько можно-то.

> Вообще - файлухи и файлы давно уже вымахали за пределы 2^32, так что сказать что их хватает - это несколько покривить душой.

Ну как верно заметили, если тебе нужно читать файл кусками, то все ок. Проблема в том, что довольно часто это не вариант.

> Конечно при остром желании uint64_t можно наверное даже на AVR с его 8 бит регистрами посчитать, но вот эффективность этого кода будет в районе плинтуса.

u128 на 64 битах вполне себе повседневность :)))))

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

143. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 17-Дек-24, 19:37 
> Я понимаю что мы все травмированы луркмором в детстве, но сколько можно-то.

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

> Ну как верно заметили, если тебе нужно читать файл кусками, то все ок.

Что значит - "все ок"? Описание размещения файла будет запросто ворочать числами превышающими 2^32. И указание где файло, и его размер, etc. Не вижу чего офигенного ворочать математику этажеркой в таких вещах, если можно вместо этого - регистр-регистр за 1 такт.

> Проблема в том, что довольно часто это не вариант.

Даже если это вариант - это не делает математику этажеркой чем-то хорошим и эффективным.

> u128 на 64 битах вполне себе повседневность :)))))

Да я и например 1024-битными числами могу при случае ворочать по каким-то своим причинам. А уж 256-битными так оптом просто и везде. Но это все же довольно нишевой случай.

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

149. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 17-Дек-24, 20:13 
> Что значит - "все ок"? Описание размещения файла будет запросто ворочать числами
> превышающими 2^32. И указание где файло, и его размер, etc. Не
> вижу чего офигенного ворочать математику этажеркой в таких вещах, если можно
> вместо этого - регистр-регистр за 1 такт.

прости, а ты точно фс писал? а то я не очень понимаю, чего сложного в сдвигах, которые со времён… вот не помню, iAPX386 или iAPX486 делаются одной командой для 64 битов. или в сравнении. а для маньяков — ты не поверишь, но в SSE есть целочисленные операции над квадвордами. впрочем, это всё неважно, у нас тут тредик про моду, а не про технологии.

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

163. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 18-Дек-24, 18:25 
> прости, а ты точно фс писал? а то я не очень понимаю,
> чего сложного в сдвигах, которые со времён… вот не помню,
> iAPX386 или iAPX486 делаются одной командой для 64 битов. или в сравнении.

Как ты кодировать даже просто поле "размер файла" намерен без 64-битных чисел? И все операции с этим соответственно, by design - 64 битные. И не очень понимаю - чего и куда можно "сдвинуть" в поле размера файла?

> а для маньяков — ты не поверишь, но в SSE есть целочисленные операции над квадвордами.

1) Я искренне сомневаюсь что это ОК в кернеле делать.
2) То что компилер сам так допрет - не факт.
3) А на 64 битах вся математика нативно 64 бита по размеру регистров и регистров - больше.

И это я еще постеснялся уточнить что все современные алго на 64 бита оптимизированы. Ибо жевать в 2 раза битиков за такт - хорошо и правильно.

> впрочем, это всё неважно, у нас тут тредик про моду, а не про технологии.

Да как бы тебе сказать? Развлекаться с SIMD и какими там еще сдвигами, когда можно просто накодить что задумал - сам понимаешь. Не, код не должен быть брейнфаком полным хаков. Его потом поддерживать почти невозможно станет. Особенно в большом проекте.

И лично я вполне солидарен с Торвальдсом по части "I'm not sentimental". Я бы сказал что весб x86-32 это с точки зрения процессоростроения - совсем не то о чем я буду скучать. Могу я немного эстетом побыть и назвать г-но г-ном? x86-32 это именно оно. Его единственное достоинство - дешевое и массовое.

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

173. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 19-Дек-24, 00:02 
> Как ты кодировать даже просто поле "размер файла" намерен без 64-битных чисел?

а, то есть, в x86 нельзя 64-битные целые использовать, для этого обязательно x86_64 надо. яснопонятно. современная ойти во всей красе.

>> а для маньяков — ты не поверишь, но в SSE есть целочисленные операции над квадвордами.
> 1) Я искренне сомневаюсь что это ОК в кернеле делать.

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

впрочем, тут у нас ходят разговоры, что поддержку x86 вообще надо бы выкинуть. откуда неизбежно получается ориентация на интел-камни, у которых есть как минимум SSE2 — который уже имеет почти всё нужное.

> 3) А на 64 битах вся математика нативно 64 бита по размеру
> регистров и регистров - больше.

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

> И это я еще постеснялся уточнить что все современные алго на 64
> бита оптимизированы. Ибо жевать в 2 раза битиков за такт -
> хорошо и правильно.

и тут же:

> Да как бы тебе сказать? Развлекаться с SIMD и какими там еще
> сдвигами, когда можно просто накодить что задумал - сам понимаешь.

ты принципиально не видишь тут противоречия?

кстати, мой компилятор спокойно справляется с генерацией SSE2 кода для 64-битных целых. чего сложного-то? PoC был на интринсиках, потом я добавил SSE-кодоген. ни строчки написаного кода программ при этом не поменялось.

> код не должен быть брейнфаком полным хаков.

ну и не пиши такой, зачем такой писать?

> немного эстетом побыть и назвать г-но г-ном? x86-32 это именно оно.

потому что весь x86 такой. а это была попытка хоть какого-то deshittification. закономерно не удалась: пипл любит жрать коричневое и вонючее, лишь бы его рекламировали и все жрали.

p.s.: а теперь про сдвиги. я же не зря спросил, действительно ли ты FS писал. потому что вся математика с 64 битами в FS — конвертация байтовых смещений в блочные и обратно. а размер блоков всегда power of two. всё ещё не понимаешь, при чём тут сдвиги?

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

188. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 20-Дек-24, 22:53 
> а, то есть, в x86 нельзя 64-битные целые использовать, для этого обязательно
> x86_64 надо. яснопонятно.

Надо же, 64-бит процы лучше работают с 64-бит числами. Какая неожиданность.

> современная ойти во всей красе.

А еще я забил на AVR - и юзаю STM32. Экий я злыдень, не хочу лезть на второй этаж используя намыленый столб, в акваланге, когда можно - по лестние подняться.

> возможно, ты удивишься, когда узнаешь, что ядро местами *уже* проверяет фичи CPU,
> и использует оптимизированые функции, если возможно.

Это - хаки! Усложняет майнтенанс. Их с удовольствием выпилят! Потому что сложный, проблемный код с рядом проблемных или нежелательных взаимодействий. Скажем такая активность не айс с точки зрения W^X. И просто майнтенанса. Не, спорт с залезанием на намыленный столб в акваланге из принципа - вон там самоцелью не является. Даже если кто и хотел сказать "во как я могу!" это так, из области курьезов.

> выкинуть. откуда неизбежно получается ориентация на интел-камни, у которых есть как
> минимум SSE2 — который уже имеет почти всё нужное.

Не очень понимаю ремарку про SSE2 и Intel, ибо гарантированный SSE2 это визитная карточка x86-64 как раз. И это дело начали, внезапно, АМД.

Впрочем возможно я не следил за жабогадюкингом - ибо я с 64 битами уже наверное скоро как 20 лет. Нехилый интервал так то.

> а также код больше,

Зависит от. Из за куцего регистрового файла оно занимается пушпопами от души. И на x86-32 например position independent code - ну, его нет. Зато нате вам супер-порно с релоками. Костыль на костыле и костылем погоняет.

> и указатели больше,

Зато может адресовать мне ВСЮ RAM - не утыкаясь в тупые проблемы "циферок не хватило". И какими нибудь абстракциями типа mmaped файлов можно нормально пользоваться.

> и есть некоторые забавные проблемы с адресацией.
> что, конечно, не является какой-то непреодолимой сложностью — но
> зачем оно надо, если оно не надо?

Вот лично мне не надо - уродца с полутора регистрами, пачками релоков, кодом наполовину состоящим из пушпопов, и прочими прелестями. Это то про что я тоже скажу "I'm not nostalgic". Да, x86-64 не предел мечтаний. Но лучше той какахи, нечто более похожее на нормальный регистровый файл, нет дефицита циферок, умеет position-independent код (PC-relative addressing) и проч. И в 2 раза больше битов за такт жует. Шаг в правильную сторону, жаль что полловинчатый.

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

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

А, да, кстати о птичках. Менее идиотское ABI еще в актив запишите, во! Насколько я помню, когда небольшой число параметров у функции можно - их прям в регистрах передавать. Как и у остальных процов с нормальным регистровым файлом, типа ARM и проч.

> кстати, мой компилятор спокойно справляется с генерацией SSE2 кода для 64-битных целых.

Я рад за твой компилер и вообще. Только вот SSE2 гарантирован - только в 64 бит прцах. А если мы про обрубки - то там уповать на SSE2 не комильфо.

И кроме того - в случае вот именно кернела еще размер контекста не пустой звук. Оно ж абстракцию монопольного использования проца обеспечивает.

> чего сложного-то? PoC был на интринсиках, потом я добавил SSE-кодоген. ни
> строчки написаного кода программ при этом не поменялось.

Сложно станет - когда захочется
1) Чтобы кернел работал на РАЗНЫХ процах. Если выдвигать требование SSE2, то имхо и 32 бита нахрен, ибо с гарантиями это только в 64-битниках и есть.
2) Свичить задачи и делать вид что задача тут одна. Ну то есть все решаемо конечно. Но сложнее, тормознее, хреновее и кривее - с более страшным кодом - очень даже может и получиться.

В ядре линя и так дофига хаков для всяких окаменелых каках. И до сих пор кто-то делает мозг какими-то я извиняюсь линиями A20. Уж и той шины давно нет, а ритуалы остались.

>> код не должен быть брейнфаком полным хаков.
> ну и не пиши такой, зачем такой писать?

Затем что всякий рантайм патчинг в ядре - делает это сложнее и кривее. И чем такого меньше тем всем проще жизня.

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

Ну как бы x86-64 все же несколько более похожий на нормальные процы чем x86-32 как по мне.

> p.s.: а теперь про сдвиги. я же не зря спросил, действительно ли
> ты FS писал. потому что вся математика с 64 битами в
> FS — конвертация байтовых смещений в блочные и обратно. а размер
> блоков всегда power of two. всё ещё не понимаешь, при чём тут сдвиги?

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

Сие несколько подбешивает на мк кстати. Но что вот тут сделаешь?

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

190. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 20-Дек-24, 23:22 
>> а, то есть, в x86 нельзя 64-битные целые использовать, для этого обязательно
>> x86_64 надо. яснопонятно.
> Надо же, 64-бит процы лучше работают с 64-бит числами. Какая неожиданность.

надо же: сначала ты заявил, что в 32-бит режиме невозможно сделать 64-бит числа, а теперь сдал назад. какая неожиданность.

>> возможно, ты удивишься, когда узнаешь, что ядро местами *уже* проверяет фичи CPU,
>> и использует оптимизированые функции, если возможно.
> Это - хаки!

ну кто ж вам виноват, что ваше ядро — один сплошной хак?

>> выкинуть. откуда неизбежно получается ориентация на интел-камни, у которых есть как
>> минимум SSE2 — который уже имеет почти всё нужное.
> Не очень понимаю ремарку про SSE2 и Intel

а всё просто: внезапно — нет никакой причины бежать за толпой на 64 бита, потому что операции над 64-битными целыми отлично доступны в 32-бит режиме, с восемью отдельными регистрами для этого. деления, правда, нет, а для умножения придётся немного заинлайнить. ок.

>> а также код больше,
> Зависит от. Из за куцего регистрового файла оно занимается пушпопами от души.

нет, не занимается. давай ты опять не будешь со мной спорить по поводу компиляторов, ок?

> И на x86-32 например position independent code - ну, его нет.

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

> Зато нате вам супер-порно с релоками. Костыль на костыле и костылем
> погоняет.

ты очень удивишься, когда узнаешь, что в x86_64 релоки никуда не делись. и ничего в них страшного нет. впрочем, если тебя это так волнует — пересобери нужные тебе библиотеки так, чтобы они не перекрывались. или — ой — используй PIC. а, прости, я забыл: у тебя же его на x86 нет.

>> и указатели больше,
> Зато может адресовать мне ВСЮ RAM

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

> Вот лично мне не надо - уродца с полутора регистрами

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

> Нет, я не вижу. Когда прямое выполнение на основном регистровом файле -
> с умеренным размером контекста - это одно. Когда какие-то "расширения" и
> нужда сэйвить контекст эвон какого размера - это как бы несколько
> грабли.

когда-нибудь ты узнаешь размер контекста в своём любимом x86_64. это будет шокирующая новость. я хинтану: он *больше*, чем в 32-бит режиме.

> А, да, кстати о птичках. Менее идиотское ABI еще в актив запишите

опять ты гордо несёшь ерунду.

>> кстати, мой компилятор спокойно справляется с генерацией SSE2 кода для 64-битных целых.
> Я рад за твой компилер и вообще. Только вот SSE2 гарантирован -
> только в 64 бит прцах.

pentium-m? pentium-4? не, не слышали, не было.

> А если мы про обрубки - то там уповать на SSE2 не комильфо.

потому что тебе это не нравится, ломает красивую картинку мира?

> И кроме того - в случае вот именно кернела еще размер контекста
> не пустой звук. Оно ж абстракцию монопольного использования проца обеспечивает.

см.выше. рыдай.

> Сложно станет - когда захочется
> 1) Чтобы кернел работал на РАЗНЫХ процах.

автоматический рантайм патчинг? не, не слышали? ну, я не виноват, что ваш гцц в такие штуки умеет очень плохо. у меня — оверхед на первый вызов, дальше full speed.

> 2) Свичить задачи и делать вид что задача тут одна. Ну то
> есть все решаемо конечно. Но сложнее, тормознее, хреновее и кривее -
> с более страшным кодом - очень даже может и получиться.

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

> В ядре линя и так дофига хаков для всяких окаменелых каках.

ну кто ж вам виноват, что вашу свалку кода на лету пересобрать под конкретный камень — задача нереальная?

> Затем что всякий рантайм патчинг в ядре - делает это сложнее и
> кривее.

ты только что объявил все переменные злом. а, ну да: у вас же там всё сложно, концепция «code as data» давно утеряна.

> Ну как бы x86-64 все же несколько более похожий на нормальные процы
> чем x86-32 как по мне.

если закрыть глаза и отвернуться разве что.

> Но в конечном итоге ояд вещей до сектора не округляется.

например?

> тут еще всякие алгоритмы хеширования и проч может захотеться. И ессно
> они лучше - на 64 битах.

давеча SHA512 сделал, понадобилось. никаких проблем. вышло в два раза быстрее, чем у `gcc -O3 -march=native -mtune=native`. без ручных оптимизаций, код один и тот же. ну, плохо ваш гцц с 64 битами в 32-бит режиме работает. это личные проблемы гцц и тех, кто использует этот хлам.

> Крипто все тоже на 64 бита давно оптимизировано.

вот как раз и смотри про SHA512 выше, лол.

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

155. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Ананимус (?), 18-Дек-24, 01:18 
> Так что я понимаю что кому-то досадно было себя в описании узнать - ну а кто мешал учиться, развивать мозг, и вообще?

Лурк и мешал. Выросли и рассказывают байки про 95%.

> Что значит - "все ок"? Описание размещения файла будет запросто ворочать числами превышающими 2^32. И указание где файло, и его размер, etc. Не вижу чего офигенного ворочать математику этажеркой в таких вещах, если можно вместо этого - регистр-регистр за 1 такт.

Ну хотят люди страдать с 32 битами. Значит будут страдать.

> Даже если это вариант - это не делает математику этажеркой чем-то хорошим и эффективным.

Но не делает особо неэффективной. В вызове llseek64 неродная для процессора математика -- капля в море.

> Да я и например 1024-битными числами могу при случае ворочать по каким-то своим причинам. А уж 256-битными так оптом просто и везде. Но это все же довольно нишевой случай.

Да, но чиселки в сисколе это экономия на спичках. Тормозит лялекс вовсе не там.

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

165. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 18-Дек-24, 18:34 
> Лурк и мешал. Выросли и рассказывают байки про 95%.

Я интернет начал использовать задолго до этого. И о тех соотношениях догадался тоже. Лучше прогони IQ тесты и посмотри что они тебе скажут и как тебе такое. Мне кажется arisu тебя обставит в способности к абстрактному мышлению как с куста.

> Ну хотят люди страдать с 32 битами. Значит будут страдать.

Просто размеры файлов и проч - давно уже в 32 бита не лезут.

> Но не делает особо неэффективной. В вызове llseek64 неродная для процессора математика
> -- капля в море.

1) Кроме этого вызова есть более 9000 иных мест типа работы с метаданными.
2) Современные алго тоже так то на 64 бита оптимизируют.
3) Нынче в моде сверхскоростное IO с ломовыми IOPS и кроме всего прочего - жор CPU всяким оверхедом стал весьма злободневным топиком.

> Да, но чиселки в сисколе это экономия на спичках. Тормозит лялекс вовсе
> не там.

Я не про сисколы а в целом факт что ФС может хотетть работать с чем-то более 2^32 достаточно часто и много.

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

147. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 17-Дек-24, 20:06 
> Ну, вообще, между нами, этот дефолт - отлично работает! Вероятность угадать 95%
> примерно. Так что он угадывает в 95% случаев, и лажается в
> 5%. А это - на минуточку - почти провидец. Чисто технически.
> И вот на что в такой схеме жаловаться, а?

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

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

170. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 18-Дек-24, 20:41 
> я так и знал, что надо было патентовать метод. а теперь и
> в суд не подать за опубликование…

Да блин, обломалось бы оно из-за prior art'а. Такой стиль поведения двуногих (сформировать ожидания и потом уповать что всегда будет так, угадывая 90% времени и пролетая остальные 10%) - такое весьма дефолтовое свойство "тренированых нейросеток".

А разум в этом контексте состоит в том чтобы более трезво и критично оценивать возможность расклада "пролетает остальные 10%" и минимизировать вероятность такого события :)

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

174. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 19-Дек-24, 00:18 
на самом деле можно хотя бы начать с оценки того, действительно ли надо бежать, если «все побежали». и если надо — то точно в ту сторону, куда все?

я в своё время тоже считал все новые блестящие штуковины очень крутыми, а тех, кто их не применяет сразу же — дедами-луддитами. только по мере набора опыта понял, почему обычно стоит ограничиваться достаточным для удобного выполнения задачи инструментом, а не самым новым и распиареным.

теперь вот изредка вступаю в дискуссии тут, но в целом — сижу и наблюдаю, как предсказания дедов-луддитов сбываются (не только в ойте), а летние дети бегают и причитают: «но как же так получилось? ничего же не предвещало!» некоторую горечь наблюдениям придаёт то, что я сам был таким же летним ребёнком, и — увы — не знаю метода, позволяющего научить других эту фазу скипать.

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

176. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 19-Дек-24, 00:33 
> на самом деле можно хотя бы начать с оценки того, действительно ли надо бежать, если «все побежали». и если надо — то точно в ту сторону, куда все?

Конечно.
И не думаю что такое решение обсуждается с бухты-барахты.
Собственно слова в заголовке новости "обсуждение поддержки 32-разрядных систем" говорит о том, что еще никто никуда не побежал, а обсуждают чего делать.

> я в своё время тоже считал все новые блестящие штуковины очень крутыми, а тех, кто их не применяет сразу же — дедами-луддитами.

Логично.

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

Или сам стал тем самым бурчащим дедом, который не хочет чему-то новому учиться и ему достаточно привычных вещей)
Можно конечно рассуждать что ʼи этот инструмент достаточный, даже не буду пробовать другиеʼ.
Но я обычно видел удивление "ого, так вот как сейчас можно делать"

> теперь вот изредка вступаю в дискуссии тут, но в целом — сижу и наблюдаю, как предсказания дедов-луддитов сбываются (не только в ойте),

хм... и какие предсказания сбылись?

> а летние дети бегают и причитают: «но как же так получилось? ничего же не предвещало!» некоторую горечь наблюдениям придаёт то, что я сам был таким же летним ребёнком, и — увы — не знаю метода, позволяющего научить других эту фазу скипать.

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


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

177. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 19-Дек-24, 00:53 
> Или сам стал тем самым бурчащим дедом, который не хочет чему-то новому
> учиться и ему достаточно привычных вещей)

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

>> теперь вот изредка вступаю в дискуссии тут, но в целом — сижу и наблюдаю, как предсказания дедов-луддитов сбываются (не только в ойте),
> хм... и какие предсказания сбылись?

о, множество. если взять навскидку несколько вещей, более-менее актуральных — банкротство капитализма, несостоятельность современной экономической системы, уеренная победа RISC-ов, утопание в мусорной псевдоинформации, инженерная деградация… много всего. и ещё больше весёлого впереди. заранее скажу, что об этом всём я спорить не буду. ;-)

> Но у детей есть полученный опыт и время чтобы его применить.
> А у дидов его уже нету, только сожаления.

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

и учиться дедовость не мешает. если всю жизнь кайфовал от учёбы — то нельзя просто взять и бросить: это же круче всякой искусственной наркоты! а во многом учиться — опять таки за счёт опыта — можно быстрее и лучше.

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

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

179. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 19-Дек-24, 14:54 
> для того, чтобы знать, достаточно ли — надо хотя бы иметь представление о новом.

возможно конкретно ты разбираешься, но мне попадались тяжелые случаи, когда предложения отметались еще на этапе предложения.
реально как в мемной сцене из фильма
"- А может.. ?
-- Не стоит!"

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

тогда ты еще не настолько дедовый)

>> хм... и какие предсказания сбылись?
> о, множество. если взять навскидку несколько вещей, более-менее актуральных — банкротство капитализма, несостоятельность современной экономической системы, уеренная победа RISC-ов, утопание в мусорной псевдоинформации, инженерная деградация… много всего.

хм.. спорить не буду но ИМХО "банкротство капитализма" слегка преувеличено) как и уверенная победа RISC.
про вендокапец я тоже слышу столько лет, что уже даже не смешно.

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

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

> в итоге решаешь задачи быстрее молодёжи,

в моей практике это не так, возможно сферы разные

> и учиться дедовость не мешает. если всю жизнь кайфовал от учёбы — то нельзя просто взять и бросить: это же круче всякой искусственной наркоты! а во многом учиться — опять таки за счёт опыта — можно быстрее и лучше.

значит, по моему определению, ты не "дед"))

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

182. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 19-Дек-24, 22:46 
>> в итоге решаешь задачи быстрее молодёжи,
> в моей практике это не так, возможно сферы разные

ну, это не всегда и не во всём, конечно. молодёжь тоже разная бывает. я скорее про «в среднем по больнице» тут.

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

189. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 20-Дек-24, 23:18 
> на самом деле можно хотя бы начать с оценки того, действительно ли
> надо бежать, если «все побежали». и если надо — то точно
> в ту сторону, куда все?

Ну вот лично я совсем не откажусь от...
1) В 2 раза больше битов за тот же 1 такт. Это _разные_ мегагерцы при прочих равных.
2) Нормальный position independent код.
3) Более адекватный регистровый файл и ABI. Нет, куча пушпопов по причине куцести регистрового файла - этими не является.
4) Оператива давнор превысила 2^32 и с фига ли я не должен мочь это адресовать?

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

Однако с мощным и хорошим инструментом при прочих равных можно достичь большего. Распиаренность тут не при чем. Молотить за такт в 2 раза больше битов - и не ограничивать себя 2^32 байтов памяти просто весьма логично. Без всяких пиаров.

> же не предвещало!» некоторую горечь наблюдениям придаёт то, что я сам
> был таким же летним ребёнком, и — увы — не знаю
> метода, позволяющего научить других эту фазу скипать.

Что - получилось? У меня вот получились - некоторые выводки blob-free систем. Я должен расстроиться по этому поводу? Или плакать что Olimex 64-битный одноплатник вообще в открытом KiCad отрисовали? Вообще-то я заждался когда мерзотные недо-божки типа производителей мамок отправятся за всеми остальными проприетарщиками. И, конечно, такую штуку будет мучительно рисовать на совсем уж тетрисе в силу сложности топологии.

Ну или я вон в xnec2c развлекаюсь с ягой, не, не той которая бухло. И тому подобным. И что-что а вот производительности там много не бывает.

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

193. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 20-Дек-24, 23:40 
>> на самом деле можно хотя бы начать с оценки того, действительно ли
>> надо бежать, если «все побежали». и если надо — то точно
>> в ту сторону, куда все?
> Ну вот лично я совсем не откажусь от...
> 1) В 2 раза больше битов за тот же 1 такт.

а я в 32-бит режиме могу как минимум в четыре раза больше битов. и что?

> 2) Нормальный position independent код.

а вот зачем? это из той же оперы: «все побежали». возможно, ты не в курсе, что переходы и вызовы у x86 всегда были pc-relative — так я сообщаю. из столь ненавидимых тобой фиксапов конкретно кода — только доступ к глобалам. в нормальном коде это весьма редкая ситуация. надо будет как-нибудь ради интереса опять сделать статистику, она довольно забавная получается.

> 3) Более адекватный регистровый файл и ABI. Нет, куча пушпопов по причине
> куцести регистрового файла - этими не является.

зачем ты используешь такие плохие компиляторы?

> 4) Оператива давнор превысила 2^32 и с фига ли я не должен
> мочь это адресовать?

ура, теперь мы можем загадить мусором больше 4гб за раз!

> Однако с мощным и хорошим инструментом при прочих равных можно достичь большего.

расскажу тебе историю. в современных интел-камнях `rep movsb` внутри камня очень оптимизирована. она умеет копировать большими блоками, а не по байту. мощная и удобная штука. вот только startup time у неё такой, что простой ручной цикл успевает за время стартапа перекинуть байт 16 уже, а то и больше. надо ли пихать эту — без иронии — мощную инструкцию (технически это одна инструкция) в любых копированиях?

> Распиаренность тут не при чем. Молотить за такт в 2 раза
> больше битов

…я могу без раздувания указателей. кстати, средний размер инструкций в x86_64 тоже больше, чем в x86.

> И что-что а вот производительности там много не бывает.

вот только это имеет мало отношения к битности, и много — к прямым рукам и хорошим алгоритмам.

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

125. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Хрю (?), 17-Дек-24, 12:20 
>неимоверно радует тот факт, что хумансы без проблем, например, доверяют свои жизни устройствам с непонятным принципом функционирования

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

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

148. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 17-Дек-24, 20:08 
> А ты понимаешь как работает твой мозг?

а ты понимаешь разницу между «мы сделали» и «нам было дадено изначально, без документации»? вопрос, если что, риторический: очевидно, что не понимаешь, для этого как раз рабочий мозг нужен.

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

52. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от нах. (?), 16-Дек-24, 20:51 
> Это одна из базовых фич, которые продают их продукты — замена компонентов на лету, без остановки
> всей машины.

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

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

(и именно по этой причине те же вмварьские кластеры настойчиво рекомендуют включать EVC - и хрен ты соберешь в один кластер камни одновременно от intel и амуде - потому что от такой миграции, внезапно, может и поплохеть)

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

102. "KVM: регрессии производительности и обсуждение поддержки 32-..."  –1 +/
Сообщение от 12yoexpert (ok), 17-Дек-24, 06:34 
там небось ещё и ядра cpu по подписке. каждое. отдельно
Ответить | Правка | Наверх | Cообщить модератору

142. Скрыто модератором  +/
Сообщение от нах. (?), 17-Дек-24, 18:29 
Ответить | Правка | Наверх | Cообщить модератору

51. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (51), 16-Дек-24, 20:50 
В device emulator из Android SDK можно работающий андроид остановить с сохранением состояния, то же в VirtualBox. Продолжать можно, КМК, на другом железе .
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

53. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (51), 16-Дек-24, 20:54 
... хотя это может к гостевой системе и не относится
Ответить | Правка | Наверх | Cообщить модератору

37. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +1 +/
Сообщение от Аноним (37), 16-Дек-24, 18:49 
Когда переход на 128 бит?
Ответить | Правка | Наверх | Cообщить модератору

103. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +3 +/
Сообщение от Аноним (103), 17-Дек-24, 10:50 
Уже осуществлён. И переосуществлён. Многий софт уже требует SSE4.2, там векторы 128-битные. А размер указателя не особо важен - он привязан к размеру памяти. Когда потреб...ительство доходит до того, что 32 бита становится мало, тогда оверхед на вдвое болшие указатели становится несущественен - всё равно эффективные потреб...ители транжирят в разы больше, а других разрабов софта для вас нет: рыночек порешал, если клиент не готов платить даже за железо - то за софт он и подавно платить не готов, эффективный фильтр отсеять заведомо неприбыльные сегменты рынка.
Ответить | Правка | Наверх | Cообщить модератору

43. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +1 +/
Сообщение от Аноним (43), 16-Дек-24, 19:25 
Когда тебе перестанет хватать 16 Экзабайт(!) памяти. Ну или 8 терабайт под один процесс.
Ответить | Правка | Наверх | Cообщить модератору

49. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (50), 16-Дек-24, 20:13 
> 8 терабайт под один процесс

В некоторых задачах аналитики мы довольно близки у этим значениям. Мне девелоперы иногда жалуются, что терабайт мало, а на четырёх серверах по ¼ТБ — медленно. А айбиэмовского мейнфрейма у меня для них нет.

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

62. Скрыто модератором  +1 +/
Сообщение от arisu (ok), 16-Дек-24, 22:35 
Ответить | Правка | Наверх | Cообщить модератору

124. Скрыто модератором  +/
Сообщение от Аноним (-), 17-Дек-24, 12:12 
Ответить | Правка | Наверх | Cообщить модератору

150. Скрыто модератором  +/
Сообщение от arisu (ok), 17-Дек-24, 20:16 
Ответить | Правка | Наверх | Cообщить модератору

104. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (104), 17-Дек-24, 10:53 
убогонький DSG-2 от NVidia - имеет на борту 768-1500 Gb памяти
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

126. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от BeLord (ok), 17-Дек-24, 12:37 
Напомни разрабам, что станок в ЧПУ решал свои вопросы с 256 байтами памяти и делал детали из которых можно собрать кресло на котором этот разраб сидит-))
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

134. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от _kp (ok), 17-Дек-24, 15:22 
Не совсем с 256 байтами. У него память на перфоленте была. ;)
Ответить | Правка | Наверх | Cообщить модератору

137. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (137), 17-Дек-24, 15:54 
> Напомни разрабам, что станок в ЧПУ решал свои вопросы с 256 байтами
> памяти и делал детали из которых можно собрать кресло на котором
> этот разраб сидит-))

Но на станке где памяти больше - можно делать и куда более крутые детали. Куда качественнее.

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

145. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (67), 17-Дек-24, 20:00 
Нет. Механика станка ограничивает, а не размер памяти
Ответить | Правка | Наверх | Cообщить модератору

151. "KVM: регрессии производительности и обсуждение поддержки..."  +1 +/
Сообщение от arisu (ok), 17-Дек-24, 20:18 
> Нет. Механика станка ограничивает, а не размер памяти

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

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

167. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (-), 18-Дек-24, 18:47 
>> Нет. Механика станка ограничивает, а не размер памяти
> вот зачем ты? Современные Успешные Айтишники уверены, что любую проблему можно решить
> просто увеличив объём хранилищ и число процессоров. не ломай людям жизни.

Вообще-то вот именно этот конкретный айтишник - смотрит на забавную менюху в UART'е где можно интерактивно степпером порулить по приколу :)

При том оно напрогано - с ноля, самим мной, by specs. Т.е. я просто посмотрел времянки сигналов потребные степперу - и напрогал это. Без всяких serial.begin'ов и прочих либ в стиле черного ящика от богов. Вплоть до разгона, торможения, бибикиния степпером и проч (когда микросекунды можно потрогать пальцами, можно и немного поприкалываться).

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

166. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (-), 18-Дек-24, 18:41 
> Нет. Механика станка ограничивает, а не размер памяти

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

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

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

175. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 19-Дек-24, 00:23 
ты сейчас описал DSP с обратной связью. для чего традиционно используют кастомно разработаное железо. конечно, можно приспособить и серийное — но это, по моему мнению, всё ещё не повод усложнять серийное железо до степени, когда оно сможет делать всё-всё (но хреново).
Ответить | Правка | Наверх | Cообщить модератору

191. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от Аноним (191), 20-Дек-24, 23:34 
> ты сейчас описал DSP с обратной связью.

Ну а ты посмотри что в современном motor control вообще бывает - мало не покажется. По мере разжирения микроконтроллеров - народ и алго заапгрейдил, раз считать подешевело. И да, свойства крутилок от этого несколько улучшились.

> для чего традиционно используют кастомно разработаное железо. конечно, можно
> приспособить и серийное — но это, по моему мнению, всё ещё не повод усложнять
> серийное железо до степени, когда оно сможет делать всё-всё (но хреново).

Да господи, я себе сам нарисовал например борду STM32 с степпером. И на бис ее повторял, копипаст штука такая. DSP я правда не заморачивался, степперу оно не особо надо, но разгон, торможение и даже бибикание мотором - сделал себе по приколу.

При том пафосу то сколько. А реально - вечерок в KiCad порисовать. И да, это даже без фабы можно сделать и собрать. Собссно поэтому народ и развлекается созданием всякой "полуиндустриаловки" чуть не на коленке. Всякие 3D принтеры, кастомизированные принтеры для печати сразу на печатку по фоторезисту, и тому подобное около-CNCшное и т.п. - ну и вот фирмвар накорябать.

И пока индустрия протупляла на тему что там кому (не)нужно такие и запустили направление 3D печати например. Да и другие (полулабораторные) штуки - вот, пожалста.

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

194. "KVM: регрессии производительности и обсуждение поддержки..."  +/
Сообщение от arisu (ok), 20-Дек-24, 23:45 
ты описываешь, как очень нужно DSP, просто жить без него никак — и тут же рассказываешь, как не нужно, и жить нормально. а можно, мы будем беседовать без подобных шизофренических тэйков? я тоже в подобное умею, но мы же не триьбют монтипайтонам делаем?
Ответить | Правка | Наверх | Cообщить модератору

180. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (24), 19-Дек-24, 17:54 
Ну ты ровно на 20 лет опоздал.
Тому же Mach3 и LinuxCNC хватает 32х битного 4 пня типа нортвуда из далекого 2004 года...
Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

192. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (191), 20-Дек-24, 23:35 
> Ну ты ровно на 20 лет опоздал.
> Тому же Mach3 и LinuxCNC хватает 32х битного 4 пня типа нортвуда
> из далекого 2004 года...

Теперь попробуйте вместо этого перфоленту и 256 байтов на все, и как вам такой "апгрейд технологий"? :)

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

54. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +2 +/
Сообщение от Аноним (58), 16-Дек-24, 21:17 
>Желание избавиться от поддержки 32-разрядных систем объясняется тем, что даже на массовых 32-разрядных процессорах ARM, таких как ARM Cortex A7, виртуализация не получила развития

На самом деле это просто окно Овертона двигают в сторону полного дропа. Хотя на самом деле никакого окна нет, и дропнуть можно просто решением Линуса все 32-битные ISA скопом. Good riddance - скажет он, как уже говорил.

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

127. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (127), 17-Дек-24, 12:48 
>KVM: регрессии производительности

Это не у KVM регрессии, а у Интеля. Правильное решение: "либо покупайте у нормальных вендоров CPU, либо не вякайте".

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

154. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Zenitur (ok), 17-Дек-24, 23:38 
Вопрос: а зачем на 64-битных армах KVM? Разве там есть аппаратная виртуализация? Или там паравиртуализация, как с Xen в 2005 году?
Ответить | Правка | Наверх | Cообщить модератору

160. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (159), 18-Дек-24, 16:13 
Да, есть. Для того, чтобы крутит код юзера в виртуалке, а bootloader залочить и никого кроме своих - не пущать.
Ответить | Правка | Наверх | Cообщить модератору

168. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +/
Сообщение от Аноним (168), 18-Дек-24, 18:51 
> Вопрос: а зачем на 64-битных армах KVM? Разве там есть аппаратная виртуализация?

Поздравляю с отпуском ручника. Аппаратная виртуализация у ARM была еще в ARMv7 32 битном - поэтому для них даже был KVM. Но его все же пару лет назад задропали, ибо юзать на относительно хилых железках с скромной RAM виртуалки - странная идея и так никто не делал.

А уж ARMv8 с и подавно с виртуализацией. Представляете, у x86 нет монополии на прогресс. И RISCV идеи соьезьянил, что они, рыжие?!

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

181. "KVM: регрессии производительности и обсуждение поддержки 32-..."  +1 +/
Сообщение от nilsys (?), 19-Дек-24, 18:04 
да, аппаратная

да, даже на телефонах. см. android virtualization framework

это только на опеннете ни у кого ничего никогда нет

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

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

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




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

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