Плюс мильярд!
Об этом и не скрываясь пишут на сайте Аффтадеска.
Посему - лучше меньше ядер выше частота, чем утыкан как ёж тупящими 16 ядрами.
Впервые я вкорячился с этим ещё на Атлоне ХП - очень хотел на ядре Бартон, т.к. у него было много кеша.
И чо? более дешевый Атлон ХП на Торобреде, но бОльшей частотой лехко рвал его как Тузик грелку.
Так что частота - на первом месте. Всё остальное - вторично.
Станислафф, рост частоты упирается в TPD которое упирается в техпроцесс. А техпроцесс если уже не уперся то скоро упрется в теоритический предел.
Да уж скорее бы, может быдлокодерам перестанут плотить 300к/нсек за программы, скомпилированные с Бейсика.
Нет. Сами программисты скорее рады бы делать нормально, но условия в IT индустрии этого не позволяют. Первое, это сроки. Дело в том, что потребители покупают первое как-то работающее решение, после чего никакие другие, хоть в разы лучшие - их уже практически не интересуют. Соответственно, идет гонка сроков. Второе - во многом как следствие первого - это монополизация. Практически по любому виду IT услуг есть де-факто монополист, конкурировать с которым - бессмысленно: никому не нужна "несовместимость", если не собственно ПО (или его входных/выходных данных), то привычек тех, кто с ним работает. Соответственно, компании для оборудования рабочих мест покупают то ПО, с которым умеют работать большинство специалистов на рынке, то есть круг замыкается. В итоге де-факто получается набор монополий с очень небольшими нишами для "нестандартных" задач, в которых чисто экономически развиваться невозможно, соответственно, ПО/услуг на коммерческой основе для многих таких ниш просто нету или исчезают. Как паллиатив - open source ПО, типа, лепим сами коллективными усилиями....
Не совсем так. Рост частоты упирается в степень локальности программ и абсолютное время доступа к памяти: собственно "обрабатываюшую часть" давно уже можно разогнать на десятки ГГц, только толку от этого - ноль. Так как быстрый кэш, способный работать на такой скорости - получается очень маленьким (при том, что и греться начинает в первую очередь именно он). Поэтому всегда ищется компромисс, а учитывая гигантский оверхэд кода, то для реального ускорения эффективнее оказывается увеличивать объемы быстрых кэшей, даже несколько в ущерб частоте ядра, несмотря на то, что это еще и дорого.
Последний раз редактировалось sia_2; 09.08.2020 в 16:47.
Offтопик:
Первое, это управление. Руководство не хочет оплачивать человеко-часы. Можно сделать и быстро, просто нужно больше рук.
Монополизация - отсутствие конкуренции. А раз нет конкурентов, то куда торопиться? Майкростофт - практически монополист. Никто их не гонит. Ничего особо нового в их продуктах нет. 1С - монополист. Что им мешает сделать качественный продукт? Зачем программе, которая складывает и умножает простые числа 4 ГБ ОЗУ?
Жадность. Нежелание руководства вникать в тех. проблемы.
Вылизыванием кода заниматься дорого. Дешевле подправить графу "системные требования" в спецификации, по крайней мере, когда речь о "настольном" ПО.
Если это хобби - да, можно и повылизывать долгими зимними вечерами. Но это большая редкость, чтобы хороший программист заморочился на досуге разработкой чего-либо из любви к исксству. Тем не менее, иногда подобным образом рождаются жемчужины опенсорса. При этом нужно понимать две вещи: 1) многие проекты физически неподъёмны для одного разработчика, 2) чем опытнее программист, тем меньше шансов, что он будет работать за идею.
В коммерческой разработке тоже случается, что руководство хочет не столько достичь коммерческих результатов, сколько утереть нос конкуренту, иногда это приводит к получению очень качественного кода. Но такое по понятным причинам встречается ещё реже...
Но есть и другие области, где вылизывать код таки выгодно - high load, жёсткий embedded и подобные области где апгрейд железа невозможен или обходится очень дорого - вот там, кодят, как ни странно, хорошо
∇·D = ρ
∇·B = 0
∇xE = – ∂B/∂t
∇xH = j + ∂D/∂t
© J. C. Maxwell, O. Heaviside
Чтобы хорошо кодить, помимо воли руководства и рыночного смысла нужен ещё один компонент : нужно уметь хорошо кодить. Сдается мне, непросто найти специалиста, способного не просто на фреймворках и библиотеках код плодить.
Денис.
Offтопик:
Не скажу, что очень просто, но если ЗП выше средней по рынку, то без особых проблем, по крайней мере, в мск. Сложности начинаются, если нужен специфический опыт...
∇·D = ρ
∇·B = 0
∇xE = – ∂B/∂t
∇xH = j + ∂D/∂t
© J. C. Maxwell, O. Heaviside
Такое тоже бывает, но в более чем 90% случаев - реально нет необходимости. Вот из собственного опыта: писал я data maining программу, занятую калибровкой (в общем, неважно чего). Работает она на i5 примерно полчаса. В принципе, алгоритм можно перепахать, ускорение будет минимум на порядок даже без распараллеливания. Но заказчика то, что есть, устраивает, и работу по доработке он оплачивать не будет, хотя бы потому, что получение исходных данных занимает минимум сутки, и на этом фоне полчаса - ерунда. Соответственно, я ее бесплатно дорабатывать тоже не буду. И точно так же во многих других случаях: клиентов интересует первое более-менее годное решение по сходной цене, а на степень его "внутренней" эффективности и "красоты" - им перпендикулярно.
А еще есть задачи из разряда "формально невозможно, но очень надо". Например, реализовать трехканальный КИХ дециматор с точностью 32+ бит и длиной ~500 отсчетов при частоте входных отсчетов 8 кГц по каждому каналу ... на пусть и быстром (48 МГц), но 8051. И с памятью по ~600 байт на канал. Сделали, работает , причем не занимая полностью ресурс процессора, все остальное тоже на нем.
Вообще-то в современном мире перевыполнение требований заказчика считается избыточным производством и приравнивается к потерям, которые нужно сокращать.
Денис.
У нас довольно часто бывает, что мы делаем чуть больше чем изначально планировалось. Но почти всегда - это вызывает лишь кучу дополнительных вопросов от заказчиков. И чем крупнее контора заказчика, тем их больше.
P.S. В позапрошлом году, одна ГНУсная #небудуназыватьпоимени# контора, просто достала, когда в пакете данных они получили кроме требуемого, еще несколько параметров которые не просили, и на которые у них не предполагалась визуаилизация.
Но он у нас автоматически получаются в ходе вычислений, просто если не нужны - то наружу не выдаем.
А тут чисто машинально подключили. Че там было! Сначала длинное обсуждение, пока они пытались понять что это за параметры. Потом длительная дискуссия типа "полезно ли их будет выводить на экран?".
Это длилось месяца три, мы уже предлагали убрать все лишнее (на чтонадо минут 10), но потом они приняли половнчатое решение - "пусть будет, но сейчас мы использовать это не будем, так как чтобы из выводить надо сильнопеределать наш gui, придумать пиктограммы, как выводить найти место в меню и пр.".
На самом деле, у них в этих часах уже просто память заканчивалась, и им лень было что-то добавлять....
"Замполит, чайку?"(с)"Охота за Красным Октябрем".
"Ну что, можете меняться обратно."(с)типа анек.
<-- http://altor1.narod.ru --> Вопросы - в личку, е-мейл, скайп.
Если руководство узнает, что разработчик занимается наведением красоты кода или оптимизацией без явной необходимости со стороны заказчика, то разработчика накажут. Другое дело, что в продуктах с длинным жизненным циклом _выгодно_ писать "красиво", т. к. это снижает трудоёмкость (ака стоимость) сопровождения. Но опять же красивый код далеко не всегда эффективен, зачастую - наоборот.
∇·D = ρ
∇·B = 0
∇xE = – ∂B/∂t
∇xH = j + ∂D/∂t
© J. C. Maxwell, O. Heaviside
Бейсик тут кстати совсем не при чём
Вот пока я был в отпуске. Возникла небольшая проблемма в проекте, так дев у, и из-за которого она возникла, вместо того чтобы потратить 20 минут и разобраться, ломает код в одном месте (апсерт в таблицу не имеющий проблем с high concurrency / high load) применив классический корявый антипатерн с гарантированными проблемами, и в другом месте, так как его антипатерн не работает толком, лепит кусок кода стирающий записи из таблицы (которые должны быть обновлены) т.е. будет происходить постоянный многократный delete/insert в достаточно кривой таблице с десятками миллионов записей (пара полей блобы) и под тремя репликациями на проде. Когда я вышел из отпуска и увидел этот конченый пи..ец уже всё "оттестировано" (легаси апп и тестеры тестируют руками) и код я поменять не могу без полного ретестинга но который нет времени так и пойдёт в прод.
И это вот совершенная элементарщина, возникшая из-за тараканов в голове начальства считающего себе девелопером, ну пишет человек корявый код под корявейшим легаси фреймворком писанным инопланетянами ибо гуманоиды с этой планеты подобное нагромождения глупостей и костылей написать просто не способны. И совершнно не понимает ни принципов архитектуры ни принципов работы основного хранилища данных с которым работает (классика идиотизма сохранения значения в принципе не бывающего длиннее 2 чарс в варчар(мах)) Убеждённого в том что в базе бывает слишком много таблиц и в том что лучше добавить миллионы записей в корявую таблицу с блобами уже имеющую миллионы записей, чем сделать короткую оптимизированную с отличной партиционностью таблицу под конкретную достаточно тяжелую задачу рядом, в которой реальные запросы будут гоняться с одинаковой скоростью и на миллионе записей и на 500 миллионах.
---------- Сообщение добавлено 13:01 ---------- Предыдущее сообщение было 12:32 ----------
Это похоже понятно только некоторым толковым разрабам с опытом. А то вот тут рядом вроде толковые разрабы, с одним из которых мы поддерживаем отношения на проф темы, но один из главных их "идеологов" очень любит устраивать забеги по полям усеенным не только граблями, но и мышеловкали. Уже в третьем стартапе получают по лбу теми же самыми граблями. Я уже устал говорить - I told you so.
Последний раз редактировалось funny the rat; 12.08.2020 в 19:54.
В интернете вы можете быть кем угодно. Странно, что многие предпочитают быть идиотами.
Как жаль, что тупость не причиняет боль ее носителю.
∇·D = ρ
∇·B = 0
∇xE = – ∂B/∂t
∇xH = j + ∂D/∂t
© J. C. Maxwell, O. Heaviside
Offтопик:
На прошлой работе архитектором системы был я и проблем там не было А тут гигантская legacy система которую надо поддерживать, отсутствие позиции системного архитектора и корпоративный принцип что никто не шевелится пока зад не прищемило уж совсем серьёзно. Плюс гигантская инерция корпорации (интересы очень многих вышестоящих задеваются) и невероятная сложность найти работников под этот дурацкий проприетарный фреймворк. Нормальный дев только под него не пойдёт, а стандартной девелоперской работы на двух человек и оба места заняты. Поэтому набирают, или родственников (1 штука), или студентов, или людей которые думают, что могут писать запросы, иллюзии рассеиваются когда они попадают на террабайтную базу, но у многих очень не быстро.
Ну и самое главное, то что я делаю в своём нынешнем качестве (preventing fires) и при всех существующих для меня свободах как спец очень неплохо платят и существующее положение дел меня вполне устраивает. K тому же где то 80% процентов проблем я таки помогаю избегать. А в упомянутые стартапы, там практически одна команда в которок тому же я всех знаю и с 80% из них работал, звали два раза, но мы достаточно сильно не сошлись в деньгах. А становится начальником... боже упаси, никогде не хотел и не нравилось когда им был
Ну и не надо забывать о деньгах
Последний раз редактировалось funny the rat; 12.08.2020 в 22:02.
В интернете вы можете быть кем угодно. Странно, что многие предпочитают быть идиотами.
Как жаль, что тупость не причиняет боль ее носителю.
Социальные закладки