Zen (март 2017), потом микрооптимизация Zen+ (апрель 2018, 2700x), потом-потом Zen 3 (ноябрь 2020). Можно вполне и 3.5 года сосчитать.
очень интересно у вас получается - сравниваете 2 конкретных проца с известными датами выпуска, но у первого почему-то считаете дату выхода платформы.
Я именно так рассчитал и пересел с Ryzen 1700 (только к концу марта 2017 нашел в наличии и получил за РРЦ в ~350€) на 5700X3D (200€ на момент покупки). Дешевле, чем первый проц. Разница в цене плохих и нормальных материнок была около 40€. Альтернативно мог выбрать из 5900X или 5950X. Мой друг пересаживался с Ryzen 1600 -> 2700X -> 5900X. Что мы сделали не так?
В итоге во сколько конкретно денег вам обошелся апгрейд? Вы отдали 350 евро, потом выбросили проц и через пару лет отдали еще 200?
Ryzen 1600 вышел в ноябре 2017, 2700x вышел в апреле 2018. Ваш друг каждые несколько месяцев меняет проц что ли? А почему вы тогда спрашиваете меня "что не так"?
Но я урок из этого извлек и пересел с i5 2400 (4c/4t) на Ryzen 7 1700 (8c/16t)
возникает сразу куча вопросов: 1)а вы не пробовали сразу купить проц с multithreading? 2)вы уверены, что все-все покупатели пк сразу занимаются его разгоном? 3)а потом вы пишете "энтузиасты продолжали сидеть на разогнанных Sandy Bridge, потому что производительностью он устраивал". Т.е. возвращаемся к самому началу - кто-то продумал, чего ожидает от нового пк, а кто-то нет. Вы относитесь ко второй категории.
С учетом использования быстрой памяти и там и там (DDR4-3600 + 5950X vs DDR5-6000 12900K), то отставание в Blender (1.02x), Corona не потрясающее. Cinebench R23 масштабировался лучше (1.07x), но не до степени "приговор" старой платформе.
вы сначала пишете, что хотите, чтобы сокет проца поддерживался долго, но когда разговор заходит о памяти, то оказывается, что вас устроит и память предыдущего поколения, которая явно будет поддерживаться меньше по времени. "Вы не понимаете, это другое?"
И не указали ни cTDP в вашей сборке, ни установленную память.
TDP 45Вт, 32Gb DDR5 4800Mhz. На случай, если потребуются остальные характеристики - "6800H ES" достаточно уникальная фраза, по которой можно найти всю интересующую информацию, но вы этого почему-то не сделали.
просто в два раза больше ядер для меня было очень важно.
странный субъективный аргумент. Вам потребовалось в два раза больше ядер, но HEDT вас не устраивают, а обновить проц нужно именно на текущей платформе. Вы говорите, что переставили проц в комп жены, а что за проц был там до этого? И все равно сводится к вопросам целесообразности. И раз вспомнили такие аргументы, то я обычно настольные компы полностью меняю раз в 10 лет, а ноутбуки - раз в 6 лет, поэтому даже если intel меняет сокеты каждое поколение - меня это вполне устраивает. Если нужна бОльшая мощность, а докупать б/у комплектующие по деньгам больше не имеет смысла, то значит время обновлять пк.
Без танцев с бубном, но с прошивкой биоса, но вы почему-то о этом так говорите как будто прошивка биоса это что-то сложное и невероятное.
До последнего пк у меня были компы на Intel. Мне ни разу не потребовалось прошивать биос, чтобы поменять проц. На платформе amd наоборот нужно всегда его прошивать?
Я купил какой-то процессор он не устроил меня производительностью видео ядра, поэтому идея встраивать видео ядра в процессор плохая.
6800H ES - это не единственный пример. До этого пробовал на core i3-3240 (2012 года) запустить игру Armello (простая настольная игра 2015 года, но в 3d) - она шла хуже, чем с видеокартой 9600 (2008 года). Снова неправильная видеокарта и неправильный проц?
А вас не смущает что так устроены два поколения последних плейстейшен и хбокс?
а потом люди в интернетах не понимают, почему эти консоли не выдают 60 fps...
А Intel 8086 и Intel 8087стояли в разных сокетах, и первые материнки под х86 были двухсокетные и что? Ключевой компонент их успеха, я щитаю, надо делать именно так. FPU тогда было аналогом GPU сейчас.
сегодня у вас есть сокет под проц и есть видеокарта отдельной платой, которые можно менять. Или вам принципиально, чтобы еще каждая микросхема на видеокарте стояла в держателе, и ее можно было менять без перепайки?
Вы не поверите, но такие эксперименты были. CPU, GPU, это достаточно условное в принципе деление. AVX512 делает ли CPU векторным процессором или нет? Можно ли микрокод CPU считать аналогом драйвера для GPU? Считать ли ALU и FPU двумя разными процессорами в одном кристалле?
И что случилось с этими экспериментами? Более слабый CPU победил более мощную GPU?
вот давайте не приукрашивать. Разница между 2700х и 5950х - два года, а не 3 как вы тут рассказываете. Через два года менять процессор - это не преимущество сокета, а вы просто не рассчитали нужную мощность пк и переплатили за замену проца.
Дальше новый процессор у вас стал на старую материнку с AM4 без танцев с бубном (прошивка bios) или вы об этом умолчали?
А то, что amd не меняла сокет и отчасти из-за этого долго не могла добавить поддержку DDR5 - это другое?
общая память под процессор и видеоядро это архитектурно более правильное решение, приставки, телефоны и даже ноутбуки(макбуки и процессоры серии Ryzen 9 AI) и даже десктопы (мак мини и мини ПК) такую схему используют. Причем перф я бы не сказал что там слабый, уровень средне бюджетных видеокарт примерно. То есть не дохлая встройка что бы было.
купил мини-пк с 6800H ES... Уровень видеокарты чуть-чуть лучше R9 270x - средняя дискретная видеокарта... десятилетней давности
почему бы не сделать тогда два сокета под такие процессоры
Atari Jaguar была на 5 процессорах в 3 чипах и это был один из факторов ее провала.
почему бы не сделать "процессор" состоящий из одного только видео ядра отдав весь транзисторный бюджет только под видео ядро.
с такой логикой зачем в компьютере вообще CPU? Давайте заменим его видеокартой - видеокарты же мощнее)
мне тоже не нравится, но походу скоро так и будет с блокнотами (из-за chatGPT).
По поводу GitHub не согласен - может я предпочитаю для саморазивития читать теорию - те же статьи на хабре вместо того, чтобы вести какой-то узкоспециализированный pet-проект.
у меня было не 15 этапов, а 3 или 4. Они хотели много собеседований - я сделал то, чего они хотят с одной оговоркой. Я к каждому техническому собесу готовился как к экзамену, а экзамены чаще, чем раз в 3 дня не ставят. Где-то в конце не я, а уже меня спрашивали, нельзя ли побыстрее)
Спасибо за детальный ответ, но меня смутило немного другое. Perplexity мне тоже выдал, что [weak self] использовать не нужно, но запрос:
you use Structured Concurrency in swift. Task { ... } means using of swift blocks. Should you always write [weak self] and "guard let self else" (or other code) to prevent retain cycles
Ответ:
When using Structured Concurrency in Swift with Task { ... } blocks, you don't always need to write [weak self] and guard let self else to prevent retain cycles45. Here's why:
Swift Concurrency and Memory Management: Swift’s concurrency model, introduced in Swift 5.5, includes features like async/await, actors, and tasks, designed to avoid traditional multithreading pitfalls such as race conditions and deadlocks1.
Sendable Closures: When you create a new task, the work it performs is within a @Sendable closure. These closures are restricted from capturing mutable variables in their lexical context, ensuring that captured values are safe to share5. This is achieved because the values are either value types (like Int and String) or objects designed to be accessed from multiple threads, such as actors5.
Structured Concurrency Benefits: Structured concurrency manages the lifecycle of concurrent tasks in a hierarchical manner, ensuring tasks are created, executed, and terminated within a clear scope7. This helps in automatic resource management and makes code more predictable7.
When to Use [weak self]: The primary reason to use [weak self] is to prevent strong reference cycles when capturing self in a closure, especially if the closure might outlive the object it's capturing46. However, with Swift Concurrency, the need for [weak self] is reduced because asynchronous callbacks are guaranteed to run exactly once, eliminating the possibility of permanent reference cycles4.
Unnecessary [weak self] Overhead: Reflexively adding [weak self] can increase runtime overhead and code complexity, as it requires handling the possibility of self being nil4. This can make the code harder to reason about, as arbitrary amounts of code might be skipped if self is nil4.
In summary, while [weak self] and guard let self else are crucial in many traditional closure scenarios to prevent retain cycles, Swift's structured concurrency and the nature of asynchronous tasks often eliminate the need for them145. You should focus on using actors and @Sendable closures to manage state and ensure data safety in concurrent code57.
Спасибо за статью про эксперименты с GCD я ее читал и перечитывал несколько раз. Я еще не читал последнюю статью, но если в первых двух у вас playground и отдельные функции, где обработка retain cycle особо не имеет значения, то в последней она нужна, а вы ее игнорируете. Получается, что вы заморочились на то, чтобы у вас изображение не подтянулось старое (хотя это можно предусмотреть и в GCD отдельно), но проигнорировали то, что у вас структура остается висеть в памяти. Другими словами если у вас есть код:
DispatchQueue.main.async {
self....
}
То DispatchQueue настолько "мощно" удерживает self в памяти, что без `[weak self]` этот класс/структура могут быть созданы в фоновом потоке, а уничтожиться в главном.
Насколько я понимаю, с Task будет аналогичная ситуация - объект будет удерживаться в памяти в лучшем случае до тех пор, пока этот Task не закончится. А это кроме утечек может привести к другим приколам, например, если класс внутри Task посылает сообщения другим классам. Кстати нигде в документации не описано, что делать с Task в таких случаях.
По поводу @MainActor и nonisolated - я вас правильно понимаю, вы сначала включили strict concurrency, а потом с помощью nonisolated вручную отключили проверки? Но какой тогда смысл в strict concurrency?
До Swift 6 (на который еще не все перешли) буквы в лог выводятся в произвольном порядке, хотя казалось бы - главный поток, и каждая Task должна "наследовать контекст".
В итоге оказывается, что structured concurrency до сих пор сырой. А если предусматривать все-все его особенности, то сложность кода окажется похлеще, чем у Pyramid of doom. И кстати почему-то предыдущий Combine в этом плане оказался более продуманным.
Но опять же может я и ошибаюсь - по особенностям работы Task я не всегда нахожу информацию. А chatGPT вряд ли поможет в этом - я использую Perplexity, который аргументирует свои ответы ссылками на источники, откуда берет информацию - и эти источники часто неверные.
я просил возможно еще более простую вещь - нарисовать 2 view с эффектом blend (смешивание) в UIKit. Визуально это отдаленно похоже на 2 соединенные капли. До сих пор все модели или пытаются смешать 2 цвета в один и закрасить им все, или придумывают несуществующий фильтр "blend", с которым приложение даже не скомпилируется.
старый CGD (Central Grand Dispatch), так что приходилось дополнительно рефакторить код до современного async / await.
Использовал современную async / await систему работы с многопоточностью
Выборка данных из сети выполнена с помощью современной async / awaitсистемы работы с многопоточностью.
И дальше еще несколько раз упомянуто, что "swift concurrency современный". Соответственно: 1)вы писали, что генерируете код с помощью нейросетей, но у вас и сама статья сгенерирована в chatGPT? 2)если статья все-таки не сгенерирована, то чем конкретно в вашем примере GCD хуже, чем Structured Concurrency, да еще со strict concurrency? Код вам уже сгенерировали. Сложность кода при переходе на strict concurrency растет в геометрической прогрессии.
очень интересно у вас получается - сравниваете 2 конкретных проца с известными датами выпуска, но у первого почему-то считаете дату выхода платформы.
В итоге во сколько конкретно денег вам обошелся апгрейд? Вы отдали 350 евро, потом выбросили проц и через пару лет отдали еще 200?
Ryzen 1600 вышел в ноябре 2017, 2700x вышел в апреле 2018. Ваш друг каждые несколько месяцев меняет проц что ли? А почему вы тогда спрашиваете меня "что не так"?
возникает сразу куча вопросов:
1)а вы не пробовали сразу купить проц с multithreading?
2)вы уверены, что все-все покупатели пк сразу занимаются его разгоном?
3)а потом вы пишете "энтузиасты продолжали сидеть на разогнанных Sandy Bridge, потому что производительностью он устраивал".
Т.е. возвращаемся к самому началу - кто-то продумал, чего ожидает от нового пк, а кто-то нет. Вы относитесь ко второй категории.
держите и вы тогда про недостатки самостоятельной прошивки bios:
https://forum.ixbt.com/topic.cgi?id=42:18912
вы сначала пишете, что хотите, чтобы сокет проца поддерживался долго, но когда разговор заходит о памяти, то оказывается, что вас устроит и память предыдущего поколения, которая явно будет поддерживаться меньше по времени. "Вы не понимаете, это другое?"
TDP 45Вт, 32Gb DDR5 4800Mhz. На случай, если потребуются остальные характеристики - "6800H ES" достаточно уникальная фраза, по которой можно найти всю интересующую информацию, но вы этого почему-то не сделали.
А в arc уже завезли оптимизацию? Я про энергопотребление в простое
Нет, так не работает или по крайней мере не работало, когда видеокарты были agp.
для вашей задумки не подходит райзер на pcie x1?
странный субъективный аргумент. Вам потребовалось в два раза больше ядер, но HEDT вас не устраивают, а обновить проц нужно именно на текущей платформе. Вы говорите, что переставили проц в комп жены, а что за проц был там до этого? И все равно сводится к вопросам целесообразности.
И раз вспомнили такие аргументы, то я обычно настольные компы полностью меняю раз в 10 лет, а ноутбуки - раз в 6 лет, поэтому даже если intel меняет сокеты каждое поколение - меня это вполне устраивает. Если нужна бОльшая мощность, а докупать б/у комплектующие по деньгам больше не имеет смысла, то значит время обновлять пк.
До последнего пк у меня были компы на Intel. Мне ни разу не потребовалось прошивать биос, чтобы поменять проц. На платформе amd наоборот нужно всегда его прошивать?
6800H ES - это не единственный пример. До этого пробовал на core i3-3240 (2012 года) запустить игру Armello (простая настольная игра 2015 года, но в 3d) - она шла хуже, чем с видеокартой 9600 (2008 года). Снова неправильная видеокарта и неправильный проц?
а потом люди в интернетах не понимают, почему эти консоли не выдают 60 fps...
сегодня у вас есть сокет под проц и есть видеокарта отдельной платой, которые можно менять. Или вам принципиально, чтобы еще каждая микросхема на видеокарте стояла в держателе, и ее можно было менять без перепайки?
И что случилось с этими экспериментами? Более слабый CPU победил более мощную GPU?
вот давайте не приукрашивать. Разница между 2700х и 5950х - два года, а не 3 как вы тут рассказываете. Через два года менять процессор - это не преимущество сокета, а вы просто не рассчитали нужную мощность пк и переплатили за замену проца.
Дальше новый процессор у вас стал на старую материнку с AM4 без танцев с бубном (прошивка bios) или вы об этом умолчали?
А то, что amd не меняла сокет и отчасти из-за этого долго не могла добавить поддержку DDR5 - это другое?
купил мини-пк с 6800H ES... Уровень видеокарты чуть-чуть лучше R9 270x - средняя дискретная видеокарта... десятилетней давности
Atari Jaguar была на 5 процессорах в 3 чипах и это был один из факторов ее провала.
с такой логикой зачем в компьютере вообще CPU? Давайте заменим его видеокартой - видеокарты же мощнее)
почему вы перепечатываете чужие статьи и даже не проверяете работоспособность ссылок?
в статье игрушка со светодиодами, метеостанция и телевизор на андроиде, которые вызывают еще больше вопросов в плане целесообразности
меня впечатлил только кибердек
я увольнялся с предыдущего места работы и в последний месяц взял отпуск.
встречный вопрос - что мешает проходить собеседования в несколько компаний одновременно - по крайней мере до первого оффера?
мне всегда казалось, что более ценный навык - умение осваивать новые алгоритмы, а не решать простые задачи с литкода
у меня даже часть "испытательного срока" была на удаленке при наличии офиса в городе, а вы пишете про "работать только в офисе"
мне тоже не нравится, но походу скоро так и будет с блокнотами (из-за chatGPT).
По поводу GitHub не согласен - может я предпочитаю для саморазивития читать теорию - те же статьи на хабре вместо того, чтобы вести какой-то узкоспециализированный pet-проект.
у меня было не 15 этапов, а 3 или 4. Они хотели много собеседований - я сделал то, чего они хотят с одной оговоркой. Я к каждому техническому собесу готовился как к экзамену, а экзамены чаще, чем раз в 3 дня не ставят. Где-то в конце не я, а уже меня спрашивали, нельзя ли побыстрее)
Спасибо за детальный ответ, но меня смутило немного другое. Perplexity мне тоже выдал, что [weak self] использовать не нужно, но запрос:
Ответ:
Выглядит правильно и логично, но ссылается сюда (здесь вообще ничего, просто примеры swift concurrency):
https://toxigon.com/swift-concurrency-best-practices
и сюда (список proposals, которые не обязательно вошли в релиз swift):
https://forums.swift.org/t/swift-concurrency-roadmap/41611
Т.е. рассуждения вроде как верные, но некоторые источники невалидные/нерелевантные.
как убрать эту статью из выдачи? А то Хабр превращается в ресурс NSFW (Not Suitable For Work)
Спасибо за статью про эксперименты с GCD я ее читал и перечитывал несколько раз.
Я еще не читал последнюю статью, но если в первых двух у вас playground и отдельные функции, где обработка retain cycle особо не имеет значения, то в последней она нужна, а вы ее игнорируете. Получается, что вы заморочились на то, чтобы у вас изображение не подтянулось старое (хотя это можно предусмотреть и в GCD отдельно), но проигнорировали то, что у вас структура остается висеть в памяти.
Другими словами если у вас есть код:
То DispatchQueue настолько "мощно" удерживает self в памяти, что без `[weak self]` этот класс/структура могут быть созданы в фоновом потоке, а уничтожиться в главном.
Насколько я понимаю, с Task будет аналогичная ситуация - объект будет удерживаться в памяти в лучшем случае до тех пор, пока этот Task не закончится. А это кроме утечек может привести к другим приколам, например, если класс внутри Task посылает сообщения другим классам. Кстати нигде в документации не описано, что делать с Task в таких случаях.
По поводу @MainActor и nonisolated - я вас правильно понимаю, вы сначала включили strict concurrency, а потом с помощью nonisolated вручную отключили проверки? Но какой тогда смысл в strict concurrency?
Дальше тут я недавно читал эту статью https://habr.com/ru/companies/yandex/articles/879078/ и там есть кусок кода:
До Swift 6 (на который еще не все перешли) буквы в лог выводятся в произвольном порядке, хотя казалось бы - главный поток, и каждая Task должна "наследовать контекст".
В итоге оказывается, что structured concurrency до сих пор сырой. А если предусматривать все-все его особенности, то сложность кода окажется похлеще, чем у Pyramid of doom. И кстати почему-то предыдущий Combine в этом плане оказался более продуманным.
Но опять же может я и ошибаюсь - по особенностям работы Task я не всегда нахожу информацию. А chatGPT вряд ли поможет в этом - я использую Perplexity, который аргументирует свои ответы ссылками на источники, откуда берет информацию - и эти источники часто неверные.
я просил возможно еще более простую вещь - нарисовать 2 view с эффектом blend (смешивание) в UIKit. Визуально это отдаленно похоже на 2 соединенные капли.
До сих пор все модели или пытаются смешать 2 цвета в один и закрасить им все, или придумывают несуществующий фильтр "blend", с которым приложение даже не скомпилируется.
И дальше еще несколько раз упомянуто, что "swift concurrency современный". Соответственно:
1)вы писали, что генерируете код с помощью нейросетей, но у вас и сама статья сгенерирована в chatGPT?
2)если статья все-таки не сгенерирована, то чем конкретно в вашем примере GCD хуже, чем Structured Concurrency, да еще со strict concurrency? Код вам уже сгенерировали. Сложность кода при переходе на strict concurrency растет в геометрической прогрессии.