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

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

Сообщения

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

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

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

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

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

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

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

	7. "KVM: регрессии производительности и обсуждение поддержки 32-..."	+6 +/–
	Сообщение от Аноним (-), 16-Дек-24, 15:42
	> Опять этот любитель rust'а Arnd Bergmann. Он так то - майнтайнер ARMов в основном, а вовсе не... > Если консерватория не позволяет нормально обрабатывать разные варианты, > то исправляете что-то в консерватории, а не варианты по живому отрезайте. Так изучение показало что бобик давно сдох. - ARM на KVM был но это никто не юзал и вынос KVM оказался всем просто пофиг. Никто даже в рассылку не пискнул. Слишком хилые железки чтоб VM на них запускать. - x86 которые не умели 64 бита но умели аппаратную виртуализацию было буквально полтора античные уродца, типа CoreDuo чтоли. И конечно никто не запускает VM всерьез на таком, с 32 бит хостами. - Все остальное из этого списка вы вероятно даже на картинке не видели. Если вдруг видели - ну, пискните в рассылку что так и сяк, еще живые и юзаете. Иначе однажды они все же посчитают что таки - все с этим сдохли. А раз так - для кого работается работа? Ублажение /dev/null чисто по приколу?
	Ответить | Правка | Наверх | Cообщить модератору

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

	26. "KVM: регрессии производительности и обсуждение поддержки 32-..."	+/–
	Сообщение от Аноним (26), 16-Дек-24, 17:40
	> Core Duo, полагаю, тоже мало кто в живую видел. Оно только на > ноутах и было, чем, кстати, и объясняется отсутствие поддержки 64-бит - > на ноуты в те времена не ставили столько оперативки, чтобы возникала > потребность отказываться от 32-битной ОС. > Широкие массы познакомились с этим уже в виде десктопных Core2. Ну так собственно пойнт той возни: множество (умеет HW Virt) && (не умеет 64 бита) - на x86 крайне маргинальное и являет собой буквально полторы малорпспостраненных уродца от интеля, докор2дубной эпохи ажно. На ARM - при всем моем интересе к ARM я так ни разу KVM там и не заюзал на 32 битах. А кто еще из 32 бит остался в результате? А, ну вот те полтора экзота. Их кто-то видел хотя-бы на картинке? Я лично - нет. Тут у девов и вопрос - а для кого фича таскается? Они - есть?
	Ответить | Правка | Наверх | Cообщить модератору

	178. "KVM: регрессии производительности и обсуждение поддержки 32-..."	+/–
	Сообщение от xintrea (ok), 19-Дек-24, 14:07
	> Core Duo, полагаю, тоже мало кто в живую видел. Аж чуть не поперхнулся. У меня это моя рабочая машина с 4Gb ОЗУ. Летом, наверно, займусь апгрейдом компа, поменяю на i3-4130, и вкорячу целых 8Gb! Даже не представляю, что буду со всей этой мощью делать.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "KVM: регрессии производительности и обсуждение поддержки 32-..."	+/–
	Сообщение от Аноним (-), 19-Дек-24, 23:01
	>> Core Duo, полагаю, тоже мало кто в живую видел. > Аж чуть не поперхнулся. У меня это моя рабочая машина с 4Gb ОЗУ. У вас до сих пор 32 битная машина для работы? > Летом, наверно, займусь апгрейдом компа, поменяю на i3-4130, и вкорячу > целых 8Gb! Даже не представляю, что буду со всей этой мощью делать. Ну это смотря в чем работа состоит. Если например просто захотеть скомилять сабжевое ядро с другим конфигом - там и EPYC лишним не покажется. Почему-то.
	Ответить | Правка | Наверх | Cообщить модератору

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

	195. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 23-Дек-24, 23:34
	>> У вас до сих пор 32 битная машина для работы? > вот у меня, например, 32-битная ось, и 8гб памяти на рабочей машине. Зашибись комбо когда нельзя даже аллоцировать доступную оперативу некоей программе. >> Ну это смотря в чем работа состоит. Если например просто захотеть скомилять >> сабжевое ядро с другим конфигом > пересборка ядра занимает примерно шесть минут. не то чтобы мне это было > постоянно надо, но вот так. Что однозначно выдает дико обрубленый и неуниверсальный кернел. Прекрасно для админа локалхоста но очень непрактично для всего остального.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

	117. "KVM: регрессии производительности и обсуждение поддержки 32-..."	+/–
	Сообщение от Аноним (-), 17-Дек-24, 11:57
	> Оно было очень массово на серверах, звалось Xeon LV (https://theretroweb.com/chips/3393) > и от ноутбучного действительно отличалось мало. Массово - по сравнению с чем? Сколько я себя помню энтерпрайзы очень быстро подсели на 64 бита и хардварную виртуализацию - а все вон то было крайне нишевой ситуацией еще 10 лет назад, а сейчас это как хост VM - ну, хоть 1 остался? Если вдруг - его владельцам и пищать в рассылке что мол они тут еще не померли. Хотя как по мне - могут LTS ядра просто юзать. > Часто вижу такие системы в проде до сих пор в формате двухпроцессорных SBC > в составе контроллеров видеостен, некоторого промышленного и реже медицинского оборудования. Эти ископаемые даже если и юзали Linux то врядли что-то делали с виртуалками.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "KVM: регрессии производительности и обсуждение поддержки 32-..."	+/–
	Сообщение от IdeaFix (ok), 17-Дек-24, 13:29
	Тут вопрос в другом вообще. Формулировка цели, для достижения которой ставится задача "пищать" не верна. Много где отлично до сих пор на 2.6. Одно дело когда дропали HP-PA - просто разом убрали всю документацию, выкрутили руки всем кто официально контрибутил в чпукс, прямо поудаляли всё и везде и ничего не дали в плане документации после смерти. А тут... в 6.хх ядре сломают Коре дуо?:) Ха-ха... у нас на два шесть всё прекрасно. А хосты на ESX 3i на х86 без vt таки да, до сих пор встречаются. Недавно такой хост в гиперв мигрировал :)
	Ответить | Правка | Наверх | Cообщить модератору

	135. "KVM: регрессии производительности и обсуждение поддержки 32-..."	+/–
	Сообщение от Аноним (-), 17-Дек-24, 15:39
	> Тут вопрос в другом вообще. Формулировка цели, для достижения которой ставится задача > "пищать" не верна. Позволю не согласиться. Ресурсы у разработчиков - ограниченные. Кода - много. И по приколу наворачивать на мусорный бак, не зная используется ли - непозволительная роскошь. > Много где отлично до сих пор на 2.6. Они и продолжат на 2.6 фигачить, при чем тут майнлайн? Ядра 2.6 официально не поддерживаются много лет. Что и для кого в этой схеме меняется? > не дали в плане документации после смерти. А тут... в 6.хх > ядре сломают Коре дуо?:) У кого-то еще осталось это барахло - и они там реально виртуалки гоняли? Ну пусть в рассылку пискнут, обрисовав свой сценарий. Это ж RFC пока. > Ха-ха... у нас на два шесть всё прекрасно. Так и пользуйтесь им дальше, при чем тут майнлайн? Для каких-то реально странных типов довольно свежие LTS - с этим всем - будут еще до минимум 2030 поддерживаться. А там, глядишь, или шах, или ишак... > А хосты на ESX 3i на х86 без vt таки да, до > сих пор встречаются. Недавно такой хост в гиперв мигрировал :) Вот, прекрасно, делайте вон тем мозги майкрософту, интересно же насколько у них благодати хватит поддерживать кору даже не дуба. Может еще и нахаляву даже? Я совсем не против если майкам такой якорь вобьют :D
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	41. "KVM: регрессии производительности и обсуждение поддержки..."	+4 +/–
	Сообщение от arisu (ok), 16-Дек-24, 19:16
	> И конечно никто не запускает VM всерьез на таком, с 32 бит хостами. опять меня не существует, да что ж ты будешь делать-то!
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

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

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

	74. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 17-Дек-24, 00:40
	> а разве это они в паре комментариев выше написали на опеннете, что меня не существует? Ты им сообщил, что еще не вымер? Как они должны были догадаться, что такие оригиналы еще существуют? А вот написал бы, и они бы сразу же решили "не, ну раз arisu пользуется, то не будем дропать еще лет десять!"
	Ответить | Правка | Наверх | Cообщить модератору

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

	82. "KVM: регрессии производительности и обсуждение поддержки..."	+1 +/–
	Сообщение от Аноним (-), 17-Дек-24, 01:39
	Так про то что таких как ты не существует написали не только местные комментаторы. А непосредственно те, кто хочет дропнуть: It probably makes sense to drop all of these at the same time, provided there are no actual users remaining (not counting regression testing that developers might be doing). https://lore.kernel.org/kvm/3589ad69-13df-40f1-88c2-55d39790.../ Ну и у тебя есть выбор - или сообщить что они не правы и оно все еще кому-то нужно, или ничего не делать и наслаждать дропом поддержки того, чем ты пользуешься.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от arisu (ok), 17-Дек-24, 01:45
	> Так про то что таких как ты не существует написали не только > местные комментаторы. это, без сомнения, очень интересная информация. однако я обращался именно к местному комментатору. надеюсь, правилами ещё не указано, что для обращения к анонимусу на опеннете мне надо писать в lkml, чтобы они потом переслали сюда? > или ничего не делать и наслаждать дропом поддержки того, чем ты пользуешься будь любезен, приведи цитату, где я недоволен этим дропом. потому что я сам отчего-то её найти не смог.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	108. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (108), 17-Дек-24, 11:04
	> то есть, твоё пожелание мне писать маинтайнерам было высказано просто так, чисто чтобы повысить уровень шума в сигнале? Разумеется нет! А исключительно чтобы просветить тех темных и невежественных людей из мейнлайна: "Динозавры существуют! Более того, они ходят среди нас!" Может они будут в шоке, что такое все еще встречаются. А может поржут и покрутят пальцем у виска.
	Ответить | Правка | Наверх | Cообщить модератору

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

	114. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 17-Дек-24, 11:26
	> я совершенно не понимаю, почему твоё желание кого-то просвещать вдруг должен исполнять я. Потому что мне они не поверят. Скажут "не, такого быть не может. они все вымерли, вот что ты нам заливаешь!" А ты пруфу предоставишь, скрины например. Скажешь "я сижу за компом - значит существую". Все равно у тебя много свободного времени и явно нечего делать. Иначе ты бы не писал такой длинный тред с безымянным аноном из инета)))
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	144. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от arisu (ok), 17-Дек-24, 19:58
	> Все равно у тебя много свободного времени и явно нечего делать. это совершенно не значит, что мне интересно реализовывать твои хотелки, тем более бесплатно.
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	120. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (120), 17-Дек-24, 12:05
	> я совершенно не понимаю, почему твоё желание кого-то просвещать вдруг должен исполнять я. Кэп, ты лол. Давай я тебе расскажу? Эти конфиги - нужны тебе. Ну, если - нужны. Вот поэтому и - ты. А если не нужны даже и тебе - то и подавно выкинуть на мороз, соответственно. Ибо настолько отшибленых извращенцев чтобы KVM на 32 бит хосте запускать - на глобусе немного. Их и раньше то не дофига было. А сейчас - вымирающий вид. И таки да, если кто будет смеяться что встретил дино на переходе - ну извините :)
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

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

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

	172. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от arisu (ok), 18-Дек-24, 23:48
	> ты реально юзаешь KVM на 32 бит хостах, не умеющих в 64 бита? ну не выкидывать же рабочее железо. я вообще не люблю выкидывать железо, которое можно к делу приспособить. не то чтобы прямо уж юзаю и жить без этого не могу, но иногда и редко — случается.
	Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

	185. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 19-Дек-24, 23:11
	> ну не выкидывать же рабочее железо. я вообще не люблю выкидывать железо, > которое можно к делу приспособить. Я совсем ненужное - раздал всяким сельпошникам, у которых денег и на такое не было. Да и не так уж много у меня откровенного хлама было. А некоторое количество дохляков - так то оказались полезны как "запчасти". Правда, мне их другие сбагрили, с аргументом что я электроникой интересуюсь. Я сперва брыкался. Но посмотрел чего можно паяльной станцией сдуть, и решил что скажем полкило жирных хороших силовых полевиков нашару - вполне недурно. > не то чтобы прямо уж юзаю и жить без этого не могу, но иногда и редко — случается. И там вот реально виртуализация? oO А то я так и не сподвигся KVM потестить на ARM, большая часть одноплатников на 32 бит ARM как-то не вызывают острого желания там виртуалки запускать пачками. Сугубо по ресурсам.
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

	187. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от arisu (ok), 19-Дек-24, 23:32
	> И там вот реально виртуализация? kvm удобен в том числе для создания хорошо изолированых окружений. но в общем — да. хотя это был скорее эксперимент в бесполезном, чего скрывать. ;-)
	Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

	196. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 23-Дек-24, 23:37
	> kvm удобен в том числе для создания хорошо изолированых окружений. но в > общем — да. хотя это был скорее эксперимент в бесполезном, чего скрывать. ;-) Ну как бы у меня он так и юзается. И вот гуесты иногда можно и 32 бита. Хотя 64 лучше по перфомансу крипто всякого и проч, а оперативы они у меня много не жрут - я умею минимальные дебианы фигарить.
	Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

	119. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 17-Дек-24, 12:02
	> ещё раз спрошу: зачем мне это *им* сообщать? это они несколькими комментариями > выше написали на опеннете, что меня не существует? Ну так пискни в рассылку - и сообщи что существует. Ну, если это все реально надо. А то народ недоумевает зачем на /dev/null работать надо. Ибо юзать виртуализацию на 32 бит хосте - это уже лет цать назад было как минимум странным чудачеством. Просто для понимания - я ни разу не сподвигся KVM на ARM попробовать, даже и не удобно было в рассылке высовыватся. Мол, офигенная фича, я правда ни разу не пробовал - но плиз оставьте? :D
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	157. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Роман (??), 18-Дек-24, 08:44
	> Как они должны были догадаться, что такие оригиналы еще существуют? через телеметрию или хотя бы по проданным лицензиям..oh wait..
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

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

	164. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 18-Дек-24, 18:27
	>>> Как они должны были догадаться, что такие оригиналы еще существуют? >> через телеметрию или хотя бы по проданным лицензиям..oh wait.. > Да не, спасибо, вы там таким жабогадюкингом в своей виндочке как-нибудь без нас занимайтесь. Как говорится - "хорошо там, где вас нет". Правильно! И чтобы стало хорошо, мы делаем чтобы вас не было) А то просто неудобно - прогрессивный проект и тут какие-то нищуки-луддиты с коре дуо (даже не с ДВА дуо!). И ладно если бы они просто сидели на старой версии, бекпортили фиксы, которые им делают товарищи поумнее, и не чирикали. Но нет! Они начинают вонять на форумах "нам должны! вы обязаны поддерживать наше некрожелезо пока последний некролюб не помрет!" и так далее. И вот в таких случаях телеметрия супер полезна. Просто тыкаешь хама мордочкой в статистику - где нет ни одного луддита (ну или 1%) и закрываешь issue как wont fix
	Ответить | Правка | Наверх | Cообщить модератору

	169. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 18-Дек-24, 20:36
	> Правильно! > И чтобы стало хорошо, мы делаем чтобы вас не было) Ну вот меня и нету в ваших виндочках. Я нифига не [] agree с тем булшитом который там написан, а для улучшения качества моего обслуживания намного лучше если м....ки с троянами, малварью, спайварью и незапрошенной активности - пойдут нафиг, наносить пользу и причинять добро кому-нибудь другому. Например, себе. > А то просто неудобно - прогрессивный проект и тут какие-то нищуки-луддиты с > коре дуо (даже не с ДВА дуо!). Ну вот зачем запускать виртуализатор - на именно 32 бит хосте - при том что за всю историю человечества было полторы модели процов с таким сочетанием фич - я тоже не понимаю. Как видим - телеметрия для этого не требуется. > И ладно если бы они просто сидели на старой версии, бекпортили фиксы, > которые им делают товарищи поумнее, и не чирикали. Да вообще-то так и делают. Вооон там LTSные кернелы пачками есть. Это ж не только им надо но и каким-нибудь индустриальным некромасерам и проч. > Но нет! Они начинают вонять на форумах "нам должны! вы обязаны поддерживать > наше некрожелезо пока последний некролюб не помрет!" и так далее. Как по мне фаны телеметрии не лучше этих. Выпустить тех и других на арену, раздать мечи, и зрителей позвать, во. > Просто тыкаешь хама мордочкой в статистику - где нет ни одного луддита > (ну или 1%) и закрываешь issue как wont fix Ну это вы там с вашими хомячками сами разбирайтесь, я врядли ваш софт вообще увижу и тем более юзать буду. Не пользуюсь крапом с телеметрией и со своей стороны считаю это малварью, что даже несколько больше чем хамство. Де факто это попытка интрузии и кражи данных, лично я бы за такое уголовку шил.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 18-Дек-24, 20:52
	> я врядли ваш  софт вообще увижу и тем более юзать буду. фух, какое облегчение! > Не пользуюсь крапом с телеметрией и со своей стороны считаю это малварью, это твои проблемы, что чем считать. вон некоторые считают, что земля плоская ¯\_(ツ)_/¯ > что даже несколько больше чем хамство. Де факто это попытка интрузии и кражи данных, лично я бы за такое уголовку шил. де факто это твои больные фантазии, типа как "ИНН - число диявола". есть закон который определяет какие данные персональные, какие паспортные, а какие нет. а все что не запрещено - разрешено.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 19-Дек-24, 23:17
	> фух, какое облегчение! Держите нас в курсе. >> Не пользуюсь крапом с телеметрией и со своей стороны считаю это малварью, > это твои проблемы, что чем считать. > вон некоторые считают, что земля плоская ¯\_(ツ)_/¯ А я вот как раз люблю разбираться что и как работает. И за кого меня держат в энной схеме. Поэтому к м...кам пытающимся косплеить "богов" у меня отношение - весьма характерное. Зачем мне малварь, спайварь, адварь и прочий крап? Я как раз опенсорсом пользуюсь - для избавления от всего этого "счастья". > де факто это твои больные фантазии, типа как "ИНН - число диявола". > есть закон который определяет какие данные персональные, какие паспортные, а какие нет. ЧСХ такие м....ки и нарвались на вещи типа GDPR. > а все что не запрещено - разрешено. С другой стороны так и я не обязан юзать вон те какахи - и тем более говорить что-то позитивное о их авторах и таком софте. Какие-то проблемы? :)
	Ответить | Правка | Наверх | Cообщить модератору

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

	118. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 17-Дек-24, 11:59
	>> И конечно никто не запускает VM всерьез на таком, с 32 бит хостами. > опять меня не существует, да что ж ты будешь делать-то! Ты где-то отковырял именно семейство процов которое уже умело HW Virt но не умело 64 бита? Их за всю историю человечества - полторы наименования было. И да, прости но x86-32 таки - по сути все. Это лютейшее легаси в 2024 году. Типа ARMv4 какого-нибудь - только костылей в 20 раз больше.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

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

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

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

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

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

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

	113. "KVM: регрессии производительности и обсуждение поддержки 32-..."	+/–
	Сообщение от Аноним (-), 17-Дек-24, 11:20
	> а теперь живёт чисто на донатах Забавно что ты вспомнил именно ее. Так вот - жила. Ну... или пока еще живет. While OctoPrint’s usage numbers have steadily grown by 30% since 2021 to an all time high of now over 150000 active instances (and that’s just the ones I know about), financial support for my work on OctoPrint has dropped by over 30% over that same time, with most of this decline happening over the course of the past 12 months. Денег стало меньше. Потому что донаты дело добровольное.
	Ответить | Правка | Наверх | Cообщить модератору

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

	40. "KVM: регрессии производительности и обсуждение поддержки 32-..."	+2 +/–
	Сообщение от Аноним (-), 16-Дек-24, 19:04
	> любитель rust'а Arnd Bergmann. Сразу видно что человек не заскостенелый, некролюбсвтом и луддизмом заниматься не хочет. Хорошо что в ядре есть сторонники прогресса. > а не варианты по живому отрезайте. Какому живому? Этот хлам устарел еще во времена core 2 duo.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

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

	158. "KVM: регрессии производительности и обсуждение поддержки 32-..."	+/–
	Сообщение от Аноним (2), 18-Дек-24, 14:50
	> Сразу видно что человек не заскостенелый, некролюбсвтом и луддизмом заниматься не хочет. Хорошо что в ядре есть сторонники прогресса. Тут другая проблема всплывает. Выпиливают не потому что устарело, а потому что иначе на rust получается комбинаторный взрыв. Ну нет в нем нормальной условной компиляции. И то что выпиливают старое - ладно. Но вот то что не правят консерваторию - очень плохо. Ибо как только rust обоснуется в ядре станет фактором приводящем к огромному количеству работу при добавлении каких-либо вариантов архитектурной функциональности. И потому, несмотря на то что может быть и надо было бы дропнуть устаревшее, его ни в коем случае нельзя дропать, что бы rust не влезал в ядро пока его не допилят.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

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

3. "KVM: регрессии производительности и обсуждение поддержки 32-..."	+1 +/–
Сообщение от Аноним (4), 16-Дек-24, 15:30
> В ядре 6.14 будет представлена полная версия патча, дополнительно улучшающая производительность. Я так понял, там еще будет третий патч, связанный с кэшированием всего CPUID. В данном только XSAVE закэшировали.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	42. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от arisu (ok), 16-Дек-24, 19:24
	> но согласись, такой примитивный запрос как CPUID > не должен тормозить, это просто смешно. так и простая команда `xchg eax, edx` тормозить не должна, например. это ведь просто указание ремаперу регистров, правда? а вот нет, неправда. тормозит. более чем в два раза медленней, чем `mov ebx, eax / mov eax, edx / mov edx, ebx`. и вот так у интеля всё, за что ни ухватись. и вот так у нынешних процессоров всё, за что ни ухватись. почему `movups` по выравненым адресам всё ещё в полтора-три раза медленней, чем `movaps`? (потом Зоркие Глаза заметили, починили.) почему попытки избежать domain stall в SSE иногда (и непредсказуемо заранее где) всё замедляют в разы? почему, почему, почему…
	Ответить | Правка | Наверх | Cообщить модератору

	48. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (50), 16-Дек-24, 20:09
	> почему, почему, почему… Ну почему это как раз очень просто понять. Современный CPU штука весьма сложная, а делают их люди. Люди неизбежно будут ошибаться, и жаловаться на это так же бессмысленно как сетовать на дождь. Тем более что сложность CPU как раз того самого рода которая хуже всего поддаётся людям: сложность из-за количества. Нашего «7±2» явно недостаточно для того, чтобы осознать все взаимодействия внутри даже довольно простых схем, а тут миллионы транзисторов на околоквантовых расстояниях.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	76. "KVM: регрессии производительности и обсуждение поддержки..."	+1 +/–
	Сообщение от arisu (ok), 17-Дек-24, 00:55
	> Люди существа практичные хумансы — существа неимоверно тупые прежде всего. я только не понимаю, зачем ты доказываешь этот очевидный факт своим комментарием. я написал что? я написал, что хумансы делают девайсы, принципов работы которых не понимают, хотя понимать эти принципы для разработки девайсов надо. ты мне в ответ приводишь примеры совсем из другой области.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (91), 17-Дек-24, 02:27
	Никакой он не дурак, товарищ Арису. "Понимать" это, как ни странно, относительное явление. Можно "понимать" до какой-то степени, а до какой-то не понимать, и при этом вполне решать прикладные задачи. Принципы перехода жидкости в пар и прочая молекулярно-кинетическая теория не особенно нужны производителям чайников со свистком.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от arisu (ok), 17-Дек-24, 02:33
	> Никакой он не дурак, товарищ Арису. дурак он потому, что начал приводить примеры из другой области, которая связана с оригинальной только на глупый поверхностный взгляд. то есть, сделал типичное дурацкое действие, на остановившись даже для минимального анализа.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

	136. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 17-Дек-24, 15:52
	> Да нет, он обычный школьный edgelord -- все тупые, РЯЯЯЯ. Ну, вообще, между нами, этот дефолт - отлично работает! Вероятность угадать 95% примерно. Так что он угадывает в 95% случаев, и лажается в 5%. А это - на минуточку - почти провидец. Чисто технически. И вот на что в такой схеме жаловаться, а? > То что мы, как вид, развиваемся с невиданной на планете скоростью и за > несколько десятков тысяч лет прошли путь от швыряния друг в друга > палкой до редактирования генома конечно же мелочи, главное что люди используют > 64 бита для редактирования текста, когда хватило бы 32 :)))) Вообще - файлухи и файлы давно уже вымахали за пределы 2^32, так что сказать что их хватает - это несколько покривить душой. Конечно при остром желании uint64_t можно наверное даже на AVR с его 8 бит регистрами посчитать, но вот эффективность этого кода будет в районе плинтуса.
	Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

	138. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Ананимус (?), 17-Дек-24, 16:01
	> Ну, вообще, между нами, этот дефолт - отлично работает! Вероятность угадать 95% примерно. Так что он угадывает в 95% случаев, и лажается в 5%. А это - на минуточку - почти провидец. Чисто технически. И вот на что в такой схеме жаловаться, а? Я понимаю что мы все травмированы луркмором в детстве, но сколько можно-то. > Вообще - файлухи и файлы давно уже вымахали за пределы 2^32, так что сказать что их хватает - это несколько покривить душой. Ну как верно заметили, если тебе нужно читать файл кусками, то все ок. Проблема в том, что довольно часто это не вариант. > Конечно при остром желании uint64_t можно наверное даже на AVR с его 8 бит регистрами посчитать, но вот эффективность этого кода будет в районе плинтуса. u128 на 64 битах вполне себе повседневность :)))))
	Ответить | Правка | Наверх | Cообщить модератору

	143. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 17-Дек-24, 19:37
	> Я понимаю что мы все травмированы луркмором в детстве, но сколько можно-то. Вообще-то - как известно в каждой шутке лишь доля шутки. И лурк просто квинтэссенция этого. Так что я понимаю что кому-то досадно было себя в описании узнать - ну а кто мешал учиться, развивать мозг, и вообще? > Ну как верно заметили, если тебе нужно читать файл кусками, то все ок. Что значит - "все ок"? Описание размещения файла будет запросто ворочать числами превышающими 2^32. И указание где файло, и его размер, etc. Не вижу чего офигенного ворочать математику этажеркой в таких вещах, если можно вместо этого - регистр-регистр за 1 такт. > Проблема в том, что довольно часто это не вариант. Даже если это вариант - это не делает математику этажеркой чем-то хорошим и эффективным. > u128 на 64 битах вполне себе повседневность :))))) Да я и например 1024-битными числами могу при случае ворочать по каким-то своим причинам. А уж 256-битными так оптом просто и везде. Но это все же довольно нишевой случай.
	Ответить | Правка | Наверх | Cообщить модератору

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

	163. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 18-Дек-24, 18:25
	> прости, а ты точно фс писал? а то я не очень понимаю, > чего сложного в сдвигах, которые со времён… вот не помню, > iAPX386 или iAPX486 делаются одной командой для 64 битов. или в сравнении. Как ты кодировать даже просто поле "размер файла" намерен без 64-битных чисел? И все операции с этим соответственно, by design - 64 битные. И не очень понимаю - чего и куда можно "сдвинуть" в поле размера файла? > а для маньяков — ты не поверишь, но в SSE есть целочисленные операции над квадвордами. 1) Я искренне сомневаюсь что это ОК в кернеле делать. 2) То что компилер сам так допрет - не факт. 3) А на 64 битах вся математика нативно 64 бита по размеру регистров и регистров - больше. И это я еще постеснялся уточнить что все современные алго на 64 бита оптимизированы. Ибо жевать в 2 раза битиков за такт - хорошо и правильно. > впрочем, это всё неважно, у нас тут тредик про моду, а не про технологии. Да как бы тебе сказать? Развлекаться с SIMD и какими там еще сдвигами, когда можно просто накодить что задумал - сам понимаешь. Не, код не должен быть брейнфаком полным хаков. Его потом поддерживать почти невозможно станет. Особенно в большом проекте. И лично я вполне солидарен с Торвальдсом по части "I'm not sentimental". Я бы сказал что весб x86-32 это с точки зрения процессоростроения - совсем не то о чем я буду скучать. Могу я немного эстетом побыть и назвать г-но г-ном? x86-32 это именно оно. Его единственное достоинство - дешевое и массовое.
	Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

	173. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от arisu (ok), 19-Дек-24, 00:02
	> Как ты кодировать даже просто поле "размер файла" намерен без 64-битных чисел? а, то есть, в x86 нельзя 64-битные целые использовать, для этого обязательно x86_64 надо. яснопонятно. современная ойти во всей красе. >> а для маньяков — ты не поверишь, но в SSE есть целочисленные операции над квадвордами. > 1) Я искренне сомневаюсь что это ОК в кернеле делать. возможно, ты удивишься, когда узнаешь, что ядро местами *уже* проверяет фичи CPU, и использует оптимизированые функции, если возможно. впрочем, тут у нас ходят разговоры, что поддержку x86 вообще надо бы выкинуть. откуда неизбежно получается ориентация на интел-камни, у которых есть как минимум SSE2 — который уже имеет почти всё нужное. > 3) А на 64 битах вся математика нативно 64 бита по размеру > регистров и регистров - больше. а также код больше, и указатели больше, и есть некоторые забавные проблемы с адресацией. что, конечно, не является какой-то непреодолимой сложностью — но зачем оно надо, если оно не надо? > И это я еще постеснялся уточнить что все современные алго на 64 > бита оптимизированы. Ибо жевать в 2 раза битиков за такт - > хорошо и правильно. и тут же: > Да как бы тебе сказать? Развлекаться с SIMD и какими там еще > сдвигами, когда можно просто накодить что задумал - сам понимаешь. ты принципиально не видишь тут противоречия? кстати, мой компилятор спокойно справляется с генерацией SSE2 кода для 64-битных целых. чего сложного-то? PoC был на интринсиках, потом я добавил SSE-кодоген. ни строчки написаного кода программ при этом не поменялось. > код не должен быть брейнфаком полным хаков. ну и не пиши такой, зачем такой писать? > немного эстетом побыть и назвать г-но г-ном? x86-32 это именно оно. потому что весь x86 такой. а это была попытка хоть какого-то deshittification. закономерно не удалась: пипл любит жрать коричневое и вонючее, лишь бы его рекламировали и все жрали. p.s.: а теперь про сдвиги. я же не зря спросил, действительно ли ты FS писал. потому что вся математика с 64 битами в FS — конвертация байтовых смещений в блочные и обратно. а размер блоков всегда power of two. всё ещё не понимаешь, при чём тут сдвиги?
	Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

	188. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 20-Дек-24, 22:53
	> а, то есть, в x86 нельзя 64-битные целые использовать, для этого обязательно > x86_64 надо. яснопонятно. Надо же, 64-бит процы лучше работают с 64-бит числами. Какая неожиданность. > современная ойти во всей красе. А еще я забил на AVR - и юзаю STM32. Экий я злыдень, не хочу лезть на второй этаж используя намыленый столб, в акваланге, когда можно - по лестние подняться. > возможно, ты удивишься, когда узнаешь, что ядро местами *уже* проверяет фичи CPU, > и использует оптимизированые функции, если возможно. Это - хаки! Усложняет майнтенанс. Их с удовольствием выпилят! Потому что сложный, проблемный код с рядом проблемных или нежелательных взаимодействий. Скажем такая активность не айс с точки зрения W^X. И просто майнтенанса. Не, спорт с залезанием на намыленный столб в акваланге из принципа - вон там самоцелью не является. Даже если кто и хотел сказать "во как я могу!" это так, из области курьезов. > выкинуть. откуда неизбежно получается ориентация на интел-камни, у которых есть как > минимум SSE2 — который уже имеет почти всё нужное. Не очень понимаю ремарку про SSE2 и Intel, ибо гарантированный SSE2 это визитная карточка x86-64 как раз. И это дело начали, внезапно, АМД. Впрочем возможно я не следил за жабогадюкингом - ибо я с 64 битами уже наверное скоро как 20 лет. Нехилый интервал так то. > а также код больше, Зависит от. Из за куцего регистрового файла оно занимается пушпопами от души. И на x86-32 например position independent code - ну, его нет. Зато нате вам супер-порно с релоками. Костыль на костыле и костылем погоняет. > и указатели больше, Зато может адресовать мне ВСЮ RAM - не утыкаясь в тупые проблемы "циферок не хватило". И какими нибудь абстракциями типа mmaped файлов можно нормально пользоваться. > и есть некоторые забавные проблемы с адресацией. > что, конечно, не является какой-то непреодолимой сложностью — но > зачем оно надо, если оно не надо? Вот лично мне не надо - уродца с полутора регистрами, пачками релоков, кодом наполовину состоящим из пушпопов, и прочими прелестями. Это то про что я тоже скажу "I'm not nostalgic". Да, x86-64 не предел мечтаний. Но лучше той какахи, нечто более похожее на нормальный регистровый файл, нет дефицита циферок, умеет position-independent код (PC-relative addressing) и проч. И в 2 раза больше битов за такт жует. Шаг в правильную сторону, жаль что полловинчатый. >> Да как бы тебе сказать? Развлекаться с SIMD и какими там еще >> сдвигами, когда можно просто накодить что задумал - сам понимаешь. > ты принципиально не видишь тут противоречия? Нет, я не вижу. Когда прямое выполнение на основном регистровом файле - с умеренным размером контекста - это одно. Когда какие-то "расширения" и нужда сэйвить контекст эвон какого размера - это как бы несколько грабли. А, да, кстати о птичках. Менее идиотское ABI еще в актив запишите, во! Насколько я помню, когда небольшой число параметров у функции можно - их прям в регистрах передавать. Как и у остальных процов с нормальным регистровым файлом, типа ARM и проч. > кстати, мой компилятор спокойно справляется с генерацией SSE2 кода для 64-битных целых. Я рад за твой компилер и вообще. Только вот SSE2 гарантирован - только в 64 бит прцах. А если мы про обрубки - то там уповать на SSE2 не комильфо. И кроме того - в случае вот именно кернела еще размер контекста не пустой звук. Оно ж абстракцию монопольного использования проца обеспечивает. > чего сложного-то? PoC был на интринсиках, потом я добавил SSE-кодоген. ни > строчки написаного кода программ при этом не поменялось. Сложно станет - когда захочется 1) Чтобы кернел работал на РАЗНЫХ процах. Если выдвигать требование SSE2, то имхо и 32 бита нахрен, ибо с гарантиями это только в 64-битниках и есть. 2) Свичить задачи и делать вид что задача тут одна. Ну то есть все решаемо конечно. Но сложнее, тормознее, хреновее и кривее - с более страшным кодом - очень даже может и получиться. В ядре линя и так дофига хаков для всяких окаменелых каках. И до сих пор кто-то делает мозг какими-то я извиняюсь линиями A20. Уж и той шины давно нет, а ритуалы остались. >> код не должен быть брейнфаком полным хаков. > ну и не пиши такой, зачем такой писать? Затем что всякий рантайм патчинг в ядре - делает это сложнее и кривее. И чем такого меньше тем всем проще жизня. > закономерно не удалась: пипл любит жрать коричневое и вонючее, лишь бы > его рекламировали и все жрали. Ну как бы x86-64 все же несколько более похожий на нормальные процы чем x86-32 как по мне. > p.s.: а теперь про сдвиги. я же не зря спросил, действительно ли > ты FS писал. потому что вся математика с 64 битами в > FS — конвертация байтовых смещений в блочные и обратно. а размер > блоков всегда power of two. всё ещё не понимаешь, при чём тут сдвиги? Я так понимаю что ты про отыгрыш скольких-то битов на размере сектора. Но в конечном итоге ояд вещей до сектора не округляется. А тут еще всякие алгоритмы хеширования и проч может захотеться. И ессно они лучше - на 64 битах. Крипто все тоже на 64 бита давно оптимизировано. Сие несколько подбешивает на мк кстати. Но что вот тут сделаешь?
	Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

	190. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от arisu (ok), 20-Дек-24, 23:22
	>> а, то есть, в x86 нельзя 64-битные целые использовать, для этого обязательно >> x86_64 надо. яснопонятно. > Надо же, 64-бит процы лучше работают с 64-бит числами. Какая неожиданность. надо же: сначала ты заявил, что в 32-бит режиме невозможно сделать 64-бит числа, а теперь сдал назад. какая неожиданность. >> возможно, ты удивишься, когда узнаешь, что ядро местами *уже* проверяет фичи CPU, >> и использует оптимизированые функции, если возможно. > Это - хаки! ну кто ж вам виноват, что ваше ядро — один сплошной хак? >> выкинуть. откуда неизбежно получается ориентация на интел-камни, у которых есть как >> минимум SSE2 — который уже имеет почти всё нужное. > Не очень понимаю ремарку про SSE2 и Intel а всё просто: внезапно — нет никакой причины бежать за толпой на 64 бита, потому что операции над 64-битными целыми отлично доступны в 32-бит режиме, с восемью отдельными регистрами для этого. деления, правда, нет, а для умножения придётся немного заинлайнить. ок. >> а также код больше, > Зависит от. Из за куцего регистрового файла оно занимается пушпопами от души. нет, не занимается. давай ты опять не будешь со мной спорить по поводу компиляторов, ок? > И на x86-32 например position independent code - ну, его нет. опачки. вот это новости. ты только больше никому это не говори, а то ведь может неудобно выйти. > Зато нате вам супер-порно с релоками. Костыль на костыле и костылем > погоняет. ты очень удивишься, когда узнаешь, что в x86_64 релоки никуда не делись. и ничего в них страшного нет. впрочем, если тебя это так волнует — пересобери нужные тебе библиотеки так, чтобы они не перекрывались. или — ой — используй PIC. а, прости, я забыл: у тебя же его на x86 нет. >> и указатели больше, > Зато может адресовать мне ВСЮ RAM и в булочную ты на траке-тяжеловесе ездишь наверняка. ну, вдруг чего перевезти-то понадобится? лучше брать самое большое! > Вот лично мне не надо - уродца с полутора регистрами лично тебе это без разницы, потому что ты всё равно никогда в жизни никаких практических компиляторов не писал, и рассуждаешь о том, в чём не разбираешься. и ISA соответствующие очевидно не знаешь. > Нет, я не вижу. Когда прямое выполнение на основном регистровом файле - > с умеренным размером контекста - это одно. Когда какие-то "расширения" и > нужда сэйвить контекст эвон какого размера - это как бы несколько > грабли. когда-нибудь ты узнаешь размер контекста в своём любимом x86_64. это будет шокирующая новость. я хинтану: он *больше*, чем в 32-бит режиме. > А, да, кстати о птичках. Менее идиотское ABI еще в актив запишите опять ты гордо несёшь ерунду. >> кстати, мой компилятор спокойно справляется с генерацией SSE2 кода для 64-битных целых. > Я рад за твой компилер и вообще. Только вот SSE2 гарантирован - > только в 64 бит прцах. pentium-m? pentium-4? не, не слышали, не было. > А если мы про обрубки - то там уповать на SSE2 не комильфо. потому что тебе это не нравится, ломает красивую картинку мира? > И кроме того - в случае вот именно кернела еще размер контекста > не пустой звук. Оно ж абстракцию монопольного использования проца обеспечивает. см.выше. рыдай. > Сложно станет - когда захочется > 1) Чтобы кернел работал на РАЗНЫХ процах. автоматический рантайм патчинг? не, не слышали? ну, я не виноват, что ваш гцц в такие штуки умеет очень плохо. у меня — оверхед на первый вызов, дальше full speed. > 2) Свичить задачи и делать вид что задача тут одна. Ну то > есть все решаемо конечно. Но сложнее, тормознее, хреновее и кривее - > с более страшным кодом - очень даже может и получиться. попробуй не писать это сложнее, тормознее, хреновее и кривее. у меня получается, это возможно. > В ядре линя и так дофига хаков для всяких окаменелых каках. ну кто ж вам виноват, что вашу свалку кода на лету пересобрать под конкретный камень — задача нереальная? > Затем что всякий рантайм патчинг в ядре - делает это сложнее и > кривее. ты только что объявил все переменные злом. а, ну да: у вас же там всё сложно, концепция «code as data» давно утеряна. > Ну как бы x86-64 все же несколько более похожий на нормальные процы > чем x86-32 как по мне. если закрыть глаза и отвернуться разве что. > Но в конечном итоге ояд вещей до сектора не округляется. например? > тут еще всякие алгоритмы хеширования и проч может захотеться. И ессно > они лучше - на 64 битах. давеча SHA512 сделал, понадобилось. никаких проблем. вышло в два раза быстрее, чем у `gcc -O3 -march=native -mtune=native`. без ручных оптимизаций, код один и тот же. ну, плохо ваш гцц с 64 битами в 32-бит режиме работает. это личные проблемы гцц и тех, кто использует этот хлам. > Крипто все тоже на 64 бита давно оптимизировано. вот как раз и смотри про SHA512 выше, лол.
	Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

	198. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (198), 25-Дек-24, 02:53
	> надо же: сначала ты заявил, что в 32-бит режиме невозможно сделать 64-бит Это где я такое сказал? O_O. Пойнт был лишь что это менее эффективно в дофига номинаций и идет в комплекте с кучей грабель. > числа, а теперь сдал назад. какая неожиданность. А нельзя ли уточнить где я сказал что совсем нельзя? Я лишь сказал что это будет менее эффективно. > ну кто ж вам виноват, что ваше ядро — один сплошной хак? Ну так никто не заставляет его юзать. И да, разгребают понемногу ошибки молодости. >> Не очень понимаю ремарку про SSE2 и Intel > а всё просто: внезапно — нет никакой причины бежать за толпой на > 64 бита, потому что операции над 64-битными целыми отлично доступны в > 32-бит режиме, с восемью отдельными регистрами для этого. деления, правда, нет, > а для умножения придётся немного заинлайнить. ок. На 32 битах SSE2 не гарантирован. Конец истории. Если гарантирован - то это x86-64 как раз и есть. С современными объемами RAM имхо нет никакого смысла экономить на спичках байты на указателях, попутно обувая себя в разы на всю скорость крипто, кодеков, фильтров изображения и проч. Все это добро давно уже юзает факт 64-битности регистра от души. Хотя для желающих странного появилось x32 ABI но большая часть людей решили что хотят адресовать ВСЮ память, а не утыкаться 2^32 - оказалось нафиг надо. Хоть так и можно было. ИМХО твое комбо - as irrational as it can get. Сложно, криво, майнтайнить надо какие-то костыли, отдельное внимание уделять, и даже так - оно профачит все и вся. Твой компилер не соберет же тебе допустим линухкернел и крипто в нем, и прочие openssl и ко - с скоростью не хуже 64 битного? И a/v кодеки - тоже. И патчить руками ВСЮ математику в системе с вон теми фортелями - ты, таки, имхо, устанешь. Поэтому скорость всего этого будет - в разы хуже. >> Зависит от. Из за куцего регистрового файла оно занимается пушпопами от души. > нет, не занимается. давай ты опять не будешь со мной спорить по > поводу компиляторов, ок? Таки - буду. Я лю смотреть на код в виде ассемблера. И в реально существующем коде x86 пушпопов - на каждый пук. Стандартный calling convention функций (ABI) там подразумевает пушпопы. Передача нескольких параметров через регистры? Не слышали. В отличе от более нормальных процов типа ARM, x86-64, RISCV и проч. Что генерит твой компилер - мне не интересно, это какой вообще % кода в системе? И оно соберет хотя-бы линухкернел? Или куда твой супер-компилер девать? > опачки. вот это новости. ты только больше никому это не говори, а > то ведь может неудобно выйти. У него PC-relative addressing нет. Поэтому для переноса в другие адреса надо перепахивать буквально половину бинаря. >> Зато нате вам супер-порно с релоками. Костыль на костыле и костылем погоняет. > ты очень удивишься, когда узнаешь, что в x86_64 релоки никуда не делись. Они много где есть. Но на x86-32 без них вообще просто шагу ступить нельзя. Потому что сам по себе этот кусок крапа не умеет в PC-relative addressing как ARM, RISCV и x86-64. Там все это - сильно проще и эффективнее. > и ничего в них страшного нет. впрочем, если тебя это так > волнует — пересобери нужные тебе библиотеки так, чтобы они не перекрывались. > или — ой — используй PIC. а, прости, я забыл: у тебя же его на x86 нет. PC-relative addressing у этой какахи никаким волшебством не отрастет, обречен умереть недоделаным уродом на костылях. "I'm not nostalgic" (c) Torvalds. > и в булочную ты на траке-тяжеловесе ездишь наверняка. ну, вдруг чего перевезти-то > понадобится? лучше брать самое большое! Я могу хотеть попробовать довольно разные вещи. Включая достаточно интенсивные по ресурсам. От транскодирования 4K видео, до жевания OSM planet data, или врубить оптимизацию LTO на _жирном_ проекте. Что так то прилично RAM требует для глобального анализа кода. Зато там видишь ли жор памяти - временно, а -25...30% кода в бинаре, без потерь скорости, а то и с выигрышем - "навсегда". >> Вот лично мне не надо - уродца с полутора регистрами > лично тебе это без разницы, потому что ты всё равно никогда в > жизни никаких практических компиляторов не писал, и рассуждаешь о том, в > чём не разбираешься. и ISA соответствующие очевидно не знаешь. Изучать ISA блевотного дино - не моя прерогатива. И "практических компиляторов" есть GCC да Clang. Ну, ладно, хруст еще - тоже LLVM, да пару JIT'ов типа V8. Это генерит львиную долю кода в типовой системе. Остальное, извините, маргинальная хрень. Я очень сомневаюсь что ты LTO обставишь. А пушпопы ты делать будешь как зайчик, ибо calling convention такой, куда ты денештся с подводной лодки то? Или ты утверждаешь что сможешь общесистемно ABI перепахать? Для этого надо иметь нехило времени и быть очень неленивым. > когда-нибудь ты узнаешь размер контекста в своём любимом x86_64. это будет шокирующая > новость. я хинтану: он *больше*, чем в 32-бит режиме. Это вместе с SSE? И к тому же SSE - насколько я помню все же не GPR и имеет ряд ограничений на использование. >> А, да, кстати о птичках. Менее идиотское ABI еще в актив запишите > опять ты гордо несёшь ерунду. А таки - возможность передать параметры в регистрах, без постоянных пушпопов в стек - штука полезная. >> Я рад за твой компилер и вообще. Только вот SSE2 гарантирован - только в 64 бит прцах. > pentium-m? pentium-4? не, не слышали, не было. У лично меня нет ни того ни другого. И билд или -march=native если для себя, или - под широкие семейства процов - если для других. Если меня заносит черт билдить для x86-32 я не собираюсь требовать от народа чтобы это всенепременно было только вот эти полтора уродца и более никак. В таких допущениях - я извините вообще заскипаю 32-бит билд. Он грубо говоря рассматривается как поддержка легаси и древностей. Для меня pentium-m и pentium-4 такие же дино как и атлоны или кто там без SSE2. >> А если мы про обрубки - то там уповать на SSE2 не комильфо. > потому что тебе это не нравится, ломает красивую картинку мира? Потому что билдить код таргетируя полтора наименования проца - иррационально и субоптимально. >> не пустой звук. Оно ж абстракцию монопольного использования проца обеспечивает. > см.выше. рыдай. Да чему мне то рыдать? У x86-32 SSE изначально не было и для упования на него - надо прокатить всех у кого его нет. Чем они хуже pentium-m и прочих pentium4 я хз. Ради только этих двух уродцев затевать 32 битный билд как по мне - вообще смысла нет, нерациональные затраты времени и сил. Если x86-32 билд - так уж поддержку максимально широкого спектра этого легаси чтобы возню оправдать. > автоматический рантайм патчинг? не, не слышали? ну, я не виноват, что ваш > гцц в такие штуки умеет очень плохо. у меня — оверхед на первый вызов, дальше full speed. 1) Зато это позволяет пометить секцию кода readonly, а принцип W^X лично я нахожу правильным. Рантайм патчинг с этой идеей клещится. И в целом секурити заметно нагибает. 2) Ну ты своей штукой и билдуй себе линух кернел или что там для тебя работает. И покажи мастеркласс майнтенанса этого. И так i++ лет. Посмотрим насколько тебя хватит. > попробуй не писать это сложнее, тормознее, хреновее и кривее. у меня получается, это возможно. У тебя оно получается - в объемах вообще не заслуживающих внимания. Ибо удачи тебе хотя-бы линух кернель собрать без этого самого GCC. А, ну вот clang есть, но он по поведению почти копипаста gcc'ы. > ну кто ж вам виноват, что вашу свалку кода на лету пересобрать > под конкретный камень — задача нереальная? Спасибо - я видел как это в .NET работает. Нафиг мне чтобы каждая первая система билдфермой становилась после апдейтов и проч? Это очень непрактично по ресурсам и времени операций. Особенно на слабых железках. >> Затем что всякий рантайм патчинг в ядре - делает это сложнее и кривее. > ты только что объявил все переменные злом. а, ну да: у вас > же там всё сложно, концепция «code as data» давно утеряна. Есть довольно большая разница между переменными и кодом, man W^X. Мне этот принцип нравится. > если закрыть глаза и отвернуться разве что. Ну как, регистровый файл и abi более адекватные, pc-relative addressing есть, ворочает в 2 раза больше за такт, SSE2 - именно гарантированный, таргетируя x86-64 даже самых лохматых диалектов можно уповать на SSE2 там. Ессно все равно дурное наследие икается, но с всякими итаниками - фэйл вышел, оверинженерия и оверпрайс штука такая. >> Но в конечном итоге ояд вещей до сектора не округляется. > например? Например тот же размер файла. > давеча SHA512 сделал, понадобилось. никаких проблем. вышло в два раза быстрее, чем > у `gcc -O3 -march=native -mtune=native`. без ручных оптимизаций, код один и > тот же. ну, плохо ваш гцц с 64 битами в 32-бит режиме работает. > это личные проблемы гцц и тех, кто использует этот хлам. Теперь повтори это с линухкернелом, openssl и прочим. Удачи в этом начинании. >> Крипто все тоже на 64 бита давно оптимизировано. > вот как раз и смотри про SHA512 выше, лол. Вот конкретно SHA-512 я вообще не знаю где массово применяется. А так где ты такой умный был в эпоху cpu mining? Показал бы этим неумехам мастеркласс с SHA-256? :))
	Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

	201. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от arisu (ok), 25-Дек-24, 06:14
	>> надо же: сначала ты заявил, что в 32-бит режиме невозможно сделать 64-бит > Это где я такое сказал? O_O. прямо в сообщении #163. как ещё можно понять твоё удивление тем, что же я без таких чисел делать буду? никак иначе, чем: «на 32-битных архитектурах 64-битные числа обрабатывать нельзя!» это удивление не трактуется. > На 32 битах SSE2 не гарантирован. Конец истории. ой. простите, мистер фукуяма, не узнал вас без логина. кстати SHA512 без SSE (а мой компилятор умеет и так) медленнее… вот тут сделаю драматическую паузу… держим паузу… держим… примерно на процент. чуть меньше, может быть. > попутно обувая себя в разы на всю скорость крипто ну, см. мои рассуждения про SHA512 таки. Keccak — одни из немногих криптостойких примитивов, который натурально ложится на 64 бита. и там нет абсолютно ничего кроме побитовых операций. которые довольно плохо оптимизируются без специально разработаного железа, потому что последующие операции используют результаты предыдущих. так что хоть миллиард битов одновременно обрабатывай — толку не будет. ты снова рассуждаешь о вещах, в которых не разбираешься? > кодеков ты же в курсе, что там в основном floating point? > фильтров изображения ты же в курсе, что вне SSE нет даже простейшей операции FMAD, или сложения/вычитания с сатурацией, и никакие 64 бита в обычных регистрах тут не помогают? > проч. Все это добро давно уже юзает факт 64-битности регистра от > души. 128 и выше. вот только это SSE/AVX регистры, а не регистры основного набора инструкций. > но большая часть людей решили что хотят адресовать ВСЮ память апелляцию к большинству я каждый раз люблю как в первый. > ИМХО твое комбо - as irrational as it can get. с моей стороны: пояснения, что раздутые в два раза указатели, и немного более раздутый код как минимум быстрее засоряют кэши процессора. примеры из жизни, где 32-бит код был быстрее. пояснения на пальцах почему 32 битов вполне достаточно для большинства применений. с твоей: «а я хочу адресовать больше 4гб!» иррационально при этом у меня. > Твой компилер не соберет же тебе допустим линухкернел конечно, нет: он вообще ни одной строчки си-кода собрать не сможет. > и крипто в нем, и прочие openssl и ко > - с скоростью не хуже 64 битного? ладно, я не буду придираться к тому, что ты сейчас поинтересовался *скоростью* *компиляции*. замечу только, что большинство обычных задач всё ещё i/o bound, это раз. и я неоднократно писал, что для разных применений нужны разные инструменты. это два. > И a/v кодеки - тоже. не знаю, музыка играет. mpeg2 тоже может. где-то на этом месте мне надоело. кстати, если ты заглянешь в исходники ffmpeg, то с удивлением узнаешь, что сишечка тоже не очень может: там немало ассемблерного кода. а неассемблерный на sse-интринсиках, которые… ой… работают с float'ами, и никак не используют Мощные 64 Бита Регистров Основного Набора. > И патчить руками ВСЮ математику в системе с вон теми > фортелями - ты, таки, имхо, устанешь. а зачем мне руками-то? O_O >>> Зависит от. Из за куцего регистрового файла оно занимается пушпопами от души. >> нет, не занимается. давай ты опять не будешь со мной спорить по >> поводу компиляторов, ок? > Таки - буду. Я лю смотреть на код в виде ассемблера. И > в реально существующем коде x86 пушпопов - на каждый пук. Стандартный > calling convention функций (ABI) там подразумевает пушпопы. тебя прикалывает позориться, что ли? тот же gcc сломал x86 ABI, требуя выравнивание стека на 16 байт. вследствие чего для любой функции сложнее парустрочника с одним вызовом выделяет стековый фрэйм на входе, и никаких пашпопов в коде нет. исключение — вызовы vararg-функций. которые — внизапна! — в столь любимом тобой x86_64 ABI (а ты в курсе, что этих аби не одна штука, кстати?) тоже обязаны передавать параметры через стек, и нагадят тебе ненавистными пашпопами. я продолжаю не понимать, зачем ты с увереным видом несёшь ерунду в областях, в которых совершенно не разбираешься. > Передача нескольких параметров через регистры? fastcall? не, не слышали. внутренние функции не обязаны соблюдать ABI, сдизайненый *исключительно* для внешних вызовов? не, не слышали. ты, кстати, в курсе, что столь любимые тобой риски/x86_64 с кучей регистров довольно часто имеют ABI, одним из требований которого является резервирование стекового фрейма определённого размера для аргументов *вызывающей* *стороной*? настолько стек не нужен, что даже в ABI зачем-то предусмотрели его резервирование на *каждый* ABI-conformant call. > Что генерит твой компилер - мне не интересно конено, тебе неинтересно. как только ты начинаешь «плавать» в теме (или вовсе нести ерунду) — тебе сразу становится неинтересно. типовой план большинства дискуссий с тобой выглядит таким образом: оппонент: XYZ технически плохо/излишне. ты: а я хочу! и вот это хочу, и вот то! оппонент: вот это делается без проблем, вот то нужно довольно редко и нет смысла навязывать его всем. вот куча примеров. а вот тут ты вообще не понял, о чём говоришь. ты: а мне неинтересно! все делают не так! >> опачки. вот это новости. ты только больше никому это не говори, а >> то ведь может неудобно выйти. > У него PC-relative addressing нет. Поэтому для переноса в другие адреса надо > перепахивать буквально половину бинаря. ты таки твёрдо решил опозориться? ну ладно, не смею мешать тогда. >> ты очень удивишься, когда узнаешь, что в x86_64 релоки никуда не делись. > Они много где есть. Но на x86-32 без них вообще просто шагу > ступить нельзя. в x86_64 тоже. > не умеет в PC-relative addressing как ARM, RISCV и x86-64. Там все > это - сильно проще и эффективнее. в кои-то веки ты сказал минорную вещь верно. и то не полностью: с самого начала x86 умел в PC-relative для call и jmp. так что умеет, но ограничено. зато, например, ARM не умеет загрузить в регистр 32-битный immediate, и за ним надо или лазить в память, или генерировать загрузку по кусочкам. > PC-relative addressing у этой какахи никаким волшебством не отрастет а других методов ты не знаешь, поэтому их не существует. > "I'm not nostalgic" (c) Torvalds. так, для информации: я не считаю торвальдса авторитетом. > Я могу хотеть попробовать довольно разные вещи. я так понимаю, у тебя все машины — минимум 128-ядерные станции минимум с 512гб памяти и кучей специализированых сопроцессоров. а до вдруг ты захочешь попробовать довольно странную вещь. > или врубить оптимизацию LTO на _жирном_ проекте. Что так то прилично RAM требует > для глобального анализа кода. и даёт на выходе от силы несколько процентов ускорения в микробенчмарках. очередная перехайпованая ерунда. > Зато там видишь ли жор памяти - > временно, а -25...30% кода в бинаре, без потерь скорости, а то > и с выигрышем - "навсегда". не, не навсегда. только пока интель или амд новый камень не сделают, где окажется, что фьюзинг работает иначе, раскладка по уопсам другая, и можно было особо не потеть — всё равно пересобирать. но тут ты скажешь, что неважно, в этом случае suboptimal performance вдруг станет нормальной вещью. > Изучать ISA блевотного дино - не моя прерогатива. удивительное дело: знать ISA ты не хочешь, зато рассуждать о них как будто ты их знаешь — это завсегда пожалуйста. > И "практических компиляторов" есть GCC да Clang. проблема ограниченности твоего пузыря — это исключительно твоя личная проблема. > Я очень сомневаюсь что ты LTO обставишь. да запросто. вопрос только в том, кто пишет микробенчмарки. > А пушпопы ты делать будешь как зайчик, ибо calling convention > такой, куда ты денештся с подводной лодки то? будь любезен, поясни, зачем мне соблюдать системный ABI в каких-то местах кроме вызовов внешних библиотек. если твой код состоит в основном из таких вызовов… ну, тогда я не понимаю, какой смысл мучаться с сишечкой, когда скриптовые языки с таким справляются намного лучше, и использовать их удобней. >> когда-нибудь ты узнаешь размер контекста в своём любимом x86_64. это будет шокирующая >> новость. я хинтану: он *больше*, чем в 32-бит режиме. > Это вместе с SSE? а у тебя операционки не сохраняют некоторую часть регистров CPU, что ли? хорошие операционки, дайте десяток. > И к тому же SSE - насколько я > помню все же не GPR и имеет ряд ограничений на использование. и что? какое это отношение имеет к размеру контекста? а понятие GPR в x86 вообще довольно размазано: даже базовый регистровый набор не ортогональный. кстати, SSE/AVX команды намного более ортогональные. >>> А, да, кстати о птичках. Менее идиотское ABI еще в актив запишите >> опять ты гордо несёшь ерунду. > А таки - возможность передать параметры в регистрах, без постоянных пушпопов в > стек - штука полезная. именно поэтому мой компилятор её активно использует. на 32 битах. ой. >>> Я рад за твой компилер и вообще. Только вот SSE2 гарантирован - только в 64 бит прцах. >> pentium-m? pentium-4? не, не слышали, не было. > У лично меня нет ни того ни другого. скажи (мне чисто из любопытства): почему когда ты сказал чушь, тебя на этой чуши поймали — ты сразу начинаешь юлить, но никогда — кажется, вообще никогда — не признавал, что просто ошибся и сказал ерунду? какое отношение к утверждению «SSE2 гарантирован - только в 64 бит прцах» имеет то, есть ли у тебя CPU определённых моделей? или ты сейчас начнёшь ретконить, утверждая, что оппонент обязан был протелепатировать дополнительные условия твоего утверждения? >>> А если мы про обрубки - то там уповать на SSE2 не комильфо. >> потому что тебе это не нравится, ломает красивую картинку мира? > Потому что билдить код таргетируя полтора наименования проца - иррационально и субоптимально. это опять твои личные проблемы, не имеющие отношения к изначальным утверждениям. а мне вот всё равно, у меня компилятор может сохранить IR-код, и потом спеть по нему машинный, обследовав имеющийся CPU. ну, и закэшировать его, например. ну кто ж тебе виноват, что у тебя тормозной тулчейн без удобных фич? > Да чему мне то рыдать? У x86-32 SSE изначально не было и > для упования на него - надо прокатить всех у кого его > нет. о. забота о пользователях древнего железа прорезалась. прокатить их же, нагенерив 64-бит-онли — это нормально, вы не понимаете, это другое. > Если x86-32 > билд - так уж поддержку максимально широкого спектра этого легаси чтобы > возню оправдать. это опять твои личные заморочки, которые приводят к твоим личным проблемам. поддерживай. тут у тебя куда-то желание СуперОптимизировать куда-то делось, правда, но я к подобным махинациям уже почти привык. >> автоматический рантайм патчинг? не, не слышали? ну, я не виноват, что ваш >> гцц в такие штуки умеет очень плохо. у меня — оверхед на первый вызов, дальше full speed. > 1) Зато это позволяет пометить секцию кода readonly, а принцип W^X лично > я нахожу правильным. Рантайм патчинг с этой идеей клещится. И в > целом секурити заметно нагибает. бедные житеры. оно, правда, никто не мешает поменять права доступа, пропатчить, и поменять обратно. всё равно пометка страниц защищает не от rogue code, а от случайных ошибок, когда каша на сишечке сошла с ума и начала вслепую стрелять по невалидным указателям. > 2) Ну ты своей штукой и билдуй себе линух кернел или что > там для тебя работает. И покажи мастеркласс майнтенанса этого. И так > i++ лет. Посмотрим насколько тебя хватит. да без проблем: я уже говорил, что ты оплачиваешь свою хотелку — я делаю. если оплата устроит. хочешь, чтобы я показал, как сопровождать вашего монстра, который мне совершенно в этом плане неинтересен — плати соответствующую сумму. >> попробуй не писать это сложнее, тормознее, хреновее и кривее. у меня получается, это возможно. > У тебя оно получается - в объемах вообще не заслуживающих внимания. а, я понял. все, не страдающие гигантоманией, внимания не стоят. а попробуй покрутить в голове такую мысль: я не страдаю гигантоманией как раз потому, что умею лучше. > удачи тебе хотя-бы линух кернель собрать без этого самого GCC. ну, TCC собирал в своё время. нормально работало. я, конечно, могу такой же финт соорудить — надо парзер сишечки сделать только. но зачем? и фронтэнд от libFIRM, например, может. ему, кажется, надо встроеный асм только подпилить. если бы меня интересовали компиляторы именно сишечки — то и собирал бы своим компилятором сишечки. это совершенно не ракетная наука. >> ну кто ж вам виноват, что вашу свалку кода на лету пересобрать >> под конкретный камень — задача нереальная? > Спасибо - я видел как это в .NET работает. а я видел, как это у меня работает. меня устраивает. кто ж тебе виноват, что ты постоянно смотришь на переусложнённые решения? что характерно: они тебе не нравятся. > Есть довольно большая разница между переменными и кодом, man W^X. Мне этот > принцип нравится. конечно: когда используется плохой язык — приходится отсекать фичи и навешивать дополнительные решётки. а потом заявлять, что в смирительной рубашке даже лучше, удобней, и вообще это писк моды. старательно забывая о том, что вся современная ойти построена на концепции «code as data». >>> Но в конечном итоге ояд вещей до сектора не округляется. >> например? > Например тот же размер файла. отлично. и что? это так важно, что весь код драйвера FS из-за этого… что? >> давеча SHA512 сделал, понадобилось. никаких проблем. вышло в два раза быстрее, чем >> у `gcc -O3 -march=native -mtune=native`. без ручных оптимизаций, код один и >> тот же. ну, плохо ваш гцц с 64 битами в 32-бит режиме работает. >> это личные проблемы гцц и тех, кто использует этот хлам. > Теперь повтори это с линухкернелом, openssl и прочим. Удачи в этом начинании. без проблем. какая оплата? >>> Крипто все тоже на 64 бита давно оптимизировано. >> вот как раз и смотри про SHA512 выше, лол. > Вот конкретно SHA-512 я вообще не знаю где массово применяется. а-а-а-а-а-а-а-а-а-а!!! прости, но как не орать? окей, буду считать, что это ты так пошутил. > где ты такой умный был в эпоху cpu mining? учился. теперь вот научился. тогда не умел. так бывает.
	Ответить | Правка | К родителю #198 | Наверх | 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ообщить модератору

	199. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 25-Дек-24, 03:14
	> а я в 32-бит режиме могу как минимум в четыре раза больше битов. и что? То что в SSE оно обладает кучей особенностей которых у GPR нет. И на x86-64 это не просто можно - но и как раз там гарантировано. А билдить 32 бит код - спецом под полтора уродца - обломав всех остальных - не понимаю какой пойнт этой активности вообще. Это типа билда -march=native для вот именно себя? Я для себя не юзаю никакие "pentium4" и "pentium-m", ктулху меня упаси такое юзать. > pc-relative — так я сообщаю. из столь ненавидимых тобой фиксапов конкретно > кода — только доступ к глобалам. Немножечко беременна, ага. > в нормальном коде это весьма редкая ситуация. надо будет как-нибудь ради > интереса опять сделать статистику, она довольно забавная получается. Не очень понимаю как можно быть "немножечко" беременной. Архитектура или поддерживает режимы адресации нужные для position independent, или нет. И если нет - это сразу полкило фееричных костылей на ровном месте. >> 3) Более адекватный регистровый файл и ABI. Нет, куча пушпопов по причине >> куцести регистрового файла - этими не является. > зачем ты используешь такие плохие компиляторы? Пересобирать своим мегакомпилятором ВООБЩЕ СОВСЕМ ВСЕ в мои планы - не входит, я не настолько донкихот, извини. И сейчас, на закате этой архитектуры, радикаьлно менять ABI - несомненно самое время. А ты можешь показать мне билд хотя-бы кернела и всех либ твоей ос в таком виде. > ура, теперь мы можем загадить мусором больше 4гб за раз! Ога. Тем более что там было менее 4 гигов с одной стороны, а mmaped файлы например - порой довольно удобная абстракция. И налетать на лимит в стиле "FAT32" - ну вот не, "I'm not nostalgic". Де факто у меня 32 бита это одноплатники и МК. Им простительно. И то первое уже 64 битное становится. > она умеет копировать большими блоками, а не по байту. мощная и > удобная штука. вот только startup time у неё такой, что простой > ручной цикл успевает за время стартапа перекинуть байт 16 уже, а > то и больше. надо ли пихать эту — без иронии — > мощную инструкцию (технически это одна инструкция) в любых копированиях? Очевидно это зависит от объемов задач. И как показала практика я вполне могу озадачить мощную конфигу вещами которые считаю полезными себе или окружающим. > …я могу без раздувания указателей. кстати, средний размер инструкций в x86_64 тоже > больше, чем в x86. Я рад, но можешь ты это все - где-то там. В каком-то нафиг никому не нужном софте. И вот какое мне дело до всего этого? Кернель, либы и кодогенераторы компилеров которые генерят код, без которого ты даже на форум пискнуть не сможешь - будут вон так. А донкихотство и рассказы сколько мне оперативы можно юзать - прекрасно, конечно, но... >> И что-что а вот производительности там много не бывает. > вот только это имеет мало отношения к битности, и много — к прямым рукам и хорошим алгоритмам. Это частично правда, но таки - удачи тебе с вон тем крипто, кодеками и проч. Посмотрим сколько из этого ты сможешь переписать/перекомпилять/whatever, ага? :) И главное - весь этот гимор, извините, "чтобы что"? :)
	Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

	202. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от arisu (ok), 25-Дек-24, 06:39
	>> а я в 32-бит режиме могу как минимум в четыре раза больше битов. и что? > То что в SSE оно обладает кучей особенностей которых у GPR нет. да. например, у ESI/EDI нельзя использовать младшие части регистров как восьмибитные. у SSE/AVX регистров таких ограничений нет — там все регистры равноправны. или вот работа с памятью через EBP автоматически делает префикс SS. > И на x86-64 это не просто можно - но и как > раз там гарантировано. там у нас есть операции сложения/вычитания с сатурацией хотя бы? или хоть min/max? > А билдить 32 бит код - спецом под полтора уродца - обломав > всех остальных - не понимаю какой пойнт этой активности вообще. ну, не все же используют проприетарный софт. > Не очень понимаю как можно быть "немножечко" беременной. Архитектура или поддерживает режимы > адресации нужные для position independent, или нет. И если нет - > это сразу полкило фееричных костылей на ровном месте. а загрузи-ка мне 64-битный immediate в регистр, а? ну, частая же операция, нет? ой, а она, оказывается, костыльная! ой, а полную 64-бит адресацию можно только с аккумулятором! костыли-костылики! но это, конечно, всё ненужно, так что на такие костыли мы обращать внимания не будем. ой, а у нас ведь даже 64-битного смещения в call нет, только индиректом через регистр! ну и ладно, ну и не надо. зато сразу понятно, зачем столько регистров: заканчиваются с адовой скоростью. > А ты можешь показать > мне билд хотя-бы кернела и всех либ твоей ос в таком > виде. могу. даже с gcc. сколько платишь? > Очевидно это зависит от объемов задач. ура! ты опять высказал рациональную мысль. попробуй её развить. >> …я могу без раздувания указателей. кстати, средний размер инструкций в x86_64 тоже >> больше, чем в x86. > Я рад, но можешь ты это все - где-то там. В каком-то > нафиг никому не нужном софте. И вот какое мне дело до > всего этого? «я не видел — значит, не существует, и тем более не нужно», номер-у-меня-переполнился-счётчик. надо было 64-битный счётчик заводить. > Кернель, либы и кодогенераторы компилеров которые генерят код, без > которого ты даже на форум пискнуть не сможешь ой, точно не смогу? > Это частично правда, но таки - удачи тебе с вон тем крипто, > кодеками и проч. а на это я в другом сообщении ответил, копипастить не стану. > И главное - весь этот гимор, извините, "чтобы что"? :) ну, например, чтобы не переустанавливать систему, которая у меня с 2009-го года отлично работает. да, там очень много самосбора. если ты считаешь аргументы типа «а у меня» весомыми — то вот тебе очень весомый аргумент. или это «у тебя» весомо, а «у других» — так, ерунда?
	Ответить | Правка | К родителю #199 | Наверх | 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ообщить модератору

	200. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от Аноним (-), 25-Дек-24, 03:34
	> ты описываешь, как очень нужно DSP, просто жить без него никак — > и тут же рассказываешь, как не нужно, и жить нормально. а > можно, мы будем беседовать без подобных шизофренических тэйков? я тоже в > подобное умею, но мы же не триьбют монтипайтонам делаем? В именно степперах - DSP по сей день весьма опциональное развлечение, и имеет какой-то смысл только если железо его более-менее нормально поддерживает. Т.е. если сильно заморочиться - можно сделать микрошаги и проч - и крутить ЭТО примерно как и другие моторы, где вон то делают. Это имет некие плюсы: выше разрешение, тише работает. Но. Это заметно все усложняет. И если кто ставит степпер, возможно - он хотел таки - "гарантированными" шагами фигачить с минимумом заморочек, и уповать на позицию этого всего без feedback. Но грань на самом деле достаточно размытая. Т.е. какой-нибудь синхронный 3-фазный BLDC от этого не так уж и отличается. И поэтому сие иногда ставят "сервомотором". А в целом вон то разводят когда хотят чтобы тихо работало, в том числе на мелких оборотах, как раз без явных "шагов", с управлением моментом и оборотами. Степеры просто редко юзают под вот именно такие хотелки, изначально они совсем не это. Хотя при сильном желании и они становятся чем-то наподобие, ибо у большей части моторов есть кое-что общее. В продвинутых станках - так например крутилку шпинделя могут сделать. И, конечно, оно сможет изобразить сильно больше чем вон то - с 256 байтами на все. Весьма ювелирно крутя шпиндель, на самых разных оборотах, вплоть до стабильного момента на мизерных оборотах.
	Ответить | Правка | Наверх | Cообщить модератору

	203. "KVM: регрессии производительности и обсуждение поддержки..."	+/–
	Сообщение от arisu (ok), 25-Дек-24, 06:44
	зачем ты тогда описывал задачи с 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-..."	+/–
	Сообщение от Аноним (198), 18-Дек-24, 18:51
	> Вопрос: а зачем на 64-битных армах KVM? Разве там есть аппаратная виртуализация? Поздравляю с отпуском ручника. Аппаратная виртуализация у ARM была еще в ARMv7 32 битном - поэтому для них даже был KVM. Но его все же пару лет назад задропали, ибо юзать на относительно хилых железках с скромной RAM виртуалки - странная идея и так никто не делал. А уж ARMv8 с и подавно с виртуализацией. Представляете, у x86 нет монополии на прогресс. И RISCV идеи соьезьянил, что они, рыжие?!
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

	181. "KVM: регрессии производительности и обсуждение поддержки 32-..."	+1 +/–
	Сообщение от nilsys (?), 19-Дек-24, 18:04
	да, аппаратная да, даже на телефонах. см. android virtualization framework это только на опеннете ни у кого ничего никогда нет
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

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

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