Долго ли ещё производители CPU смогут выжимать соки из своих продуктов?
 

Предел тех процесса почти достигнут. Осталось теперь шаманить с архитектурой и драйверами. Сколько ещё лет Intel и AMD смогут наращивать производительность своих процессоров?

DoProFaU, предела достигли ещё лет пятнадцать назад, когда закончилась т.н. «Гонка мегагерц». Всё, что позже — это попытки интенсивного роста, где-то удачные, где-то не очень.

Теперь будет постоянно увеличиваться количество ядер до бесконечности.
А может мировой кризис грянет и лет на 20 всё затормозится.

На новую архитектуру внезапно никто не перейдёт - x86 уже с четверть века пытаются закопать (вполне обоснованно), но что-то не получается. ;) RISC взлетел только в случае со смартфонами, но там огромная ниша появилась на пустом месте.

Сейчас рост мощностей это не наша, пользователей, головная боль, а маркетологов, которым нужно уговорить нас купить новое железо. Судите сами, сегодня вполне можно пользоваться первыми i7 (если не сдох), вложив совсем небольшие деньги в память, ссд и гпу. А они, на минуточку, в 2008 вышли. Пользоваться же в 2008 процессором 1996 года выпуска было решительно невозможно, никакой апгрейд не мог заставить Windows Vista бегать на Pentium MMX (да и вообще запуститься наверное). С XP не лучше. А сейчас - у меня есть лаптоп с i7-720QM и там Win10 летает.

Сегодня проблема не в железе, а в софте. Железо уже давно, как верно подметил Jula0071, достаточно "быстрое и мощное".
В том числе изза этого, перестали быть нужны программеры, которые знают и умеют кодить "как надо". Взамен того, сегодня сотни условных "индусов" при поддержке разных библиотек, пишут избыточный и медленный код, совершенно не заботясь о том, как оно будет ворочаться... ай, да ну железо жеж вытянет.

Самый крайний случай применения этого метода на букву "ГЭ", это WarCraft Reforget :drug: Вместо 1,4ГБ - "улучшились" до 25ГБ , при этом убрав половину работающих настроек и функций; а особых визуальных отличий найти сложно +тормоза там, где их небыло до этого 15лет. Размер в 10 раз больше, а функций в пять раз меньше + внешн.вид примерно такой же.
Или тот же Skype; сделать из проги на 20МБ работающей везде... неповоротливое, глючное УГ на 300+МБ, при этом ухудшив и безопасность, и приватность, и интерфейс.

Дробление и параллельные вычисления, удвоение потоков и проч. будет дальше. Только вот, нафик оно надо кому.... если , повторяю, дело не в hardware - а в software.
«Очевидно, что создание процессоров с тысячами ядер возможно, пишет автор статьи в ZDNet Джек Кларк (Jack Clark). - В теории даже нет границ по числу ядер. Однако перед созданием таких процессоров нам предстоит ответить на множество вопросов и, прежде всего, на вопрос, нужно ли нам такое число ядер, каким приложениям может потребоваться такая вычислительная мощность».

Jula0071, не соглашусь. Случаи из моей практики. Работаю админом в 1С-ной конторе. Программисты делают ТЗ принесенные внедренцами, затем внедренцы проверяют работу. Часто возникают ситуации когда одни и те же дейтсвия ( отчеты, закрытия месяца, открытие, сохранение конфигурации и прочее) делаются на одной и той же базе, но на разных компах. Среди компов программистов и внедренцев есть машины, у которых диски одинаковые, отличие в поколении процессора ( ну и мамке из-за этого ). Пример: Core I5 2400 / Core I5 8500. Первый внедренца, второй программиста. Операция на компе внедренца выполняется 30 секунд, эту же делает программист - 7 секунд. При этом:
- процессор ни там ни там не загружаются больше чем на 50 %
- Средняя длина очереди диска не превышает единицы
- свободной оперативы не меньше 3-х GB
Новые процессоры однозначно в разы быстрее старых, и в сравнении, бывает очевидно, что старые часто не подходят - операции на в базах на типовых ( не измененных) конфигах делаются медленно на старых машинах, клиента это не устраивает - анализируем проблему, т.к. конфига типовая, обращаться в поддержку 1С бессмысленно - будут долго парить мозги и скорее всего либо затянут решение, либо пошлют, тестим на новом железе - "вуаля", закрытие месяца вместо 3-х минут формируется 20 сек ( еще раз, отличие идет только по процу основное) - клиент покупает новое железо, доволен, проблема закрыта.
При этом, ОС работает нормально и на старом желеле, но часто нужна скорость работы больше софта, чем ОС.

Что это значит, за последние 10 лет вычислительные мощности выросли по вашей метрике раза в 4 (я даже не буду придираться к скорости памяти и диска).

А вот за 10 лет с 1995 по 2005 например вычислительные мощности выросли раз в 50. Говорим про ПК с условным ценником 1000 баксов.

zbeypepels, ну, так это проблемы пользователей. Главный ресурс — время. Посему производители и считают оплаченное время своих программистов. Следовательно — не стоит ждать каких-либо оптимизаций (разве что, кроме самых крайних случаев).

Чёрта-с-два они быстрее. В Вашем случае — чуть повыше бустовая тактовая частота и, главное — в полтора раза больший кэш, шина — пять против восьми и память работает на вдвое большей частоте. То есть, это не просто «новый процессор быстрее». Это «всё новое толще и ширше».

P.S. И я что-то не очень верю в:

Цитата:

Цитата __sa__nya процессор ни там ни там не загружаются больше чем на 50 % »

поскольку на первом четыре ядра, на втором — шесть (я слабо верю в такую оптимизацию, что на первом потоки 1С садятся строго на два ядра, а на втором — строго на три).

- это значит просто факты по замерам операций в 1С, которые были в последний раз. 1С при этом не является утилитой замера производительности процессоров.

- Дело ваше, тратить время на споры, предоставление журналов производительности не буду, пишу то что было на моей практике.

__sa__nya, дык я не спорю. Я сомневаюсь :).

Вопрос не в тему Вам, как практикующему 1С-нику: как нынешние версии 1С оптимизированы под многоядерность/многопроцессорность? Раньше, помнится, было «никак» (от слова «совсем»). Как нынче с этим обстоят дела? Условно говоря — у нас гипотетический процессор с двумя ядрами (для простоты будем рассматривать только ядра и только физические), берём вместо него гипотетический процессор с четырьмя/шестью/восемью ядрами и получаем прирост производительности вдвое/втрое/вчетверо (я помню, что в реальности прирост производительности даже для остаточно оптимизированных приложений будет колебаться примерно как 50%/30%/15%, так что это я так грубо утрирую)?

- Клиентские приложения - не знаю. Сервер 1С Предриятия - однозначно оптимизирован:
1. Бывают случаи когда rphost ( один процесс на кластер) загружает 6-ти ядерный проц на 70-90 % ( пиково).
2. за счет таких параметров как "Количество ИБ на процесс" и "Количество соединений на процесс". Если в свойстве сервера поставить, например "Количество соединений на процесс - 5", то на каждые новые 5 соединений будет создаваться процесс rphost.exe, который может "сесть" на другое ядро.
3. Это подтверждает и база знаний ИТС от 1С:
- это выдержка из статьи "Глава 1. Требования к аппаратуре и программному обеспечению", где 1С-ники говорят что чем больше ядер доступно на компе со службой "Сервер 1С:Предприятия", тем шустрее он будет работать, когда "шустрость" зависит от количества ядер.

Жаль, меня именно эта сторона в первую очередь интересовала :(. Чаще всего проблемы бывают именно на клиенте (всяческие самопальные неоптимизированные обработки, гоняющие чуть ли не всю базу по сети — увы, и такое наблюдал неоднократно).

Тем не менее, спасибо за информацию, коллега.

Там вон уже умные дядьки квантовые компьютеры во всю изобретают. Может чего нибудь радикально новое в будущем представят

Обычно подобные вопросы решает "кошелек" - экономическая целесообразность. Возможно, когда-нибудь спираль развития снова подойдет к идее "тонкого клиента". Обычные (с сегодняшним уровнем производительности) серверные процессоры тысячами будут трудиться в Дата-центрах, а пользователи (в условиях, когда всюду оптика и вай-вай) ходить/сидеть с недорогими гаджетами, вся задача к-х будет только в обеспечении связи с этими самыми ДЦ. Не нужны камни в диапазоне Celeron - i9 - такое решение будет либо сравнительно дорогим, либо слабо мобильным, либо просто слабым, либо неудобным (нравится работать "на коленке" с ноутом с диагональю 15,6 в той же 1С с ее таблицами ?), либо комбинация из нескольких таких недостатков. Идеалом мне кажется устройство величиной не больше современного смартфона, к-е сможет транслировать данные на монитор (предполагается, что мониторы внушительных размеров будут такими же обязательными атрибутами каждого помещения, как, например, уборная).

Iska, а мне тоже интересно, спрошу у тех. поддержки 1С, затем отпишу.

- Вообще, по сети база может "гоняться" только если используется файловый режим через общую папку. В клиент-серверном режиме гонять базу по сети в принципе по умолчанию сложно, т.к. в этом режиме как минимум половина вычислений ложится на сервер 1С. Надеюсь у вас 1С работает не по сети через общую папку ? Как у вас база гоняется по сети ?

Iska, в общем получается что клиентское приложение 1С многоядерность не поддерживает:
1. Погонял с программистами различные операции на базах, которые длились от 20 сек до 40 сек, а так же ТИИ базы со всеми опциями - на компе с 4-х ядерным процом процесс 1cv8.exe не занимал более 25 % процессорного времени, т.е. он "сел" на 1 ядро
2. Ответ тех. поддержки 1С о многоядерности в клиентском приложении:
Под клиент-серверной версией они имеют ввиду Сервер 1С:Предприятия, о чем я писал вчера.

Таки да. Та же флэш-память появилась много раньше, нежели стоимость её производства позволила запустить массовое производство в виде тех флэшек, что мы знаем.

__sa__nya, большое спасибо, что не поленились и отписать в техподдержку, и опробовать. То есть, по большому счёту, тактовая частота всё ещё остаётся определяющим фактором производительности клиентской версии 1С.

Цитата:

Цитата __sa__nya - Вообще, по сети база может "гоняться" только если используется файловый режим через общую папку. В клиент-серверном режиме гонять базу по сети в принципе по умолчанию сложно, »

Легко. Досточно иметь сертификат от 1С, но при этом нихрена не понимать ни принципов работы языка запросов 1С, ни что такое SQL сервер, ни принципов построения баз данных.

Цитата:

Цитата __sa__nya В клиент-серверном режиме гонять базу по сети в принципе по умолчанию сложно, т.к. в этом режиме как минимум половина вычислений ложится на сервер 1С. »

Но не в том случае, если в одну таблицу (которая постоянно блокируется при вызове выбора) пихается куча абсолютно левой информации (у нас, например, каждый стол, стул и утюг имел своего комбайнёра, водителя и кучу прочей ахинеи — потому как доблестные «программисты»-франчи нихрена не понимали, что такое реляционные базы данных и с чем их жуют). Также можно было, легко и непринуждённо, сделать запрос к подобной гиговой таблице, пардон, не запрос, конечно, а сделать выборку всех полей всех записей таблицы, а потом уже на клиенте делать отбор потребных записей и пары полей в коде — вместо нормального запроса. И вместо десятка-сотни килобайт через сеть (в том числе и по воздуху — на 10-12 км) меееееедленно тяяяяяяяянется вся гиговая таблица.

Посему я и говорю, что уложить можно и SQL-сервер. Было бы отсутствие знаний, очень много апломба и нежелание чему-либо учиться.

Цитата:

Цитата __sa__nya Надеюсь у вас 1С работает не по сети через общую папку ? »

По сети. MS SQL, не помню уже какой.

Цитата:

Цитата __sa__nya Как у вас база гоняется по сети ? »

Уже никак. Точнее, не знаю. Полагаю, гоняется, но уже без моего участия :).

Да и в области оптических компьютеров тоже есть надежды:
https://www.nature.com/articles/s41566-019-0392-8