Ваш изначальный "тэйк" неправильный. И по-хорошему минусы надо ставить за тэйк, а не случайную ошибку (но ошибка - показывает, что вы влезли вообще не имея представления о чём пишите).
Ну конкретно псие может и не помог, но те же маки уже 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 файлик (с интерфейсами если есть разделение на них и реализацию).
Для всех: Это её "генетический код". Если он равен нулю, матрица "больна" — она вырождена. Геометрически определитель — это коэффициент изменения площади (для 2D), объема (для 3D) или гиперобъема при преобразовании, которое задает матрица.
Вы же перепечатали статью из учебника или конспекта? А хорошо вчитывались?
Потому, что если излагать "всеобъемлюще и последовательно" - то и начинать надо с того, что матрица - это линейное преобразование (квадратная матрица - преобразование в себя), произведение - композиция 2х преобразований, нахождение обратной - преобразование ^-1^ , решение линейного уравнения - обращение преобразования вектора; А X A^-1^ ....
А если начали со "шпаргалки" - то в последовательном изложении и вовсе этого не упоминать, дабы умы школьников подглядывающих в шпаргалку не смущать.
Я лишь половину осилил и мне книга показалась в стиле "маня-циним".
Если сокращать до 3 слов, то смысл книги "действуй более цинично". Проблема в сравнительном залоге.
Как только ты действуешь "более цинично и на опережение" - все тут же будут знать чего от тебя ждать и все советы моментом обесценятся твоей же репутацией.
Первая мысль - просто оперировать символьной арифметикой (в принципе +/- курсовик для 10-11 классов школы) с переменными и без констант и выводить числовое представление на экран.
Ещё один шаг, на пути, который прошёл гугл - просто оперировать символьной арифметикой с переменными и без констант и выводить числовое представление на экран.
Но в принципе я растом довольно сильно разочарован. При разработке на Rust ты не решаешь задачу "выразить Х" и "разработать функциональность Y". Ты решаешь задачу: "как выразить то, что ты и без того знаешь именно на Rust". Вот если честно - не уверен, что это прям хорошо при обучении программированию.
Ваш изначальный "тэйк" неправильный.
И по-хорошему минусы надо ставить за тэйк, а не случайную ошибку (но ошибка - показывает, что вы влезли вообще не имея представления о чём пишите).
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 файлик (с интерфейсами если есть разделение на них и реализацию).
Да как-то так. Но после первой "по-крупному" все будут об этом знать и строить свои отношения исходя из этого.
Вы же перепечатали статью из учебника или конспекта? А хорошо вчитывались?
Потому, что если излагать "всеобъемлюще и последовательно" - то и начинать надо с того, что матрица - это линейное преобразование (квадратная матрица - преобразование в себя), произведение - композиция 2х преобразований, нахождение обратной - преобразование ^-1^ , решение линейного уравнения - обращение преобразования вектора; А X A^-1^ ....
А если начали со "шпаргалки" - то в последовательном изложении и вовсе этого не упоминать, дабы умы школьников подглядывающих в шпаргалку не смущать.
Я лишь половину осилил и мне книга показалась в стиле "маня-циним".
Если сокращать до 3 слов, то смысл книги "действуй более цинично".
Проблема в сравнительном залоге.
Как только ты действуешь "более цинично и на опережение" - все тут же будут знать чего от тебя ждать и все советы моментом обесценятся твоей же репутацией.
Первая мысль - просто оперировать символьной арифметикой (в принципе +/- курсовик для 10-11 классов школы) с переменными и без констант и выводить числовое представление на экран.
Ещё один шаг, на пути, который прошёл гугл - просто оперировать символьной арифметикой с переменными и без констант и выводить числовое представление на экран.
В теорее да - сам об этом думал.
Но в принципе я растом довольно сильно разочарован.
При разработке на Rust ты не решаешь задачу "выразить Х" и "разработать функциональность Y". Ты решаешь задачу: "как выразить то, что ты и без того знаешь именно на Rust". Вот если честно - не уверен, что это прям хорошо при обучении программированию.