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

Выпуск CRIU 1.0, системы для заморозки и восстановления сост..., opennews (ok), 25-Ноя-13, (0) [смотреть все] А кто может подсказать, как происходить переброс TСP соединения , Dcow (ok), 21:47 , 25-Ноя-13, (1) –1 // Надо полагать, вместе с сетевым стеком контейнера, включая IP-адрес , Аноним (-), 21:57 , 25-Ноя-13, (2) http www opennet ru opennews art shtml num 34387 Релиз ядра Linux 3 5Поддержк, Аноним (-), 21:59 , 25-Ноя-13, (3) +4 // IP тот же остается или можно поменять на другой , Аноним (-), 15:40 , 26-Ноя-13, (48) // По всей видимости, тот же Он привязан к виртуальному стеку контейнера netns и, Аноним (-), 17:24 , 26-Ноя-13, (53) Ну вот так - Траффик заворачивается на другую железяку - Ядру хинтят состояние , Аноним (-), 22:12 , 25-Ноя-13, (8) // Узнаю нашего старого доброго user294 - ни слова по делу, зато рунглиш из всех ще, Аноним (-), 15:00 , 26-Ноя-13, (42) –3 кого-то таки достал полурабочий cryopid похвально и вообще, давно хочу такую ш, arisu (ok), 22:00 , 25-Ноя-13, (4) –1 Надо ещё на systemd-logind протестировать его , Аноним (-), 22:01 , 25-Ноя-13, (5) –1 // зачем поцтеринг вам напишет свою реализацию кривую, косую, хреново документиро, arisu (ok), 22:06 , 25-Ноя-13, (6) –4 // Кажется, этот онаним хотел сказать, чем можно заменить засуспенживание винлогона, Аноним (-), 23:23 , 25-Ноя-13, (13) // а-а-а тогда да, одобряю , arisu (ok), 23:39 , 25-Ноя-13, (14) –2 Так SIGSTOP же есть Стопаешь, значит, systemd-logind, и все появившиеся после э, Аноним (-), 14:55 , 26-Ноя-13, (39) Еще можно нажать Alt SysRq B и потом придти скандалить в LKML ваш линyпс убил в, Аноним (-), 15:07 , 26-Ноя-13, (45) кривые только руки твои, сачок коль не осилил, так на себя пенять надо, 1 (??), 08:15 , 26-Ноя-13, (27) +3 // вангую пердеж в лужу про ненужность, user296-стайл, ариса, фас, 1 (??), 08:17 , 26-Ноя-13, (28) Вообще-то 294-й достаточно нормально относится к идее чего-то типа systemd По к, Аноним (-), 17:25 , 26-Ноя-13, (54) Впервые вижу человека, которому пришлось по вкусу пoделие, молча игнорирующее ко, Аноним (-), 17:43 , 26-Ноя-13, (61) Ну я как бы не возражаю что оно должно бы чертыхнуться куда-нибудь в лог Багу с, Аноним (-), 20:52 , 27-Ноя-13, (97) Такие, как он, всегда видят корень своих проблем в окружающих И просто неспособ, Аноним (-), 14:56 , 26-Ноя-13, (40) +1 Скорее наоборот, это в systemd будут тестировать фичи CRIU , Аноним (-), 15:02 , 26-Ноя-13, (43) –1 Даже на офсайте сходу не удалось понять, с какой версии ядра все необходимое в с, Vee Nee (?), 22:10 , 25-Ноя-13, (7) +1 // 3 11, в которое включили https git kernel org cgit linux kernel git torvalds l, Аноним (-), 22:29 , 25-Ноя-13, (9) +1 // это необязательная фича, вообще-то p s насколько я понял из текста на офсайте, , arisu (ok), 22:32 , 25-Ноя-13, (11) судя как раз по офсайту 8212 с 3 10 должно работать проверить, правда, не мо, arisu (ok), 22:31 , 25-Ноя-13, (10) тьфу, распронаедрит налево пересобирал ядро, перезагружался 8212 а эта беспо, arisu (ok), 23:17 , 25-Ноя-13, (12) –8 // профиксил, Аноним (-), 00:20 , 26-Ноя-13, (15) +9 // херово и неверно , arisu (ok), 00:36 , 26-Ноя-13, (17) –4 // Все правильно он починил Ни замшелое гoвно, ни его адепты в этом мире никому не, Аноним (-), 14:58 , 26-Ноя-13, (41) –1 а обосновать сможешь , Аноним (-), 20:24 , 26-Ноя-13, (67) тысячу тысяч раз уже говорено , arisu (ok), 00:57 , 27-Ноя-13, (78) все правильно Устаревшие архитектуры ненужны , Аноним (-), 21:31 , 26-Ноя-13, (70) +1 я согласен, x86 и x86_64 обе 8212 устарели и нафиг не нужны , arisu (ok), 00:57 , 27-Ноя-13, (77) +1 Отлично, я еще 8 лет назад перешел исключительно на 64 бита, kurokaze (ok), 01:45 , 26-Ноя-13, (18) +5 // мне очень важно было это узнать, спасибо , arisu (ok), 05:07 , 26-Ноя-13, (21) –4 // Так же, как нам - что Вам не нужно , ABATAPA (ok), 12:21 , 26-Ноя-13, (38) +1 Любка, ты чтоль , гость (?), 18:41 , 27-Ноя-13, (96) А нам очень интересно было прочитать про ваши половые трудности с 64-битными сис, Аноним (-), 15:10 , 26-Ноя-13, (47) Да уже несколько лет как большая часть x86 железа ушла на свалки Так что на 32 , Аноним (-), 15:05 , 26-Ноя-13, (44) +1 // Ну так 64-битные процессоры появились чуть ли не десятилетие назад А при соврем, Аноним (-), 17:29 , 26-Ноя-13, (55) +2 о, виндузятник пришёл это у вас в винде 32-битная икспишечка не может в больше , arisu (ok), 01:00 , 27-Ноя-13, (79) +1 ХР SP1 может адресовать до 16GB из 32 возможных в 36-битном адресном пространств, Проходимец (?), 08:50 , 27-Ноя-13, (91) –1 ссылку на то, где m его раздаёт , arisu (ok), 09:15 , 27-Ноя-13, (92) +1 Аж 294 раза По что ругаешься, Кэп форум считает данное слово бранным, что кон, Аноним (-), 21:09 , 27-Ноя-13, (98) я не ругался, я обзывался как будто я тебя не узнал 171 почто 187 про всё о, arisu (ok), 01:19 , 28-Ноя-13, (105) Нет, не издохла Вот только она касается только юзерспейса - ядро там всё равн, Led (ok), 05:08 , 28-Ноя-13, (111) у меня на него аллергия, когда оно без толку суётся в x32 я толк вижу 8212 в, arisu (ok), 05:30 , 28-Ноя-13, (112) Не совсем Там есть свои накладные расходы на невыровненные обращения к памяти , AlexAT (ok), 07:17 , 28-Ноя-13, (113) –1 точно такие же, как и у других режимов, насколько я помню , arisu (ok), 07:52 , 28-Ноя-13, (116) А зачем использовать 32-битную систему Или, может быть, у тебя L4Linux, 64-битн, Kibab (ok), 01:52 , 26-Ноя-13, (19)   // а зачем мне 64-битная система, если у меня нет софта, которому требуется больше , arisu (ok), 05:09 , 26-Ноя-13, (23) –2   // А только x86_64-ядра недостаточно нужен ещё и 64-битный юзерспейс , Led (ok), 06:02 , 26-Ноя-13, (24)   не знаю, у меня ядро 32-битное, так что проверить не могу , arisu (ok), 06:10 , 26-Ноя-13, (25)   А у тебя и пямяти меньше 4 гигз Или мсье нравятся феерические костыли типа PAE , Аноним (-), 17:30 , 26-Ноя-13, (56) +1   171 Дисковый кэш 8212 кривая хрень, которой пользуются только законченные и, Аноним (-), 17:45 , 26-Ноя-13, (62)   а какое отношение а мне без разницы, я это руками не делаю вот этого не помню н, arisu (ok), 01:02 , 27-Ноя-13, (80) +1   Ну я как бы считаю невозможность напрямую адресовать всю память системы жутким к, Аноним (-), 21:17 , 27-Ноя-13, (99)   тогда тебе исключительно в real mode потому что в protected ты вообще адресуешь, arisu (ok), 01:22 , 28-Ноя-13, (106)   Дело не в этом Дело в костылях в виде сегментов или оконной загрузки страниц Н, AlexAT (ok), 07:20 , 28-Ноя-13, (114) +1   вот ты когда свой софт на сишечке под пингвинус собираешь, это видишь нет, не в, arisu (ok), 07:54 , 28-Ноя-13, (117) –1   Я это увижу, если рискну большую инсталляцию MySQL развернуть на x86-32 Правда,, AlexAT (ok), 20:11 , 28-Ноя-13, (119) +1   это, без сомнения, рутинная домашняя задача все так делают, каждый день , arisu (ok), 02:58 , 29-Ноя-13, (121)   Задача-то не домашняя, но вот работает она каждый день И вполне себе рутинная, AlexAT (ok), 07:25 , 29-Ноя-13, (123)   я десктоп писал десктоп о десктоп несколько десктоп других десктоп обл, arisu (ok), 10:24 , 29-Ноя-13, (125)   x64 - это не только снятие лимита в 3 гигабайта Это еще набор из 8 дополнительн, AlexAT (ok), 07:40 , 26-Ноя-13, (26) +5   ощутимой разницы в быстродействии нифига нет а как там извращается компилятор п, arisu (ok), 08:26 , 26-Ноя-13, (30) +1   Достаточно добавить 64-битное ядро, Led (ok), 08:55 , 26-Ноя-13, (31)   для чего 32-битный софт остаётся 32-битным , arisu (ok), 09:03 , 26-Ноя-13, (33) +1   Например, для CRIU Да и 32-битного софта можно запустить больше , Led (ok), 10:46 , 26-Ноя-13, (36)   например, само ядро больше памяти слопает с чего бы вдруг 32-битное ядро ни раз, arisu (ok), 11:38 , 26-Ноя-13, (37)   На машинах где 64 бита имеют смысл это как правило не принципиально Плюс-минус , Аноним (-), 17:36 , 26-Ноя-13, (57) +3   Как будто это что-то плохое , Аноним (-), 17:41 , 26-Ноя-13, (59) –1   Вообще-то плохое, да На одну и ту же операцию потратится намного больше тактов , Аноним (-), 19:47 , 26-Ноя-13, (64) +3   использовать 64-битные указатели для адресации пары гигов памяти 8212 вот это, arisu (ok), 01:08 , 27-Ноя-13, (82)   Да Но я не вижу почему мне должно быть нельзя юзать всю доступную память из 1 п, Аноним (-), 21:19 , 27-Ноя-13, (100)   потому что ядро тебе не разрешит даже 64-битное 2 48 остальные биты вашего огр, arisu (ok), 01:23 , 28-Ноя-13, (107)   зато кэш процессора 8212 существенно указателей в ядре много, все указатели , arisu (ok), 01:07 , 27-Ноя-13, (81)   Кэши тоже растут, здесь прогресс определенно есть, в отличие от производительнос, AlexAT (ok), 22:01 , 27-Ноя-13, (101) +1   и поэтому надо сильней забивать их мусором честное слово у меня нет задач, гипе, arisu (ok), 01:32 , 28-Ноя-13, (108) –1   Вообще-то в режиме x86-64 и SSE-регистров поболе Даже на банальном веб-сервере , AlexAT (ok), 07:30 , 28-Ноя-13, (115) +1   ссе 8212 вовсе не панацея для всех случаев но да, возможно значит, говнокоде, arisu (ok), 08:00 , 28-Ноя-13, (118) –1   Ну какбэ вместо команд FPU GCC для float уже давно юзается SSE Да Потому что де, AlexAT (ok), 20:12 , 28-Ноя-13, (120) +1   ну десктоп , извини десктоп , я десктоп думал десктоп , что десктоп прост, arisu (ok), 03:00 , 29-Ноя-13, (122)   А в целом идея неплоха, скобочки с десктопом несколько освежают текст Стоит про, AlexAT (ok), 07:34 , 29-Ноя-13, (124) +1   лично на своём 8212 замечу резко прекратит работать весь самосборный софт в, arisu (ok), 10:26 , 29-Ноя-13, (126) –1   У современных процессоров кэши тоже большие А всякие PAE тоже прямизны в работе, Аноним (-), 00:17 , 28-Ноя-13, (103) +1   см 108 см 108, последний абзац а, то есть, гвидобейсика у меня нет, случился, arisu (ok), 01:43 , 28-Ноя-13, (109) –1   Вообще-то открытый софт нет проблем собрать под 64 бита, знаешь ли И, кстати, р, Аноним (-), 19:52 , 26-Ноя-13, (65) +1   всё бросил и побежал пересобирать весь софт, который я до этого под 32 собирал, , arisu (ok), 01:10 , 27-Ноя-13, (83) –1   У, да ты походу весьма заржавелый типец Ну да, по такой логике всем должно хвата, Аноним (-), 00:21 , 28-Ноя-13, (104)   да я очень не люблю делать что-либо только потому, что нынче это модно нет у т, arisu (ok), 01:46 , 28-Ноя-13, (110)   ну если 10 для Вас не разница , d (??), 09:17 , 26-Ноя-13, (34)   во-первых, откуда взялись эти 10 нет, похороникс и синтетические тесты не инте, arisu (ok), 09:34 , 26-Ноя-13, (35)   Оттуда что1 Нет постоянной перегрузки полутора куцых регистров 2 Сами регистр, Аноним (-), 17:40 , 26-Ноя-13, (58) +3   а почему не 146 потолки низкие, с другого потолка другие проценты бы взяли лич, arisu (ok), 01:14 , 27-Ноя-13, (84) –1   171 Скорость 8212 это не главное 187 8482 , Аноним (-), 15:08 , 26-Ноя-13, (46)   правильно не главное главное стабильность так вот разработчики сейчас а первую о, d (??), 16:06 , 26-Ноя-13, (49)   Да пофиг на что там разработчики обращают i386 8212 архитектура, 171 прове, Аноним (-), 17:18 , 26-Ноя-13, (51)   Последний i386 вышел лет 20 назад Назывался Pentium Pro , pavlinux (ok), 19:09 , 26-Ноя-13, (63)   вообще-то это i686, Аноним (-), 21:44 , 26-Ноя-13, (74) +1   Кстате sic да, как раз P-Pro и ознаменовал конец эпохи чистых i386, и перех, AlexAT (ok), 22:57 , 26-Ноя-13, (75)   Если чо, то i386 - нет такой архитектуры, есть x86 , pavlinux (ok), 00:34 , 27-Ноя-13, (76)   Под архитектурой i386 понимается конкретный набор расширенных команд i386, мод, AlexAT (ok), 07:24 , 27-Ноя-13, (90)   Это у них называется поколения, все изменения происходят внутри, без изменения A, pavlinux (ok), 15:48 , 27-Ноя-13, (94)   Это у вас оно называется поколения, а у разработчиков оно ныне называется archit, AlexAT (ok), 22:03 , 27-Ноя-13, (102)   С разморозкой i386 в новых ядрах уже убили, осталась i686 И ту скоро выпилят з, AlexAT (ok), 20:33 , 26-Ноя-13, (68) –1   Тогда используй нормальный дистрибутив с multilib и не ставь два сразу , Аноним (-), 21:40 , 26-Ноя-13, (72) +1   или только 64битное ПО, Аноним (-), 21:40 , 26-Ноя-13, (73)   если вдруг до тебя не доходит, то miltilib 8212 это и есть 171 два дистрибу, arisu (ok), 01:17 , 27-Ноя-13, (85)   игромания Теперь можно будет сохраняться в играх, в которых не предусмотрены со, EuPhobos (ok), 08:57 , 26-Ноя-13, (32) +3 // Ага, в ДОТА2 Сохранить дамп памяти, состояние сетевого стека и состояние осталь, bobr (?), 17:01 , 26-Ноя-13, (50) // Это уже нужно делать синхронизацию с аппаратными криокамерами - , Аноним (-), 17:22 , 26-Ноя-13, (52) Останется всего ничего - синхронно заморозить остальные копии у игроков и сервер, Аноним (-), 17:42 , 26-Ноя-13, (60) // А почему бы нет Причем ведь прокатит 1 Вешаем на сервер хитрый апп, раздающий, AlexAT (ok), 21:31 , 26-Ноя-13, (71) дима завалишин оргазмирует в восторге , arisu (ok), 01:20 , 27-Ноя-13, (86) Ты запусти сначала эту хрень, и уморозь хотя бы cron иль atd размечтались ту, pavlinux (ok), 05:46 , 27-Ноя-13, (88) –1 То, что вы тут пытаетесь описать ничем по эффекту не отличается от обычной паузы, bobr (?), 13:10 , 27-Ноя-13, (93) –1 А ресурсы системы память, в частности во время паузы освобождаются Нет То-то, AlexAT (ok), 18:26 , 27-Ноя-13, (95) Или возобновить работу упавшего сервера ТФ2 8230 оч жду когда можно будет поп, Аноним (-), 20:03 , 26-Ноя-13, (66) –1 А это случайно не то же самое, что пытается сделать Дмитрий Завалишин Персистен, Аноним (-), 21:10 , 26-Ноя-13, (69) –1 Они, что издеваются make GEN include config hmake 1 Вход в катало, pavlinux (ok), 05:40 , 27-Ноя-13, (87) –1 - Thunderbird criu dump -D var lib criu -t pgrep thunderbird --file-locks 0, pavlinux (ok), 06:01 , 27-Ноя-13, (89) –1 // Да с номером версии 1 0 - это они погорячились Я тоже не осилил задампить зарес, dr (??), 11:36 , 06-Дек-13, (128) Графические приложения дампить не умеем на сайте явно написано Первоочередная ц, avagin (?), 11:11 , 10-Дек-13, (129) Интересный проект , lucentcode (ok), 19:47 , 29-Ноя-13, (127) –1 1,4,5,7,12,32,69,87,89,127

Сообщения

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

	19. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Kibab (ok), 26-Ноя-13, 01:52
	А зачем использовать 32-битную систему? Или, может быть, у тебя L4Linux, 64-битной версии которого не существует? :-)
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	23. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–2 +/–
	Сообщение от arisu (ok), 26-Ноя-13, 05:09
	> А зачем использовать 32-битную систему? Или, может быть, у тебя L4Linux, 64-битной > версии которого не существует? :-) а зачем мне 64-битная система, если у меня нет софта, которому требуется больше трёх гигабайт рабочей памяти? чтобы указатели без пользы пожирнее были? а, и ещё чтобы multilib держать, а то одной копии дистрибутива мне мало?
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Led (ok), 26-Ноя-13, 06:02
	>> А зачем использовать 32-битную систему? Или, может быть, у тебя L4Linux, 64-битной >> версии которого не существует? :-) > а зачем мне 64-битная система, если у меня нет софта, которому требуется > больше трёх гигабайт рабочей памяти? чтобы указатели без пользы пожирнее были? > а, и ещё чтобы multilib держать, а то одной копии дистрибутива > мне мало? А только x86_64-ядра недостаточно? нужен ещё и 64-битный юзерспейс?
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok), 26-Ноя-13, 06:10
	> А только x86_64-ядра недостаточно? нужен ещё и 64-битный юзерспейс? не знаю, у меня ядро 32-битное, так что проверить не могу.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (-), 26-Ноя-13, 17:30
	> не знаю, у меня ядро 32-битное, так что проверить не могу. А у тебя и пямяти меньше 4 гигз? Или мсье нравятся феерические костыли типа PAE? И кстати может ли 32-битное ядро скажем дисковый кэш скажем в 8Гб сделать?
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (-), 26-Ноя-13, 17:45
	> И кстати может ли 32-битное ядро скажем дисковый кэш скажем в 8Гб сделать? «Дисковый кэш — кривая хрень, которой пользуются только законченные идиoты» ©arisu
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от arisu (ok), 27-Ноя-13, 01:02
	>> не знаю, у меня ядро 32-битное, так что проверить не могу. > А у тебя и пямяти меньше 4 гигз? а какое отношение? > Или мсье нравятся феерические костыли типа PAE? а мне без разницы, я это руками не делаю. > И кстати может ли 32-битное ядро скажем дисковый > кэш скажем в 8Гб сделать? вот этого не помню. но мне таки без разницы: у меня 4 гб памяти, и мне их хватает. я не модный-стильный-молодёжный, и не бегу докупать памяти «просто чтобы было побольше».
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	99. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (-), 27-Ноя-13, 21:17
	> а мне без разницы, я это руками не делаю. Ну я как бы считаю невозможность напрямую адресовать всю память системы жутким костылем. > вот этого не помню. но мне таки без разницы: у меня 4 > гб памяти, и мне их хватает. я не модный-стильный-молодёжный, и не > бегу докупать памяти «просто чтобы было побольше». Ну а я не против запустить пару виртуалок и загрузить все оглавление дисков в кэш. Хорошо когда I/O работает практически со скоростью RAM drive все-таки.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok), 28-Ноя-13, 01:22
	>> а мне без разницы, я это руками не делаю. > Ну я как бы считаю невозможность напрямую адресовать всю память системы жутким > костылем. тогда тебе исключительно в real mode. потому что в protected ты вообще адресуешь некую виртуальную сущность. > Ну а я не против запустить пару виртуалок и загрузить все оглавление > дисков в кэш. Хорошо когда I/O работает практически со скоростью RAM > drive все-таки. да на здоровье — я тебе запрещаю, что ли? как я уже говорил — x32 было бы хорошим вариантом. но увы — модные-молодёжные не привыкли экономить ресурсы.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от AlexAT (ok), 28-Ноя-13, 07:20
	> тогда тебе исключительно в real mode. потому что в protected ты вообще > адресуешь некую виртуальную сущность. Дело не в этом. Дело в костылях в виде сегментов или оконной загрузки страниц. На данный момент это именно костыль, поскольку основное API ОС расчитывает на линейную адресацию. В long mode, тьфу-тьфу, "виртуальную сущность" упростили именно до линейной адресации, без сегментации. Вполне себе хватает и того, что страницы можно подключать в произвольном порядке. Это, кстати, на производительности тоже сказывается.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok), 28-Ноя-13, 07:54
	> Дело не в этом. Дело в костылях в виде сегментов или оконной > загрузки страниц. вот ты когда свой софт на сишечке под пингвинус собираешь, это видишь? нет, не видишь. виртуальная память — костыль в любом случае. одним больше, одним меньше — уже без разницы.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от AlexAT (ok), 28-Ноя-13, 20:11
	> вот ты когда свой софт на сишечке под пингвинус собираешь, это видишь? > нет, не видишь. Я это увижу, если рискну большую инсталляцию MySQL развернуть на x86-32. Правда, я этого в рабочем режиме не сделаю никогда, потому что из ума еще не выжил :)
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok), 29-Ноя-13, 02:58
	> Я это увижу, если рискну большую инсталляцию MySQL развернуть на x86–32. это, без сомнения, рутинная домашняя задача. все так делают, каждый день.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от AlexAT (ok), 29-Ноя-13, 07:25
	> это, без сомнения, рутинная домашняя задача. все так делают, каждый день. Задача-то не домашняя, но вот работает она каждый день... И вполне себе рутинная, кстати :)
	Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

	125. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok), 29-Ноя-13, 10:24
	я (десктоп) писал (десктоп) о (десктоп) несколько (десктоп) других (десктоп) областях (десктоп).
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

	26. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+5 +/–
	Сообщение от AlexAT (ok), 26-Ноя-13, 07:40
	>>> а зачем мне 64-битная система, если у меня нет софта, которому требуется больше трёх гигабайт x64 - это не только снятие лимита в 3 гигабайта. Это еще набор из 8 дополнительных доступных софту РОН и регистров SSE, увеличенная ширина регистров по умолчанию и несколько прочих плюшек, типа возможности работать с оффсетами относительно RIP.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	30. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от arisu (ok), 26-Ноя-13, 08:26
	ощутимой разницы в быстродействии нифига нет. а как там извращается компилятор при создании кода — мне пофигу. вот что мне точно не надо — два установленых дистрибутива.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Led (ok), 26-Ноя-13, 08:55
	> ощутимой разницы в быстродействии нифига нет. а как там извращается компилятор при > создании кода — мне пофигу. вот что мне точно не надо > — два установленых дистрибутива. Достаточно добавить 64-битное ядро
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от arisu (ok), 26-Ноя-13, 09:03
	> Достаточно добавить 64-битное ядро для чего? 32-битный софт остаётся 32-битным.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Led (ok), 26-Ноя-13, 10:46
	>> Достаточно добавить 64-битное ядро > для чего? 32-битный софт остаётся 32-битным. Например, для CRIU. Да и "32-битного софта" можно запустить больше.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok), 26-Ноя-13, 11:38
	> Например, для CRIU. например, само ядро больше памяти слопает. > Да и «32-битного софта» можно запустить больше. с чего бы вдруг? 32-битное ядро ни разу не ограничено четырьмя гб памяти. а если в системе закончились пиды — то тут не ядро менять надо, а прокладку.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+3 +/–
	Сообщение от Аноним (-), 26-Ноя-13, 17:36
	> например, само ядро больше памяти слопает. На машинах где 64 бита имеют смысл это как правило не принципиально. Плюс-минус пара мегов RAM на машине где >=4Gb RAM не столь уж существенно. И вообще, пристрелив какую-нить дрянь на питоне или чем там еще - можно сразу в 20 раз больше памяти отыграть, если уж так хочется. Еще ядро на машинах с большой памятью больше на служебные нужды забирает. Не без причин полагая что раз памяти много то и жабой давиться себе в ущерю ни к чему. Вполне логично. А еще в 64-битном режиме 64-разрядная математика работает быстрее. А поскольку например лимит в 4 гига при работе с файлами нас не устроит - 64-битная математика нынче в каждом закоулке. И если 64-битному процу это 1 операция, на 32-битном это выливается в этажерку. А на х86 у которого регистров полторы штуки это выливается в кошмар. А в 64-битном режиме есть нормальный набор регистров и прочая и это даже уже похоже на нормальный процессор немного, а не кусок шита из ранних 80-х.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от Аноним (-), 26-Ноя-13, 17:41
	> И если 64-битному процу это 1 операция, на 32-битном это выливается в этажерку. Как будто это что-то плохое.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+3 +/–
	Сообщение от Аноним (-), 26-Ноя-13, 19:47
	> Как будто это что-то плохое. Вообще-то плохое, да. На одну и ту же операцию потратится намного больше тактов проца при прочих равных. В общем использовать обрубок оставленный чисто для совместимости при том что на том же кристалле более нормальное нечто собрано, с более нормальной системой команд - дурь несусветная.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok), 27-Ноя-13, 01:08
	использовать 64-битные указатели для адресации пары гигов памяти — вот это и есть дурь несусветная.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (-), 27-Ноя-13, 21:19
	> использовать 64-битные указатели для адресации пары гигов памяти — вот это и > есть дурь несусветная. Да. Но я не вижу почему мне должно быть нельзя юзать всю доступную память из 1 процесса, опять же. Какое-то очередное "640К хватит всем". В то что 2^64 хватит на ближайшее время - я еще готов поверить даже.
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	107. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok), 28-Ноя-13, 01:23
	> Да. Но я не вижу почему мне должно быть нельзя юзать всю > доступную память из 1 процесса, опять же. потому что ядро тебе не разрешит. даже 64-битное. > всем». В то что 2^64 хватит на ближайшее время — я > еще готов поверить даже. 2^48. остальные биты вашего огромного указателя тупо ничего не делают и копируются из 47-го.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	81. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok), 27-Ноя-13, 01:07
	> На машинах где 64 бита имеют смысл это как правило не принципиально. > Плюс-минус пара мегов RAM на машине где >=4Gb RAM не столь > уж существенно. зато кэш процессора — существенно. указателей в ядре много, все указатели в два раза больше. > И вообще, пристрелив какую-нить дрянь на питоне чтобы продать что-нибудь ненужное, надо сначала купить что-нибудь ненужное. > Еще ядро на машинах с большой памятью больше на служебные нужды забирает. почти два гигабайта ему вполне достаточно. > А еще в 64-битном режиме 64-разрядная математика работает быстрее. через libastral, ALU боги послали? > А поскольку например лимит в 4 гига при работе с файлами нас не устроит > — 64-битная математика нынче в каждом закоулке. это да, суперсложные операции сложения, вычитания и целочисленного умножения/деления — они мегатормозят. > И если 64-битному процу это 1 операция, на 32-битном это выливается …в ту же одну операцию на том же ALU. а данные для неё благодаря спекулятивке и параллельному исполнению уже давно в камне. > на х86 у которого регистров полторы штуки ну и фиг с ним. компилятор разберётся. а обращение к памяти для тасования регистров всё равно закэшировано.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	101. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от AlexAT (ok), 27-Ноя-13, 22:01
	> зато кэш процессора — существенно. указателей в ядре много, все указатели в > два раза больше. Кэши тоже растут, здесь прогресс определенно есть, в отличие от производительности самих вычислительных юнитов. По вычислениям остаётся только распараллеливание - и увеличение длины регистров - неплохой шаг. >> А еще в 64-битном режиме 64-разрядная математика работает быстрее. > через libastral, ALU боги послали? Да нет, через: а) отсутствие префиксов; б) бОльшее число явно доступных регистров; в) бОльший размер регистров - не забываем, что i?86 ядро ничего о расширенном наборе явно доступных регистров и их увеличенной длине не знает. Если уж хочется сократить объем памяти под указатели - есть x86-64/x32, хотя пользы от него кот наплакал. >> — 64-битная математика нынче в каждом закоулке. > это да, суперсложные операции сложения, вычитания и целочисленного умножения/деления > — они мегатормозят. Даже банальным strcpy/memcpy/memcmp хорошеет от наличия 16 регистров вместо 8. Большее число явно доступных регистров позволяет меньше лазить в память при вычислениях, и оперировать бОльшими блоками, что позитивно влияет на кеширование. >> И если 64-битному процу это 1 операция, на 32-битном это выливается > …в ту же одну операцию на том же ALU Ни разу. Чехарды с внутренним переименованием регистров больше, и не всегда оно оптимально в условиях конвееризации.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok), 28-Ноя-13, 01:32
	> Кэши тоже растут и поэтому надо сильней забивать их мусором! > По вычислениям остаётся только распараллеливание — и увеличение > длины регистров — неплохой шаг. честное слово: у меня нет задач, гиперсложно обсчитывающих массу целочисленых значений. а плавающим числам и вовсе плевать на целочисленые регистры, у них своя подсистема. > Если уж хочется сократить объем памяти под указатели — есть > x86–64/x32, хотя пользы от него кот наплакал. да нет его, увы. пересобирать руками всю систему и скакать по граблям я как-то не особо готов. > Даже банальным strcpy/memcpy/memcmp хорошеет от наличия 16 регистров вместо 8. да пофигу им, пофигу. не заметишь ты разницы — разве что если твоя программа два часа ничем другим не занимается, кроме как усердно копирует стомегабайтную строку. > Большее > число явно доступных регистров позволяет меньше лазить в память при вычислениях, > и оперировать бОльшими блоками, что позитивно влияет на кеширование. ровно в том случае, когда ты упорно оптимизируешь свою числодробилку руками. во всех остальных опять пофигу. а ещё я тебе скажу, что чтение/запись в небольшой регион памяти (как и происходит, когда регистров не хватает) очень дешёвое нынче. да и компилятор делает неплохую работу, чтобы это оптимизировать. >>> И если 64-битному процу это 1 операция, на 32-битном это выливается >> …в ту же одну операцию на том же ALU > Ни разу. Чехарды с внутренним переименованием регистров больше, и не всегда оно > оптимально в условиях конвееризации. и всё это по-прежнему нифига не заметно. не надо мне доказывать, что много регистров — хорошо: я это и так знаю. однако на практике разница в скорости между x86 и x86_64 на десктопе не заметна. а gcc у меня большой проект ещё и медленней собирал, зараза (подозреваю, что у него как раз немножко кончилась RAM).
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от AlexAT (ok), 28-Ноя-13, 07:30
	> честное слово: у меня нет задач, гиперсложно обсчитывающих массу целочисленых значений. > а плавающим числам и вовсе плевать на целочисленые регистры, у них > своя подсистема. Вообще-то в режиме x86-64 и SSE-регистров поболе. > да пофигу им, пофигу. не заметишь ты разницы Даже на банальном веб-сервере разница есть. Там как раз в основном программы и занимаются тем, что тасуют строки... > и всё это по-прежнему нифига не заметно. Кому как. На десктопах с аськой и браузером, наверное, действительно будет незаметно. А вот если кодированием видео заняться - тут уже разница вылезет. Когда что-то на сервере ворочается - заметно. В свое время переход с x86-32 на x86-64 дал где-то 5-7% производительности по LAMP, за данный момент не скажу - ни одного сервера с x86-32 просто не осталось, и даже x86-32 библиотек ни на одном нет. Тестировать не на чем. Из личного хобби еще был MaNGOS - тому вообще сильно похорошело (где-то на четверть упала нагрузка на CPU). MySQL (и прочие движки БД) прекрасно умеет юзать и любит более 4Гб памяти. Так что если кто-то конкретный не может задействовать фичи x86-64 - это не значит, что x86-64 не нужен. Компиляция больших проектов GCC, кстати, именно что имеет обратную разницу между x86-32 и x86-64, c 99% вероятностью из-за того, что в сумме упирается в диск. Дисковых операций тут получается (в основном из-за выравнивания мелких структур, + объем кода на x86-64 несколько больше) несколько больше, соответственно процесс идет несколько дольше. Тут, правда, ccache может спасти очень даже неплохо хоть на x86-32, хоть на x86-64.
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	118. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok), 28-Ноя-13, 08:00
	> Вообще-то в режиме x86–64 и SSE-регистров поболе. ссе — вовсе не панацея для всех случаев. но да, возможно. >> да пофигу им, пофигу. не заметишь ты разницы > Даже на банальном веб-сервере разница есть. Там как раз в основном программы > и занимаются тем, что тасуют строки… значит, говнокодеры писали. не надо в веб-серверах постоянно строки тасовать. > А вот если кодированием видео заняться — тут уже разница вылезет. я где-то писал, что ежедневно видео кодирую? это *не десктопная* задача. а я вёл речь про десктопы. ну, вот мой, например, где чаще всего запускается gcc. и нет, я пробовал: никакого мегавыигрыша переход на 64-битную систему мне не дал. > Когда что-то на сервере ворочается — заметно. мне в каждом посте после каждого слова в скобках писать «десктоп»? я *не вёл речи* про специализированные задачи изначально. ну и да, традиционно: ламп говно. очень сильно — из-за последей «п». всё остальное поскипал, потому что там после каждого слова надо было скобочки с «десктоп» вписывать.
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	120. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от AlexAT (ok), 28-Ноя-13, 20:12
	>> Вообще-то в режиме x86–64 и SSE-регистров поболе. > ссе — вовсе не панацея для всех случаев. но да, возможно. Ну какбэ вместо команд FPU GCC для float уже давно юзается SSE. >> Когда что-то на сервере ворочается — заметно. > мне в каждом посте после каждого слова в скобках писать «десктоп»? Да. Потому что десктопное применение Linux - это очень узкая ниша...
	Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

	122. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok), 29-Ноя-13, 03:00
	>>> Когда что-то на сервере ворочается — заметно. >> мне в каждом посте после каждого слова в скобках писать «десктоп»? > Да. Потому что десктопное применение Linux — это очень узкая ниша… ну (десктоп), извини (десктоп), я (десктоп) думал (десктоп), что (десктоп) простые (десктоп) вещи (десктоп) очевидны (десктоп).
	Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

	124. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от AlexAT (ok), 29-Ноя-13, 07:34
	А в целом идея неплоха, скобочки с десктопом несколько освежают текст. Стоит продолжать. Если серьезно - то на десктопе с браузером, офисным пакетом и аудиоплеером ты просто не заметишь разницы между x86-32 и x86-64. В случае видео (не важно - проигрывания, кодирования, с участием аппаратной части для (де)кодера или без) - уже косвенно заметишь эти самые 5-15% разницы, хотя бы через температуру CPU при проигрывании и время работы при кодировании. В офисном пакете - вряд ли заметишь. Но легко заметишь при обработке изображений - inner loop фильтров неплохо оптимизируются числом и жирностью регистров.
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

	126. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok), 29-Ноя-13, 10:26
	> Если серьезно - то на десктопе с браузером, офисным пакетом и аудиоплеером > ты просто не заметишь разницы между x86–32 и x86–64. лично на своём — замечу: резко прекратит работать весь самосборный софт. вот я всё бросил и побежал пересобирать кучу пакетов, да. вариант «да поставь ещё один дистрибутив, хитро замаскированый словом multilib» — не предлагать.
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	103. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (-), 28-Ноя-13, 00:17
	> два раза больше. У современных процессоров кэши тоже большие. А всякие PAE тоже прямизны в работе с памятью не добавляют. И скорость работы IIRC сажают. Ну и вообще - примеры где 32-битные системы по скорости лучше 64-битных будут? > чтобы продать что-нибудь ненyжное, надо сначала купить что-нибудь ненyжное. Я думаю что при таком зуде вполне можно что-нибудь объявить ненyжным, чтобы не засоряло память и кэши процессора :). Можно какой-нибудь bash например расстрелять за то что слишком жирный. > почти два гигабайта ему вполне достаточно. Что за 2 гигабайта? И почему именно 2? >> А еще в 64-битном режиме 64-разрядная математика работает быстрее. > через libastral, ALU боги послали? Через регистры, мля. В 32-битном режиме вывешивается жалкий обрубок от ALU, с мизером куцых 32-битных регистров. И то что в 64-битном режиме записывается как 1 регистровая операция, в 32-битном будет немеряной этажеркой с тасовкой регистров и спасибо если без пушпопов которые в сумме равны NOPам и являют собой "необходимое зло" (которое вообще не часть логики программы). > это да, суперсложные операции сложения, вычитания и целочисленного умножения/деления > — они мегатормозят. Учитывая сколько регистров у х86 уродца - там не больно пошикуешь, программа наполовину состоит из сохранения-восстановления тасуемых в процессе счета регистров. Даже просто вызов функции - пушпоп по любому. В 64-битном режиме ABI передает все через регистры, если параметров не сильно много (в большинстве функций так и есть). Так что там еще и основания для более быстрого вызова функций есть - действий меньше. > …в ту же одну операцию на том же ALU. а данные для > неё благодаря спекулятивке и параллельному исполнению уже давно в камне. Данный тезис не объясняет тот факт что 64-битные как правило программы быстрее. Не, конечно можно накапать море пипеткой, а 64-битную математику - 32-битными командами. Но вот оптимальность этого действия вызывает некоторые вопросы. > ну и фиг с ним. компилятор разберётся. а обращение к памяти для > тасования регистров всё равно закэшировано. Тем не менее, в среднем по больнице 64-битные программы как-то быстрее получаются обычно. Хотя может SSE2 еще как-то влияет.
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	109. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok), 28-Ноя-13, 01:43
	> У современных процессоров кэши тоже большие. см. #108. > примеры где 32-битные системы по скорости лучше 64-битных будут? см. #108, последний абзац. > Я думаю что при таком зуде вполне можно что-нибудь объявить ненyжным, чтобы > не засоряло память и кэши процессора :). Можно какой-нибудь bash например > расстрелять за то что слишком жирный. а, то есть, гвидобейсика у меня нет, случился облом. алгоритм слетел с нарезки и пошёл рандомно тыкать в софт. круто. >> почти два гигабайта ему вполне достаточно. > Что за 2 гигабайта? И почему именно 2? потому что это примерный объем свободной RAM в моей рабочей технике. остальное занято. > и спасибо если без пушпопов которые в сумме равны NOPам и по скорости тоже. давно уже это мегадёшево, но некоторые гики до сих пор упарываются. а если ваших 64-битных регистров не хватит (а их не хватит), то push/pop, исходя из твоей логики, ещё больше всё тормознут. гыг. > и являют собой «необходимое зло» (которое вообще не часть логики программы). прикинь: в любом машинном коде такого «необходимого зла» дофига. иначе «декомпиляция» была бы тривиальной задачей. > Учитывая сколько регистров у х86 уродца — там не больно пошикуешь, программа > наполовину состоит из сохранения-восстановления тасуемых в процессе счета регистров. в x86_64 их не намного больше. и все их надо радостно перезагружать после вызова функции (или не менее радостно терять). а поскольку вызовы функций — дело очень частое, то получается, что ваш x86_64 ВНИЗАПНА! даёт выигрыш только говнокодерам, которые пишут портянки на десять экранов без единого обращения «наружу». гыг. спасибо, в таком разрезе я об этом раньше не думал. > Так что там еще и основания для более быстрого вызова функций есть — действий меньше. давно уже никто не заморачивается fastcall'ами. как раз потому, что запись в стек и чтение стека — очень дешёвые. это раз. и два — сэкономленое на вызове в большинстве случаев сразу же компенсируется в самой функции, которая полученые регистры весело сохраняет в локальные переменные на стеке. а регистров у x86_64 не настолько много, чтобы всё было так уж красиво. > Данный тезис не объясняет тот факт что 64-битные как правило программы быстрее. настолько, что это вообще глазом не заметно. «ура, мы выиграли целых пять с половиной секунд на тестовом получасовом прогоне!» > Не, конечно можно накапать море пипеткой, а 64-битную математику — 32-битными > командами. Но вот оптимальность этого действия вызывает некоторые вопросы. необходимость тоже. умножение/деление 64 на 32 давно уже одной командой делается. в подавляющем большинстве случаев этого достаточно. > Тем не менее, в среднем по больнице 64-битные программы как-то быстрее получаются > обычно. см. выше.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (-), 26-Ноя-13, 19:52
	> 32-битный софт остаётся 32-битным. Вообще-то открытый софт нет проблем собрать под 64 бита, знаешь ли. И, кстати, разница за счет размеров указателей и префиксов команд не такая уж и большая как может показаться - как правило здорово меньше чем в 2 раза.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	83. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok), 27-Ноя-13, 01:10
	>> 32-битный софт остаётся 32-битным. > Вообще-то открытый софт нет проблем собрать под 64 бита, знаешь ли. всё бросил и побежал пересобирать весь софт, который я до этого под 32 собирал, угу. чтобы получить… а чтобы ничего в итоге не получить такого, ради чего стоило бы заниматься подобной фигнёй. > кстати, разница за счет размеров указателей и префиксов команд не такая > уж и большая как может показаться — как правило здорово меньше > чем в 2 раза. я уже писал про кэш процессора, который засирается быстрее. потому что не только указатели, но и инты часто в 64 превращают. и структуры больше занимают. а если не превращают, и продолжают использовать 32-битные инты — то тем более: нафига?
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (-), 28-Ноя-13, 00:21
	> получить такого, ради чего стоило бы заниматься подобной фигнёй. У, да ты походу весьма заржавелый типец. > только указатели, но и инты часто в 64 превращают. и структуры > больше занимают. а если не превращают, и продолжают использовать 32-битные инты > — то тем более: нафига? Ну да, по такой логике всем должно хватать 8-битных процессоров. Хотя это слишком жирно, хватит и 4-битного 4004, пожалуй. Зато сэкономим на всем чем только можно.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok), 28-Ноя-13, 01:46
	>> получить такого, ради чего стоило бы заниматься подобной фигнёй. > У, да ты походу весьма заржавелый типец. да: я очень не люблю делать что-либо только потому, что нынче это модно. > Ну да, по такой логике всем должно хватать 8-битных процессоров. нет. у тебя проблемы с логикой.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от d (??), 26-Ноя-13, 09:17
	ну если 10% для Вас не разница ...
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	35. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok), 26-Ноя-13, 09:34
	> ну если 10% для Вас не разница … во-первых, откуда взялись эти 10%? нет, похороникс и синтетические тесты не интересуют. а во-вторых (это из «во-первых» получается) я имею тебе сказать, что «узкое место» — это в большинстве случаев не процессор. и от того, что процессор будет на 10% (положим) процентов быстрее ничего не делать, пока ожидает i/o, скорость нифига не увеличится. доступно, нет?
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+3 +/–
	Сообщение от Аноним (-), 26-Ноя-13, 17:40
	> во-первых, откуда взялись эти 10%? нет, похороникс и синтетические тесты не интересуют. Оттуда что 1) Нет постоянной перегрузки полутора куцых регистров. 2) Сами регистры 64-битные и в более вменяемом количестве. > а во-вторых (это из «во-первых» получается) я имею тебе сказать, что «узкое > место» — это в большинстве случаев не процессор. А вот это уже когда как. > пока ожидает i/o Капитан намекает что оперативка - она, зараза, быстрая. При большой оперативе можно получить весьма ширный кжш. Особенно здорово в паре с SSD под системный диск. В системе все работает со скоростью выстрела из пушки. Да, наконец то я дожил до момента когда писюк может работать не хуже чем мой первый компьютер (где операционка подпертая RAM-диском ребутилась за ~пяток секунд, запускала программы с рамдиска мгновенно и прочая).
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от arisu (ok), 27-Ноя-13, 01:14
	>> во-первых, откуда взялись эти 10%? нет, похороникс и синтетические тесты не интересуют. > Оттуда что > 1) Нет постоянной перегрузки полутора куцых регистров. > 2) Сами регистры 64-битные и в более вменяемом количестве. а почему не 146%? потолки низкие, с другого потолка другие проценты бы взяли? >> а во-вторых (это из «во-первых» получается) я имею тебе сказать, что «узкое >> место» — это в большинстве случаев не процессор. > А вот это уже когда как. лично у меня именно так. >> пока ожидает i/o > Капитан намекает что оперативка — она, зараза, быстрая. При большой оперативе можно > получить весьма ширный кжш. всё бросил, побежал ставить 100500 гигов RAM. > SSD не интересует. > В системе все работает со скоростью выстрела из пушки. если запускаешь две с половиной программы, угу. так у меня не хуже, они всё равно в кэш попадают. нет, я не против SSD как такового. но у меня его нет, и покупать его я не собираюсь.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (-), 26-Ноя-13, 15:08
	> ну если 10% для Вас не разница ... «Скорость — это не главное»™
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	49. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от d (??), 26-Ноя-13, 16:06
	правильно не главное главное стабильность так вот разработчики сейчас а первую очередь обращают внимание на x64 так что он и постабильнее будет
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (-), 26-Ноя-13, 17:18
	Да пофиг на что там разработчики обращают. i386 — архитектура, «проверенная временем», а всякой новомодной фигне типа x86_64, которой еще даже 30 лет не исполнилось, место на помойке.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от pavlinux (ok), 26-Ноя-13, 19:09
	Последний i386 вышел лет 20 назад! Назывался Pentium Pro.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (-), 26-Ноя-13, 21:44
	>Последний i386 вышел лет 20 назад! Назывался Pentium Pro. вообще-то это i686
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от AlexAT (ok), 26-Ноя-13, 22:57
	>>Последний i386 вышел лет 20 назад! Назывался Pentium Pro. > вообще-то это i686 Кстате (sic!) да, как раз P-Pro и ознаменовал конец эпохи "чистых" i386, и переход на RISC с трансляцией. Хотя попытки были и до него, то ли у Cyrix, то ли у NexGen, если память не изменяет.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от pavlinux (ok), 27-Ноя-13, 00:34
	>>Последний i386 вышел лет 20 назад! Назывался Pentium Pro. > вообще-то это i686 Если чо, то i386 - нет такой архитектуры, есть x86.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	90. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от AlexAT (ok), 27-Ноя-13, 07:24
	Под "архитектурой i386" понимается конкретный набор расширенных команд i386, модель использования регистров, организацию памяти, форматы системных таблиц для CPU и т.д. Короче говоря - именно то, что и является архитектурой для софта. Между i386 и i286 произошли очень существенные изменения. В пределах "единой" архитектуры x86, угу. Далее кое-что весомое случилось между Pentium (i586) и Pentium-Pro (i686), тоже выделилось в отдельную архитектуру. Далее - случилась AMD64 (x86-64), которая тоже "типа" архитектура. И всё это - снова в пределах x86.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от pavlinux (ok), 27-Ноя-13, 15:48
	Это у них называется поколения, все изменения происходят внутри, без изменения API.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	102. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от AlexAT (ok), 27-Ноя-13, 22:03
	> Это у них называется поколения, все изменения происходят внутри, без изменения API. Это у вас оно называется поколения, а у разработчиков оно ныне называется architecture (i386, i686, AMD64).
	Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

	68. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	–1 +/–
	Сообщение от AlexAT (ok), 26-Ноя-13, 20:33
	> Да пофиг на что там разработчики обращают. i386 — архитектура, «проверенная > временем», а всякой новомодной фигне типа x86_64, которой еще даже 30 > лет не исполнилось, место на помойке. С разморозкой. i386 в новых ядрах уже убили, осталась i686. И ту скоро выпилят за ненадобностью. Мейнстрим уже давно x86-64, а для особых любителей извращений останется x86-64/x32. P.S. Скоро - это лет 10+-5.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	72. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+1 +/–
	Сообщение от Аноним (-), 26-Ноя-13, 21:40
	>мне точно не надо — два установленых дистрибутива. Тогда используй нормальный дистрибутив с multilib и не ставь два сразу.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	73. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от Аноним (-), 26-Ноя-13, 21:40
	или только 64битное ПО
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Выпуск CRIU 1.0, системы для заморозки и восстановления..."	+/–
	Сообщение от arisu (ok), 27-Ноя-13, 01:17
	>>мне точно не надо — два установленых дистрибутива. > Тогда используй нормальный дистрибутив с multilib и не ставь два сразу. если вдруг до тебя не доходит, то miltilib — это и есть «два дистрибутива».
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

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

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