-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Tue Jun 15 2021 05:53:19 GMT+0000 (Coordinated Universal Time) Posted as new post Clubs: Tags: *amd *железо *it *overclocking *обзор ну что, котятки, надо бы сделать объективный обзор на легендарный AMD-FX 9590. довелось быть счастливым владельцем оного около 6 лет, в технические характеристики, историю и тд углубляться не буду (это всё можно легко найти в интернете), поделюсь впечатлениями с точки зрения конечного пользователя, ну и развею пару мифов. например, есть кукареки, что FX-9590 это 'всего лишь разогнанный 8320' - да, архитектура там схожая, но разница в том, что не каждый FX-8320 разгонится до 4.7Ghz (если купить пару десятков FX-8320 то рано или поздно может повезти, некоторые кстати так и делали - покупали, тестили, неудачные процы продавали, но это же пердолинг), а FX-9590 гарантированно будет работать на 4.7Ghz т.к. это его сток (разве что у юзера совсем руки из жопы), цена - 6 лет назад брал за ~250 евро, это абсолютный вин т.к. он outperformит процы в несколько раз дороже и новее его. небольшой caveat - под него нужна адекватная качественная мамка типа 990FX чипсета с поддержкой 220W TDP процов (иначе загорится VRM и в лучше случае сдохнет только мать), я взял ASUS Crosshair V Formula-Z (последнее как раз означает поддержку 220W), всё работает идеально в течении всего этого времени. дополнительная причина брать именно её это фокус на оверклокинге, как следствие - в биосе много полезных опций типа настроек множителей, вольтажей, различных LLC и более advanced вещей, и да, именно на этой мамке ставили большинство мировых рекордов LN2-разгона фикусов. я до LN2 пока не добрался, ограничился обычной водянкой Corsair H110, и в принципе её полностью хватает. также добавил кулеры на RAM, NB и VRM (в итоге температуры там держатся под 45C at all times) и дополнительные кулеры в корпус для максимальной циркуляции воздуха. обычно юзаю небольшой разгон до 5Ghz, вольтаж кстати ниже стока (сток 1.52V, на 4.7Ghz стабильно работает даже на 1.39V но для 5Ghz выставляю около 1.47V), возможно, просто повезло и попался хороший экземляр, в общем при 1.52V он бы мог и 5.5Ghz взять наверное, но там уже водянка не будет справляться (сейчас при 5Ghz / 1.47V при 100% загрузке всех 8 ядер и комнатной температуре 20 градусов температура проца остаётся под 60C). кстати, все power-savingи на фикусе работают и не мешают оверклочить (отключение power-savingов стабильность при разгоне не улучшали), например в идле он тротлится вплоть до 1400Mhz / ~0.875V причём отдельно по ядрам, при нагрузке сразу переключается в топ частоту. вообще удавалось юзать на 5.2Ghz но были рандомные зависания (хоть и не частые), пробовал апнуть V и не помогало, возможно причина в чём то ещё (CPU/NB?), ну я ещё буду пробовать. можно также отключить 2, 4 или 6 ядер, тогда стабильность после 5Ghz улучшается, но минус 2 ядра это сильно замедляет например компиляцию. в играх в принципе пох, максимум 3-4 ядра используются и можно было бы пожертвовать остальными ради частоты, вообще рано или поздно в любой игре FPS упрётся в частоту проца, к примеру в xonotic сейчас в среднем около 800FPS (на минималках), на стоковых 4.7Ghz было около 650-700. это в первую очередь имеет смысл при использовании 360hz мониторов, если FPS будет падать ниже 360 - монитор полностью не будет раскрыт и будут теряться кадры (а если без vsync то желательно уже 720FPS). да, современные процы часто выигрывают в синтетических тестах, кодировании видео или некоторых играх за счёт дополнительных хитрых инструкций или прочих костылей, но имеют более низкую частоту и поэтому упрутся в этот лимит FPS раньше. так, ну с частотой понятно, также в фикусе (точнее комбинации его и этой мамки) можно отдельно разгонять CPU/NB, что является контроллером памяти, в стоке он 2.6Ghz, сейчас использую на 2.8Ghz, выше стабильности добиться не удаётся, также апнул HTLink с 2.4Ghz до 2.6Ghz (это важно в т.ч. для скорости PCIE, хотя не уверен что с моей видеокартой там ботлнек). вообще для данного проца крайне важно разгонять не только его самого, но и коммуникации с другими подсистемами, в первую очередь с памятью, и саму память, иначе получится "кукурузный разгон" когда ядра быстрые, греются, жрут, но данные к ним поступать не успевают, в итоге профита нет (этим, кстати, часто грешат нубы-обзорщики которые разогнать правильно не могут (а то и вообще юзают в стоке), а потом жалуются что он "не тащит"). а вот с памятью есть ньюанс, я бы даже сказал, недостаток - AMD FX работает с DDR3, при этом официально поддерживается только DDR3 1866Mhz. ну, возможно, мне опять же повезло, но без проблем завелось с частотой памяти 2133Mhz, потом чуть добавил вольтаж и стабилизировал на 2280Mhz (1.66V 11-12-12-33-47 T1, память Corsair Vengeance Pro 2400Mhz 32GB (4 планки)), на 2400Mhz и выше стабильность не полная, изредка то одно то другое крэшится, дальнейшее повышение V не помогает и делает только хуже, ну, это всё же не самая топовая DDR3, возможно дело в ней самой. вообще юзал и на 2520Mhz 1.67V, в некоторых играх типа cyberpunk 2077 был прирост 10FPS, но в конце концов устал от регулярных крэшей и вернулся на 2280Mhz. что интересно - стресс-тесты типа mprime работали стабильно, но как только запускал хром или xonotic начинались и крэши и в mprime тесты фейлились, возможно какие-то race conditionы возникают. вообще читал что память без проблем гонится выше 2400Mhz если там две планки (т.е. 16GB), и охотно верю, но мне как то 32GB предпочтительнее (например компилировать С++ в 8 потоков). я ещё попробую покорить 2400 и 2520, есть пара идей. но вообще DDR3 постепенно устаревает и лет через 10-15 этот проц уже будет менее актуален. ну а сейчас он тянет всё без проблем, легко раскрывает Nvidia GTX-1070 (с оверклоком почти до уровня 1080), тестировал в том же cyberpunk 2077 на линуксе через wine (!) и стабильно получал 40-50 FPS в зависимости от локации, изредка бывали просадки до 30, это на средних настройках (на низких дальнейшего увеличения FPS не было). на windows при этом было 30-40 FPS независимо от настроек, возможно это потому что wine сбилжен с оптимальными флагами под этот проц или linux более оптимизирован сам по себе, на высоких настройках на windows работало шустрее, видимо там лучше видеодрайвер. в Dark Souls 3 несмотря на wine и корявую оптимизацию 60-80 FPS есть, в dota2 или starcraft2 на средних 150+ (что удобно с 144hz моником), в xonotic удавалось добиться 900+ (при этом там однопоток). в общем, в 2021 фикус всё ещё тащит и конкурирует со всё новыми и новыми поколениями процов. потанцевал оверклокинга тоже до конца ещё не раскрыт, например можно взять DDR3 потоповее и водянку помощнее, а там глядишь и на 5.5Ghz / 2600Mhz DDR3 заведётся. да и видеокарту, я думаю он и с RTX 3080 не будет ботлнеком. LN2 тоже надо будет потестить. единственное, в чём сейчас уступает современным процам - это в энергосбережении, но это гроши какие-то, подумаешь. ну, и в синтетических тестах, которые больше маркетинг чем реальность (часто вообще затачивают тесты под процы, а то и процы под тесты). that said, найти где купить FX, совместимую с AM3+ мамку и DDR3 память будет всё сложнее, так что не могу всем советовать срочно бежать и брать, но сам ничуть не жалею // https://www.youtube.com/watch?v=6IzdM2uMD04 ! protected by SuperBnW ( https://github.com/afwbkbc/superbnw ) ! Public key: https://github.com/afwbkbc/gpg/blob/master/5122E95DCC3CF31CE9F75D956AF7D685006F5088.asc -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEUSLpXcw88xzp912VavfWhQBvUIgFAmDIQE8ACgkQavfWhQBv UIhkegwAgLnSRwUzTEkbHDBerQXvbSxJ7pZ4OUCaBC0KuEY+lARE140P4+KWMgfk NrUNV6CKZnMBeYP2Ni739Og/zTJvx/btJ0K4uKUwsS1sVqSUUmvn0d7uWPqf0IM3 KYE7Q8K5mJP5obGpqM++VYP+TGBFO0apMyt+p4EqTduL2+Taor2B9MFJx5AWUf/b YfE0I5wWwqbf1tOXdFqR8EQ2w8Ky0yKFUSpySr7usKoa98naRfvicm9VSODrdkpP DOmG88gmJkCccM1euxn3g9jnNnUz0Dj7daymfR22aXFM4z5gHhDQzhV8xH6ObI/E PEMn9W5UDSfSgtt9JE0tO5QPXyTSKgz6h+h/atWjluZqaj1m/AASPRq/9AFMS/0N r68YfOVRvgFTiumpyVgr9uTJzP6RczwYd4PGGacUHKnLv7IyYzKdhYv+X+5iTWak hnLH0reWryxTpVBe6j0hReDDBzbY15+5SMoS+xGleUJNuij/rRDaiXveqEiQTGzB FuzT0QtB =1JTg -----END PGP SIGNATURE-----

посоветуйте солидный пакет на собеседование собираюсь устраиваться айтишником нужно, чтобы подчеркивал мою individuality и business orientation пока остановил свой выбор на таком: https://images.wbstatic.net/big/new/15770000/15771476-1.jpg есть еще вариант со спорт-каром: https://images.wbstatic.net/big/new/13320000/13321537-2.jpg но мне кажеться, он слишком дерзкий и может отпугнуть потенциального работодателя

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Wed Jul 29 2020 22:55:23 GMT+0200 (Central European Summer Time) Posted as new post Clubs: Tags: *it *развитие *коучинг *обучение *programming Хочется осветить один важный, но часто незаметный и упускаемый из виду аспект разработки кода ( на самом деле работает и вне кода, но с кодом будет нагляднее ). Многие энтузиасты программирования, в основном конечно джуниоры, но встречается и среди системных архитекторов ( я видел ), начиная разработку очередного продукта как то не задумываются о его lifecycle ( как долго будет разрабатываться? как долго будет востребован? известно ли его "конечное состояние" или можно будет развивать бесконечно? ... ), в итоге на архитектуру конечно не забивают, но стараются не слишком ей заморачиваться на ранних этапах, стремясь побыстрее получить результат или как то балансировать между результатом и проработкой архитектуры ( этому чем-то способствует философия Agile, особенно если человек неправильно её понимает ). Сразу скажу, что здесь речь пойдёт о проектах, которые: 1) технически сложные 2) не имеют ограничений по срокам ( либо сроки очень большие ) 3) потенциально могут стать продуктом, который можно продолжать развивать бесконечно и сейчас не ясно где развитие продукта закончится В самом начале такого проекта нужно понимать, что результаты - не цель ( как парадоксально бы это не звучало ), цель - ускорение/упрощение получения результатов в будущем. Будущем, да. Про настоящее здесь нужно забыть, и расставляя приоритеты - не думать "какой результат это принесёт", а "каким образом это облегчит дальнейшее получение результатов". При этом облегчение получения результатов само по себе является результатом, так что выходит как бы бесконечная рекурсия, но каждый следующий виток упрощает следующие ( да-да, и может наступить момент, когда уже просто нечего оптимизировать/упрощать и вот тогда это самые "результаты" и начинаются, как бы сами собой, быстро, легко и экспоненциально ). Но не будем забегать вперёд. Вот, нарисовал небольшую инфографику для наглядности - https://tinystash.undef.im/il/5BUy29qSa7HaGuKJt6KgbjZ565uaMJMdDghgCNkYswNZiyFZBpEkxjuNd6Ft9HA3mVgMBjZ6hWugK8SQckth8JFz.png , кстати, основано на реальных событиях, конкретные проекты упомянуть пока не буду но оба находятся в начале пути, и, как вы уже наверно догадались, один из них уже имеет _видимый_ прогресс, а во втором пока вообще непонятно что происходит и происходит ли ( да ещё и код закрыт ). Почему так, почему людям так хочется гнаться за результатами? Если это не внешнее ограничение, например, сроки полученные от инвестора ( кстати, одна из причин, почему многие стартап-компании делают продукт "на отьебись", нет нет они не обманывают инвестора умышленно, но он им даёт требования и сжатые сроки и у них нет выбора, а заработать хочется, вот и получается, что инвестор вовремя получает продукт, который он хотел, но чуть позже выясняется, что одно нужно исправлять, другое переписывать, а через какое то время - что выгоднее уже вообще всё переписать, чем платить за постоянный мэйнтенанс ( при этом если первоначальный продукт был достаточно успешен и принёс прибыль то это происходит и дальше всё идёт гладко, но чаще конец печален ) ), то вторая по распространённости причина - неуверенности в себе как программиста. Начиная непривычный, или просто более сложный, чем обычно, проект ( особенно если это проект одного разработчика ( или маленькой команды ) ), человек постоянно ощущает сомнения - а получится ли? а смогу ли?, и чтобы их преодолеть ему нужно регулярно видеть _видимый_ прогресс, а это значит, что первым делом он пытается пробиться к ( если это игра ) геймплею, как к глотку свежего воздуха. Когда это происходит ( если происходит ), выделяется дофамин, человек радуется ( "у меня всё получается!" ), и потом пытается как то "натянуть" на то что есть ( что часто является 'Proof of Concept' и в принципе дальше развиваться не может без переписывания большей части кода ) какую-то архитектуру. Но, вот незадача, дофамин возвращается на место, человек замечает, что вроде работает, тратит время, силы, а визуально ( геймплей ) ничего не меняется, ничего нового не добавляется. Становится грустно и неприятно заниматься архитектурой, а приятно - добавлять больше и больше геймплея или чего-то видимого. И возникает порочный круг - те сопли ( архитектурой это не назвать ), на которых сейчас всё держится, могут выдерживать добавление новых фич только ценой роста технического долга ( который уже и так немаленький ), но если начать заниматься техническим долгом - портится настроение, снижается энтузиазм ( "я не этим скучным переливанием из пустого в порожнее хотел заниматься!" ) и рано или поздно желание продолжать проект заканчивается ( да, это результат 99%, если не 100%, таких проектов основанных на энтузиазме от _видимого_ прогресса ). Некоторые бросают сразу ( иногда начиная новый проект и наступая на те же грабли ), некоторые пытаются выжать из того что есть всё, что можно, ценой многочисленных хаков и прочих отвратительных практик ( а иногда потом ещё и продать ), но результат один. Что делает грамотный системный архитектор? Системный архитектор не спешит. Он _уже_ видит результаты в будущем, потому что понимает, что грамотно и вовремя спроектированная архитектура позволит ускорять скорость дальнейшей разработки экспоненциально ( или близко к этому ). Какая разница, что уже месяц нет видимых результатов? Постоянное улучшение архитектуры ускоряет дальнейшее её улучшение, а также облегчает добавление фич и тех самых результатов, за которыми гонятся неуверенные в себе джуниоры в самом начале проекта. Единственное, что интересно на ранних стадиях проекта - ускоряется ли ускорение разработки? Если ускоряется - всё в порядке. Но когда же начинать добавлять сами результаты? Здесь два способа - либо когда это становится уже настолько легко и быстро, что почти не занимает времени, либо использовать формулу вида "чем ближе архитектура находится к состоянию, в котором она сможет поддерживать добавление всех фич, запланнированных в проекте, тем больше внимания можно уделять добавлению этих самых фич по сравнению с улучшением архитектуры". Второй способ является более сбалансированным и часто оптимальным, но если у проекта нет видимого конца жизни ( или он ещё неизвестен, или выглядит, что проект можно будет развивать бесконечно ) то первый предпочтительнее чтобы такой вот "конец жизни" проекту не создать самому. Конечно, есть здесь и подводные камни. Во-первых, может возникнуть over-engineering архитектуры, вплоть до состояния когда сам автор не в состоянии разобраться, что делает какой-то элегантный, но уж очень хитросплетённый код. Решение - балансировать техническую сложность частей кода, и не давать ей концентрироваться в одном месте, вовремя разделяя на более простые компоненты ( даже ценой потери некоторой элегантности ). Во-вторых, может возникнуть другая крайность - когда код настолько сильно фрагментирован, что изменения приходится делать во многих файлах ( которые ещё надо найти ). Решение - наоборот 'концентрировать' какие-то разрозненные части кода в ключевых местах, желательно там, где возможно какое-то элегантное решение, позволяющее уменьшить общий объём кода. Умение балансировать между этими двумя крайностями приходит только с опытом, здесь нет универсальной формулы. Иногда можно ориентироваться по ощущениям - если ощущается неудобство от постоянных поисков по коду - можно сконцентрировать, если ощущается дискомфорт от необходимости напрягаться, чтобы разобрать хитросплетённый шедевр - можно разбить на более простые части. Есть ещё зависимости от IQ, опыта программирования в целом и в конкретном языке, или в конкретной сфере ( например геймдев или веб ) - чем они выше, тем код продукта может быть сложнее, а, следовательно, элегантнее и его объём будет меньше. Нужно также учитывать других разработчиков, если имеются или если планируется подключить в будущем. Чем сложнее код - тем сложнее будет найти разработчиков ( кстати, вопреки распространённому мнению говнокод - самый простой для понимания вариант кода и разобраться в нём может практически любой ( другое дело что его архитектура ( точнее, её отсутствие ) постоянно способствует появлению багов от любого, казалось бы, несвязанного с этим, изменения ) , просто по ощущениям это как в говне копаться, хотя тут тоже зависит от разницы между уровнем говнокодности и например IQ человека, которому нужно будет с этим возиться, совсем зелёный джуниор может даже и не догадаться, что с кодом что-то не так ). В общем, надеюсь эти небольшие мысли вслух направят начинающих джуниоров-энтузиастов на правильный путь и позволят удасться тем их проектам, которые иначе провалились бы про причинам, описанным выше. ! protected by SuperBnW ( https://github.com/afwbkbc/superbnw ) ! Public key: https://github.com/afwbkbc/gpg/blob/master/5122E95DCC3CF31CE9F75D956AF7D685006F5088.asc -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEUSLpXcw88xzp912VavfWhQBvUIgFAl8h4jsACgkQavfWhQBv UIjYEgv/QnMfp3EY0oEyzgmxpEwHZZ75+MULMpUAZC9ey6QMsNYckK5eHcDJ1pki 7J9eZ6Y/6sLuAP0j7GfZhrpPOE8XmigGDsJcvLXvDmWx6LQ3tvWDda4Q0Tzcv3DA 4O+ehwCKafS5z93zHCO1Wlo2gaKyLGvpxGwPSF/yTMBjePcRJ0ibPlp87Il6H2gA 321Y1AcbMf6dmppmHL85jhpM9kA28UjqZSLjWVlELeVBcMzuYJjzQoTIi0k3gu+D Ms8xgCbDc7Hm+Sa6HVko2qIeWdh3TrCD7aYzqWjIlHvTjcP4ahQjY2YFcY9TFX2Z xwblPpoMD06sFmDQ5uY2mOKb+rAKfHaqjFho2iHlRDtFZYZZ8+KA6tFC5jYtXIHA gmk2aP1DaYQKNsIRj3dPYfujGGd+not7SazCEawBz5YvqD15twvn0VkNyzU2XRbE cipsbC7bYj01UNn7w+eBAjwwzI4rMP0dqeeJSyC88G62+yy6DXzIAPWVHyphB6Jy O/a4D0cu =x8Uc -----END PGP SIGNATURE-----