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

"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.dev/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ообщить модератору

	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ообщить модератору

	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
	Кто о чем а нище6род из подвала - о наболевшем. Подписки к evc ни малейшего отношения не имеют. (и стоят в десятки раз меньше моей зарплаты - а "само" оно почему-то не работает)
	Ответить | Правка | Наверх | 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
	нет органических мозгов — починим докидыванием RAM!
	Ответить | Правка | Наверх | Cообщить модератору

	124. Скрыто модератором	+/–
	Сообщение от Аноним (-), 17-Дек-24, 12:12
	> нет органических мозгов — починим докидыванием RAM! Ну так RAM докупить - можно, а вот кто смог докупить себе мозги?! :)
	Ответить | Правка | Наверх | Cообщить модератору

	150. Скрыто модератором	+/–
	Сообщение от arisu (ok), 17-Дек-24, 20:16
	>> нет органических мозгов — починим докидыванием RAM! > Ну так RAM докупить - можно, а вот кто смог докупить себе > мозги?! :) хм. если рассматривать в таком аспекте, то даже нечего возразить…
	Ответить | Правка | Наверх | 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-..."	+/–
	Сообщение от nilsys (?), 19-Дек-24, 18:04
	да, аппаратная да, даже на телефонах. см. android virtualization framework это только на опеннете ни у кого ничего никогда нет
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

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

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