The OpenNET Project / Index page

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



"Разработчики ядра Linux обсуждают вопрос удаления субархитек..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Для сортировки сообщений в нити по дате нажмите "Сортировка по времени, UBB".
. "Разработчики ядра 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. Они оба будут
> жалкими, но пень все-же продует в разы и так. Но менее
> эпично чем обычно :)

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


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

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


Дальше лень.

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

Оглавление
Разработчики ядра Linux обсуждают вопрос удаления субархитек..., opennews, 12-Дек-18, 22:49  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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