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

Разработчики ядра Linux обсуждают вопрос удаления субархитек..., opennews (?), 12-Дек-18, (0) [смотреть все] О, неужто прозрели , ыфвыфв (?), 22:49 , 12-Дек-18, (1) +2 // Intel обхаживают целенаправленно и давно https wiki yoctoproject org wiki X32_, Акакжев (?), 08:44 , 13-Дек-18, (145) –1 // Ставить интел в около эмбедовку можно только от большой глупости Все как бы в , Аноним (-), 14:51 , 13-Дек-18, (241) +1 // Да не, за x86 -64, естессно в эмбедовке будущее Стоимость процов и тепловыделе, Аноним (251), 15:21 , 13-Дек-18, (251) –2 Там проблемы далеко не только в тепловыделении Но чтобы об этом знать - этим на, Аноним (262), 15:56 , 13-Дек-18, (262) +6 В том то и фишка, что все Включая Интел При этом у Интеля много фантиков, кото, Акакжев (?), 15:26 , 13-Дек-18, (252) Интел даже с своими tablet PC грезил со времен чуть не Win2000 Сейчас конец 201, Аноним (262), 15:59 , 13-Дек-18, (264) +2 А, да, туда же и скончавшийся эдисон и его нескольких родственников Те кто сдур, Аноним (262), 16:00 , 13-Дек-18, (266) +2 Ой, Вы таки слишком увлеклись технической стороной дела Если Интел подкреплял св, Акакжев (?), 07:50 , 14-Дек-18, (365) То что интел уже цатый год подряд страдает хней с околонулевым результатом Неда, Аноним (-), 15:01 , 14-Дек-18, (393) +2 У Интела под контролем почти весь рынок серверов 171 начального и среднего уро, КГБ СССР (?), 16:50 , 14-Дек-18, (412) –1 Компания Intel раскрыла финансовую отчетность за 2017 год Выручка компании соста, Акакжев (?), 19:10 , 14-Дек-18, (417) Выручка и прибыль и норма прибыли, маржа 8212 это не одно и то же Там, где, КГБ СССР (?), 19:41 , 14-Дек-18, (418) Ага, скрывается, стало быть, прибыль - Потому спонсировать сохранность x32 пр, Акакжев (?), 20:22 , 14-Дек-18, (421) Думается, что скрывать прямо и нагло 8212 нет, вряд ли Такое в США не спусти, КГБ СССР (?), 23:34 , 14-Дек-18, (431) Толстячок , Andrey Mitrofanov (?), 11:29 , 18-Дек-18, (578) Добавлю, кстати, нюанс, широко известный только в узких кругах Многие крупные к, КГБ СССР (?), 19:44 , 14-Дек-18, (419) –1 Начитался анонимов опеннета, в глазах уже рябит 8230 Разумеется, ошибка аффел, КГБ СССР (?), 19:46 , 14-Дек-18, (420) –1 Ну так речь то была про эмбедовку и тому подобные применения Там у интеля радик, Аноним (-), 12:39 , 15-Дек-18, (445) Intel давно официально забили болт на эмбеддовку , Ванёк (?), 16:56 , 19-Дек-18, (595) Отнюдь Хейтеры были с самого начала В данном случае просто опять вспомнили , Иван (??), 10:37 , 13-Дек-18, (173) // C тем же успехом я докажу, что x16 ещё эффективнее Например целочисленное вычи, pavlinux (ok), 13:28 , 13-Дек-18, (227) +1 Хейтеры или не хейтеры, но затраты на майнтенанс этой штуки есть, а реально этим, Аноним (-), 14:44 , 13-Дек-18, (239) +2 делайте lts и после неё выкидывайте, Аноним (2), 22:51 , 12-Дек-18, (2) +3 // аргументируйте, linus (?), 22:56 , 12-Дек-18, (5) +10 Ведь всем известно, что типичному приложению жизненно необходимо адресовать боле, КГБ СССР (?), 22:55 , 12-Дек-18, (4) –3 // как правило дети не наследуют таланты оотцов как правило у них они совершенно , Анонимчжан (?), 22:59 , 12-Дек-18, (6) –1 // С тем, что Америка губит таланты, я согласиться не могу Но, действительно, некот, КГБ СССР (?), 23:51 , 12-Дек-18, (36) +4 // Так папаше никто не запрещает же пойти и использовать x32, собирая под него прог, Аноним (-), 14:46 , 13-Дек-18, (240) +1 Почитал Вы преувеличили и высосали из пальца , mikhailnov (ok), 23:03 , 12-Дек-18, (7) –6 // Если то, что я прочитал в интервью не идиотизм, то что тогда идиотизм , псевдонимус (?), 03:47 , 13-Дек-18, (98) // Даже как-то по-человечески жаль стало Линуса , КГБ СССР (?), 09:09 , 13-Дек-18, (154) +1 Это скорее тебя несколько жаль В таком возрасте можно было бы и начать догадыва, Аноним (243), 15:01 , 13-Дек-18, (243) http lurkmore to Мне_вас_жальВозвращайся к пакованию эмбедовки с Али, 294-й, а, КГБ СССР (?), 15:43 , 13-Дек-18, (257) +1 Ну, блин, понимаешь, моя эмбедовка будет работать и даже ее поддержку в обозримо, Аноним (262), 16:04 , 13-Дек-18, (267) Судя по тому, что ты пишешь, к промышленной эмбедовке ты никакого отношения не и, КГБ СССР (?), 16:15 , 13-Дек-18, (270) +1 Ошибаешься Я торгую услугами по разработке и интеграции В гробу я видел пытать, Аноним (-), 16:56 , 13-Дек-18, (280) +1 А здесь на опеннете кому ты это пытаешься продать - , КГБ СССР (?), 17:37 , 13-Дек-18, (292) +1 А здесь на опеннете я ничего не пытаюсь продать Такому клиенту как ты что-то пр, Аноним (-), 15:03 , 14-Дек-18, (395) Смотря каких клиентов и для чего ты ищешь Парочке местных персонажей не мешало , КГБ СССР (?), 15:28 , 14-Дек-18, (399) –1 В идеале денежных и с интересными задачами, на которых можно прокачаться как спе, Аноним (-), 15:12 , 15-Дек-18, (450) –1 А если их при встрече окажется сильно не двое , Ванёк (?), 15:10 , 19-Дек-18, (591) Если таких, как местный борцуха с врагами из-за океана, то хоть десяток 8212 , КГБ СССР (?), 15:15 , 19-Дек-18, (592) Как обычно у непризнанных гениев то народ неправильный, то коллектив или сообщес, псевдонимус (?), 21:11 , 15-Дек-18, (471) Ну как бы сообщество на опеннете весьма специфичное И как таковое - технари Пр, Аноним (-), 18:58 , 16-Дек-18, (508) Например, если таксист повёз окольной дорогой или вовсе не туда , Ю.Т. (?), 19:11 , 16-Дек-18, (509) +1 Ну как бы куда едем, сколько стоит и за сколько времени ожидается выполнение - с, Аноним (-), 20:23 , 16-Дек-18, (510) К себе не пробовал присмотреться , псевдонимус (?), 06:25 , 17-Дек-18, (524) Продолжай утешать себя, раз обмануть не получается , псевдонимус (?), 06:28 , 17-Дек-18, (525) Возможно даже, все эти результаты позади, как и собственно эпоха кустарей-один, Ю.Т. (?), 08:41 , 17-Дек-18, (533) Писатели вредоносного по могут с тобой не согласиться Хотя и они в основном дав, псевдонимус (?), 09:13 , 17-Дек-18, (540) В любом виде деятельности всегда остаются ниши Но общее направление в любом же , Ю.Т. (?), 09:28 , 17-Дек-18, (541) Я считаю что одноплатки вообще не нужны, для мелочи есть микроконтроллеры, а для, псевдонимус (?), 10:12 , 17-Дек-18, (546) Ну это общая тенденция, чтобы без компьютера и в носу не поковырять Так уж лучш, Ю.Т. (?), 10:26 , 17-Дек-18, (547) Я думаю это попытка создать искусственный спрос У меня батхёрт от безумных домо, псевдонимус (?), 12:38 , 17-Дек-18, (555) Мне кажется, у нас на руках мало данных, чтобы делать такие прогнозы По крайней, Ю.Т. (?), 13:40 , 17-Дек-18, (558) Прибыли жидковаты по сравнению с абибас и резиновыми шлёпанцами ИМХО, не взле, псевдонимус (?), 16:28 , 17-Дек-18, (568) Данные Также всё это прекрасные зонды тут много за браузеры с зондами пережи, Ю.Т. (?), 16:45 , 17-Дек-18, (569) Я бы не переоценивал эти недотехнологии Управлять поведением умели видимо даже д, псевдонимус (?), 16:56 , 17-Дек-18, (570) Умные колонки продаются не так хорошо, как ожидалось Умное-всё-остальное, в общ, КГБ СССР (?), 13:45 , 17-Дек-18, (559) Помнишь, то же было и с планшетами, заменами ПК Люди не настолько глупы, как , псевдонимус (?), 14:42 , 17-Дек-18, (562) Людей и потребителей в них перманентно воспитывают , Ю.Т. (?), 14:51 , 17-Дек-18, (563) Как бы воспитателей самих не воспитали Как Марию-Антуанетту или кольку-кровавог, псевдонимус (?), 15:49 , 17-Дек-18, (566) Поразило полное отсутствие цели борюсь за разнообразие - А зачем А чтобы было, псевдонимус (?), 20:38 , 15-Дек-18, (466) Могу сказать я Когда окружение разнообразное, в нем представлено больше разных , Аноним (-), 20:48 , 16-Дек-18, (511) Это делается не ради толерантности, а ради создания естественного отбора В чём , Аноним (514), 21:55 , 16-Дек-18, (514) Это зависит от черномазости, белозадости или половых перверсий Да вы расист, ба, псевдонимус (?), 06:50 , 17-Дек-18, (527) Если не ясно, в чём дело, то дело в деньгах Народная польская пословица Ну ч, Ю.Т. (?), 08:47 , 17-Дек-18, (535) Но это же скучно, разве нет , псевдонимус (?), 08:49 , 17-Дек-18, (536) Думаю, им тяжело работать скучно , Ю.Т. (?), 09:03 , 17-Дек-18, (539) Похоже им вообще работать скучно Неохипаны Сметёт жизнь людей, называющих себ, псевдонимус (?), 09:34 , 17-Дек-18, (542) Новые появятся , Ю.Т. (?), 09:48 , 17-Дек-18, (544) Как появятся, так и уйдут Кто сейчас помнит т н стиляг А почему не помнят По, псевдонимус (?), 12:17 , 17-Дек-18, (554) Прежних дармоедов помнят современные Иногда даже снимают о них лестное кино , Ю.Т. (?), 13:37 , 17-Дек-18, (557) +1 Ты про сейчас уже давнее УГ Стиляги Так снимали они сами или их дети, причё, псевдонимус (?), 16:02 , 17-Дек-18, (567) Ты ничего не понимаешь в жизни, чувак У Project Manager а несколько иное видени, Аноним (-), 15:00 , 13-Дек-18, (242) Зачем сразу матом , псевдонимус (?), 20:29 , 13-Дек-18, (333) +1 Ну вот поскольку для тебя это мат - твое айти и находится в состоянии насколько, Аноним (-), 15:06 , 14-Дек-18, (396) Зато, с другой стороны, усилиями таких прогрессоров, как ты, скоро останется 1 , КГБ СССР (?), 15:33 , 14-Дек-18, (400) +1 Я себя одноклеточным не считаю, однако некоторые мои цели, интересы и задачи, вн, Аноним (-), 15:19 , 15-Дек-18, (451) Это не карман, снова ты карман со своим задом перепутал То, что ты его ешь было , псевдонимус (?), 19:25 , 15-Дек-18, (461) Какой-то непредусмотрительный тип попался С запахом адресату будет доходчивее, , Аноним (464), 20:24 , 15-Дек-18, (464) Ты их решаешь на минутку, а создаёшь на час Они появились, как и знаменитый агил, псевдонимус (?), 21:01 , 15-Дек-18, (470) А вот тут уже клиент решает Если по его мнению это так - мы не находим общий яз, Аноним (512), 20:55 , 16-Дек-18, (512) Психология не творца, но мелкого барыги проявилась ещё ярче Клиент может быть не, псевдонимус (?), 07:14 , 17-Дек-18, (528) То есть кроме пустого балабольства тебе сказать совершенно нечего ОК, благодари, КГБ СССР (?), 21:11 , 15-Дек-18, (472) +1 КГБшник, это ж и про тебя можно сказать Думаешь чего твои мессаги так грохают м, Аноним (512), 20:59 , 16-Дек-18, (513) +1 Для тебя Не приходило в голову, что для меня и для всех несколько разные по, псевдонимус (?), 09:55 , 17-Дек-18, (545) Стабильность признак мастерства не помню кто Парень мастер по демагогии , псевдонимус (?), 09:46 , 17-Дек-18, (543) Ага Я его уже за комсорга признал , КГБ СССР (?), 11:01 , 17-Дек-18, (549) Продолжай утешать себя Обосновывай важность проституции и жульничества Но ведь, псевдонимус (?), 22:30 , 14-Дек-18, (425) Дорогой Ильич по большей части про первого сейчас, конечно был проституткой, ж, Michael Shigorin (ok), 22:42 , 14-Дек-18, (427) –1 Я понимаю, то ты ненавидишь камуняков не меньше, чем ненавидимые тобою бандеровц, псевдонимус (?), 22:57 , 14-Дек-18, (430) мадам, похоже, по всплывшим недавно данным, подделала пресловутое письмо к съез, пох (?), 11:10 , 17-Дек-18, (550) Неплохо бы ссылку или ключевую фразу для гуглежа А так Ленин гений Добрый гени, псевдонимус (?), 13:57 , 17-Дек-18, (560) А что не проституция и не жульничество Подметание ломом плаца, когда все уже да, Аноним (-), 15:26 , 15-Дек-18, (452) Это в технике называется генеральный конструктор или ведущий инженер И он долже, псевдонимус (?), 19:00 , 15-Дек-18, (460) Вот ВЫ и пользуйтесь техникой от ведущих инженеров и генеральных конструкторо, Аноним (-), 20:34 , 15-Дек-18, (465) Тебе не нужно, ты уже научился в уши дуть и делать презентации Поражает глубина , псевдонимус (?), 21:29 , 15-Дек-18, (473) –1 Я не маркетолог, так что нужно Когда человек не может объяснить чем он занимает, Аноним (-), 22:15 , 16-Дек-18, (516) Ну так можно уже было перерасти их Почему же ты не хочешь объяснить, чем занимае, псевдонимус (?), 07:24 , 17-Дек-18, (529) Ваши слова только ваш уровень нравственного развития демонстрируют , Аноним (-), 23:10 , 12-Дек-18, (13) –13 // И он кстати достаточно высок Плюсанул ему , Аноним (17), 23:21 , 12-Дек-18, (17) +7 // Такой же, как и твой - чуть выше плинтуса , fske (?), 01:25 , 13-Дек-18, (69) –9 Давай не офтопить Вот конкретно ты используешь x32 Ты пересобрал под него, не , Anonim (??), 00:25 , 13-Дек-18, (43) +7   // Я использую 32-разрядные они давно все с поддержкой PAE или 64-разрядные опера, КГБ СССР (?), 00:40 , 13-Дек-18, (51) –2   // Результаты проведенного тестирования товарища аналитика как всегда искать в гугл, fske (?), 01:29 , 13-Дек-18, (72) –1   Не, не соизволитъ Он просто немного рассказал о том, что он там использует Дум, Аноним (78), 02:01 , 13-Дек-18, (78) –2   Так и пусть себе использует И майнтайнит свой зоопарк сам, если других желающих, Аноним (243), 15:05 , 13-Дек-18, (244)   А что не 16-разрядный Будет ещё экономичнее и быстрее , Анонимный прохожий (?), 07:15 , 13-Дек-18, (123) +2   Не будет 32-битный софт при прочих равных быстрее 16-битного И быстрее 64-битн, КГБ СССР (?), 07:57 , 13-Дек-18, (134) –6   Вернёмся к этому вопросу в 38-ом году , Аноним (150), 08:55 , 13-Дек-18, (150) +4   Что должно произойти в 38 году 171 Часы сломаются 187 Это не страшно И эт, КГБ СССР (?), 09:15 , 13-Дек-18, (155) –1   Поскольку вгрузить в оперативу более 4 гигз одним чихом и работсть с этим можно , Аноним (243), 15:07 , 13-Дек-18, (246)   Вгрузить в оперативку более 4 гигов одним чихом можно было и раньше 8212 при , КГБ СССР (?), 15:56 , 13-Дек-18, (263) –1   Вот знаешь что, давай ты такой умный этим и пользуйся А я таки буду использоват, Аноним (-), 16:22 , 13-Дек-18, (271) +2   Я с год назад, кажется, приводил на этом форуме в пример сравнительно успешную р, КГБ СССР (?), 17:02 , 13-Дек-18, (282) –1   Ну а вот у меня NASAвская картинка на 300, если не ошибаюсь, мегапикселей - норм, Аноним (-), 17:41 , 13-Дек-18, (293)   Ещё о Фотошопах Photoshop 7 позволяет создать картинку размером 30000 на 30000 т, КГБ СССР (?), 01:51 , 14-Дек-18, (355)   и когда у меня в системе есть 16 гигз памяти, невозможность линейно адресоват, Аноним (-), 15:14 , 14-Дек-18, (397)   Прекрасный комментарий, настоящий гимн неэффективности Даже в совке такого махр, КГБ СССР (?), 15:38 , 14-Дек-18, (401)   Гимн неэффективности - это когда машина хрустит винчом и решает задачу в десятки, Аноним (-), 15:33 , 15-Дек-18, (453)   Вообще то, эффективнее всего работать не кусками влезающими в оперативку, а с ку, Аноним (514), 15:49 , 14-Дек-18, (403)   Аксиома если математика несложная, а картинка большая - основное время работы с, Аноним (-), 15:43 , 15-Дек-18, (454)   Помимо производительности шины памяти есть так же время запроса Насколько мне и, Аноним (514), 16:21 , 15-Дек-18, (457)   Да Однако RAM сильно отстает и на последовательном доступе, и на рандомном В с, Аноним (-), 20:47 , 15-Дек-18, (467)   Напомню лицам с девичьей памятью, что у первопня и вообще тогдашних процессоров , КГБ СССР (?), 00:03 , 16-Дек-18, (492)   И тем не менее - с тех пор АБСОЛЮТНО ВСЕ разогналось как минимум В РАЗЫ Настоль, Аноним (-), 16:11 , 16-Дек-18, (494)   Разогнали шины и множители, что даёт эффект на больших порциях данных aka bloat, КГБ СССР (?), 22:14 , 16-Дек-18, (515)   То-есть если я бэкап жму - это bloatware, оказывается Да и фоточки разрешением , Аноним (523), 02:52 , 17-Дек-18, (523)   Почему не 7 8 Где теплоёмкость Тепловыделение в электронных элементах зависит, Ю.Т. (?), 08:39 , 17-Дек-18, (532)   Не в кассу Будьте добры высказывать ваши тезисы по существу, тов комсорг Техпр, КГБ СССР (?), 10:39 , 17-Дек-18, (548)   Что да - то да, ручной paging - это жопа Ребята просто ZX Spectrum 128K не заст, Онаним (?), 09:30 , 14-Дек-18, (373)   Я застал другие 8-битные железки Тоже с банкингами и прочей камасутрой И именн, Аноним (-), 15:17 , 14-Дек-18, (398)   Да не гони Вот я, положим, решил песню написать Живых барабанов у меня дома не, Алексей Михайлович (?), 18:51 , 17-Дек-18, (571)   А таки в результате на самом деле требуется старшая часть этого 32-битного сче, Аноним (-), 16:35 , 13-Дек-18, (275)   С этим соображением я согласен Если часы железные, то придётся менять железо А, КГБ СССР (?), 17:05 , 13-Дек-18, (283)   Часы железные Но - время из них я перегружаю лишь эпизодически, в основном при , Аноним (-), 17:55 , 13-Дек-18, (299)   x32 нет, ибо там не честный x86, а с префиксами, т е не то не сё Регистров бол, КО (?), 16:48 , 13-Дек-18, (278)   Да и линукс с ним, я уже устал от этой дискуссии , КГБ СССР (?), 17:06 , 13-Дек-18, (284)   Мой браузер, после того, как откроет все окна и вкладки, которыми я пользуюсь, п, Проходил мимо (?), 07:39 , 13-Дек-18, (126) +1   Твой браузер умеет работать в несколько процессов при необходимости Проблемы мо, Аноним (514), 07:53 , 13-Дек-18, (131) +2   Деревья, списки и аналогичные используемые браузером структуры данных столько по, Акакжев (?), 08:17 , 13-Дек-18, (137)   Ну вот с некоторых пор даже в ИТ многие люди не понимают столь банальных основоп, КГБ СССР (?), 09:16 , 13-Дек-18, (156) –2   Грубо говоря, если _существенно_ больше 4 ГБ и именно из-за указателей , то,, Аноним (215), 12:32 , 13-Дек-18, (215)   У каждой вкладки своё адресное пространство, если она обслуживается отдельным пр, www2 (??), 13:14 , 13-Дек-18, (225) +1   294-й не понимает, что такое виртуальная память и её адресация И в кучу к нему , КГБ СССР (?), 16:00 , 13-Дек-18, (265)   Тот анонимус таки не 294 P Но общую идею вроде уловил и вещает нормально Как т, Аноним (-), 16:31 , 13-Дек-18, (274)   мы очень рады услышать что твой браузер - раздутое шпионское bloatware, но спраш, нах (?), 10:07 , 13-Дек-18, (165)   Твой браузер работает в 64-битной системе и по умолчанию для всего целочисленног, www2 (??), 13:11 , 13-Дек-18, (224) +1   Воинствующее невежество 32-х битные программы на 64-битной ОС будут практически , Nuzhny (?), 10:45 , 13-Дек-18, (174) +3   нет, не поэтому В архитектуре x86_64 банально вдвое больше регистров общего наз, Совершенно другой аноним (?), 13:34 , 13-Дек-18, (228) +1   И еще гарантированный SSE2, так что можно и пачку SSE2 регистров еще приплюсоват, Аноним (243), 15:11 , 13-Дек-18, (247)   У меня на 32-х битах всё работает быстро, а на 64-х свопится при трёх вкладках с, Q2W (?), 15:45 , 13-Дек-18, (260)   http lurkmore to УМВР, Аноним (289), 17:23 , 13-Дек-18, (289) +1   Заканчивайте уже с этой ерундой Это не так, если, конечно, у программистов руки, meantraitor (?), 13:47 , 13-Дек-18, (229) –1   V8 upstream said they won t support x32, bug 423815, Акакжев (?), 08:12 , 13-Дек-18, (136) +2   Разницу между адресацией и выделением памяти лучше всё же понимать memory-mappe, Crazy Alex (ok), 00:26 , 13-Дек-18, (44) +4 // Да, мы тоже посмотрели и glebfm попримеривался -- в итоге решили, что оно тог, Michael Shigorin (ok), 00:34 , 13-Дек-18, (48) –3 // И правильно сделали С нехваткой ресурсов как у альта на куда более прозаичные и, Аноним (-), 15:49 , 15-Дек-18, (455) Практика показывает, что даже БД не используют memory-map огромных баз Дело в т, Аноним (514), 05:14 , 13-Дек-18, (102) +3 // собрать один раз как тебе надо минимальный дистрибутив в котором ты хотя бы умее, нах (?), 10:14 , 13-Дек-18, (168) А вот пишут про будни профессионалов и даже немного в тему https vitus-wagner, КГБ СССР (?), 10:47 , 13-Дек-18, (177) –1 Мне больше понравился turn-by-turn navigation http www wagner pp ru vitus , Аноним (-), 15:39 , 13-Дек-18, (254) Ну как бы готовый дебиан раскатать - на порядки менее трудозатратно и куда как п, Аноним (-), 15:18 , 13-Дек-18, (249) для пересборки чужих готовых пакетов - ничего из этого не требуется А я себе в л, пох (?), 17:43 , 13-Дек-18, (294) Ну как бы если воспроизвести конфигу 1 в 1 как у популярного дистра - зачем тогд, Аноним (-), 18:03 , 13-Дек-18, (303) так я что-то не понял - тебе нужна неподдерживаемая популярным дистром архитекту, пох (?), 20:27 , 13-Дек-18, (330) Мне - нет Вопрошавшему - хрен знает Мной это рассматривается как весьма серьез, Аноним (-), 15:49 , 14-Дек-18, (404) На почти все вопросы, которые здесь обсуждались, есть куда более простой и однов, КГБ СССР (?), 16:38 , 14-Дек-18, (409) Как ни горько, но вероятнее всего именно так Ведь то, что изделие переусложнило, Ю.Т. (?), 16:46 , 14-Дек-18, (411) +1 Вариантов в общем то два либо мусор вытряхивается, либо система превращается в , Аноним (-), 12:35 , 15-Дек-18, (444) Начинать такой разговор следует с того, что ляпчатое ведро всегда было помойкой,, КГБ СССР (?), 13:25 , 15-Дек-18, (448) +2 В первые дни оно было значительно более хаотичной хипстерской мусоркой Хипстеры, Аноним (456), 16:08 , 15-Дек-18, (456) Наверняка ты был старостой класса, а потом группы или даже факультета, а ещё 1, КГБ СССР (?), 21:35 , 15-Дек-18, (474) У меня талант показывать некоторым рожам что мир несколько более многогранный и , Аноним (-), 16:15 , 16-Дек-18, (495) Такой 171 талант 187 есть у каждой бабы с возраста согласия и чем баба стар, КГБ СССР (?), 22:21 , 16-Дек-18, (517) ИМХО ты меня с шигориным путаешь А линух мне нравился и когда я был значительно, Аноним (-), 07:51 , 17-Дек-18, (530) Любая потре дь, не контролирующая навеянных извне позывов, для меня по определ, КГБ СССР (?), 09:01 , 17-Дек-18, (538) –1 ну да, если оно неинтересно - нефиг было и браться или отделить типовой софт о, пох (?), 12:48 , 15-Дек-18, (447) Это уже вопросы к тем кто порт делал Это был не я Даже Шигорин продемонстриров, Аноним (-), 17:03 , 15-Дек-18, (458) Очень недальновидное отношение, даже глупое Не говоря о том, какой климат таким , Ю.Т. (?), 17:39 , 15-Дек-18, (459) Как по мне, плясать бесплатно под чужую дудку, делая то что мне самому не надо -, Аноним (-), 20:09 , 15-Дек-18, (462) Объяснять-разобъяснять не надо, это давно известная позиция И лишь вопрос -- ум, Ю.Т. (?), 23:21 , 15-Дек-18, (488) Ну как бы тут каждый сам для себя отвечает на него, затевая проект Дальше он пы, Аноним (-), 16:23 , 16-Дек-18, (496) Мы друг друга не понимаем Кстати, не я разражаюсь здесь спичами по поводу и бе, Ю.Т. (?), 16:37 , 16-Дек-18, (497) Ага На самом базовом уровне - вы явно не понимаете цели и мотивы участия людей , Аноним (-), 07:56 , 17-Дек-18, (531) Глупость какая Как раз понимаю, как и то, куда эти мотивы и цели ведут и привод, Ю.Т. (?), 08:59 , 17-Дек-18, (537) так мы про опенсорс или где Порт я могу сделать - у меня, правда, как раз нет п, пох (?), 20:48 , 15-Дек-18, (468) Вот вы и пере открыли отчуждение А ведь и выпиливаемое abi кто-то делал , Ю.Т. (?), 23:23 , 15-Дек-18, (489) Да можешь, принцип опенсорца - форкай наздоровье, если здоровья хватает Вопрос , Аноним (498), 17:25 , 16-Дек-18, (498) https wiki debian org X32Port, Moomintroll (ok), 11:06 , 13-Дек-18, (181) это ты ему машину времени посоветовал, да debian sid, прекрасный древний артефа, нах (?), 12:06 , 13-Дек-18, (202) Как бы https www debian org ports уже давно висит в in progress что намекае, Аноним (-), 15:43 , 13-Дек-18, (256) Системный вызов read тоже прочитает не столько, сколько нужно, а столько скольк, Аноним (220), 12:56 , 13-Дек-18, (220) И таки если это меньше чем запрошено, это если и не ошибка то как минимум ситуац, Аноним (-), 18:06 , 13-Дек-18, (304) I m actually not active in particular open source communities I feel much more c, Аноним (221), 12:58 , 13-Дек-18, (221) спасибо а зачем кто это такая, и почему меня должно волновать интервью с ней , arisu (ok), 16:30 , 13-Дек-18, (273) // Для общего развития Для представления о трендах Как там было с сообществом Гно, КГБ СССР (?), 17:08 , 13-Дек-18, (286) +1 // Как бы фуршеты и буклеты тоже нужны - для продвижения FSF и их идей Был бы он ко, Аноним (-), 21:47 , 13-Дек-18, (338) –1 Проблема в том, что штатах это идет отдельным предметом в колледжах унивеситетах, Аноним (354), 01:09 , 14-Дек-18, (354) Таки она страшная Лучше бы мужик родился, Торвальдс красивее своей жены, Васёк (?), 04:33 , 14-Дек-18, (359) Все претензии к разработчикам дистрибутивов Разработчики ядра поддерживали x32 , Аноним (362), 05:13 , 14-Дек-18, (362) // не обсуждалось, Аноним (362), 05:15 , 14-Дек-18, (363) По состоянию на конец 2018-го года я знаю только один дистрибутив линукса 8212, КГБ СССР (?), 08:01 , 14-Дек-18, (366) +1 // Anonymoustus у из его NT6 видней, конечно, за линукс , Аноним (-), 20:11 , 15-Дек-18, (463) Под производительностью, я так понимаю, понимается скорость работы кода, запущен, Аноним (17), 23:04 , 12-Дек-18, (8) // Экономия небольшая, браузеры не работают, Аноним (10), 23:09 , 12-Дек-18, (10) // ну экономия насколько помню была большая, где то 30 что очень существенно когд, GentooBoy (ok), 23:14 , 12-Дек-18, (15) +1 // В меня подгорает у меня вообще 2 Если уже 4 считается непозволительно мало, то, Аноним (22), 23:32 , 12-Дек-18, (22) +1 А ещё есть такой класс устройств как ноутбуки на чудесных интеловских чипсетах, , КГБ СССР (?), 23:42 , 12-Дек-18, (27) +7 Скажем так - я на трёх гигах сидел долго, и это было крайне неуютно даже с моими, Crazy Alex (ok), 01:46 , 13-Дек-18, (74) пересобрать с флагами оптимизации забыли и вообще я за ассемблер достали , Анонимчжан (?), 02:03 , 13-Дек-18, (79) –1 Да и канонического Си бы хватило, а где надо безопасно и надёжно 8212 там Ада, КГБ СССР (?), 02:18 , 13-Дек-18, (86) –2 А вот с этим можно поспорить code Added SSE4_1 variant support of horizontal, Аноним (-), 17:08 , 13-Дек-18, (285) Ни в коем случае не стану отрицать полезность и где-то даже нужность расширений,, КГБ СССР (?), 17:51 , 13-Дек-18, (296) Вон GPU есть, если кто еще не заметил Хренова куча SIMD крупным оптом Мало что, Аноним (-), 18:13 , 13-Дек-18, (305) Это всё не то и про другое Сейчас если людям хочется быстрого шифрования, то пр, КГБ СССР (?), 18:36 , 13-Дек-18, (307) Ряд софта таки научился в GPGPU на этой почве Для TLS есть криптоакселераторы, , Аноним (-), 20:18 , 13-Дек-18, (325) криптоакселераторы не могут быть не в процессоре Иначе нешифрованные данные при, Аноним (22), 23:07 , 13-Дек-18, (344) Очень спорное утверждение Подразумевающее к тому же что аноним сам сделал себе , Аноним (-), 20:59 , 15-Дек-18, (469) Если не использовать негодный софт, написанный обезьянами, то достаточно и намно, КГБ СССР (?), 02:14 , 13-Дек-18, (83) +2 Эффективность и рациональность заключается в том, что чем тратить 100500 ДОРОГУЩ, Онаним (?), 08:42 , 13-Дек-18, (143) Это не эффективность и не рациональность, а экстенсивный количественный способ, КГБ СССР (?), 08:56 , 13-Дек-18, (151) –1 О, понятно, с кем дискутировать бессмысленно Фиаско ии и автопилотов, говорите , Crazy Alex (ok), 09:56 , 13-Дек-18, (164) –1 Желаете заключить пари , КГБ СССР (?), 10:14 , 13-Дек-18, (167) Критерии в студию А то что-то автопилоты теснят человека на всех фронтах Даже , Аноним (-), 17:16 , 13-Дек-18, (288) Идиллия заканчивается, когда вдруг в СМИ пробегает статья о том, например, что п, КГБ СССР (?), 17:34 , 13-Дек-18, (291) +1 FYI ошибки пилотов убивают больше пассажиров чем все остальное Собственно по эт, Аноним (-), 18:36 , 13-Дек-18, (308) потому что все остальное к рулю не подпускают вообще - поэтому у него собствен, пох (?), 22:24 , 13-Дек-18, (342) Ишчо один идiот Объяснял же - у состава мобыть тормозной путь больше километра,, Аноним (374), 09:43 , 14-Дек-18, (374) –1 В поездах таки уже подпускают, таки временами full authority, когда машиниста не, Аноним (-), 21:51 , 15-Дек-18, (475) Ты явно не понимаешь, зачем ко всякой сложной технической системе нужен оператор, КГБ СССР (?), 22:37 , 15-Дек-18, (483) машина не рожает машину, Ю.Т. (?), 23:29 , 15-Дек-18, (491) ИР это модель некоторых возможностей человеческого разума, предназначенная вст, Ю.Т. (?), 22:16 , 13-Дек-18, (340) Касаемо фиаско , я бы не был столь категоричен и да, по первому пункту возр, PnDx (ok), 13:15 , 13-Дек-18, (226) Ну так напишите себе свой браузер, текстовый редактор и чем вы там еще пользуете, meantraitor (?), 13:58 , 13-Дек-18, (233) Писали уже, и все работало - месяцами без перезагрузок и выключенийНо обезьяны и, Урри (?), 16:11 , 13-Дек-18, (268) +1 Ну так а что вы тогда хотите - рынок -PЕсли никто не хочет качаственный софт и, meantraitor (?), 16:27 , 13-Дек-18, (272) Ну так напишите себе свой комментарий, восхваляющий современных программистов А , Аноним (309), 18:38 , 13-Дек-18, (309) Какой софт есть - тот и использую Но, например, при линковке чего-то крупного г, Crazy Alex (ok), 09:53 , 13-Дек-18, (163) Из моего примера выше Seamonkey 2 0 14 Build identifier Mozilla 5 0 Windows, КГБ СССР (?), 10:13 , 13-Дек-18, (166) А ты попробуй этот seamonkey сбилдовать Вот и узнаешь сколько линкеру надо на п, Аноним (-), 15:48 , 13-Дек-18, (261) Ну а это-то при чём Справка для альтернативно одарённых большой софт вменяемые , КГБ СССР (?), 16:13 , 13-Дек-18, (269) А я не вижу с чего бы вдруг мой десктопник не сойдет еще и за небольшую билдферм, Аноним (-), 18:44 , 13-Дек-18, (310) мы рады что у тебя много ненужных денег а мне вот понадобилось раз пять подряд п, пох (?), 22:30 , 13-Дек-18, (343) Я просто хотел себе компьютер который не будет меня клинить в моих задачах - и я, Аноним (-), 22:06 , 15-Дек-18, (476) всего-то судя по тому что ядро в восемь потоков для тебя проблема - современный , пох (?), 11:31 , 17-Дек-18, (551) Дык небось компилежка и напрягала больше всего, и прочие убер эффективные порт, Аноним (-), 17:45 , 16-Дек-18, (499) как человек, сдуру поставивший ее на недоноут давно подтверждаю - она не предн, пох (?), 11:37 , 17-Дек-18, (552) Мне известно одно разумное и вполне оправданное исключение, когда Gentoo обращаю, КГБ СССР (?), 14:22 , 17-Дек-18, (561) Да ппц не то слово прямо У меня только после старта всех необходимых для работы, freehck (ok), 06:05 , 13-Дек-18, (109) Я бы присмотрелся к Миранде через Вайн https www miranda-ng org ru К ней есть , КГБ СССР (?), 17:57 , 13-Дек-18, (301) В линухе проще пиджина поставить Протоколов под него напилено ну уж не меньше ч, Аноним (-), 18:46 , 13-Дек-18, (312) Teach Yourself JavaScript for System Administration in 24 Hours DevOps Edition , КГБ СССР (?), 23:27 , 13-Дек-18, (345) Я намекал олдскульщику что псинодевы идут с неким catch в виде хипста-команды , Аноним (-), 17:48 , 16-Дек-18, (500) Скайп вижу А слак, зум, тимс там как , freehck (ok), 09:07 , 14-Дек-18, (369) Хм Я и слов-то таких не знаю , КГБ СССР (?), 09:12 , 14-Дек-18, (370) Я первое знаю Очередная дрянь на электроне от вебмакак, конечно же , Аноним (-), 22:08 , 15-Дек-18, (477) закрывают уже , Ю.Т. (?), 23:24 , 15-Дек-18, (490) Так что я там про период полураспада в 2 года то говорил На этом фоне даже п, Аноним (-), 17:48 , 16-Дек-18, (501) Не знаю, в какой там местности его закапывают Я пока вижу, что в большинстве за, freehck (ok), 06:38 , 17-Дек-18, (526) слак пробегало в одной из рассылок, мол, туда же, куда и гугль-плюс, Ю.Т. (?), 08:42 , 17-Дек-18, (534) а, что - неужели Инфа 100 , пох (?), 11:38 , 17-Дек-18, (553) Не знаю, увы Копнул и в корзине -- нет, не найду Мне это и интересно-то было л, Ю.Т. (?), 13:36 , 17-Дек-18, (556) Открываю Алиэкспресс и вижу там вагоны ддр2, анон (?), 07:53 , 13-Дек-18, (130) Это 171 плохая 187 DDR2 Её делают китайцы из неликвидов 8212 то есть дав, КГБ СССР (?), 09:05 , 13-Дек-18, (152) +1 Еще китаезы немного балуются просто распайкой нормальных модулей на чипы Это нр, Аноним (-), 18:48 , 13-Дек-18, (313) Зубожиння 2 От создателей геймерских процессоров за 400 рублей , Иваныч (??), 10:58 , 14-Дек-18, (381) Большая Вообще не аргумент Браузеры надо поправить, и будут работать , Аноним (17), 23:30 , 12-Дек-18, (21) // Не для того макака научилась немытым хвостом бряцать по клавиатуре, производя но, КГБ СССР (?), 23:43 , 12-Дек-18, (28) +1 Никто не поправил до сих пор, значит на десктопе никому толком не надо, Аноним (10), 00:47 , 13-Дек-18, (55) Кому надо, те не умеют Вот в чём заковыка А кто умеют, тем работодатели покупа, КГБ СССР (?), 01:07 , 13-Дек-18, (62) +1 А хотят, чтобы им даром на блюдечке принеслиИли использовать linux x86_64, Аноним (10), 05:06 , 13-Дек-18, (100) +1 Который жрёт на 30 больше памяти , Аноним (514), 05:19 , 13-Дек-18, (103) –1 Чем винда Да ты угараешь, Аноним (10), 05:57 , 13-Дек-18, (106) Чем чистый x64, Аноним (514), 05:59 , 13-Дек-18, (107) –2 Что такое чистый x64 , который не x86_64 , nobody (??), 10:27 , 13-Дек-18, (170) +1 Чистый в смысле без хаков по изменению размера указателей То есть именно x86_64, Аноним (514), 10:35 , 13-Дек-18, (172) –1 чем винда x86 - да, чему тут удивляться Тому что апчатая обезьянка ту винду , нах (?), 10:19 , 13-Дек-18, (169) Когда-то у нас оракля9 работала на 256М под ХР И даже не очень тормозила А теп, Аноним (374), 14:06 , 13-Дек-18, (235) Что ты с ним сделал Прямо сейчас 10 закладок и 15 загруженных вкладок, из них , псевдонимус (?), 22:09 , 14-Дек-18, (423) Который жрёт на 30 больше памяти Нет Вне зависимости от того, чего болит у, Andrey Mitrofanov (?), 12:26 , 18-Дек-18, (581) Это совершенно нормально Если на рынок ПО предложено какое-то ПО, то его потреб, КГБ СССР (?), 08:29 , 13-Дек-18, (141) +1 Пользователь точно также имеет право не использовать программы автора Не нравит, Аноним (374), 14:10 , 13-Дек-18, (236) Только вот почему-то из всего разнообразия субкультур бегают и пристают к людям , КГБ СССР (?), 18:26 , 13-Дек-18, (306) +1 Я таки понимаю, что ты хочешь, чтобы и тебе было зафигато, и чтобы не платить Н, Аноним (374), 09:49 , 14-Дек-18, (377) Марксизм и вытекающий из него коммунизм в прямых руках, управляемых разумной чел, псевдонимус (?), 22:17 , 14-Дек-18, (424) Чему научен -- прятать от публики существенные куски фактажа ---Итак, B развити, Michael Shigorin (ok), 22:37 , 14-Дек-18, (426) Оно тут офтоп Кури Кагарлицкого и Ильина Кара-Мурза не марксист вообще , псевдонимус (?), 22:44 , 14-Дек-18, (428) –1 Кара-Мурза вообще болван, пишущий для баранов, однако это действительно уже силь, КГБ СССР (?), 00:08 , 15-Дек-18, (433) Они разные бывают, если что , Michael Shigorin (ok), 00:23 , 15-Дек-18, (434) Это никак не противоречит марксовой теории И вообще, крупному капиталу без разн, псевдонимус (?), 07:37 , 15-Дек-18, (436) Поскольку оставлена жить вся ветка, позволю себе попытаться добавить концептуаль, Ю.Т. (?), 07:42 , 15-Дек-18, (437) +1 Из всего марксизма лично я научной признаю только политэкономию О научности же,, КГБ СССР (?), 00:07 , 15-Дек-18, (432) Это мутации вроде фрейдо- марксистов , они старательно поддерживаются правящими , псевдонимус (?), 07:17 , 15-Дек-18, (435) В теории заговора я не верю, пардон, мне приходилось управлять и руководить людь, КГБ СССР (?), 07:47 , 15-Дек-18, (438) Я тоже А вот в сговор с целью подтолкнуть падающего вполне см жакерия К счас, псевдонимус (?), 10:14 , 15-Дек-18, (439) У Высоцкого даже песенка про них была Ничего, уйдёт вся эта пена, разум победит, псевдонимус (?), 11:05 , 15-Дек-18, (441) Хиппи ведь не захватывали почту, банки и телеграф, не устраивали колхозы и концл, КГБ СССР (?), 11:31 , 15-Дек-18, (443) Потому и не захватывали, это были новые левые , их сделали маргиналами и тихо с, псевдонимус (?), 12:39 , 15-Дек-18, (446) Так пусть заплатят тем кто умеет, например А, погодите, на это жаба давит Кто-, Аноним (-), 18:50 , 13-Дек-18, (314) у гейца спрашивайте Или у Дурова с его 2k btc У них может хватить на оплату пар, пох (?), 20:17 , 13-Дек-18, (324) +2 На днях на Хабре было прекрасное Манифест рок-звезды г-нокода https habr com p, КГБ СССР (?), 23:59 , 13-Дек-18, (350) ну, будем думать что звизде лет 25, только-только получила свой диплом с отличие, пох (?), 11:49 , 14-Дек-18, (383) +1 А кто это , Ю.Т. (?), 12:12 , 14-Дек-18, (384) Видимо имеется ввиду злодей, сделавший яваскрипт Айк его обычно транскрибируют , псевдонимус (?), 22:50 , 14-Дек-18, (429) Да он и оплачивает иногда Вон у него Yann Colett вкалывает - автор LZ4 Сколько, Аноним (-), 22:24 , 15-Дек-18, (479) А вот и нет В линуксе частенько вышвыривают или не принимают чужой труд тольк, КГБ СССР (?), 00:13 , 16-Дек-18, (493) Пацана никто не заставлял комитить туда И если пацан слился, за него его работу, Аноним (-), 17:56 , 16-Дек-18, (502) Пока получается далеко не так Изобретены ли линуксоидами хотя бы одна техноло, Ю.Т. (?), 18:44 , 16-Дек-18, (506) Как же это по-линуксовому Реализовывать что-либо, потратив много денег и челове, Аноним (9), 23:05 , 12-Дек-18, (9) +4 // А представь сколько ресурсов было потрачено на разработку и совершенствование па, A.Stahl (ok), 23:09 , 12-Дек-18, (11) +1 // И, полагаю, это одна из причин, почему через 5 лет после их создания никто не ск, Аноним (17), 23:26 , 12-Дек-18, (19) // Лошади это x86, паровоз это x86_64, а x86_x32 это велосипед, Аноним (9), 23:29 , 12-Дек-18, (20) ia32 - это ручная тележка можно даже в квартиру завезти, места много не требует, Аноним (17), 23:34 , 12-Дек-18, (25) Только в отличие от привычных обиходных автомобилей ездит на 2-фосфат-этилен-3-б, A.Stahl (ok), 23:39 , 12-Дек-18, (26) +2 Только в отличие от привычных обиходных карет ездит на 2-фосфат-этилен-3-бензол-, Аноним (17), 23:49 , 12-Дек-18, (34) –1 Глаза мои , Michael Shigorin (ok), 00:36 , 13-Дек-18, (49) +1 Фокус в том что паровозы подешевели, таки теперь и частнику купить, в типовой га, Аноним (-), 18:54 , 13-Дек-18, (315) x32 - это паровоз с колёсами от тележки, Онаним (?), 20:34 , 13-Дек-18, (334) У нас на работу 10 человек ездят на велосипедах Для сравнения на лошадях и п, Аноним (17), 23:43 , 12-Дек-18, (29) +3 Да щаз Тут вон под боком Тимирязевский парк -- так и на лошадях, и на паровоза, Michael Shigorin (ok), 00:38 , 13-Дек-18, (50) ну так у вас ни депо не оборудовано на работе, ни конюшня или хотя бы коновязь , нах (?), 11:15 , 13-Дек-18, (185) Дарю идею - можете парковать там своих лошадей, господа Будете лайфхакерами , Аноним (-), 22:28 , 15-Дек-18, (480) Вызовом Торвальдса , Аноним (-), 18:55 , 13-Дек-18, (316) Intel потратил деньги и человекочасы, а поддерживать надо сообществу, Аноним (10), 05:09 , 13-Дек-18, (101) // ох оно перенапряглось поддерживать а, ну да, ну да - stable api is nonsense , нах (?), 11:19 , 13-Дек-18, (186) –1 Давно пора Это будет толчком для других , Аноним (12), 23:10 , 12-Дек-18, (12) –2 // Ты даже не понимаешь о чем сабж Зыжимхо, сабж можно оставить, а вот 32 бита пуст, ананим.orig (?), 12:06 , 13-Дек-18, (201) +1 // 32 бита нужно оставить для совместимости со старым железом , Аноним (351), 00:09 , 14-Дек-18, (351) –2 // зачем вам на железе 2007го года выпуска - самое распоследнее ведро линукса Ему , пох (?), 14:52 , 14-Дек-18, (391) В 2013 году на генте юзал так как была необходимость оперативку экономить Тепер, GentooBoy (ok), 23:11 , 12-Дек-18, (14) // У всех отпала , Аноним (16), 23:21 , 12-Дек-18, (16) +3 // В сотый раз говорю - где вы в последние три года видели технику с менее 8 гигов , Аноним (187), 11:22 , 13-Дек-18, (187) +4 // в сотый раз тебе говорят - если в твоей младшей группе детсада для одаренных дет, нах (?), 11:37 , 13-Дек-18, (191) –1 Какой ты культурный и воспитанный, нечто просто Тебе конструктив, а ты на лично, Аноним (187), 11:48 , 13-Дек-18, (199) +7 конструктив уровня я не видел - значит не бывает - заслуживает ровно такого у, нах (?), 12:11 , 13-Дек-18, (204) Это ещё зачем , Алексей Михайлович (?), 18:53 , 17-Дек-18, (572) Ну да Офигенный повод отдать её одному юзерспейсному приложению , ананим.orig (?), 12:09 , 13-Дек-18, (203) современные разработчики ведра - однозадачные , нах (?), 12:12 , 13-Дек-18, (205) Ты не поверишь, но да Во время работы Maya, Max, Nuke, итд спокойно могут выжра, Аноним (187), 12:13 , 13-Дек-18, (206) +3 Не успеют Какой-нить новый и текущий фф сожрет первым Или очередной пасьянсА вот, ананим.orig (?), 14:02 , 13-Дек-18, (234) +1 Последний или предпоследний фф, открыто вкладок 10 с лентами тумблера, девиант, Аноним (187), 16:48 , 13-Дек-18, (277) +2 Открываешь мало вкладок , Ванёк (?), 22:43 , 16-Дек-18, (518) +1 Видим в магазинах СЕЙЧАС 4 Гб, Аноним (212), 12:19 , 13-Дек-18, (212) Во всех без исключения гос учреждениях на компах сотрудников от 2 до 4 Гб операт, Адекват (ok), 10:40 , 18-Дек-18, (575) Аноним с опеннета докупил памяти - архитектуру из ядра можно удалять Отпишись т, Аноним (17), 23:24 , 12-Дек-18, (18) +7 // Тамошние дядьки - это не Тео, им корпорации железо покупают топовое, ведь заплан, Аноним (22), 23:33 , 12-Дек-18, (24) +2 // А, кто, кто я вас спрашиваю подумает о простом анониме с опеннета Даёшь линукс с, Мастер над релизами (?), 05:21 , 13-Дек-18, (104) Даешь форк и сопровождаешь его, анон (?), 07:56 , 13-Дек-18, (133) +1 Форк анонима , Аноним (210), 12:17 , 13-Дек-18, (210) Ну, может этот аноним и был единственным пользователем этой фичи Если она тепер, Гентушник (ok), 00:08 , 13-Дек-18, (39) +4 Это не удивительно, что из Линукса хотят убрать x86_x32 Это же только десктопна, Аноним (9), 00:09 , 13-Дек-18, (40) // Блин, да она нигде, считай, не используемая Кроме генты я не припомню ни одного, Crazy Alex (ok), 00:32 , 13-Дек-18, (47) +3 // В debian есть была неофициальная поддержка, Аноним (10), 00:48 , 13-Дек-18, (56) +1 Знаете ли Вы, что многие VDS имеют 4Гб памяти, а если и имеют, то там ведь не, Аноним (514), 05:44 , 13-Дек-18, (105) +2 // Как это не осилили В Chromium одна вкладка - один процесс, Аноним (9), 15:14 , 13-Дек-18, (248) // А v8 не умеет jit в x32 ABI И соответственно JS пролетает как фанера над париже, Аноним (-), 18:57 , 13-Дек-18, (317) Хватит ли мне пальцев одной руки, чтобы пересчитать анонимов с опеннета лора вме, Аноним (45), 00:26 , 13-Дек-18, (45) +7 // Боюсь, хватит, даже если Вы матёрый и лихой фрезеровщик , Michael Shigorin (ok), 00:43 , 13-Дек-18, (54) +6 // Уже не хватит, Миш , Аноним (144), 08:42 , 13-Дек-18, (144) +1 Мишаня запамятовал встраиваемые системы, где лишний объём памяти выливается в ув, Ванёк (?), 22:46 , 16-Дек-18, (519) Жаль что не взлетело - для GUI бы подошло, когда основная система 64-битная -- б, vadiml (ok), 00:30 , 13-Дек-18, (46) +2 // Жаль, но таки не взлетело, Crazy Alex (ok), 01:47 , 13-Дек-18, (75) // Не то слово Очень жаль там где можно использовать оптимизацию под x64 регистры, fi (ok), 17:48 , 13-Дек-18, (295) На десктопе сейчас ровно одна главная программа, и она 4Г съест легко Называетс, Zulu (?), 15:16 , 17-Дек-18, (564) +1 // Лечится заменой этой программы на Firefox 3 5 19 или Seamonkey 2 0 14 оба с нен, КГБ СССР (?), 15:45 , 17-Дек-18, (565) // То есть не получится делать то, ради чего вообще эта программа нужна Эпичная по, Zulu (?), 19:42 , 18-Дек-18, (585) Ну так за эти пару лет Гугель подмял под себя все интернеты и произошло нескольк, КГБ СССР (?), 20:09 , 18-Дек-18, (587) Просветите, плиз Таким же образом реализовано выполнение 32-кода в 64-разрядной , Аноним (53), 00:42 , 13-Дек-18, (53) // Гугли про WoW google com search q Windows on WindowsДобавлю неофициально, что в, КГБ СССР (?), 01:27 , 13-Дек-18, (70) –1 нет , userd (ok), 12:47 , 13-Дек-18, (217) Также как и x86 в Линуксе если не вдаваться в детали x32 это отдельная песня , КО (?), 16:51 , 13-Дек-18, (279) +1 Да Этот x32 по процессорной документации так и называется Compatible Mode , Himik (ok), 20:22 , 13-Дек-18, (326) –2 // Вы точно не путаете систему команд IA32 и x32 ABI , Michael Shigorin (ok), 23:31 , 17-Дек-18, (574) Может им послать фотки с завода, на котором уйма индустриальных станков с 256Мб , OldFart (?), 01:54 , 13-Дек-18, (77) –7 // И зачем им новое ядро на CentOS 5 6 7 протянут У меня есть реальный случай ког, Аноним (85), 02:17 , 13-Дек-18, (85) Здесь не поймут Я уже пытался донести до опеннетовской публики основные идеи пр, КГБ СССР (?), 02:24 , 13-Дек-18, (88) –2 // Да ты наркоман, планировать использование никем не тестируемой кодовой базы на п, Аноним (108), 06:02 , 13-Дек-18, (108) +10 Очень трогательно, что ты заботишься о том, чтобы буржуй мог купить себе еще оди, Аноним (374), 14:44 , 13-Дек-18, (238) // Классовая и сословная солидарность с буржуями У нас дворцы, у вас халупы , КГБ СССР (?), 17:10 , 13-Дек-18, (287) Лучше пошлите нам фотки, как вы на машины с 256 памяти ставите дистрибутив на св, AnonPlus (?), 02:39 , 13-Дек-18, (91) +1 // Не самое свежее, зато сразу с Иксами, оконным менеджером и другими программами h, КГБ СССР (?), 03:02 , 13-Дек-18, (95) –2 подписываюсь tits or GTFO, Аноним (108), 06:25 , 13-Дек-18, (120) +2 Речь идет про 64-битные процы и 32-битные указатели на них , axredneck (?), 02:54 , 13-Дек-18, (93) +6 А при чём тут 32х-битные процы x32 -- это один из вариантов поддержки 32-битных, freehck (ok), 06:17 , 13-Дек-18, (111) +1 // При том, что 32-битных писюковых уже нет новых в продаже если не учитывать всяк, КГБ СССР (?), 09:28 , 13-Дек-18, (158) –2 // x32 к этому никакого отношения не имеет ia32 никто выкидывать не собирается, та, Нанонимус (?), 10:45 , 13-Дек-18, (175) Ну давай ещё десять энергичных анонимов мне напишет, что x32 это не синоним x86,, КГБ СССР (?), 10:54 , 13-Дек-18, (178) –2 Еще раз, у тебя станки с 256М памяти, что ты там собрался делать с x32 , Нанонимус (?), 13:06 , 13-Дек-18, (223) Ну, понимаешь, он NT6 чтототам использует, там такого ABI нет как класса, поэтом, Аноним (-), 18:58 , 13-Дек-18, (318) +1 Причем втирает начальству, что для 256М памяти ну прямо-таки жизненно необходим , Нанонимус (?), 14:14 , 14-Дек-18, (385) Я мягко говоря сомневаюсь что на бортовом компьютере ископаемого станка вообще с, Аноним (-), 22:32 , 15-Дек-18, (481) Разъясните, пожалуйста, еще Никак не могу взять в толк, что вам мешает запускать, meantraitor (?), 14:12 , 13-Дек-18, (237) 32-битные приложения на 64-битном ядре запускают в 32-окружении, а x32 - это 32, fi (ok), 17:51 , 13-Дек-18, (297) Я знаю Дальше-то что Речь тут шла про 32-битные приложения Ну и запускайте себ, meantraitor (?), 18:02 , 13-Дек-18, (302) За себя скажу, что надо , freehck (ok), 09:19 , 14-Дек-18, (371) Некоторые шибко ретивые анонимы уверены, что они умнее всех, а вокруг все глупые, КГБ СССР (?), 09:45 , 14-Дек-18, (375) Чувак, читал бы ты тред повнимательнее , freehck (ok), 09:59 , 14-Дек-18, (378) +1 да тут 3 4 сообщений - его, Аноним (386), 14:37 , 14-Дек-18, (386) Зачем я буду читать комментарии малолетних обиженок и мамкиных кульхацкеров, в к, КГБ СССР (?), 15:59 , 14-Дек-18, (405) И здесь Вас не не уважают Кругом враги Ну надо же Обидно, правда , Благодарный читатель. (?), 10:56 , 15-Дек-18, (440) Дополню ссылкой на пояснения Интела https software intel com en-us node 628, КГБ СССР (?), 09:47 , 14-Дек-18, (376) Чукча не читатель, чукча - писатель , Анонимный прохожий (?), 07:47 , 13-Дек-18, (127) +2 // Согласен Читать внимательней надо было думал на ia32 позарились , OldFart (?), 00:55 , 14-Дек-18, (353) –1 Пусть таки попробует x32 ABI запустить на этих станках, для начала А то это чег, Аноним (482), 22:36 , 15-Дек-18, (482) А теперь поясните на кой хрен в станках менять софт если они работают , анон (?), 07:58 , 13-Дек-18, (135) // дохнут они, не поверишь, станки-то Причем механика живет долго, хотя точность и, нах (?), 11:40 , 13-Дек-18, (193) +2 // И Софт менять Да там на складах всякие LPT с i286 еще в масляной бумаге лежат,, Аноним (386), 14:41 , 14-Дек-18, (387) неа, у меня приятель прекрасно подрабатывает заменой сдохшей производственной _м, пох (?), 15:00 , 14-Дек-18, (392) Если текстолит правильный, то он ещё наших внуков переживёт Как, собственно, и , КГБ СССР (?), 16:01 , 14-Дек-18, (406) Ну не знаю, у мну валяется 286 по приколу Ничего там не расслоилось, только акк, Аноним (482), 22:43 , 15-Дек-18, (484) Чет я пургу прогнал прочитав новость по диагонали подумал что x86 выпилить хо, OldFart (?), 00:45 , 14-Дек-18, (352) +3 // Да ничо, бывает Мне тоже совестно, столько г-на вылил уже, даже КГБ забрызгало, Аноним (386), 14:50 , 14-Дек-18, (390) // Не переживай, за вашими фонтанами искромётного подплинтусного юмора я наблюдаю и, КГБ СССР (?), 16:05 , 14-Дек-18, (407) ix86 выкиньте пжлст, а x32 оставьте Спасибо , Аноним (85), 02:08 , 13-Дек-18, (81) –4 // кстати, да - вот такой процессор теперь уже действительно нигде не купить, кроме, нах (?), 11:41 , 13-Дек-18, (194) означает ли это, что все 32 битные приложухи игори там старые например преврат, Нуб (?), 03:00 , 13-Дек-18, (94) –2 // нет, Аноним (96), 03:16 , 13-Дек-18, (96) +6 Да, именно так , Himik (ok), 20:24 , 13-Дек-18, (327) –2 Но есть ещё эмуляторы, типа QEMU для запуска 32-битных игр на 64-битной системе , Himik (ok), 23:29 , 13-Дек-18, (346) –1 а как насчёт нового кодекса ведь удаление того кода это в чистом виде унижение т, тентакль (?), 06:16 , 13-Дек-18, (110) +4 // Если запретить удалять код, то куда можно засунуть право на модификацию кода, га, freehck (ok), 06:20 , 13-Дек-18, (113) // Но если пиво мешает работе W W W лицензия мешает CoC у , Аноним 80_уровня (ok), 08:31 , 13-Дек-18, (142) Как это переваривать Предложения с двойным отрицанием Нет, это не так Этот не, EuPhobos (ok), 06:18 , 13-Дек-18, (112) // Утро добрым не бывает не против, если поддержит, если Ну вот так прим, freehck (ok), 06:22 , 13-Дек-18, (115) Это русский язык, детка 171 Нет, ну так-то, да 187 , трурль (?), 07:55 , 13-Дек-18, (132) Это финский язык И на нём думает Линус Торвальдс - , Himik (ok), 20:27 , 13-Дек-18, (332) А как же Я У меня все еще архитектура x32, что мне теперь покупать x64 придетс, Вася (??), 06:21 , 13-Дек-18, (114) –5 // У меня вообще x16 на генту Нормально, жить можно, ну и идиоты же, Аноним (108), 06:23 , 13-Дек-18, (117) Вникать в текст новости сейчас, смотрю, немодно , Анонимный прохожий (?), 07:48 , 13-Дек-18, (128) +7 Вася, остынь - если у тебя процессор 32-битный, то архитектуру x86 пока не вык, А (??), 11:45 , 13-Дек-18, (196) интересно, где ты достал такое но гордись ты единственный на планете владелец , arisu (ok), 16:38 , 13-Дек-18, (276) // да че пристал он не понял разницы между архитектурой х86 и х32 программной реа, трололо (?), 17:55 , 13-Дек-18, (300) У нас на работе тоже ноут оказался 32bit msi s420 думал вставлю в него ssd и о, Адекват (ok), 11:07 , 18-Дек-18, (576) А как же типа переносимая ось и всё такое Проще писать под одну платформу и не , cutlass (?), 06:22 , 13-Дек-18, (116) // Ну вот потому в качестве доступной промышленной ОС и используют DOS, а не линукс, КГБ СССР (?), 09:33 , 13-Дек-18, (160) –1 // А 64-битная DOS есть , Ванёк (?), 15:16 , 19-Дек-18, (593) https flameeyes blog 2012 06 19 is-x32-for-me-short-answer-no , Аноним (10), 06:45 , 13-Дек-18, (121) Забавно, что половина комментаторов на глубоко техническом ресурсе даже не пон, Аноним (125), 07:35 , 13-Дек-18, (125) +14 // Как обычно Вас это еще развлекает Подождите, еще немного и вы будете здесь чит, dango (ok), 08:18 , 13-Дек-18, (139) Забавно, что даже в LKML нашёлся молодчик, причём из угадай, Онаним (?), 08:46 , 13-Дек-18, (146) // из угадай какой страны, который тоже не осилил, Онаним (?), 08:46 , 13-Дек-18, (147) кто-то впервые увидел икспертов опеннета , Нанобот (ok), 12:03 , 13-Дек-18, (200) А могли бы ещё несколько лет по говнохранительствовать Ядро то ведь всё равно м, Аноним (150), 08:47 , 13-Дек-18, (148) А вообще с x86-64-x32 - давно пора Оно не взлетело и не взлетит никогда, потому, Онаним (?), 08:50 , 13-Дек-18, (149) –2 // дело не в памяти, а в кэше Делая указатели в 2 раза короче, оно экономит кэш, к, inferrna (ok), 13:06 , 13-Дек-18, (222) +2 // Спорно Кэш, как и память, адресуется блоками, размер которых зашит в процессо, Аноним (230), 13:48 , 13-Дек-18, (230) –1 // Так в том то и дело Кешлайн 64 байта Это либо N команд, либо N 2 ну хорошо x8, КО (?), 16:58 , 13-Дек-18, (281) Во-первых, кеш адресуется блоками по 64 байта, а не по 8 байт Во-вторых, экономи, Аноним (520), 02:46 , 17-Дек-18, (520) Про выравнивание данных не стоит забывать, оно 64 бита какбэ , Аноним (251), 15:19 , 13-Дек-18, (250) У меня только один гб памяти и я не могу просто её докупить, потому что сижу на , Аноним (153), 09:06 , 13-Дек-18, (153) // А про кэш процессора ты специально забываешь Или мамка купила тебе i9 , Аноним (162), 09:47 , 13-Дек-18, (162) +1 // А ты уверен, что в кеш-линиях нет выравнивания по 64 в x32 режиме У меня есть н, Аноним (386), 13:50 , 13-Дек-18, (231) С самого начала было понятно, что эта архитектура обречена быть непопулярной Оп, Аноним (157), 09:26 , 13-Дек-18, (157) // С самого начала было понятно, что для популяризации архитектуры надо придать ей , Аноним (162), 09:45 , 13-Дек-18, (161) +2 // Посчитайте для начала падение ценника на гигабайт DRAM лет за 10 хотя бы, потом , Аноним (171), 10:31 , 13-Дек-18, (171) // Измерьте для начала площадь продаваемого за доллар обработанного кремния в виде , КГБ СССР (?), 11:03 , 13-Дек-18, (180) э за которые десять Если за последние, так она подорожала раза этак в полтор, нах (?), 11:46 , 13-Дек-18, (197) +1 MByte2008 0 0232009 0 0102010 0 0192011 0 0102012 0 00492013 0 00432014 , Аноним (251), 12:22 , 13-Дек-18, (213) +1 Отсюдаhttps jcmit net memoryprice htm, Аноним (251), 12:22 , 13-Дек-18, (214) Так себе источник , Аноним (162), 12:51 , 13-Дек-18, (218) +1 Только в 2008 достаточно было купить 2, а сейчас надо 8 , Ю.Т. (?), 22:19 , 13-Дек-18, (341) +2 Если бы 8230 Сейчас 171 у каждого офисного планктона минимум 16 187 Так, , КГБ СССР (?), 23:41 , 13-Дек-18, (348) Вернее, сейчас у каждого мамкиного игруна минимум 16, а настолки нужны только д, Ю.Т. (?), 07:14 , 14-Дек-18, (364) вот дерьмо А у меня восемь, и начальство говорит что это в нашей конторе круто , пох (?), 15:02 , 14-Дек-18, (394) Начальство на то и начальство, что не ошибаться в генеральной линии и потребност, КГБ СССР (?), 16:08 , 14-Дек-18, (408) Ну так начальство тебе выделило машину не для того чтобы ты там в GTA игрался К, Аноним (-), 18:01 , 16-Дек-18, (503) Давай лучше про падение ценников на топовые процы и материнки поговорим А то сд, Аноним (162), 12:53 , 13-Дек-18, (219) –1 А что с ними Как продавал штеуд свои иксы за 999 1999, так и продает Ну и как , Аноним (374), 15:06 , 13-Дек-18, (245) –1 все ок - падение компенсируется удорожанием раритетных компонентов не на десят, пох (?), 19:37 , 13-Дек-18, (323) Поставил на слабый планшет с 32 бит загрузчиком 64-битный минт Производители бы, Аноним (159), 09:29 , 13-Дек-18, (159) // Если точнее, то подстраивается система А размер указатела все равно в 2 раза бол, Аноним (179), 11:01 , 13-Дек-18, (179) // Ну больше и больше Указатели серьёзно погоду делают только в случае чрезмерно с, Аноним (251), 12:18 , 13-Дек-18, (211) +1 // std string - 3 указателя, один на начало данных, второй на конец, третий на емк, Аноним (335), 20:59 , 13-Дек-18, (335) Это в модели ptr8 Оговорились , Michael Shigorin (ok), 21:42 , 13-Дек-18, (336) Насколько помню, std string короткие строки вписывает в саму структуру , Онаним (?), 09:24 , 14-Дек-18, (372) Это не отменяет наличие трёх указателей В случае пустых строк, наличие локально, Аноним (514), 10:13 , 14-Дек-18, (379) +1 Не скажу за си а в си таки оптимизатор очень даже может резко отменить к чертя, Аноним (-), 22:50 , 15-Дек-18, (485) Встраиваемая техника, роутеры и т д , ускорение до 30 очень кстати , Аноним (179), 10:47 , 13-Дек-18, (176) +2 // Хоть один роутер на x86-x64-x32 видели , Аноним (251), 11:07 , 13-Дек-18, (182) –2 // На сколько это важно , Аноним (179), 11:12 , 13-Дек-18, (183) –1 // 0, Аноним (251), 12:15 , 13-Дек-18, (208) Легко делается на дешёвой материнке с сокетом FM1 , Аноним (189), 11:31 , 13-Дек-18, (189) // как ни старался - не смог в своей стране найти дешёвой материнки с FM1 есть с F, имя (?), 11:47 , 13-Дек-18, (198) Так кто-то делает Ну, не кустарщину, а коммерческий продукт У меня и на x86-64 , Аноним (251), 12:16 , 13-Дек-18, (209) Делают -- но, разумеется, именно x32 в знакомых случаях не впёрся , Michael Shigorin (ok), 15:45 , 13-Дек-18, (259) Как ни странно, да , Аноним (520), 02:47 , 17-Дек-18, (521) Чтобы x86 в что-то встраиваемое сунуть надо крепко долбануться А увидеть 30 ус, Аноним (319), 19:08 , 13-Дек-18, (319) // у меня роутер есть на каком-то проце от амд в отличие от китайских собратьев, в, Аноним (331), 20:27 , 13-Дек-18, (331) // Ну и чего А я китайский арм с дебианом с годом аптайма видел Ну, работает А ч, Аноним (-), 22:57 , 15-Дек-18, (486) Любые конденсаторы, включая керамические, имеют ограниченный срок службы, и дале, Аноним (520), 02:49 , 17-Дек-18, (522) Для роутеров на железной архитектуре x86_64 самое то Сам использовал, понравило, Аноним (189), 11:25 , 13-Дек-18, (188) +1 Вот это надо было выделить большими, жирными, красными буквами не путать с x86, Ващенаглухо (ok), 12:47 , 13-Дек-18, (216) +3 // нет, не надо Пусть долбятся, Аноним (386), 13:52 , 13-Дек-18, (232) +3 ммм как насчет wine он же до сих пор запускает огромный пласт x32 приложений Ил, Аноним (255), 15:41 , 13-Дек-18, (255) // Еще плюс один не видящий разницы между x86 и AMD64 с 32-х битными указателя, А (??), 17:26 , 13-Дек-18, (290) // Ну простите не все здесь сидящие шарят в таких нюансах , Аноним (255), 19:32 , 13-Дек-18, (321) –1 // Зато все думающие шарят А сидящие пусть сидят дальше , Ванёк (?), 15:29 , 19-Дек-18, (594) Если это не повлияет на юзерспейс -- тогда в топк у смело , Аноним (255), 19:33 , 13-Дек-18, (322) а по количеству занятой памяти какое соответствие между x86, x32 и x64 , J.L. (?), 17:51 , 13-Дек-18, (298) // Кстати да, почему меряют только скорость , vedronim (?), 01:54 , 14-Дек-18, (356) Если хоть один человек использует данный инструментарий, то его нельзя удалять и, Аноним (337), 21:47 , 13-Дек-18, (337) +1 // Это не инструментарий И хоть одного человека никто из ядра не удаляет А сл, Michael Shigorin (ok), 22:04 , 13-Дек-18, (339) // Ты не обитал на rsdn какое-то давнее время назад Был один персонаж там, про пун, Аноним (386), 14:49 , 14-Дек-18, (389) // Здесь посмотри, там целая страничка ему лично посвящена myrotvorets center crimi, КГБ СССР (?), 17:46 , 14-Дек-18, (413) Ещё надобно сжечь на площадях его книги или дистрибутивы , Ю.Т. (?), 17:58 , 14-Дек-18, (414) +1 как и многие из других персонажей этого нарушающего УК бывшей УКраины сайтА П, Michael Shigorin (ok), 18:41 , 14-Дек-18, (415) И от цензуры бывает польза, однако , Ю.Т. (?), 19:04 , 14-Дек-18, (416) И от расстрелов Главное чтобы пулемет был в правильную сторону Вот в сторону Ю, Аноним (-), 18:05 , 16-Дек-18, (504) Укуси меня, Харди , Ю.Т. (?), 18:45 , 16-Дек-18, (507) НЕТ Первые страны, которые пострадали от нацистов 8212 это нацисткая Германия, Благодарный читатель. (?), 11:16 , 15-Дек-18, (442) Вот увы, неразборчив Макс в раздаче полномочий И отдал модерацию рожам которые , Аноним (-), 18:08 , 16-Дек-18, (505) Может Максу надоел этот ресурс может он его согласится продать, если ему предл, Адекват (ok), 12:05 , 18-Дек-18, (580) Я готов предложить 30 рублей , КГБ СССР (?), 12:57 , 18-Дек-18, (582) Ну Вы же, светлоликий наш эльф, не вызвались И если Максим Вам как мне предл, Michael Shigorin (ok), 20:38 , 18-Дек-18, (589) +1 Я про ту же промышленность и инфраструктуру -- Вы сейчас по сути описали то, что, Michael Shigorin (ok), 20:29 , 18-Дек-18, (588) Зачем Пусть влачит существование, он сам себя наказал переездом в Нигерию, толь, Zulu (?), 19:45 , 18-Дек-18, (586) –1 Ой, а ты уже вернулся в замечательный киевский климат из клятых Нидерландив или , Michael Shigorin (ok), 20:42 , 18-Дек-18, (590) да это баян Просто было интересно, обитал ли Михаил на кывте Я давно ушел, а т, Аноним (449), 14:36 , 15-Дек-18, (449) Правильно, догоним и перегоним винду по прожорливости Иж ты, линукс на десктопе, Аноним (-), 23:55 , 13-Дек-18, (349) // Ты завсегда можешь пересобрать ядро удалив ненцжное, если приспичит Это ж опенс, vedronim (?), 01:55 , 14-Дек-18, (357) Жаль, но удаление будет верным решением Если с 2012 года дистростроители так т, Аноним (362), 05:08 , 14-Дек-18, (361) // Дистростроители ударными темпами осваивали системду, а также готовили и согласов, КГБ СССР (?), 08:03 , 14-Дек-18, (367) +3 Много есть такого, чего до сих пор не освоили дистростроители Например system c, anonymous (??), 11:36 , 14-Дек-18, (382) +1 согласен к примеру тот-же Debian осваивает apparmor - думают внедрять его в ста, имя (?), 21:19 , 14-Дек-18, (422) Уф,я уж испужался не на шутку dhcpcd хотят похерить еще и вайн не запустиь с 32 , Анонимчик (?), 13:26 , 18-Дек-18, (583) Из-за этого чертового прогресса приходиться извращаться чтобы пользоваться привы, Анонимчик (?), 13:28 , 18-Дек-18, (584) 1,2,4,8,9,12,14,40,45,46,53,77,81,94,110,112,114,116,121,125,148,149,153,157,159,176,188,216,255,298,337,349,361,583,584

Сообщения

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

	43. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+7 +/–
	Сообщение от Anonim (??), 13-Дек-18, 00:25
	Давай не офтопить. Вот конкретно ты используешь x32? Ты пересобрал под него, не знаю, хромиум? Или firefox? И как, работает? Намного ли стал меньше жрать памяти? Бесноватые были во все времена. И в основном им нужно внимание. И вставляя про них упоминания, ты лишь им помогаешь.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	51. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 00:40
	Я использую 32-разрядные (они давно все с поддержкой PAE) или 64-разрядные операционные системы на соответствующем железе и, по возможности, 32-разрядные программы в этих 32- или 64-разрядных операционных системах. Никакому прикладному софту обычного юзера ни для чего не нужно уметь адресовать много памяти. При прочих равных 32-разрядный софт почти всегда лучше, быстрее и экономнее для ресурсов. Я никак не могу представить себе, для чего, например, браузеру, мультимедийному проигрывателю, табличному процессору или текстовому редактору быть 64-битными. Если ты можешь назвать конкретные выгоды — назови.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от fske (?), 13-Дек-18, 01:29
	>При прочих равных 32-разрядный софт почти всегда лучше, быстрее и экономнее для ресурсов. Результаты проведенного тестирования товарища аналитика как всегда искать в гугле или он соизволить свой пук в лужу аргументировать?
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от Аноним (78), 13-Дек-18, 02:01
	Не, не соизволитъ. Он просто немного рассказал о том, что он там использует. Думая, что это кому-то интересно.
	Ответить | Правка | Наверх | Cообщить модератору

	244. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (243), 13-Дек-18, 15:05
	> Не, не соизволитъ. Он просто немного рассказал о том, что он там > использует. Думая, что это кому-то интересно. Так и пусть себе использует. И майнтайнит свой зоопарк сам, если других желающих это делать не найдется. У меня вот последних лет 10 - насквозь 64-битная система на основных комапх. Зато программы могут mmap()-ать любые файлы, а графический редактор не упадет по глупой причине если я открою там даже огроменную картинку. И это все же хорошо.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Анонимный прохожий (?), 13-Дек-18, 07:15
	> При прочих равных 32-разрядный софт почти всегда лучше, быстрее и экономнее для ресурсов А что не 16-разрядный?  Будет ещё экономичнее и быстрее.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	134. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–6 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 07:57
	Не будет. 32-битный софт при прочих равных быстрее 16-битного. И быстрее 64-битного.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+4 +/–
	Сообщение от Аноним (150), 13-Дек-18, 08:55
	Вернёмся к этому вопросу в 38-ом году.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 09:15
	> Вернёмся к этому вопросу в 38-ом году. Что должно произойти в 38 году? «Часы сломаются»? Это не страшно. И это на самом деле не зависит от адресации памяти. Можно «новую эпоху» открывать хоть каждые десять лет. Просто для удобства выбирают какие-то отправные даты и затем «ради обратной совместимости» морочат себе и людям головы. Это на самом деле не проблема. Открою, кстати, маленькую большую тайну: 64-битная архитектура x86 на самом деле не использует 64-разрядную адресацию. Вот и стоило затевать всю эту канитель? Польза ведь только для Большого Железа.
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (243), 13-Дек-18, 15:07
	Поскольку вгрузить в оперативу более 4 гигз одним чихом и работсть с этим можно - стоило. А то что 640 кило хватит всем - вот кому хватит, тот пусть и пользуется 640 кило.
	Ответить | Правка | Наверх | Cообщить модератору

	263. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 15:56
	> Поскольку вгрузить в оперативу более 4 гигз одним чихом и работсть с > этим можно - стоило. А то что 640 кило хватит всем > - вот кому хватит, тот пусть и пользуется 640 кило. Вгрузить в оперативку более 4 гигов одним чихом можно было и раньше — при помощи PAE. Открою тебе страшную тайну: и больше можно было, если ещё увеличить разрядность адресации. Сколько угодно много можно, если на то пошло. Ограничение в 4 гига — это ограничение для _одной программы_. Его обойти в 32-битной архитектуре не получится, да. А надо? А точно-точно надо? Ты не сумеешь обосновать необходимость этого, поскольку в реальности не существует рациональной аргументации за это. Нет, жирные регистры можно и без всеобъемлющего перехода на 64 бита (более того, можно удвоить и учетверить жирность их, если очень надо). Да, адресовать много памяти можно и без всеобъемлющего перехода на 64 бита. Смысл 64 битов только в общем адресном пространстве для архитектуры, и более ни в чём. Ну и в типа согласовании. Внутри себя это смесь «разноразрядных» устройств и технологий. И даже та AMD64, которую ты здесь нахваливаешь, не понимая, что она есть такое, имеет на самом деле меньшую (внезапно!) разрядность адресации памяти. Просто потому, что не надо никому так много памяти в настоящее время. Чтоб ты лучше понял суть сказанного, AMD64 — это такая PAE наоборот, когда отсчитывают от большего, а не от меньшего. Ну и плюс несколько новых 64-битных плюшек. Маркетинг и разводилово в лучшем виде.
	Ответить | Правка | Наверх | Cообщить модератору

	271. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (-), 13-Дек-18, 16:22
	> Вгрузить в оперативку более 4 гигов одним чихом можно было и раньше — при > помощи PAE. Вот знаешь что, давай ты такой умный этим и пользуйся. А я таки буду использовать линейные моделди адресных пространств в стиле фон-неймана. Потому что это удобно, и ниипет. И поэтому вон тот редактор графики (любой!) спокойно сожрет даже какой-нибудь скан A0 в диком разрешении не поперхнувшись. Если в системе в принципе есть достаточно оперативы. И наверное это - хорошо и правильно. А у тебя с твоими разглагольствованиями редактор тупо грохнется когда ему адресного пространства не хватит. И таки вгрузить картинку в память и что-то сделать с ее пикселями - это таки самый простой и логичный способ. Все остальное намного сложнее, медленнее и требует нефиговый объем нетривиального кода, который по сути попытается изобрести нечто типа свопфайлов, только через задний проход и без явной поддержки железом. Потому что в железо программы ща вообще не пускают и именно в настоящий HW-assisted paging подпертый MMU они еще и не вклинятся. Во избежание поимения всей системы. > Открою тебе страшную тайну: и больше можно было, если ещё увеличить разрядность адресации. Это напоминает мне ту городскую легенду, где чувак посмотрел что можно выжать из его древнего драндулета, если стырить пороховой ускоритель... > Ограничение в 4 гига — это ограничение для _одной программы_. Его обойти > в 32-битной архитектуре не получится, да. А надо? Да, надо. А почему, собственно, я не должен иметь возможность открыть БОЛЬШУЮ картинку в редакторе, например? Или еще что-то большое в память загнать целиком и поработать с этим со скоростью RAM, а не винча? Это как бы на несколько порядков разница по производительности. И мне видится очень тупым что я не могу адресовать всю оперативку одним линейным куском. Доступным одним куском а не лоскутным одеялом в куче процессов, если так удобнее и результативнее. > Ты не сумеешь обосновать необходимость этого, поскольку в реальности не существует > рациональной аргументации за это. Уже обосновал. А все эти PAE как по мне должны сдохнуть жестокой смертью, как самые извращенские костыли которые я когда либо видел. Это просто е...й стыд системной архитектуры. Впрочем у интеля в IA32 такого вообще есть. > имеет на самом деле меньшую (внезапно!) разрядность адресации памяти. Она имеет достаточную адресацию памяти для того чтобы отдать мне ВСЮ установленную в компе оперативу одним куском в моей программе, если мне что-то такое вдруг надо.
	Ответить | Правка | Наверх | Cообщить модератору

	282. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 17:02
	> Вот знаешь что, давай ты такой умный этим и пользуйся. А я таки буду использовать линейные моделди адресных пространств в стиле фон-неймана. Потому что это удобно, и ниипет. И поэтому вон тот редактор графики (любой!) спокойно сожрет даже какой-нибудь скан A0 в диком разрешении не поперхнувшись. Если в системе в принципе есть достаточно оперативы. И наверное это - хорошо и правильно. Я с год назад, кажется, приводил на этом форуме в пример сравнительно успешную работу старинного Фотошопа версии 5.5 с громадной картинкой размером 20000 х 20000 точек. Полноценной работой это, конечно, не назовешь, но тут дело принципа. 32-битный графический редактор способен схарчить и переварить такое файло. На большее в него захардкодили ограничения, ЕМНИП. Да, и я бы предпочел в качестве ПК компьютер Гарвардской архитектуры. Не делают-с, увы. > А у тебя с твоими разглагольствованиями редактор тупо грохнется когда ему адресного пространства не хватит. И таки вгрузить картинку в память и что-то сделать с ее пикселями - это таки самый простой и логичный способ. Все остальное намного сложнее, медленнее и требует нефиговый объем нетривиального кода, который по сути попытается изобрести нечто типа свопфайлов, только через задний проход и без явной поддержки железом. Потому что в железо программы ща вообще не пускают и именно в настоящий HW-assisted paging подпертый MMU они еще и не вклинятся. Во избежание поимения всей системы. Обходить ограничения научились ещё в допотопные времена работой с памятью через окошко (потому-то людям с прямыми руками и не требуются на самом деле колоссальные объёмы памяти и большая разрядность адресации). Ты что, до сих пор не в курсе? Чувак, я потрясён! :) > Это напоминает мне ту городскую легенду, где чувак посмотрел что можно выжать из его древнего драндулета, если стырить пороховой ускоритель... Загугли же наконец про то, что такое виртуальная память. > Да, надо. А почему, собственно, я не должен иметь возможность открыть БОЛЬШУЮ картинку в редакторе, например? Или еще что-то большое в память загнать целиком и поработать с этим со скоростью RAM, а не винча? Это как бы на несколько порядков разница по производительности. И мне видится очень тупым что я не могу адресовать всю оперативку одним линейным куском. Доступным одним куском а не лоскутным одеялом в куче процессов, если так удобнее и результативнее. Если руки не из нижней части спины, то это всё не обязательно. Как быстро вы все забыли, что ещё каких-то двадцать лет назад суперкомпьютеры имели сопоставимые с нынешними ПК вычислительные мощности, но при этом на них успешно выполнялись задачи для суперкомпьютеров, а на нынешних супер-ПК Ворд тормозит так же, как и тогда тормозил. > Уже обосновал. А все эти PAE как по мне должны сдохнуть жестокой смертью, как самые извращенские костыли которые я когда либо видел. Это просто е...й стыд системной архитектуры. Впрочем у интеля в IA32 такого вообще есть. То есть ты не осознаёшь, что AMD64 + EM64T — это тоже набор костылей, «расширенный и улучшенный»? Ну и замечательно, только с этого и надо было начинать, я бы не тратил своё время на чтение твоих графоманских простыней. :)
	Ответить | Правка | Наверх | Cообщить модератору

	293. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 17:41
	> успешную работу старинного Фотошопа версии 5.5 с громадной картинкой размером 20000 > х 20000 точек. Полноценной работой это, конечно, не назовешь, Ну а вот у меня NASAвская картинка на 300, если не ошибаюсь, мегапикселей - нормально открылась. Без вот этих вот оговорочек про полноценную работу. И вот так мне почему-то больше нравится. > но тут дело принципа. У меня простой принцип: компьютеры должны работать, а не канифолить мозг. И когда я не могу просто взять и просто воспользоваться всей оперативкой которую я установил, без дурных условий и оговорок - клятая железка греет мне мозг и это очков симпатий ей совсем не добавляет. > На большее в него захардкодили ограничения, ЕМНИП. Ну так юзер иначе повесится от такой "работы", когда аналог paging все время будет диском тарахтеть. В то время как половина оперативы компа не используется. Очень умно и эффективно. > Да, и я бы предпочел в качестве ПК компьютер Гарвардской архитектуры. Не > делают-с, увы. Програмить канительно. Кто не верит - ну вон атмеги и аттини есть. На них даже си натянули худо-бедно. И даже плюсы слегка. Но вот именно гарвардская природа таки основательно канифолит мозг и требует отдельных приседаний. ARM например умнее сделал - "электрически" у них ядро гарвардец. I и D шины - электрически разные. Поэтому оно может одновременно тащить инструкции и данные для них - по разным шинам. Одновременно. Но для софта это таки вывешено как фоннейман и програмить это все же не так геморно как настоящего гарвардца. > колоссальные объёмы памяти и большая разрядность адресации). Ты что, до сих > пор не в курсе? Чувак, я потрясён! :) Я в курсе что можно самому изобрести эрзац-своп и эрзац-mmu. Там вон чуваки на атмеге убунту забутявили - сэмулировав ARMv5 с MMU :D. Есть только одна проблема - они загрузки системы в минимальном виде ждали 2 часа, чтоли, а работа с шеллом больше смахивала на пошаговую стратегию - ваш ход, вы жмете букву. Ход переходит к AI, он обдумавает ваш ход минуту :) > Загугли же наконец про то, что такое виртуальная память. Я в курсе, спасибо. И на системном уровне это рюхается ядром и MMU. В которые user-mode софт в общем случае лучше не пускать, иначе расхакают всю систему вдрызг. Я также насмотрелся на всякие банки, окошки и проч. Достаточно для того чтобы возненавидеть все это и полюбить линейную адресацию и memory-mapped периферию. Потому что это просто, быстро, эффективно и не грызет мозг, в отличие от камасутры с переключениями банков, окошек, эрзацсвопов и прочей гадостью, заставляющей костылить убогость железа в софте. > Если руки не из нижней части спины, то это всё не обязательно. Ну как бы с точки зрения скорости работы и минимального объема кода, минимума глюков и проч - это самый простой и логичный вариант. > успешно выполнялись задачи для суперкомпьютеров, а на нынешних супер-ПК Ворд тормозит > так же, как и тогда тормозил. Я рад за суперкомпьютеры но у меня нет суперкомпьютерных задач. И таки вот конкретно мой компьютер таки не особо тормозит. Он достаточно мощный для того чтобы я его так по грубому завалить работами мог только весьма эпизодически. Ну ок, полный ребилд с ноля кернела со всеми наворотами в 8 потоков займет его на ~15 минут. Частичный или более скромную конфигу - меньше. А обычные задачи - блин у меня свопа то нет. Чтобы не наслаждаться латенси от paging. Ну zram вон есть, на случай если приперло. В него cold добро можно отгрузить компресанутым, если приперло. Но RAM, даже компреснутый и косящий под swap - не идет ни в какое сравнение с латенси винча :) > То есть ты не осознаёшь, что AMD64 + EM64T — это тоже набор костылей, То-есть я отлично осознаю что это набор костылей и далеко не предел мечтаний. Но это лучше чем IA32 и всякие PAE. А чего-то недорогого и сильно лучше пока особо и нет. Ну вот ARM еще появляются, да RISC-V на подходе. У ARM ядра в целом менее кривые, но при переходе 32 -> 64 они тоже ессно совместимостью с легаси обвесились. Без этого их порвут. RISC-V ... ну его в 32-битной инкарнации в штуках способных запустить linux никто не видел, так что там они могут и не париться :) но это лишь потому что они стартанули после начала заката 32-бит эпохи.
	Ответить | Правка | Наверх | Cообщить модератору

	355. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 01:51
	Ещё о Фотошопах. Photoshop 7 позволяет создать картинку размером 30000 на 30000 точек, то есть 900 мегапукселей. Её пустой стартовый вес — 2,51 ГБ. Photoshop CS позволяет создать картинку размером 300000 на 300000 точек, то есть 90000 мегапикселей. Стартовый вес пустого файла обещают нам аж в 251,5 ГБ. Достаточно или надо ещё? ;-) Дальнейших изысканий с последующими версиями я не проводил, ибо мне таки достаточно. Обращаю внимание твоё и всех адептов прогрессивной математики, что это 32-разрядные программы.
	Ответить | Правка | Наверх | Cообщить модератору

	397. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 14-Дек-18, 15:14
	> Photoshop 7 позволяет создать картинку размером 30000 на 30000 точек, то есть > 900 мегапукселей. Её пустой стартовый вес — 2,51 ГБ. ...и когда у меня в системе есть 16 гигз памяти, невозможность линейно адресовать всего-то 2.5 гигза (для кернела тоже надо адреса) - не находит понимания. Еще более иди0тски, когда прога тарахтит винчом экономя адресное пространство :D :D :D в то время как большая часть оперативы пустует. Циферок, блин, в математике не хватило. Волшебно. > Photoshop CS позволяет создать картинку размером 300000 на 300000 точек, то есть > 90000 мегапикселей. Стартовый вес пустого файла обещают нам аж в 251,5 ГБ. И это прекрасно. Но без 64 битов он не сможет держать его одним куском в памяти и эффективно с ним работать. А свопить на диск даже "всего-то" 2.5 гига - это ты как-нибудь без меня. Поттому что SSD при такой "работе" тормозить будет, конечно, умерерно, но протрется довольно быстро. А на винче - скорость работы будет такой, что на третий день такого работинга захочется послать все к чертям и заняться выращиванием рассады. > Обращаю внимание твоё и всех адептов прогрессивной математики, что это 32-разрядные программы. Спасибо, я видел как фотошоп работает когда он не может держать всю картинку в памяти. Смею заверить, увиденного хватило для того чтобы предоставить эту участь другим.
	Ответить | Правка | К родителю #355 | Наверх | Cообщить модератору

	401. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 14-Дек-18, 15:38
	Прекрасный комментарий, настоящий гимн неэффективности! Даже в совке такого махрового лицемерного трындежа не было. :-) Так ты эмбедовкой занимаешься, говоришь? Ну-ну… Большой привет клиентам! :-)
	Ответить | Правка | К родителю #397 | Наверх | Cообщить модератору

	453. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 15:33
	> Прекрасный комментарий, настоящий гимн неэффективности! Даже в совке такого махрового > лицемерного трындежа не было. :-) Гимн неэффективности - это когда машина хрустит винчом и решает задачу в десятки раз медленнее, вместо того чтобы просто взять и использовать весь свой имеющийся ресурс. > Так ты эмбедовкой занимаешься, говоришь? Ну-ну… Большой привет клиентам! :-) А в эмбедовке все просто: задача или умещается в ресурсы, или нет. И если умещается - то в общем то дальнейшие оптимизации имеют смысл разве что для души и прочих перспектив поюзать этот код потом и на более дохлом хардваре, или под более крутой поток данных, или там что еще. И в эмбедовке только сказочный талпайоп изначально хватает камень, ресурсы которого заведомо впритык. Уж разработка всяко делается на железе с запасом. А потом смотрится - если можно малой кровью обрубить под более хилую железку, это проносит какие-то профиты и не тормозит проект на годы - ок, может быть. А так еще дедушка Кнут сказал нам что преждевременная оптимизация - корень всех зол. Мы его таки услышали.
	Ответить | Правка | К родителю #401 | Наверх | Cообщить модератору

	403. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (514), 14-Дек-18, 15:49
	> И это прекрасно. Но без 64 битов он не сможет держать его > одним куском в памяти и эффективно с ним работать. Вообще то, эффективнее всего работать не кусками влезающими в оперативку, а с кусочками влезающими в кеш процессора. Насколько я знаю, видео все и всегда обрабатывают как раз такими кусочками.
	Ответить | Правка | К родителю #397 | Наверх | Cообщить модератору

	454. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 15:43
	> Вообще то, эффективнее всего работать не кусками влезающими в оперативку, а с > кусочками влезающими в кеш процессора. Аксиома: если математика несложная, а картинка большая - основное время работы с ней что так что эдак уйдет на выгруз из оперативы источника и вгруз в оперативу результата. Кэш как таковой кэш ничего с этим сделать не может. Ваша мысль имеет право только в допущении что все упирается в процессор, а не оперативку. Но процессоры сейчас быстрые и оперативку обгоняют сильно, по поводу чего и есть кэши. Так что какие-то такие соображения могут иметь смысл только для каких-то очень частных случаев, когда математика применяемая к кускам картинки очень крутая, обращается к пикселам много раз подряд и это - какой-то существенный процент времени по сравнению с IO с оперативой. А если вы жуете всю картинку - то вы ее всю прочтете и запишете в оперативу. Что с кэшом, что без. И таки при лопатинге 2.5 гигз кэш во многих случаях погоды вообще не сделает. Лучшее что там может закешироваться - сам алгоритм, но никак не данные которые он жевал. Да, я развлекался с компрессором данных. И когда у меня source и destination уместились в кэш, на повторных сжатиях и распаковках выигрыш получился офигительный. На однократной профита не наступает - в конечном итоге источник придется взять оперативки, а результат записать в оперативку. Что с кэшом, что без. Куда такой профит прикрутить - я толком и не придумал. Ну, можно бенчмарки накручивать, наверное. Если 7z b меряет 20000 MIPS, то подмухлевав в таком духе можно получить и все 100000 если не больше. Проблема в том что в реальных сценариях это никто не увидит. > Насколько я знаю, видео все и всегда обрабатывают как раз такими кусочками. Хотелось бы пруфца на столь храброе заявление. Желательно в исходниках.
	Ответить | Правка | К родителю #403 | Наверх | Cообщить модератору

	457. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (514), 15-Дек-18, 16:21
	Помимо производительности шины памяти есть так же время запроса. Насколько мне известно кеш второго уровня страничный и если процессор запрашивает данные из страницы которой нет в кеше, то содержимое одной из страниц кеша сбрасывается в оперативку. И только после того как сброс будет полностью завершён будет произведён запрос блока из оперативки. Это операция занимает около 100нс и вообще не ускоряется с появлением нового железа, скорость света будь она не ладна. То есть узким местом будет даже не шина, а пинг до оперативки. Всего 10 млн. операций с памятью в секунду, пентиум-1 умрёт со смеху обрабатывая картинку за тоже время, что и топовый i7.
	Ответить | Правка | К родителю #454 | Наверх | Cообщить модератору

	467. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 15-Дек-18, 20:47
	> Помимо производительности шины памяти есть так же время запроса. Да. Однако RAM сильно отстает и на последовательном доступе, и на рандомном. В случае последовательного, кстати, характерного для работы с изображениями, GPU вообще используют специальные виды памяти. И таки даже GDDR5, не говоря про HBM и проч - очень хорошо показывает DDR3/4 кто в этом рулит. Пример: ПСП DDR3 и GDDR5 примерно сравнимых времен покупки около 20 GB/sec vs 180GB/sec. Разница почти в 9 раз. На именно рандомном доступе так конечно не будет. Но для работы с картинками - последовательный доступ достаточно характерен. Именно рандомно хватать пикселы картинки по всей площади - так можно, но что это за процессинг картинки лично я не понимаю. > секунду, пентиум-1 умрёт со смеху обрабатывая картинку за тоже время, что > и топовый i7. Таки со времен первого пентиума щины стали быстрее, частоты увеличились везде, DDR тоже улучшился. И в результате это скорее "одноплатник с половину кредитки умрет со смеха, уделав в 30 раз огроменный железный ящик, потребляя в 30 раз меньше энергии". Ну вот как-то так технологии со времен первого пня ушли, что первопень ползает со скоростью когда даже MIPS в роутере-мыльнице будет над ним смеяться.
	Ответить | Правка | К родителю #457 | Наверх | Cообщить модератору

	492. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 16-Дек-18, 00:03
	Напомню лицам с девичьей памятью, что у первопня и вообще тогдашних процессоров был сравнительно короткий конвейер и совсем маленький множитель тактовой частоты, что вкупе с низком латентностью памяти прекрасно работает на сравнительно маленьких порциях данных. А в современных процессорах с многомегабайтными кешами нескольких уровней и длиннющим конвейером, большими множителями, очень большой латентностью ОЗУ (но при широкой оного шине) высокая производительность имеет место только для больших порций данных. На скромных и компактных «морально устаревших» программах, умевших-таки обрабатывать огромное файло, не умещавшееся даже в ОЗУ, а не только в кеш, выигрыш ультрасовременных вычислительных железяк внезапно нивелируется, если их не грузить чем-то очень объёмным. Что недвусмысленно намекает и на некоторые свойства железа, и на умения погромиздов, пишущих модно-прогрессивный софт. Я приводил уже в пример суперкомпьютер начала девяностых, имевший максимально 128 гигов памяти. Но оном суперкомпьютере люди решали суперкомпьютерные задачи. На сопоставимом по «чистой» вычислительной мощности современном писюке веб-макака способна разве что писать однодневный ненужнософт в невероятно прожорливых IDE. Мощность как бы выросла, ага, и «время ращработчиков дороже стоит», а польза от вычислений снизилась на многие-многие порядки.
	Ответить | Правка | К родителю #467 | Наверх | Cообщить модератору

	494. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 16-Дек-18, 16:11
	> вкупе с низком латентностью памяти прекрасно работает на сравнительно маленьких порциях > данных. А в современных процессорах с многомегабайтными кешами нескольких уровней и > длиннющим конвейером, большими множителями, очень большой латентностью ОЗУ (но при широкой > оного шине) высокая производительность имеет место только для больших порций данных. И тем не менее - с тех пор АБСОЛЮТНО ВСЕ разогналось как минимум В РАЗЫ. Настолько что по скорости и латенси памяти этому УГ может воткнуть даже мипсовая мыльница-роутер, потому что там видите ли DDR2, а то и 3 нормальный впаяли, на приличной частоте. А у пенька извините что было? EDO? Или в лучшем случае SDRAM? Одно это обеспечит ему чебурашью скорость работы. Придирчивый народ мониторит в тех же армовских одноплатниках частоты/ширину шины. Потому что одно дело DDR2 на 16-битной шине, и совсем другое 32 и тем более 64 бита DDR3 c более приличной частотой. Он такой красивый и на больших порциях выиграет, и на маленьки. Потому что порции при лопатинге картинки уж наверное покрупнее 16 битов подразумевались, и наверное с каким-никаким линейным доступом - по другому картинки процессят только очень странные люди, которым производительность явно не интересна была: они мигом аннулируют любые намеки на кеширование, префетч и создают море оверхеда на шине памяти т.к. там для каждой операции потребуется слать адреса, а не просто запустить отправку жирного блока и грести лопатой, уже без отсылки адресов на каждую порцию, чуть ли не по порции размером с ширину шины каждый такт, что гораздо веселее. > На скромных и компактных «морально устаревших» программах, умевших-таки обрабатывать > огромное файло, не умещавшееся даже в ОЗУ, Это все круто, НО есть весьма характерный tradeoff между памятью и скоростью. И как бы экономия памяти означает тормозной процессинг. Особенно весело когда половина оперативы в результате пустая, а программа занимается тасовкой файлов по причине нехватки, блин, циферок в своей математике. Очень "эффективно" получается. При том что против идеи процессинга данных не влезающих в RAM я ничего не имею. Это по своему красиво. Но производительность зачастую получается издевательской по сравнению с тем что можно получить врузив датасет в рам - и так делают только когда данные реально большие или неограниченно растут. Ну типа как OSMная база данных, особенно ежели со всей историей редактирования - там да, никакой RAM не хватит, и с течением времени данных будет только больше. > кеш, выигрыш ультрасовременных вычислительных железяк внезапно нивелируется, если их > не грузить чем-то очень объёмным. Таки оно все-же выигрывает даже и так. Из-за апгрейда остальных частей системы, и вообще. А так то можно порассуждать о том что будет если кэши вырубить, что пентиуму, что core i9. Они оба будут жалкими, но пень все-же продует в разы и так. Но менее эпично чем обычно :) > Что недвусмысленно намекает и на некоторые свойства железа, и на умения погромиздов, Погромизды стали оптимизировать свой софт под свойства актуального железа, делая удобно именно ему. Чтобы оно реализовывало свой потенциал. Таки железо и софт шли навстречу друг другу. Пэтому вот вам выравнивание структур на линию кэша. Даже если это и делает структуру более жирной, зато скорость доступа улучшается, т.к. кэшу удобно стало. А вот крипто, ворочает 64 бита за раз. Потому что проц может за такт долбануть 32 бита, а может 64. И если за тот же такт вдвое больше обмолочено, это профит. Почти в 2 раза. Нахаляву. И сама математика такая что уже не избегает операций регистр-регистр, потому что РОНов типа много. > уже в пример суперкомпьютер начала девяностых, имевший максимально 128 гигов памяти. > Но оном суперкомпьютере люди решали суперкомпьютерные задачи. При том эти задачи были интересны лишь очень узкому кругу лиц. И как бы тогда никто не смотрел видео на компьютерах. И картинки в 300Мпикс всерьез никто не редактировал. Ну вот может кроме нескольких рож с суперкомпьютерами на всю планету. Типовой же юзерь 5 фотошопа с пентиумом получив на вход 300Мпикс картинку очень быстро отползет, увидев как его фотож... с этим реально работает. Теоретически, конечно, он через недельку прожует это. Практически оно юзеру через недельку - не очень то и хотелось. А про монстроIDE и софт с полураспадом в год я таки согласен :)
	Ответить | Правка | К родителю #492 | Наверх | Cообщить модератору

	515. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 16-Дек-18, 22:14
	> И тем не менее - с тех пор АБСОЛЮТНО ВСЕ разогналось как > минимум В РАЗЫ. Настолько что по скорости и латенси памяти этому > УГ может воткнуть даже мипсовая мыльница-роутер, потому что там видите ли > DDR2, а то и 3 нормальный впаяли, на приличной частоте. А > у пенька извините что было? EDO? Или в лучшем случае SDRAM? > Одно это обеспечит ему чебурашью скорость работы. Разогнали шины и множители, что даёт эффект на больших порциях данных (aka bloatware). А реальные «железные» скорости не разогнались особо, потому что там физика. Если сильно разгонять, начнёшь радио слушать чипом. Надеюсь, ты ещё помнишь про то, как получается «частота процессора», и про обещания Интела обеспечить всем коммунизм^W по 10 ГГц в каждый дом? > Придирчивый народ мониторит в тех же армовских одноплатниках частоты/ширину шины. Потому > что одно дело DDR2 на 16-битной шине, и совсем другое 32 > и тем более 64 бита DDR3 c более приличной частотой. Он > такой красивый и на больших порциях выиграет, и на маленьки. Как ты думаешь, почему оперативную память делают по «морально устаревшим» техпроцессам, и почему внутренняя скорость чипов памяти не растёт? >  c более приличной частотой Нету там внутри никакой «более приличной частоты». Только ширина шины больше. И накладные расходы на её обслуживание, ха-ха-ха. Старую память контроллеру обойти было быстро не только потому, что её было мало. :) Ты пойми: бесплатный сыр бывает только в мышеловке. >> На скромных и компактных «морально устаревших» программах, умевших-таки обрабатывать >> огромное файло, не умещавшееся даже в ОЗУ, > Это все круто, НО есть весьма характерный tradeoff между памятью и скоростью. > И как бы экономия памяти означает тормозной процессинг. Особенно весело когда > половина оперативы в результате пустая, а программа занимается тасовкой файлов по > причине нехватки, блин, циферок в своей математике. Очень "эффективно" получается. Я уже видел, как по стратегии «займём всю память, она же не должна простаивать» постоянно приходится пинать ОС вручную, чтобы освободила память для других приложений, а «только что закрытым» она понадобится не раньше, чем я это решу, а не тупой диспетчер памяти, настроенный обезьянами. Когда я читаю твои развесистые рассуждения о том, как правильно использовать памяти, мне кажется, что ты всё-таки на самом деле не понимаешь, что такое виртуальная память и что такое неймановская архитектура. Слова умные вроде знаешь, и даже складывать их в предложения умеешь, а смысла никакого из них не рождается. Представь, что ОЗУ — это быстрый кэш, не более того. Если ты забил промежуточный буфер между медленной долговременной памятью (диском) и процессором, то быстро ехать уже не получится даже при всём желании. Поэтому правильно держать эту буферную память максимально свободной, ибо иначе придётся постоянно лезть на диск за каждым ссаным байтом, пока ОЗУ будет занято тем, что «может пригодиться, ведь его только что недавно закрыли». И это в каждый момент времени! Ага, я такое видел. Спасибо, больше не хочу. Предпочитаю лучше подождать дополнительных 100 мс при каждом запуске приложения, а не постоянно доставать всё нужное из свопа. > При том что против идеи процессинга данных не влезающих в RAM я > ничего не имею. Это по своему красиво. Но производительность зачастую получается > издевательской по сравнению с тем что можно получить врузив датасет в > рам - и так делают только когда данные реально большие или > неограниченно растут. Ну типа как OSMная база данных, особенно ежели со > всей историей редактирования - там да, никакой RAM не хватит, и > с течением времени данных будет только больше. Бджд, для высокой производительности программ надо всего лишь писать производительный код на максимально близком к железу уровне, вот и всё. А не превращать всё в «интерпретатор языка высокого уровня». Почему-то у хорошей сисясто-ассемблерной программы обычно нет проблем с производительностью даже на старом железе и скудной памяти, а у модно-прогрессивных аппликух постоянно нехватка ресурсов, «надо докупить ещё, память нынче стоит копейки». >> кеш, выигрыш ультрасовременных вычислительных железяк внезапно нивелируется, если их >> не грузить чем-то очень объёмным. > Таки оно все-же выигрывает даже и так. Из-за апгрейда остальных частей системы, > и вообще. А так то можно порассуждать о том что будет > если кэши вырубить, что пентиуму, что core i9. Они оба будут > жалкими, но пень все-же продует в разы и так. Но менее > эпично чем обычно :) Внутренние скорости работы чипов и прочего железа — гугл ит, плиз, энд рид ит. >> Что недвусмысленно намекает и на некоторые свойства железа, и на умения погромиздов, > Погромизды стали оптимизировать свой софт под свойства актуального железа, делая удобно > именно ему. Чтобы оно реализовывало свой потенциал. Таки железо и софт > шли навстречу друг другу. Нет, товарищ комсорг, не так всё было. Никто ничего не оптимизировал, ибо оптимизацию ваши товарищи по комсомолу и партии возложили на трудящихся в формате регулярного похода в магазин за новым железом. Дальше лень.
	Ответить | Правка | К родителю #494 | Наверх | Cообщить модератору

	523. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (523), 17-Дек-18, 02:52
	> Разогнали шины и множители, что даёт эффект на больших порциях данных (aka bloatware). То-есть если я бэкап жму - это bloatware, оказывается? Да и фоточки разрешением 640х480 не втыкают. > А реальные «железные» скорости не разогнались особо, потому что там физика. Сильнее всего в те поры физика упиралась в нормы техпроцессов и результирующее оттуда потребление и тепловыделение. По мере уменьшения элементов схем тепловыделение уменьшалось, довольно круто. Пропорционально 3...4 степени. Кроме того - не умели делать компактное, массовое и эффективное охлаждение на подобные мощности (в серверах лучше, но звук!!!). А еще - преобразователи питания и управление питанием, DVFS и проч. С тех пор как минимум... - Многофазные схемы питания с регулируемым вольтажом. Которые не пасуют перед отгрузкой 1V 100A в проц. Ну вот такой вот трамвайчик. - Полимерные lowESR кондеры, которые и не вскипают от нагрева своим же ESR. - DVFS, power & clock gating - позволили схемам быть быстрым в пике но не жрать как трамвай на холостых режимах. - Частоты стали выше в разы. Глобально, везде. - Вентиляторами научились управлять с регулировкой оборотов. - Сами технологии охлаждения здорово прокачали (на десктопах, в лаптопах, а теперь и в мобильных устройствах). - Шины - усовершенствовали и довольно радикально сменили парадигмы местами. Это была эпоха начала конца параллельных шин. - Оператива сейчас напрямую к процу, а не чипсету. Минус латенси гейтовки CPU FSB <-> RAM чипсетом. > Если сильно разгонять, начнёшь радио слушать чипом. В железном ящике? :) А так слив по transmission line и антеннам засчитан. Да, это пришлось узнать не только RF engineer'ам, но и цифровикам c энного момента. Как раз поэтому. Как ты думаешь, почему в IDE стало 80 проводов? :) Посотри на кабель SATA, особенно 6Gbps. Это не просто кусок провода. А дорожки на платах следуют хитрым паттернам и идут парами. Не просто так. Они все стали низковольтными, дифференциальными, более последовательными и менее синхронными в отличие от наивных первобытных шин сделанных "в лоб". А так у цифры фронты крутые - даже в "низкоскоростной" схеме уровня ардуины по этому поводу можно выкусить. Спроси у Зенкова какой спектр у прямоугольника с его фронтами. > Интела обеспечить всем коммунизм^W по 10 ГГц в каждый дом? Таки интел лоханулся именно по линии частот и тепловыделения. Загнать кремний на 10ГГц как таковой можно. Но не миллиардом транзисторов, в этом случае он умрет по перегреву. Вести 10ГГц по плате так себе идея. Реально по FR4 разводят до примерно 5. Кто не верит - смотрит домашние роутеры. Хотя в спутникаовых штуках и 10 вроде делают, но выглядит специфично. Собственно опытом RFщиков пользуются. Когда надо, излучает. Когда не надо - не излучает. Правда теперь цифровики реально мыслят как СВЧшники наполовину. Даже не только из-за мегагерцев, но и из-за наносекундных фронтов, которые разлетаются независимо от периодичности. Если кто не понял - возможны странные методы синтеза сигнала, когда периодики с энным периодом как таковой может и не быть. Какой период у wideband сигналов? > Как ты думаешь, почему оперативную память делают по «морально устаревшим» техпроцессам, > и почему внутренняя скорость чипов памяти не растёт? А потому что смысла нет. Если сделать DRAM меньше по размеру элемента, конденсаторы DRAM начнут жутко утекать, вместо счастья случится EPIC FAIL. Этот эффект очень сильно долбит на мелких техпроцессах. И там где потребление важно, борьбе с этим посвящен целый раздел технологий power management. Потребление ничего не делающего тонкого чипа довольно сильно состоит из утечек. А когда так DRAM делает - она еще и склерозом становится. И чем жарче - тем лучше. Любители тырить пароли из ребутнутого компа - уважают жидкий азот :) > Нету там внутри никакой «более приличной частоты». Да все там есть. Хотя самые высокие частоты синтезируют прямо в чипах, чтобы не тащить по плате. Man PLL. > Только ширина шины больше. А теперь посмотри в вике что означает "DDR" - одно это делает шину вдвое быстрее на той же частоте. Даже если забить на прочие оптимизации и ощутимый пересмотр "электрики" в сторону дружественности высоким скоростям. > И накладные расходы на её обслуживание, ха-ха-ха. Старую память контроллеру обойти > было быстро не только потому, что её было мало. :) Старая память была тормозной аки трактор, неоптимальной по циклам шины, дурной по физике, тормозной по частотам. И работала с непотребной скоростью. Пеньку с EDO, да даже и с SDR SDRAM - воткнет даже 20-баксовая MIPSовая мыльница с DDR'ом. > Ты пойми: бесплатный сыр бывает только в мышеловке. Бывает эволюция технологий. Физику нельзя обмануть. Но можно взять на свою сторону. Там где мы хотим излучать - антенна. Не хотим - делаем transmission line (wave guide). Это просто делается по разному. С явным осмыслением. Да, это уже не просто протяжка дорожек наобум и требует странные скиллы. И не всегда выходит с первого раза даже с крутейшими CAD и симуляторами. ...а цена в чуть ином. Например DVFS и управление вентилями позволяет системе с одной стороны не выть как пылесос в холостом режиме, с другой - показывать впечатляющую производительность. Но это делает систему более хрупкой. Можно срубить сдуру вентилятор. Можно заказать чипу питания напряжение выше чем он физически выдержит на этой частоте. Начинают требоваться сервисные процики, которые этим займутся в жестком реальном времени. Система становится сложнее и хлипче. Ее старт напоминает запуск ракеты. > Я уже видел, как по стратегии «займём всю память, она же не > должна простаивать» постоянно приходится пинать ОС вручную, Кому приходится - тот пусть этим и страдает. А я в моей ОС не занимаюсь ручным менеджментом память по счастью. > такое виртуальная память и что такое неймановская архитектура. Слова умные вроде > знаешь, и даже складывать их в предложения умеешь, а смысла никакого из них не рождается. Таки понимаю. Это ты не понимаешь что в обозримом будущем возможно вообще вся память в системе станет адресуемой напрямую. Без такого понятия как стораж. NVDIMM тому первый звоночек, но ни разу не последний. Вообще идея пропихать NAND через SATA - изврат. И даже через PCI-E. Он логичнее смотрится замапленым напрямую в адреса, с тонким и быстрым слоем трансляции. MRAM/FRAM - и подавно. Упомянутых кстати уже промышленно делают. Ramtron так по жизни для индустриалов делает "вечные EEPROM", Ti слегка это лицензировал для своих МК. > Представь, что ОЗУ — это быстрый кэш, не более того. Скоро, похоже, сторажи станут "медленным RAM", как мне кажется. Периферия уже стала, она вся сплошь "memory mapped". Это удобно. И сишникам с точки зрения програмизма, и виртуалкам, достаточно очевидный IOMMU позволяет отрезать железку в VM. Делая то же что MMU, но с другой стороны. > буфер между медленной долговременной памятью (диском) и процессором, то быстро ехать > уже не получится даже при всём желании. Плохо стыкуется с примером 300Мпикс картинки и процессинга ее пикселей. Вгрузить ее с диска 1 раз, к тому же сжатую. Декомпресс и любая возня с пикселями будут намного лучше, если попадут в хотя-бы RAM, без насилия над диском вообще. На линейных операциях характерных для обсчета картинок к тому же неплох даже обычный RAM. Хотя GDDR или HBM в GPU лучше. Но их меньше, потому что они дорогие и не апгрейдабельные. > буферную память максимально свободной, ибо иначе придётся постоянно лезть на диск > за каждым ссаным байтом, пока ОЗУ будет занято тем, что «может > пригодиться, ведь его только что недавно закрыли». И тем не менее, по моему опыту, жирный дисковый буфер - делает работу с ОС намного приятнее. По сути превращая медленный стораж в подобие быстрого рамдиска. Спору нет, если все забить приложениями - эта иллюзия отвалится. Поэтому забивать память под завязку приложениями все же не стоит. ...но если картинка весила допустим 5 гигз, в системе было 16, то у меня еще 11 гигз на все такое прочее. А обсчитать картинку как просто массив в оперативе явно быстрее чем таскать ее расжатую версию из свопа с диска и чего там еще. Вот отлить несколько гигз на диск - это не быстро по хоть каким стандартам. И поэтому фотожоп с 300Мпикс картинке на первом пне - не упадет, но скорость его работы - заманает в край. В отличие от скорости работы любого редактора на машине с 16 гигз. > лучше подождать дополнительных 100 мс при каждом запуске приложения, а не > постоянно доставать всё нужное из свопа. У меня нет свопа. Как максимум у меня есть zram, типа-своп в сжатом рамдиске. Если оперативы хронически не хватило - холодные данные можно попробовать закомпрессить, в надежде что вот так ее все же хватит. Если и так не хватит - и нафиг. Камасутра с 5-м фотошопом на пентиуме и 300 мпикс картинкой - не ко мне. > Бджд, для высокой производительности программ надо всего лишь писать производительный > код на максимально близком к железу уровне, вот и всё. С современным железом это легче сказать чем сделать. Начиная с того что реально код не имеет дело с блоками выполнения. Он попадает в uCode ROM и тот разваливает его на микрооперации, а что случится дальше, а также сколько и каких блоков фактически есть в том или ином камне - известно лишь крайне приблизительно. Кроме того - при чрезмерном увлечении код получается не портабельным или обладает хреновой производительностью на других архитектурах, если там сделано иначе. А так то да, дрова в досе и даже 95 писали на асме. Было круто и быстро. Но работало только на x86. А нтя таки с дровами на си уже была. Поэтому и была неповоротливой, зато таки портированной на кучу архитектур. Этот тренд и в остальных системах продолжился. > А не превращать всё в «интерпретатор языка высокого уровня». Как бы интерпретаторы никогда не были быстрыми. Еще со времен бэйсика. > Почему-то у хорошей сисясто-ассемблерной программы обычно нет проблем > с производительностью даже на старом железе и скудной памяти, а у модно-прогрессивных > аппликух постоянно нехватка ресурсов, «надо докупить ещё, память нынче стоит копейки». И все же, даже если ты запустишь чисто сишный вариант допустим современного крипто на чем-то 32-битном а потом на сравнимом 64-битном, разница будет довольно убедительной. Так же с мультимедийным добром и прочей тяжелой математикой. А где еще производительность собственно нужна? Ну наверное не в туповэйтинге юзерского ввода. > Внутренние скорости работы чипов и прочего железа — гугл ит, плиз, энд рид ит. Хотите об этом поговорить? :) Я как бы в курсе ПСП шин. И так для понимания... - ПСП шины памяти на K6-2 (даже покруче первого пентиума) около 600Мб/сек была. - ПСП DDR3 у моего десктопа около 20 Гб/сек. - ПСП GPU GDDR5 под 180Гб/сек. Это более-менее линейный доступ. Первые 2 измерены мемтестами, последнее opencl'ными бенчами похожими по смыслу. И как угодно но при прочих равных линейный доступ к оперативе, типовой для обсчета картинки, воткнет той штуке эпохи пентиумов в 33 раза на типовых паттернах характерных для обсчета картинок. Но еще лучше будет если это влезет в GPU и туда придет opencl фильтр, который мало того что массово SIMDшный как черти что, так еще и ПСП эвон какой. И он таки реально в разы быстрее основного cpu сжует это. Поэтому и GPU, собственно - хорошо с графикой работает. > Нет, товарищ комсорг, не так всё было. Никто ничего не оптимизировал, Посмотри на эволюцию крипто и не тупи. Симметричные алгоритмы и хэширование. Salsa, chacha, sha-3, да даже AES... их лучше на 64-бит проце крутить. Больше за 1 такт обсчитывается. И вот так было везде где скорость счета кого-то колыхала. Будь то графические фильтры или мультимедийные кодеки или что там еще. > ибо оптимизацию ваши товарищи по комсомолу и партии возложили на трудящихся в > формате регулярного похода в магазин за новым железом. Да ну ерунда, не все же - вебмакаки. Есть и алгоритмисты. И они таки тоже на 32 бита забили. А как я это узнал? Блин попробовал найти алгоритмов под 32 битный микроконтроллер. И обчертыхался. Таки да, 64-бит математика там есть, и даже работает, но таки из 32-бит регистров она получается медленнее. И код жирнее, чем если нативный юнит с которым оперировали был бы 32 бита. А на 64 бит проце оно конечно же офигенно раскладывается.
	Ответить | Правка | К родителю #515 | Наверх | Cообщить модератору

	532. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Ю.Т. (?), 17-Дек-18, 08:39
	> Сильнее всего в те поры физика упиралась в нормы техпроцессов и результирующее > оттуда потребление и тепловыделение. По мере уменьшения элементов схем тепловыделение > уменьшалось, довольно круто. Пропорционально 3...4 степени. Почему не 7...8? Где теплоёмкость? Тепловыделение в электронных элементах зависит от объёма единичного элемента, который *в общем* пропорционален 3-й степени линейного размера, силы протекающего тока и частоты переключений.
	Ответить | Правка | К родителю #523 | Наверх | Cообщить модератору

	548. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 17-Дек-18, 10:39
	>> Разогнали шины и множители, что даёт эффект на больших порциях данных (aka bloatware). > То-есть если я бэкап жму - это bloatware, оказывается? Да и фоточки > разрешением 640х480 не втыкают. Не в кассу. Будьте добры высказывать ваши тезисы по существу, тов. комсорг. >> А реальные «железные» скорости не разогнались особо, потому что там физика. > Сильнее всего в те поры физика упиралась в нормы техпроцессов и результирующее > оттуда потребление и тепловыделение. По мере уменьшения элементов схем тепловыделение > уменьшалось, довольно круто. Пропорционально 3...4 степени. Техпроцессы считают по производственному оборудованию, ёпт, а не по транзисторам. :) Тепловыделение делают настолько высоким, сколько можно остудить за приемлемую стоимость без стремительной деградации кристалла. А можно сделать любым, да. В том числе таким, что печка i9 будет работать при комнатной температуре вообще без радиатора. Но будет немножко не так быстро. И в этом месте любому здравомыслящему человеку должно стать понятно, что прогрессивные современные процессоры уже с завода разогнаны. Самую малость, ага, чуть-чуть. И ещё это трезвомыслящим людям повод для размышлений о том, насколько велики на самом деле внутри архитектурные изменения в сравнении с Pentium Pro. Если мысленно отрезать, эксперимента ради, весь кэш, то останется из внутренних отделов… ой, какое всё знакомое! Что ж ты делаешь, Интел! > Кроме того - не умели делать компактное, массовое и эффективное охлаждение на > подобные мощности (в серверах лучше, но звук!!!). А еще - преобразователи > питания и управление питанием, DVFS и проч. С чего ты взял, что не умели? Или речь про теплотрубки? Ну да, на писяках этого когда-то не было. А схемы питания с каких пор стали рокетсаенсом? Просто не гнали первопни до тепловыделения под 300—500 Вт, как гонят i9. П-ц, натуральный же утюг. >[оверквотинг удален] > - DVFS, power & clock gating - позволили схемам быть быстрым в > пике но не жрать как трамвай на холостых режимах. > - Частоты стали выше в разы. Глобально, везде. > - Вентиляторами научились управлять с регулировкой оборотов. > - Сами технологии охлаждения здорово прокачали (на десктопах, в лаптопах, а теперь > и в мобильных устройствах). > - Шины - усовершенствовали и довольно радикально сменили парадигмы местами. Это была > эпоха начала конца параллельных шин. > - Оператива сейчас напрямую к процу, а не чипсету. Минус латенси гейтовки > CPU FSB <-> RAM чипсетом. Некоторые элементы значительно улучшены, верно, и появилось чуть нового. Но всё остальное, ты уж извини, это не рокетсаенс. И не надо тут людям вешать на уши про управление оборотами вентиляторов, смешно же читать. :) А шины просто расширили, по сути. Никаких научно-технических прорывов не было. Касательно ОЗУ — ты хоть сам себе честно ответь на вопрос: CL 2 и CL 20 — это сколько разницы в абсолютной скорости на уровне ячеек, и на уровне шины, и на уровне контроллера? Про эффективность так про эффективность! ;-) >[оверквотинг удален] > засчитан. Да, это пришлось узнать не только RF engineer'ам, но и > цифровикам c энного момента. Как раз поэтому. > Как ты думаешь, почему в IDE стало 80 проводов? :) Посотри на > кабель SATA, особенно 6Gbps. Это не просто кусок провода. А дорожки > на платах следуют хитрым паттернам и идут парами. Не просто так. > Они все стали низковольтными, дифференциальными, более последовательными и менее синхронными > в отличие от наивных первобытных шин сделанных "в лоб". > А так у цифры фронты крутые - даже в "низкоскоростной" схеме уровня > ардуины по этому поводу можно выкусить. Спроси у Зенкова какой спектр > у прямоугольника с его фронтами. Вот и пришлось менять параллельные шины на последовательные. Чтоб на высоких скоростях не слушать сплошное радио всеми внутренними потрохами и внешними устройствами. Радио не буквально, разумеется, а в виде помех и наводок, ибо местами на несколькогигагерцовых частотах мелкие проводники сами начинают излучать. Таки да, внутри железного ящика. :) >> Интела обеспечить всем коммунизм^W по 10 ГГц в каждый дом? > Таки интел лоханулся именно по линии частот и тепловыделения. Загнать кремний на > 10ГГц как таковой можно. Но не миллиардом транзисторов, в этом случае > он умрет по перегреву. Загнать-то можно. Ещё в какие годы Межделмаш сделал транзистор, переключающийся на 100+ ГГц. Только с этого нет пользы, ибо на высоких частотах появляются новые факторы из-за новых физических явлений, а не только тепловое излучение. >> Как ты думаешь, почему оперативную память делают по «морально устаревшим» техпроцессам, >> и почему внутренняя скорость чипов памяти не растёт? > А потому что смысла нет. Если сделать DRAM меньше по размеру элемента, > конденсаторы DRAM начнут жутко утекать, вместо счастья случится EPIC FAIL. Этот > эффект очень сильно долбит на мелких техпроцессах. И там где потребление > важно, борьбе с этим посвящен целый раздел технологий power management. Потребление > ничего не делающего тонкого чипа довольно сильно состоит из утечек. А > когда так DRAM делает - она еще и склерозом становится. И > чем жарче - тем лучше. Любители тырить пароли из ребутнутого компа > - уважают жидкий азот :) Ну вот, вроде как человек в теме и в курсе всех проблем. А за системду топит. Непостижимо. Заплатили? Скажи хоть сколько. Может и я начну писать за деньги агитпродукт за системду. >> И накладные расходы на её обслуживание, ха-ха-ха. Старую память контроллеру обойти >> было быстро не только потому, что её было мало. :) > Старая память была тормозной аки трактор, неоптимальной по циклам шины, дурной по > физике, тормозной по частотам. И работала с непотребной скоростью. Пеньку с > EDO, да даже и с SDR SDRAM - воткнет даже 20-баксовая > MIPSовая мыльница с DDR'ом. Ну я не про аж такую старую. Берём 20-летней давности SDRAM типа PC-100, например. > Таки понимаю. Это ты не понимаешь что в обозримом будущем возможно вообще > вся память в системе станет адресуемой напрямую. Без такого понятия как > стораж. NVDIMM тому первый звоночек, но ни разу не последний. Вообще > идея пропихать NAND через SATA - изврат. И даже через PCI-E. > Он логичнее смотрится замапленым напрямую в адреса, с тонким и быстрым > слоем трансляции. Сомневаюсь в скором наступлении этого светлого будущего. Это неэффективно с точки зрения накладных расходов для большинства применений. То есть сделать-то можно, но мало кому это на самом деле нужно. А кому нужно, те не удовлетворятся ширпотребом. Жадные производители настолько зажрались, что распаивают на материнках лишние слоты с расшаренными линиями. Зато всё в разноцветных огнях светодидов, разукрашено в цвета китайского дракона и так далее. > MRAM/FRAM - и подавно. Упомянутых кстати уже промышленно делают. Ramtron так по > жизни для индустриалов делает "вечные EEPROM", Ti слегка это лицензировал для > своих МК. Ну, я думаю, что излишне напоминать, сколько мы читаем о «завтраках» на эту тему. А воз и ныне там. Я уже забил ждать. :) >> Представь, что ОЗУ — это быстрый кэш, не более того. > Скоро, похоже, сторажи станут "медленным RAM", как мне кажется. Периферия уже стала, > она вся сплошь "memory mapped". Это удобно. И сишникам с точки > зрения програмизма, и виртуалкам, достаточно очевидный IOMMU позволяет отрезать железку > в VM. Делая то же что MMU, но с другой стороны. Идея очень хорошая и плодотворная, но не с теми ячейками, которые пихают в SSD. >> буфер между медленной долговременной памятью (диском) и процессором, то быстро ехать >> уже не получится даже при всём желании. > Плохо стыкуется с примером 300Мпикс картинки и процессинга ее пикселей. Вгрузить ее > с диска 1 раз, к тому же сжатую. Декомпресс и любая > возня с пикселями будут намного лучше, если попадут в хотя-бы RAM, > без насилия над диском вообще. На линейных операциях характерных для обсчета > картинок к тому же неплох даже обычный RAM. Хотя GDDR или > HBM в GPU лучше. Но их меньше, потому что они дорогие > и не апгрейдабельные. В теоретической неймановской модели вся память условно одинакова и равноценна. Почему бы не править только те куски файла, которые надо, через окошко, не дёргая весь файл? Экономия налицо, причём при любых условиях. Ну понятно, что на актуальном железе память на самом деле не одинакова, не однородна, и ещё в ней есть медленные диски, а файло на них ещё и упаковано. :) >> буферную память максимально свободной, ибо иначе придётся постоянно лезть на диск >> за каждым ссаным байтом, пока ОЗУ будет занято тем, что «может >> пригодиться, ведь его только что недавно закрыли». > И тем не менее, по моему опыту, жирный дисковый буфер - делает > работу с ОС намного приятнее. По сути превращая медленный стораж в > подобие быстрого рамдиска. Спору нет, если все забить приложениями - эта > иллюзия отвалится. Поэтому забивать память под завязку приложениями все же не > стоит. Я имел в виду всё-таки ОЗУ. > ...но если картинка весила допустим 5 гигз, в системе было 16, то > у меня еще 11 гигз на все такое прочее. А обсчитать > картинку как просто массив в оперативе явно быстрее чем таскать ее > расжатую версию из свопа с диска и чего там еще. Вот > отлить несколько гигз на диск - это не быстро по хоть > каким стандартам. И поэтому фотожоп с 300Мпикс картинке на первом пне > - не упадет, но скорость его работы - заманает в край. > В отличие от скорости работы любого редактора на машине с 16 > гигз. Не. Не всё так просто. Руконогие эту картинку будут («а чо? память дивошая!») кэшировать и перекэшировать многократно и на каждую отмену сделанных операций и ещё на массу факторов. Поэтому всё равно памяти всегда будет мало. Простое увеличение объёма ОЗУ никак не решает проблему неэффективных алгоритмов и рук, выросших из низа спины. Возможно, что создателям эффективных графических редакторов и файловых форматов пригодились бы знания разработчиков файловых систем, но эти ребята как-то не пересекаются между собой по роду деятельности. >> лучше подождать дополнительных 100 мс при каждом запуске приложения, а не >> постоянно доставать всё нужное из свопа. > У меня нет свопа. Как максимум у меня есть zram, типа-своп в > сжатом рамдиске. Если оперативы хронически не хватило - холодные данные можно > попробовать закомпрессить, в надежде что вот так ее все же хватит. > Если и так не хватит - и нафиг. Камасутра с 5-м > фотошопом на пентиуме и 300 мпикс картинкой - не ко мне. Идея свопа в ОЗУ спорна, но обсуждать её лень. >> Бджд, для высокой производительности программ надо всего лишь писать производительный >> код на максимально близком к железу уровне, вот и всё. > С современным железом это легче сказать чем сделать. Начиная с того что > реально код не имеет дело с блоками выполнения. Он попадает в > uCode ROM и тот разваливает его на микрооперации, а что случится > дальше, а также сколько и каких блоков фактически есть в том > или ином камне - известно лишь крайне приблизительно. Кроме того - > при чрезмерном увлечении код получается не портабельным или обладает хреновой производительностью > на других архитектурах, если там сделано иначе. Ну это уже вопросы, выходящие даже за те рамки, что мы тут расширяем и углубляем. :) Пока Си и ассемблеры работают для того железа, которое сейчас у нас есть, можно принять как соглашение, что это железо внутри не изменилось со времён первых x86. > А так то да, дрова в досе и даже 95 писали на > асме. Было круто и быстро. Но работало только на x86. А > нтя таки с дровами на си уже была. Поэтому и была > неповоротливой, зато таки портированной на кучу архитектур. Этот тренд и в > остальных системах продолжился. А нам точно-точно  надо, чтоб работало где-то ещё? Кроссплатформенность — это непродуктивная идея, с точки потребителя. Нативный софт всегда работает лучше и быстрее. > И так для понимания... > - ПСП шины памяти на K6-2 (даже покруче первого пентиума) около 600Мб/сек > была. > - ПСП DDR3 у моего десктопа около 20 Гб/сек. > - ПСП GPU GDDR5 под 180Гб/сек. Согласен. А теперь ответь на мой любимый простой вопрос: почему при таком впечатляющем прогрессе новый Ворд тормозит на самом новом железе так же, как тогдашний Ворд на тогдашнем железе. >> Нет, товарищ комсорг, не так всё было. Никто ничего не оптимизировал, > Посмотри на эволюцию крипто и не тупи. Симметричные алгоритмы и хэширование. > Salsa, chacha, sha-3, да даже AES... их лучше на 64-бит проце крутить. > Больше за 1 такт обсчитывается. И вот так было везде где > скорость счета кого-то колыхала. Будь то графические фильтры или мультимедийные кодеки > или что там еще. Мне до крипто никакого дела, мне есть дело только до браузеров, фотошопов и вордов. >> ибо оптимизацию ваши товарищи по комсомолу и партии возложили на трудящихся в >> формате регулярного похода в магазин за новым железом. > Да ну ерунда, не все же - вебмакаки. Есть и алгоритмисты. И > они таки тоже на 32 бита забили. Да ладно, не по сеньке эта шапка. Забили производители железа. Как я уже говорил, фактически ADM64 это та же PAE, только «наоборот». Это не настоящая 64-битная архитектура. Сорри, я не всё комментирую, а кусочками, нет времени.
	Ответить | Правка | К родителю #523 | Наверх | Cообщить модератору

	373. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Онаним (?), 14-Дек-18, 09:30
	Что да - то да, ручной paging - это жопа. Ребята просто ZX Spectrum 128K не застали, где было одно окно в 16 килобайт. Чтобы через это окно работать со всем объёмом памяти - надо было очень сильно извращаться.
	Ответить | Правка | К родителю #271 | Наверх | Cообщить модератору

	398. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 14-Дек-18, 15:17
	Я застал другие 8-битные железки. Тоже с банкингами и прочей камасутрой. И именно поэтому - на фоне этого УГ даже cortex M0 - masterpiece of engineering :D
	Ответить | Правка | Наверх | Cообщить модератору

	571. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Алексей Михайлович (?), 17-Дек-18, 18:51
	Да не гони. Вот я, положим, решил песню написать. Живых барабанов у меня дома нет, да и вряд ли появятся (сосед не хуже меня стреляет всё-таки), а ещё я жадный и не хочу платить сессионнику, поэтому нужны электронные. Пошёл я качать библиотеку для драм-машины, чтобы песенка всё-таки жила. Скачиваю библу, распаковываю… А там — эка невидаль! — аж целых 5 с хреном гигов чистых данных. И что-то нет у меня желания выбирать библиотеки сэмплов по разрядности моей системы.
	Ответить | Правка | К родителю #263 | Наверх | Cообщить модератору

	275. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 16:35
	> Что должно произойти в 38 году? «Часы сломаются»? Это не страшно. И > это на самом деле не зависит от адресации памяти. А таки в результате на самом деле требуется "старшая часть" этого 32-битного счетчика. И я такой костыль вбил даже на STM32 где именно железный счетчик 32 разряда на уровне железа. Но есть (bat-backed) регистр где хранится старшая часть. Чтобы если оно дотикает до 2038 - не сдохло бы внезапно по дурной причине. А вся работа с временем таки в 64 битах. Хоть это и чуть более пухлый код на 32-бит платформе. Зато не подохнет внезапно в 2038, если к тому моменту это еще будет работать и будет кому-то надо. Потому что х...во когда железка внезапно взглюкивает по такой причине.
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	283. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 17:05
	> А таки в результате на самом деле требуется "старшая часть" этого 32-битного > счетчика. И я такой костыль вбил даже на STM32 где именно > железный счетчик 32 разряда на уровне железа. Но есть (bat-backed) регистр > где хранится старшая часть. Чтобы если оно дотикает до 2038 - > не сдохло бы внезапно по дурной причине. А вся работа с > временем таки в 64 битах. Хоть это и чуть более пухлый > код на 32-бит платформе. Зато не подохнет внезапно в 2038, если > к тому моменту это еще будет работать и будет кому-то надо. > Потому что х...во когда железка внезапно взглюкивает по такой причине. С этим соображением я согласен. Если часы железные, то придётся менять железо. А оно вполне может быть живо к году Г, и даже незаменимо, если прикручено к какой-нибудь домне или станку за десять миллионов зелени или к чему похуже. Но наших серверов и персоналок этой всё не касается.
	Ответить | Правка | Наверх | Cообщить модератору

	299. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 17:55
	> С этим соображением я согласен. Если часы железные, то придётся менять железо. Часы железные. Но - время из них я перегружаю лишь эпизодически, в основном при старте после ресета и все такое. А на самом деле оно живет в 64-бит переменной которая "никогда не переполнится" (по крайней мере, я до этого не доживу, и железяка тоже). Оно апдейтится по IRQ от RTC, но софт не видит 32-бит счетчик. Он ворочает 64-бит переменную. Это удобнее и безопаснее по математике и к тому же доступ к тому 32-бит счетчику специфичный, так что 64 бита в RAM как-то менее проблемны в целом, и иметь дело с ними может оказаться еще и быстрее. > А оно вполне может быть живо к году Г, и даже незаменимо, если прикручено к > какой-нибудь домне или станку за десять миллионов зелени или к чему похуже. Ну вот я не знаю заранее куда этот код и потомки этих железок будут в 2038 году прикручены и мне бы не хотелось чтобы меня вспомнили нелестным словом за такую отложенную по времени свинью. Поэтому в новых проектах этот момент я стараюсь учитывать. А хотя-бы и поступившись немного эффективностью кода. Потому что 64 бита на 32-битном ядре таки требуют больше кода. Так что с точки зрения только эффективности - меня можно за это и замесить.
	Ответить | Правка | Наверх | Cообщить модератору

	278. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КО (?), 13-Дек-18, 16:48
	x32 нет, ибо там не честный x86, а с префиксами, т.е. не то не сё. Регистров больше чем в 32 битах, команды длиннее, памяти для приложения столько же. Да и толком не тестировал никто, как оно себя ведет.
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	284. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 17:06
	> x32 нет, ибо там не честный x86, а с префиксами, т.е. не > то не сё. Регистров больше чем в 32 битах, команды длиннее, > памяти для приложения столько же. Да и толком не тестировал никто, > как оно себя ведет. Да и линукс с ним, я уже устал от этой дискуссии. :)
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Проходил мимо (?), 13-Дек-18, 07:39
	> Я никак не могу представить себе, для чего, например, браузеру, мультимедийному проигрывателю, табличному процессору или текстовому редактору быть 64-битными. Если ты можешь назвать конкретные выгоды — назови. Мой браузер, после того, как откроет все окна и вкладки, которыми я пользуюсь, потребляет существенно больше, чем 4Гб памяти. Так что идите вы со своими 32 битами на маршрут по умолчанию.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	131. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Аноним (514), 13-Дек-18, 07:53
	> Мой браузер, после того, как откроет все окна и вкладки, которыми я > пользуюсь, потребляет существенно больше, чем 4Гб памяти. Так что идите вы > со своими 32 битами на маршрут по умолчанию. Твой браузер умеет работать в несколько процессов при необходимости. Проблемы могут быть только если одна вкладка выжрет 4ГиБ памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Акакжев (?), 13-Дек-18, 08:17
	Деревья, списки и аналогичные используемые браузером структуры данных столько потребляют как раз из-за размера указателей.
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	156. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–2 +/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 09:16
	> Деревья, списки и аналогичные используемые браузером структуры данных столько потребляют > как раз из-за размера указателей. Ну вот с некоторых пор даже в ИТ многие люди не понимают столь банальных основополагающих вещей.
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (215), 13-Дек-18, 12:32
	> потребляет существенно больше, чем 4Гб памяти ... > Деревья, списки и аналогичные используемые браузером структуры данных столько потребляют как раз из-за размера указателей. Грубо говоря, если _существенно_ больше 4 ГБ и именно "из-за указателей", то, опять же очень грубо, разделив 4ГБ на два получим под 2ГБ - как раз близко к ограничению памяти для процесса на 32битной ОС (ну там конечно можно еще повыкручивать - пользовательскому процессу в выделенной виртуальной памяти отдать 3 гига, оставив 1 "технический" гиг под нужды ОС). Ну т.е. под картинки в сотнях вкладок уже ничего не останется. И не заводите шарманку про сотню открытых вкладок.
	Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

	225. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от www2 (??), 13-Дек-18, 13:14
	У каждой вкладки своё адресное пространство, если она обслуживается отдельным процессом. Внезапно, современные Chrome и Firefox работают именно так - запускают по отдельному процессу на каждую вкладку. Можешь запустить хоть 100 вкладок, каждая из которых будет жрать по 3 гигабайта, лишь бы у тебя было столько виртуальной памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	265. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от КГБ СССР (?), 13-Дек-18, 16:00
	> У каждой вкладки своё адресное пространство, если она обслуживается отдельным процессом. > Внезапно, современные Chrome и Firefox работают именно так - запускают по > отдельному процессу на каждую вкладку. Можешь запустить хоть 100 вкладок, каждая > из которых будет жрать по 3 гигабайта, лишь бы у тебя > было столько виртуальной памяти. 294-й не понимает, что такое виртуальная память и её адресация. И в кучу к нему этого не понимают, судя по таким дискуссиям, 2/3 анонимов опеннета.
	Ответить | Правка | Наверх | Cообщить модератору

	274. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (-), 13-Дек-18, 16:31
	Тот анонимус таки не 294 :P. Но общую идею вроде уловил и вещает нормально. Как там у стругацких было? Слепил дубля, отправил его на работу. Дубль получился туповатый... как-то так, да :)
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от нах (?), 13-Дек-18, 10:07
	мы очень рады услышать что твой браузер - раздутое шпионское bloatware, но спрашивали - зачем оно такое, и какие выгоды ты получил от того, что оно не умещается в 4G (у меня - умещается, да, вкладок около сотни, но лишь десяток регулярно используемых. Да, разумеется он не 64битный.)
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	224. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от www2 (??), 13-Дек-18, 13:11
	Твой браузер работает в 64-битной системе и по умолчанию для всего целочисленного использует не 32, а 64 бита. Если его с теми же вкладками открыть в 32-битном режиме, он может и сожрёт существенно больше 4 гигабайт памяти, но сожрёт существенно меньше, чем жрал в 64-битном режиме. А если учесть, что современные браузеры умеют работать в многопроцессном режиме, то у каждого процесса будет своё адресное пространство в 4 гигабайта. На каждую вкладку приходится по одному процессу. В 4 гигабайта двухчасовой фильм на DVD умещается. Что там в браузере в одной вкладке может быть на 4 гигабайта?
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	174. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+3 +/–
	Сообщение от Nuzhny (?), 13-Дек-18, 10:45
	Воинствующее невежество. 32-х битные программы на 64-битной ОС будут практически всегда работать медленнее, чем 64-х битные. Почему? Потому что для работы с этими самыми указателями надо будет производить в 2 раза больше ассемблерных инструкций (64-х битный можно просто положить в регистр одной командой). Размер указателей, как правило, очень слабо влияет на производительность, потому что программы пишутся для работы с данными, а не с указателями. Самые медленные программы - это обработка мультимедиа, архивация, научные расчёты. В них указателей мало, а самих данных много. Поэтому в случае с 64-х битыми программами поток команд уменьшается, обрабатываются данные быстрее (регистры стали больше), а в памяти по данным проигрыш совсем небольшой, на уровне погрешности. Теперь от теории перейдём к практике: 1. Ubuntu: https://www.phoronix.com/scan.php?page=article&item=ubuntu-1... 2. Windows: 2.1. https://www.passmark.com/forum/performancetest/283-comparing... 2.2. http://www.iinuu.eu/en/it-guru/windows-7-32-vs-64-bit-perfor... Тестирование всяких Фотошопов и т.п. ПО показывает примерно аналогичные цифры: 64-х битные программы выигрывают около 10-30%. Готов послушать контраргументы, подкреплённые тестами.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	228. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Совершенно другой аноним (?), 13-Дек-18, 13:34
	> 32-х битные программы на 64-битной ОС будут практически всегда работать медленнее, чем 64-х битные. нет, не поэтому. В архитектуре x86_64 банально вдвое больше регистров общего назначения, так-что хотя-бы за счёт этого - гораздо больше можно провести вычислений не производя чтение/запись из/в память. > Почему? Потому что для работы с этими самыми указателями надо будет производить в 2 раза больше ассемблерных инструкций (64-х битный можно просто положить в регистр одной командой). тут Вы неправы. В 32-х разрядной архитектуре размерность адресного пространства ограничена 4G - 32 бита, никаких доп.регистров там не требуется - при работе в 64-х разрядной ОС 32-х разрядное прикладной ПО будет ограничено 4G адресного пространства. Плюс, конечно, ОС должна знать и не выделять память сверх этого лимита. Кстати у 64-х разрядных программ и ОС есть и свои отрицательные моменты - как минимум вдвое большее потребление памяти при сохранении восстановлении контекста как задачи так и функций, просто их, как я понимаю, нивелирует кэш.
	Ответить | Правка | Наверх | Cообщить модератору

	247. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Аноним (243), 13-Дек-18, 15:11
	> нет, не поэтому. В архитектуре x86_64 банально вдвое больше регистров общего назначения, > так-что хотя-бы за счёт этого - гораздо больше можно провести вычислений > не производя чтение/запись из/в память. И еще гарантированный SSE2, так что можно и пачку SSE2 регистров еще приплюсовать. > 4G адресного пространства. Плюс, конечно, ОС должна знать и не выделять > память сверх этого лимита. Выделить более 4 гигз при 32 битах - еще ухитриться надо. Потому что вся математика к этому очень недружелюбна. > Кстати у 64-х разрядных программ и ОС есть и свои отрицательные моменты > - как минимум вдвое большее потребление памяти при сохранении восстановлении контекста > как задачи так и функций, просто их, как я понимаю, нивелирует кэш. Реально потребление растет процентов на 15-30. Вот никто и не хочет возиться. Тем более что юзерам будет периодически падать на бошку внезапный рояль с 20 этажа, в виде например падающего граф. редактора и проч, совершенно независимо от того сколько памяти воткнуто в комп.
	Ответить | Правка | Наверх | Cообщить модератору

	260. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+/–
	Сообщение от Q2W (?), 13-Дек-18, 15:45
	У меня на 32-х битах всё работает быстро, а на 64-х свопится при трёх вкладках с джирой. Вот это вот факт. А то, что некоторые могут купить себе вагон памяти, сути дела для меня не меняет.
	Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

	289. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+1 +/–
	Сообщение от Аноним (289), 13-Дек-18, 17:23
	http://lurkmore.to/УМВР
	Ответить | Правка | Наверх | Cообщить модератору

	229. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	–1 +/–
	Сообщение от meantraitor (?), 13-Дек-18, 13:47
	> При прочих равных 32-разрядный софт почти всегда лучше, быстрее и экономнее для ресурсов. Заканчивайте уже с этой ерундой. Это не так, если, конечно, у программистов руки растут откуда надо. К примеру, изо всех SPEC CPU2006 (26, что ли, их всего) только одна выиграла от x32. Других примеров, когда x32 кому-то помогло, я не знаю. Далее, если-таки вам в приложении нужно много указателей, но не нужно много памяти, то вам-таки необязательно использовать указатели ;) Возьмем, к примеру, компиляторный бэкенд, если вы знаете, что это такое. Казалось бы, в компиляторах все на указателях (см. LLVM). Однако же, когда мы портировали один такой бэкенд с 32- на 64-бита, потребление памяти у него увеличилось не более 10%, а работать он стал быстрее. А все потому, что его изначально писали люди с мозгами и прямыми руками. А не pointer-heavy приложения выигрывают от 64 бит обычно за счет большего числа регистров (и их размера) и передачи параметров через регистры, а не стек. Не говоря уже про SIMD.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	136. "Разработчики ядра Linux обсуждают вопрос удаления субархитек..."	+2 +/–
	Сообщение от Акакжев (?), 13-Дек-18, 08:12
	> пересобрал под него, не знаю, хромиум? Или firefox? # V8 upstream said they won't support x32, bug #423815
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

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

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