Если начать дробить слишком мелко - проще сразу решить задачу, чем расписывать, в условной Jira. А если действительно можно решить задачи уровня медиум лит-кода (но не ровно те, на которых её тренировали - то ещё одно моё почтение команде ChatGPT).
Целочисленное деление в Python подразумевает, что остаток от деления на N всегда будет числом от 0 до N-1, в том числе и для отрицательных чисел... Ну а второй подход лучше ложится на конкретное hardware и потому на сколько-то пикосекунд быстрее.
Второй подход, если что обеспечивает инвариант: a == b * (a / b) + a % b а первый - не обеспечивает. И ещё неизвестно что несёт "меньшую когнитивную нагрузку на программиста".
Вернее так: если вы пишете бизнес-логику - наверное лучше второй подход, если что-то хорошо ложащееся на математику - первый
я бы вас уволил ... за противопоставление себя команде и токсичность
Токсичность там двусторонняя (принесу ваш ответ поржём) "отсутствие преданности" - в ответ на невыполнение ранее достигнутых договорённостей и попытке скинуть сырой проект на поддержку (которым потом отдуваться) и вся работа, по словам@rezedent12 идёт за небольшую ЗП.
То есть фирма изначально экономит на ЗП и прочих компенсациях, набрала за ЗП по низу рынка квалификацию по низу рынка и получила качество по низу рынка. Такие фирмы обычно не очень могут выбирать кого уволить пока человек что-то делает - потому, что нанять на его место на ту же ЗП просто не смогут с учётом рыночных реалий.
А через 10 лет от начала построения институтов с 0
Расстрел парламента. Снятие Председателя Конституционного суда РФ - за то, что назвал приказ президента неконституционным (заключение КС РФ от 12 сентября 1993) Коробка налички на "президентскую кампанию" ...
А вы проверяли как это будет работать в сочетании NUMA + "multiThreading" (а не MultiProcessing)?
А то вполне допускаю, что при cache-unfriendly доступе к памяти (разумеется надо тестить) второй вариант будет хуже, а именно его вы "заставляете" применить систему просто запрещая медленные ядра: 1. 4 быстрых ядра + 4 медленных ядра + "топологически родная память" 2. 4 быстрых ядра с родной памятью + 4 быстрых ядра с чужой памятью
> Если пара потоков неудачно уедет на разные ядра то легко можно словить минус 30% производительности.
Ну на [уже сколько лет] новых AMD просто двойная NUMA-архитектура (появился дополнительный слой объединения ядер).
То есть попросту если вы ловите какую-то проблему с memory affinity на Intel, то она будет (грубо по порядку величины) вдвое сильнее проявляться на AMD. С другой стороны если у вас типичная серверная нагрузка (обслуживаете, мелкие запросы, идеально на stateless серверах) - то у вас просто чуть не вдвое больше вычислительной мощности за те же деньги.
Из физики процесса - энергопотребление (и тепловыделение тоже) пропорционально квадрату частоты. У вас есть основания считать, что для турбо-частот это не так (и если не так, то в какую сторону и почему)?
То есть фактически энергии вы экономите обратно пропорционально частоте.
Разумеется если речь идёт о хорошо параллелящемся процессе. Если вам нужно выжать максимум из 1 потока - добро пожаловать в турбо-буст.
Очень тяжело читать, при том, что материал не выглядит как что-то запредельной сложности. Мне кажется, то описанию не хватает некоторой редактуры.
Поскольку архитектура вашего курса скорее "теоретическая" (это не объём практических знаний - а порядок изложения материала: теоретические учат с начала до конца (или с конца в начало) а практические с середины - сделаем ничего не делающий, но законченный MVP), то выигрышнее смотрятся курсы каждая глава которых построена по такой схеме: 1. общее описание - чего хотим добиться и почему; 2. набросок технической реализации; 3. некоторые частные, но важные технические детали + куда копать \ что улучшать в части 2 (весь бойлерплейт части-2 оставляем читателю воспроизвести самостоятельно, как упражнение к главе);
Отличная работа. А учитывая, что вы это делаете ради самообразования \ любви к искусству (программирования) - снимаю шляпу.
ПС А транзакции планируются? Мне всегда казалось, что DBMS это что-то про гарантии консистентности данных (ну то есть по-простому начиная с транзакций).
Результат решения мне кажется очень странным (насколько согласована мотивационная часть решения с остальным законодательством - не берусь судить).
Ведь любой живой художник обучается на чужих картинах (и часто обучается специально). Но в случае "живого художника" (несмотря на то, что он исходно вдохновлялся десятками "чужих интеллектуальных собственностей) действует презумпция добросовестности - пока плагиат не является явным - это создал он. Почему же когда часть работы (в том числе по "насмотренности" и "стилизации") мы передаём от отделов человеческого мозга - нейронке вдруг эта презумпция добросовестности исчезает? В человеческом мозге так же хранятся "какие-то образы" других великих и не очень художников.
Меня этот подход абсолютно устраивает, потому что я, как технолог, знаю, что лучше конвеера ничо не придумали со времен Форда.
Ну это так только в очень "поточном" месте. Но например фуллстек (или хотя бы T-shaped) часто решает "не очень поточную" задачу раза в 1.5 раза быстрее чем два раздельных специалиста.
Цена разрабов растет ... при этом знаний все меньше и меньше. Ну а что? Теперь можно код писать перетягивая блоки на экране....
Конечно ставить кучу всего ненужного: давайте на бек postgres как основная, redis как кеш, rabbitmq для обмена сообщениями, 3 сервиса на петухоне + селери отдельным инстансом. Потом давайте на каждую единицу сделаем кластер, все сервисы завернем в докер, потом давайте еще какой-то CI/CD настроим. На фронт давайте для простого приложения просто React возьмем, но для графиков Vue.js. Еще установим вместе с ReactJs и Vue.js пару тысяч пакетом через npm и подадим попрошайкам на еду пару баксов, которые донаты просят (на самом деле не переводите деньги, меньше денег - меньше ненужных пакетов, и лайки не ставьте.
А вы когда список всех "ненужных" технологий составляли - у вас не закралось сомнения, что знать надо сегодня даже джуну довольно много?
Мне кажется, что это стандартное старческое брюзжание.
Вот я глядя на список технологий которые надо "знать" джуну я понимаю почему многие курсы "натаскивают на прохождение интервью". Сегодня джуна на Python часто спрашивают то, что лет 10 назад на С \ С++ не спрашивали (ну чтобы далеко не ходить - "виды многопоточности" (MultiThread \ MultiProcess \ Asinc) или SOLID).
Знаний чтобы "вкатиться в IT на позицию джуна" надо действительно много и проглядывая просто "ключевые слова" - каждые пару лет понимаю, что требований стновится всё больше.
Примерно каждый второй (53%) полагает, что во время подозрительных роботизированных обзвонов нельзя нажимать «1» или «2» в тональном режиме на смартфоне: так злоумышленники могут заразить устройство. На самом деле чтобы вывести смартфон из строя, его нужно либо заразить вредоносным ПО, либо использовать ту или иную уязвимость. Нажатие клавиши в тоновом режиме к этому не приводит.
Знаете какая статья сегодня в ТОП хабра?
Разработчики FreeBSD выпустили экстренный патч безопасности против критической уязвимости в утилите ping
Поэтому общая стратегия: "меньше общаться со злоумышлинниками" вполне себе ОК. Особенно, но не исключительно, для тех, кто не очень понимает что у вас происходит "под капотом".
Смотрел недавно тесты. Карта получилась не очень, т.к цена повысилась на ~70% а производительность всего на ~ 45%.
Ну так high-end не про соотношение цена-качество, а про high / high-end задачи. Поэтому Cost per %your_metrci растёт в high-сегменте и для CPU и для GPU.
ПС Иногда, вы получаете: ваша задача стала работать быстрее, т.к. "теперь вмещаться во внутреннюю память" / "подвезли реализацию на AVX512". Но всё-же это не основной сценарий использования.
А в современном C++ во главу угла ставится подход когда мы пишем "что" должно быть сделано,
Ну это просто не так. fold \ scan - не является декларативным программированием (даже map \ filter не являются) А foreach(x.begin(), x.end(), &) - ещё хуже по многим причинам, от уродсва конструкции, до невозможности проконтролировать что там внутри foreach делается.
Так что code-2 выше - обычный императивный от плоти императивного код. Обойди контейнер с начала до конца и сделай: toupper с каждой буквой. Просто code-1 изуродовали специально (или спецом нашли 99%-ugliness percentile и выставили как чучело)
std::string title(const std::string A) {
std::string B(A);
bool change_ahead = true;
for (int i = 0; i < B.size(); i++) {
if (change_ahead)
B[i] = std::toupper(B[i]);
change_ahead = std::isspace(c);
}
return B
}
А вот такое (если код-1 специально не уродовать) - уже в общем-то мало чем хуже.
Ну в условном web же с появлением библиотек сложность не делась. В компиляторах тоже - перенеслась во frontend.
Для условного Nim (это не претензия, просто его место - better C) - достаточно. И то у вас каких-то высокоуровневых оптимизаций не будет (я во front-end не понимаю, поэтому их не перечислю, но это оптимизации на Call-Graph (вызова функций)).
Уже для условного D - возникают проблемы (ЕМНИП вроде little-big endian в его собственном линкуемом runtime). Haskell - ссылки выше.
ПС Несомненно LLVM отличный инструмент, кратно упрощающий реализацию toolchain ЯП (не поймите меня неправильно). Но содержательная работа всё равно осталась.
А почему нет-то? Если компилятор переложил backend на LLMV (терминологически: gcc bakend == LLVM midend + LLVM backend) - то это не значит, что самому компилятору важной и содержательной работы на frontend не осталось.
И даже после этого степень уверенности в корректной работе (на слабых моделях памяти) у них не очень большая: "we can now have considerably greater confidence in the correctness of GHC on today’s increasingly wide".
Раньше сказывалась плохо. В 2022 году в качестве бэкэнда работает LLVM. То есть качество генерации машинного кода получается сравнимым.
Можно говорить про наличие \ отсутствие высокоуровневых оптимизаций. Но в целом есть ощущение, что ничего критичного (типа падения производительности вдвое) там не происходит. А если происходит - то место допиливается руками
Вот смотрите мне сейчас проще найти ответ на сайте банка самому, чем говорить с ботом (по сути мне бот нужен только чтобы вызвать человека).
Но вот условный ChatGPT можно обучить так - чтобы он давал уже полезные для меня ответы. То есть по сути чтобы он заменил 2ую линию поддержки.
Если начать дробить слишком мелко - проще сразу решить задачу, чем расписывать, в условной Jira.
А если действительно можно решить задачи уровня медиум лит-кода (но не ровно те, на которых её тренировали - то ещё одно моё почтение команде ChatGPT).
Второй подход, если что обеспечивает инвариант:
a == b * (a / b) + a % b
а первый - не обеспечивает. И ещё неизвестно что несёт "меньшую когнитивную нагрузку на программиста".
Вернее так:
если вы пишете бизнес-логику - наверное лучше второй подход, если что-то хорошо ложащееся на математику - первый
Токсичность там двусторонняя (принесу ваш ответ поржём)
"отсутствие преданности" - в ответ на невыполнение ранее достигнутых договорённостей и попытке скинуть сырой проект на поддержку (которым потом отдуваться)
и вся работа, по словам@rezedent12 идёт за небольшую ЗП.
То есть фирма изначально экономит на ЗП и прочих компенсациях, набрала за ЗП по низу рынка квалификацию по низу рынка и получила качество по низу рынка.
Такие фирмы обычно не очень могут выбирать кого уволить пока человек что-то делает - потому, что нанять на его место на ту же ЗП просто не смогут с учётом рыночных реалий.
Расстрел парламента.
Снятие Председателя Конституционного суда РФ - за то, что назвал приказ президента неконституционным (заключение КС РФ от 12 сентября 1993)
Коробка налички на "президентскую кампанию"
...
А то в первые 10 лет институты прямо "строились".
А вы проверяли как это будет работать в сочетании NUMA + "multiThreading" (а не MultiProcessing)?
А то вполне допускаю, что при cache-unfriendly доступе к памяти (разумеется надо тестить) второй вариант будет хуже, а именно его вы "заставляете" применить систему просто запрещая медленные ядра:
1. 4 быстрых ядра + 4 медленных ядра + "топологически родная память"
2. 4 быстрых ядра с родной памятью + 4 быстрых ядра с чужой памятью
> Если пара потоков неудачно уедет на разные ядра то легко можно словить минус 30% производительности.
Ну на [уже сколько лет] новых AMD просто двойная NUMA-архитектура (появился дополнительный слой объединения ядер).
То есть попросту если вы ловите какую-то проблему с memory affinity на Intel, то она будет (грубо по порядку величины) вдвое сильнее проявляться на AMD. С другой стороны если у вас типичная серверная нагрузка (обслуживаете, мелкие запросы, идеально на stateless серверах) - то у вас просто чуть не вдвое больше вычислительной мощности за те же деньги.
Из физики процесса - энергопотребление (и тепловыделение тоже) пропорционально квадрату частоты.
У вас есть основания считать, что для турбо-частот это не так (и если не так, то в какую сторону и почему)?
То есть фактически энергии вы экономите обратно пропорционально частоте.
Разумеется если речь идёт о хорошо параллелящемся процессе. Если вам нужно выжать максимум из 1 потока - добро пожаловать в турбо-буст.
Очень тяжело читать, при том, что материал не выглядит как что-то запредельной сложности. Мне кажется, то описанию не хватает некоторой редактуры.
Поскольку архитектура вашего курса скорее "теоретическая" (это не объём практических знаний - а порядок изложения материала: теоретические учат с начала до конца (или с конца в начало) а практические с середины - сделаем ничего не делающий, но законченный MVP), то выигрышнее смотрятся курсы каждая глава которых построена по такой схеме:
1. общее описание - чего хотим добиться и почему;
2. набросок технической реализации;
3. некоторые частные, но важные технические детали + куда копать \ что улучшать в части 2 (весь бойлерплейт части-2 оставляем читателю воспроизвести самостоятельно, как упражнение к главе);
Отличная работа.
А учитывая, что вы это делаете ради самообразования \ любви к искусству (программирования) - снимаю шляпу.
ПС
А транзакции планируются?
Мне всегда казалось, что DBMS это что-то про гарантии консистентности данных (ну то есть по-простому начиная с транзакций).
Результат решения мне кажется очень странным (насколько согласована мотивационная часть решения с остальным законодательством - не берусь судить).
Ведь любой живой художник обучается на чужих картинах (и часто обучается специально).
Но в случае "живого художника" (несмотря на то, что он исходно вдохновлялся десятками "чужих интеллектуальных собственностей) действует презумпция добросовестности - пока плагиат не является явным - это создал он.
Почему же когда часть работы (в том числе по "насмотренности" и "стилизации") мы передаём от отделов человеческого мозга - нейронке вдруг эта презумпция добросовестности исчезает?
В человеческом мозге так же хранятся "какие-то образы" других великих и не очень художников.
Что же произошло-то?
Ну это так только в очень "поточном" месте.
Но например фуллстек (или хотя бы T-shaped) часто решает "не очень поточную" задачу раза в 1.5 раза быстрее чем два раздельных специалиста.
А вы когда список всех "ненужных" технологий составляли - у вас не закралось сомнения, что знать надо сегодня даже джуну довольно много?
Мне кажется, что это стандартное старческое брюзжание.
Вот я глядя на список технологий которые надо "знать" джуну я понимаю почему многие курсы "натаскивают на прохождение интервью". Сегодня джуна на Python часто спрашивают то, что лет 10 назад на С \ С++ не спрашивали (ну чтобы далеко не ходить - "виды многопоточности" (MultiThread \ MultiProcess \ Asinc) или SOLID).
Знаний чтобы "вкатиться в IT на позицию джуна" надо действительно много и проглядывая просто "ключевые слова" - каждые пару лет понимаю, что требований стновится всё больше.
Знаете какая статья сегодня в ТОП хабра?
Поэтому общая стратегия: "меньше общаться со злоумышлинниками" вполне себе ОК. Особенно, но не исключительно, для тех, кто не очень понимает что у вас происходит "под капотом".
Ну так high-end не про соотношение цена-качество, а про high / high-end задачи.
Поэтому Cost per %your_metrci растёт в high-сегменте и для CPU и для GPU.
ПС
Иногда, вы получаете: ваша задача стала работать быстрее, т.к. "теперь вмещаться во внутреннюю память" / "подвезли реализацию на AVX512". Но всё-же это не основной сценарий использования.
Ну это просто не так.
fold \ scan - не является декларативным программированием (даже map \ filter не являются)
А
foreach(x.begin(), x.end(), &) -ещё хуже по многим причинам, от уродсва конструкции, до невозможности проконтролировать что там внутри foreach делается.Так что code-2 выше - обычный императивный от плоти императивного код. Обойди контейнер с начала до конца и сделай: toupper с каждой буквой.
Просто code-1 изуродовали специально (или спецом нашли 99%-ugliness percentile и выставили как чучело)
А вот такое (если код-1 специально не уродовать) - уже в общем-то мало чем хуже.
Ну в условном web же с появлением библиотек сложность не делась.
В компиляторах тоже - перенеслась во frontend.
Для условного Nim (это не претензия, просто его место - better C) - достаточно.
И то у вас каких-то высокоуровневых оптимизаций не будет (я во front-end не понимаю, поэтому их не перечислю, но это оптимизации на Call-Graph (вызова функций)).
Уже для условного D - возникают проблемы (ЕМНИП вроде little-big endian в его собственном линкуемом runtime). Haskell - ссылки выше.
ПС
Несомненно LLVM отличный инструмент, кратно упрощающий реализацию toolchain ЯП (не поймите меня неправильно). Но содержательная работа всё равно осталась.
А почему нет-то?
Если компилятор переложил backend на LLMV (терминологически: gcc bakend == LLVM midend + LLVM backend) - то это не значит, что самому компилятору важной и содержательной работы на frontend не осталось.
Например GHC для запуска на ARM просто переписали часть GHC-runtime.
https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html
https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html
И даже после этого степень уверенности в корректной работе (на слабых моделях памяти) у них не очень большая: "we can now have considerably greater confidence in the correctness
of GHC on today’s increasingly wide".
Раньше сказывалась плохо.
В 2022 году в качестве бэкэнда работает LLVM. То есть качество генерации машинного кода получается сравнимым.
Можно говорить про наличие \ отсутствие высокоуровневых оптимизаций.
Но в целом есть ощущение, что ничего критичного (типа падения производительности вдвое) там не происходит. А если происходит - то место допиливается руками
"С с классами" - это не про не использование (код-1) vs использование (код-2) библиотечных функций.
А про механизмы управления памятью.
А сам код код-1 - явная пародия (ну или 99-й процентиль)