То есть куда-то подевались эти самые опытные программисты. ИИ должен помочь их вернуть.
У нас в системном программировании - доля 40+ весьма значительна.
Если же говорить о "программировании вообще" - последние лет 20 в России число программистов росло экспоненциально год от года. Долю тех, кто вошёл 10-30 лет назад можете вычислить сами, в зависимости от знаменателя прогресии.
Почти любая классификация людей на "типы" (вот утюги их надо включать в розетку и не обжечься, а вот ЭЛТ-телевизоры их надо периодически бить сбоку посильнее чтобы работали) - оказывалась в итоге лженаукой, без кавычем, ибо зачастую изначально претендавала на верность и полезность.
Ваш изначальный "тэйк" неправильный. И по-хорошему минусы надо ставить за тэйк, а не случайную ошибку (но ошибка - показывает, что вы влезли вообще не имея представления о чём пишите).
Ну конкретно псие может и не помог, но те же маки уже 5й год на унифицированной быстрой памяти и это явно сильно круче традиционного разделения памяти между цпу и гпу.
SLC (system level cache) - точка когерентности для CPU и GPU SLC когерентна для L2, с инвалидацией DMA-регионов (где-то в промежутке вариант, когда поверх общей памяти мапим GPU-регион в обход кэша).
Вы не правы потому, что предполагаете первый вариант ультимативно лучше. На самом же деле оба этих варианта конкурентны и предпочитаются в зависимости от типа нагрузки.
Ох... не примите ниженаписанное за нападки - мне просто очень грустно от качества статей по микроэлектронике вообще ((.
Про перезарядку конденсаторов говорил в самом конце (про усилители считывания), в абзаце с уточнениями. ..... В следующей части будут разбираться уже логические аспекты: режимы работы процессоров х86 и их влияние на память, сегментация, страничная организация памяти и так далее.
Кажется вообще самая содержательная часть всего описания памяти, определивная весь дизайн SOC последних 30 лет - memory wall - в план статьи не попадает.
Грустно. Это вообще какая-то болезнь хабра. Про "физику" - пожалуйста. Про что-то уже понятное прикладному программисту - пожалуйста.
Написать содержательно про системное программирование и\или микроэлектронику - просто выпадает из фокуса внимания.
Труд офигенный. Но самое главное (с точки зрения цифровой схемотехники - это действительно самое главное) не освещено:
Активируемая строка считывается в лэчи (можно регистры - но это не оптимально) - по порядку величины это время 10 нс.
Это действие называется row activation - и при это даныне из капаситоров пропадают.
После этого происходят многократные манипуляции с активированной строкой (то, что так выгодно делать основывается на ключевом свойстве программ - локальности).
После того, как мы закончили обработку текущей строки - мы заново "речаржим" строку (что по порядку величины также занимает 10 нс). Это необходимо сделать, даже если мы только читали, т.к. см "1.1" - в банке памяти текущей строки больше нет, она заменена 0-ми.
Ну и обо всяких мелочах, что общение происходит словами (а значит ширина смещения адреса внутри строки = "размер строки / размер слова в битах") - лучше бы тоже поправить. Вы буквально на всех уровнях: ISA / LLC / DDR-контроллер - оперируете со словами в памяти, а не с какими-то наборами бит.
В целом ощущение, что одну полноценную статю вы скомпали в пару абзацев и решили "и так сойдёт", хотя это прям ключевые моменты про устройство DDR.
Меркатор - неспроста самый популярный вариант карты Земли (наглядность).
Неправильно - с точки зрения наглядности меркатор очень плохая проекция (собственно поэтому её пытаются отменить, но слишком прижилась).
Главное преимущество - меркатор, проекция земли, сохраняющая углы - что было критически важно при путешествиях буквально до 20 века. Т.е. буквально каритан рисует свой вектор "азимут 30" смотрит на карту на сколько ему надо повернуть - и ровно на столько ему надо осуществить поворот в реальности вне зависимости от широты. Это навигационное удобство крыло как бык овыу все проблемы карты с наглядностью.
2. "Трудность путешествий" и "невозможность путешествий" - разные вещи. В вашем случае такая карта "симулирует" невозможность - опять мимо.
3.
вставлять в историческую симуляцию Земли карту, для которой не существует корректного 3Д-представления - это, мягко говоря, контрпродуктивно
Игры, в которые я играл без 3Д-карты: - герои 3,5,7 - age of wonders: 3, planetfall, 4 - UFO 2 - Total War - Rome, Warhammer Игры, в которые я играл с 3Д-картой: - UFO-1.
... симуляция развития человечества в реальной истории. И для этой цели карта-труба - близкий к идеалу баланс между наглядностью, интуитивностью и реализмом.
А есть какие-нибудь подтверждения этого тезиса?
Потому, что задав вопрос про обоснования тезиса - в ответ услышал лишь тот же самый тезис повторённый ещё несколько раз, без обоснований.
Мир-"баранка" и плоская карта - это две довольно разные карты.
Это "баранка" это только топологически, но если добавить размеры - то у баранки есть уменьшение внутренней части, чего нет у плоского представления. Это вообще крайне классная карта, т.к. любая топологическая точка на ней абсолютно симметрична (как и у шара). К сожалению корректного 3Д-представления этой развёртки не существует.
Ну и хочу сказать, что здесь вы крайне пристрастны. Я бы дал геймплею на такой карте 5 баллов. Т.к. каждая топологическая точка на ней эквивалентна (что особенно важно в начале игры).
Возьмите свою доку - оформленную как древовидная структура страничек. Каждый файлик вашего репозитория должен относится к какой-то странице (спекулятивное предположение - только к одной). Если несколько файликов относятся к одной странице - назовите их как-то например "мета-файл" (не хочу применять термины "пакет" или "модуль" - т.к. они могут законфликтовать с уже применяемыми).
======================================================== Цель - помочь агентам с архитектурой. Общая идея - отобразить семантическую структуру и доки и кода на архитектуру проекта.
Т.е. если вам надо как-то поменять "компонент-Х", вы находите его в дереве иерархии и:
1. Читаете саму страничку компонента 2. Читаете все станички "от корня до данной". 3. Читаете все под-странички компонента. 4. Читаете код исходных файликов, относящихся к этой страничке (по 2,3 - на этапе "предложи архитектуру" код читать не нужно).
цель - повысить уровень абстракции при работе ИИ-агента. Вообще с уровнями абстракции у современного ИИ не очень хорошо (в сравнении с человеком), но это очень длинная тема.
т.е. зафорсить его "скажи как надо сделать, оцени что оно делаемо вообще". Ок, теперь реализуй это.
Workflow - снижает ошибки (ну т.е. обратные петли с тестированием и watchdog'ом зовущим челвоека разгребать если пайп не прошёл). Проект - древовидная документация в конфлюесн + интерфейсы (боле-менее соответствующая структуре проекта в ФС).
Любой промпт (заливает в проект атомарно), вызывает следующие изменения: 1. Меняет "верхнеуровневую доку" конфлюенс (требует апрува от человека "продолжай") 2. По результатам изменений конфлюенса - меняет код, доуточняет изменение интерфейсов (которые через doxigen-like тоже экспортятся в доку) и нижнеуровневой доки 3. Дальше - прогоняет пайплайны, дописывает автотесты и т.д.
Основная фишка - проект это ВЕРХНЕУРОВНЕВАЯ ДОКА (которую читает агент) + код в файликах примерно в соотношении: 1 страничка : 1 файлик (с интерфейсами если есть разделение на них и реализацию).
Вы всерьёз спрашиваете или троллите?
Впрочем в любом из этих вариантов смысла в дальнейшем разговоре не вижу. Всего хорошего.
У нас в системном программировании - доля 40+ весьма значительна.
Если же говорить о "программировании вообще" - последние лет 20 в России число программистов росло экспоненциально год от года. Долю тех, кто вошёл 10-30 лет назад можете вычислить сами, в зависимости от знаменателя прогресии.
Есть куча материалов, где экспериментатор утверждает, что гоминиды шутят.
Но довольно сложно найти материал, где гоминиды без
суфлёраэкспериментатора демонстрируют те же способности.Почти любая классификация людей на "типы" (вот утюги их надо включать в розетку и не обжечься, а вот ЭЛТ-телевизоры их надо периодически бить сбоку посильнее чтобы работали) - оказывалась в итоге лженаукой, без кавычем, ибо зачастую изначально претендавала на верность и полезность.
И вот ещё одна.
Ваш изначальный "тэйк" неправильный.
И по-хорошему минусы надо ставить за тэйк, а не случайную ошибку (но ошибка - показывает, что вы влезли вообще не имея представления о чём пишите).
SLC (system level cache) - точка когерентности для CPU и GPU
SLC когерентна для L2, с инвалидацией DMA-регионов
(где-то в промежутке вариант, когда поверх общей памяти мапим GPU-регион в обход кэша).
Вы не правы потому, что предполагаете первый вариант ультимативно лучше. На самом же деле оба этих варианта конкурентны и предпочитаются в зависимости от типа нагрузки.
Что называется - давайте обратимся к источника.
Худшее, что можно сделать с guard clauses - это смешать их с вложенными условиями, особенно попеременно.
Особенно попеременно. После этого код становится абсолютно нечитаемым и крайне осложнённым для понимания.
Ох... не примите ниженаписанное за нападки - мне просто очень грустно от качества статей по микроэлектронике вообще ((.
Кажется вообще самая содержательная часть всего описания памяти, определивная весь дизайн SOC последних 30 лет - memory wall - в план статьи не попадает.
Грустно.
Это вообще какая-то болезнь хабра. Про "физику" - пожалуйста.
Про что-то уже понятное прикладному программисту - пожалуйста.
Написать содержательно про системное программирование и\или микроэлектронику - просто выпадает из фокуса внимания.
Труд офигенный.
Но самое главное (с точки зрения цифровой схемотехники - это действительно самое главное) не освещено:
Активируемая строка считывается в лэчи (можно регистры - но это не оптимально) - по порядку величины это время 10 нс.
Это действие называется row activation - и при это даныне из капаситоров пропадают.
После этого происходят многократные манипуляции с активированной строкой (то, что так выгодно делать основывается на ключевом свойстве программ - локальности).
После того, как мы закончили обработку текущей строки - мы заново "речаржим" строку (что по порядку величины также занимает 10 нс). Это необходимо сделать, даже если мы только читали, т.к. см "1.1" - в банке памяти текущей строки больше нет, она заменена 0-ми.
Ну и обо всяких мелочах, что общение происходит словами (а значит ширина смещения адреса внутри строки = "размер строки / размер слова в битах") - лучше бы тоже поправить. Вы буквально на всех уровнях: ISA / LLC / DDR-контроллер - оперируете со словами в памяти, а не с какими-то наборами бит.
В целом ощущение, что одну полноценную статю вы скомпали в пару абзацев и решили "и так сойдёт", хотя это прям ключевые моменты про устройство DDR.
А вы про это - да без разницы.
Первая реализация должна прибить гвоздями какое-то конкретное представление (чтобы на этот уровень времени не тратить).
Если это будет репозиторий в котором хранится *.md - ok.
Неправильно - с точки зрения наглядности меркатор очень плохая проекция (собственно поэтому её пытаются отменить, но слишком прижилась).
Главное преимущество - меркатор, проекция земли, сохраняющая углы - что было критически важно при путешествиях буквально до 20 века. Т.е. буквально каритан рисует свой вектор "азимут 30" смотрит на карту на сколько ему надо повернуть - и ровно на столько ему надо осуществить поворот в реальности вне зависимости от широты.
Это навигационное удобство крыло как бык овыу все проблемы карты с наглядностью.
2.
"Трудность путешествий" и "невозможность путешествий" - разные вещи.
В вашем случае такая карта "симулирует" невозможность - опять мимо.
3.
Игры, в которые я играл без 3Д-карты:
- герои 3,5,7
- age of wonders: 3, planetfall, 4
- UFO 2
- Total War - Rome, Warhammer
Игры, в которые я играл с 3Д-картой:
- UFO-1.
А есть какие-нибудь подтверждения этого тезиса?
Потому, что задав вопрос про обоснования тезиса - в ответ услышал лишь тот же самый тезис повторённый ещё несколько раз, без обоснований.
Зачем после того, как уже дано объяснение вы пишите так, как будто его не читали?
Топологические, метрические и географические - три разных понятия.
На реальной земле (без учёта рельефа) - топологические и метрические точки с любой разумной погрешностью эквивалентны.
Географические - нет.
П.С.
Что вам мешает в варианте "бублик" выделить экватор?
Мир-"баранка" и плоская карта - это две довольно разные карты.
Это "баранка" это только топологически, но если добавить размеры - то у баранки есть уменьшение внутренней части, чего нет у плоского представления.
Это вообще крайне классная карта, т.к. любая топологическая точка на ней абсолютно симметрична (как и у шара).
К сожалению корректного 3Д-представления этой развёртки не существует.
==================================================
Геймплей:
- Труба = 3
- Сфера = 5
- Баранка = 3
- Блин = 3
- Два блина = 4
Ну и хочу сказать, что здесь вы крайне пристрастны.
Я бы дал геймплею на такой карте 5 баллов. Т.к. каждая топологическая точка на ней эквивалентна (что особенно важно в начале игры).
Я пожалуй немного смягчу условие.
Возьмите свою доку - оформленную как древовидная структура страничек.
Каждый файлик вашего репозитория должен относится к какой-то странице (спекулятивное предположение - только к одной).
Если несколько файликов относятся к одной странице - назовите их как-то например "мета-файл" (не хочу применять термины "пакет" или "модуль" - т.к. они могут законфликтовать с уже применяемыми).
========================================================
Цель - помочь агентам с архитектурой.
Общая идея - отобразить семантическую структуру и доки и кода на архитектуру проекта.
Т.е. если вам надо как-то поменять "компонент-Х", вы находите его в дереве иерархии и:
1. Читаете саму страничку компонента
2. Читаете все станички "от корня до данной".
3. Читаете все под-странички компонента.
4. Читаете код исходных файликов, относящихся к этой страничке (по 2,3 - на этапе "предложи архитектуру" код читать не нужно).
Ответил выше про "зафорсить повышение уровня абстракции при работе ИИ-агентов".
цель - повысить уровень абстракции при работе ИИ-агента. Вообще с уровнями абстракции у современного ИИ не очень хорошо (в сравнении с человеком), но это очень длинная тема.
т.е. зафорсить его "скажи как надо сделать, оцени что оно делаемо вообще".
Ок, теперь реализуй это.
Ну так нужны новые языки "под ключ" для агентов.
С новыми workflow и хранением проекта.
Workflow - снижает ошибки (ну т.е. обратные петли с тестированием и watchdog'ом зовущим челвоека разгребать если пайп не прошёл).
Проект - древовидная документация в конфлюесн + интерфейсы (боле-менее соответствующая структуре проекта в ФС).
Любой промпт (заливает в проект атомарно), вызывает следующие изменения:
1. Меняет "верхнеуровневую доку" конфлюенс (требует апрува от человека "продолжай")
2. По результатам изменений конфлюенса - меняет код, доуточняет изменение интерфейсов (которые через doxigen-like тоже экспортятся в доку) и нижнеуровневой доки
3. Дальше - прогоняет пайплайны, дописывает автотесты и т.д.
Основная фишка - проект это ВЕРХНЕУРОВНЕВАЯ ДОКА (которую читает агент) + код в файликах примерно в соотношении: 1 страничка : 1 файлик (с интерфейсами если есть разделение на них и реализацию).
Да как-то так. Но после первой "по-крупному" все будут об этом знать и строить свои отношения исходя из этого.