Ту же ньютоновскую механику до сих пор более чем успешно применяют на практике, хотя она не согласуется с теорией относительности.
Ньютоновская механика — частный случай СТО для малых скоростей. СТО — частный случай ОТО без учета гравитации.
Свет рассматривают в зависимости от задачи как электромагнитную волну или как поток частиц. Тоже вполне успешно.
Теория тут тоже одна и они [элементарные частицы] проявляют одновременно и свойства частиц, и свойства волн. В каких-то условиях можно упростить вычисления и пренебречь некоторыми особенностями: чисто волновое описание является опять таки частным случаем: просто для того что бы нам рассчитать антенны, нам не нужно городить формулы из квантовой электродинамики, а вот для описания фотоэффекта чисто волновое представление уже не проканает.
Физика — она как Шрек, который как луковица :-) представляет из себя слои разных теорий разной степени приближенности к одной основной (пока неизвестной). Реально то теорий сейчас всего две — квантовая механика, да теория относительности, остальные можно рассматривать как их производные, да частные случаи и то, это только потому что КМ и ОТО не очень совместимы друг с другом.
А почему не должно? Почему должно быть так мало языков?
А зачем их собственно много? Я еще понимаю ассемблер — он для каждого процессора свой нужен, хотя один фиг, все ассемблеры (по крайней мере для одного типа вычислительных машин) будут пересекаться друг с другом основным набором команд.
А вон у совсем брутальных хардварщиков языка вообще два — Verilog, да VHDL, да их производные и справляются как-то.
А для языков высокого уровня — действительно нет никакой фундаментальной причины плодиться и размножаться, кроме как различия платформ (а их не так уж и много). Т.е. все то многообразие что мы наблюдаем — просто разная степень кривизны реализации, да вкусовщина.
Собственно реально массово используемых действительно не так уж и много языков, а все современные языки происходят либо от Fortran'а и его прямых потомков: Algol и Basic, либо от более поздних независимых веток: APL, Lisp (точнее IPL), COMIT и Cobol (точнее FLOW-MATIC) — больше чойт на память и не приходит, либо их комбинации.
С точки зрения работы над ошибками и наличия строгого обоснования, самые подкованные это APL и Lisp — их приемы много куда проникли, но между тем я что-то не вижу орд программистов на Scheme (хотя именно на нем идет обучение в MIT) и Haskell со всякими F# (на Scala вроде как кто-то пишет)
Вообще первый объектный язык — SIMULA (SIMUlation LAnguage) был создан именно что для описания объектной картины мира и последующей её симуляции. Сам язык был создан для научно-исследовательских задач, а не для прикладных… потом уже всякие Страуструпы и Аланы Кейны переврали его, кто как мог :-)
в ней вообще есть только один корневой класс Object
А еще там есть примитивные типы: byte, short, int, long, char, float, double и boolean, которые живут сами по себе. Забудете про разницу между Long и long — наткнетесь на упаковку-распаковку.
Если уж быть последовательными, то операция сложения не принадлежит матрице, скорее уж она принадлежит какому-нибудь вычислителю…
Хз, наверное как посмотреть: математически для каждого множества определяется свой набор арифметических операций, порой с особыми правилами (например, умножение матриц), так что арифметические операции именно что являются свойствами множества, то бишь классов и типов по программерски
В другом подходе ОБЪЕКТ
Вот в этом то вся бяда. Нет точных определений, т.е. да, действительно, у ООП есть проблема с фундаментальным теоретическим обоснованием.
который на специализированном языке описывает предметную область
Вы наверное фанат декларативного программирования :-) Угадал? :-)
Есть такая фигня. Как правило в этих же странах семейное положение учитывается при подсчете налога и вознаграждается соответствующей ставкой уже для общего домовладения (а не для каждого по отдельности).
Но там вообще-то ограничения всегда присутсвуют — в ряде штатов, например, требуется чтоб 10 лет прожили вместе причем так, что один из супругов сколько-то лет вел хозяйство и потерял квалификацию. Ну и рассматривается эта фигня как форма раздела имущества, например, в некоторых штатах ученая степень, полученная в браке тоже вот внезапно считается совместным имуществом — теперь делите её как хотите :-)
И логика здесь именно в том, что прекращение брачных отношений, не освобождает кормильца от финансовой ответственности за тех, кто находится у него на иждивении :-) Т.е. это отношения не ПОСЛЕ, а именно что продолжение прежних [финансовых] обязательств не смотря на развод.
И кстати зачастую не требуется наличие зарегистрированного брака (palimony) — достаточно доказать факт сожительства (хотя тут сложнее) и факт нахождения на иждивении в этом сожительстве. Естественно это в равной мере относится и к супругам и к детям (сhild support)… и кстати к родителям: иск от родителей к детям на содержание тоже может быть — деньги на образование, лечение и т.п. и т.д. В общем долг платежом красен.
Все тут однозначно:
1) Запрет на работу у конкурента — попытка монополизации трудовых ресурсов. Любая монополия оказывает разрушительное действие на рынок.
2) Основа рынка — конкуренция: работодатели конкурируют между собой за работников, работники конкурируют между собой за вакансию, производители конкурируют между собой за долю в рынке, покупатели конкурируют между собой за товар и т.д. Если какой-то умник пытается такими договорами ограничить конкуренцию, то см. пункт 1.
3) Вторая основа рынка — свобода. Все участники рынка находятся в равных правах. Навязывая такой пункт в договоре, работодатель хочет нечестным способом повысить свою позицию в этой бизнес игре. А это смотри пункт 1
4) В принципе рынок строится на компромиссах. Так что если одна сторона где-то забирает, то должна где-то что-то дать, материальное вознаграждение за подписание такого пункта, вполне себе ассиметричная игра. Но вот такая уловка как раз таки неоднозначная, т.к. смотри пункт 1
5) Ну это является дискриминацией, увы но после полюбовного завершения договорных отношений ни одна сторона уже не может ничего предъявить другой.
6) Крепостное право и рабство вроде как во всех развитых странах отменили. Вон даже штат Миссисипи подтянулся.
Потому что:
а) Любое односторонние ограничение должно компенсироваться — пусть тогда платит, зарплату пока действует соглашение, а работник уже не работает.
б) Это выходит за пределы компетенции работодателя.
в) Это форма монополизации трудовых ресурсов.
г) Это бессмысленно и намекает на то, что бизнес-процесс построен хреново, раз один рядовой сотрудник, уйдя к конкуренту порушит весь это проебизнес.
Это не юридическое ограничение, а обязательство по содержанию детей, к браку вообще не относится.
Требование погашать задолженность по кредиту, ПОСЛЕ того как разбил айфон
Потому что кредитный договор не заканчивается пока не будет полностью выплачен кредит.
Лишение права вождения ПОСЛЕ того, как протрезвел и осознал.
Военный или чиновник, который должен держать в тайне знания и навыки ПОСЛЕ увольнения.
Не должен, т.к. это никак не связано с увольнением и службой. Должен если подписал отдельный договор — подписку о неразглашении за доступ к данным, которая подписывается на определенный срок. Можно не подписывать. Сам тип договора, аналогичен:
Свидетелю не платят за неразглашение в интересах следствия ПОСЛЕ допроса.
Потому что допрос часть следственного процесса, в течении которого и действует подписка о неразглашении. Следственный процесс не заканчивается после допроса если что.
Лишение права вождения ПОСЛЕ того, как протрезвел и осознал.
Это вообще к чему? Не «после», а «за», а именно за нарушение общественного договора — ПДД. Собственно лишают их именно с момента свершения события, а срок лишений — мера пресечения.
Алименты платят не за то что вступил в брак, а за сделанного ребенка, причем пофиг, в браке или нет — сделал, все, на 18 лет ты родитель и обязан его обеспечивать — это не ограничение ПОСЛЕ, это обязательство на определенный срок.
В среднем в год американцы отдыхают в отпуске по 16 дней году, это сейчас, в 90-ых годах в среднем было по 20 дней (вообще да, народ жалуется, шо в 80-90 трава была зеленее), это с учетом того шо больше половины американцев не используют свои отпускные дни полностью, однако они в большинстве своём и не работают полную рабочию неделю, средняя продолжительность рабочей недели — 35 часа.
Если думайте что это все грустно, то доя сравнения, в РФ работник трудится почти 2000 часов в год, а в США и Китае — 1800 часов, в Японии — 1700, в Германии — 1400 часов. Так что российские 28 дней в году — это волшебный розовый невидимый единорог.
Как договоришься. Договориться можно и на 20 рабочих часов в неделю по 6 месяцев в году :-)
У них трудового законодательства как такового нет, так шо таблички по всем этим соцпакетам бесполезные. Обычно со второго года договариваются на 2x10 дней в году отпуска + дней 20 больничных (100% оплачиваемых), больничные могут аккумулироваться. При этом надо иметь ввиду, что имеются ввиду оплачиваемые дни, за свой счет можешь наотдыхаться хоть пол года — это в РФ 3 зафиксированных опаздания и уволен, а на каждый пропуск — нужна отписка, там могут уволить в принципе в любой момент (если у тебя не пожизненное владение, но это особый случай), поэтому бюрократическим формализмом не страдают (точнее он у них другой).
Но это так, средняя температура по больнице: Все очень сильно зависит от штата, отрасли и профсоюзов (в южных штатах позиции профсоюзов традиционно слабее, обычные айтишники тоже слабо приспособлены к ведению профсоюзной деятельности). Еще на рынок труда очень сильно влияет госсектор.
Короче все сильно индивидуально, а в статье нет никакого анализа.
Проблема даже не в туториалах.
Проблема глубже: архитектурного и идеологического плана.
В Жабе, stack наследуется от Vector, который в свою очередь наследуется от ArrayList. Стек — это просто же просто коллекция в которой последним пришел и первым вышел, все, положил да взял, больше ничего. К чему тогда все это, зачем стэку метода вектора, такая глубокая иерархия наследования — хз. Или написал Long и long, и все, хана, нарвался на упаковку-распаковку. Врожденных дефектов в Жабе море. Богатая история Жабы — с одной стороны достоинство, но учитывая костылестроение — одновременно и проклятие.
А уж туториалы — это уже следствие. Внезапное их устаревание — тоже (хотя .NET генетики тоже не с первого раза дались, но сейчас про костыль ArrayList и не вспомнит уже). А основная масса изменено .NET как правило синтаксический сахар, сама же платформа очень хорошо проработана и жестко стандартизирована (увы, на этом преимущества заканчиваются)
B) Вообще размерность результата матричных операций всегда можно предсказать, зная размерность входных массивов. Поэтому лучше использовать сразу заготовленные массивы. А с указателями на память в условиях неопределенности (хз какой участок потребуется) — можно нарваться на кучу неприятных ошибок, а всякие контейнеры с динамически изменяемым размером, тот же vector например — резервируют память всегда с запасом, как только коэффициент заполнения станет большим — он расширит область памяти под свои нужды, опять таки с запасом. Неоптимально.
В) Вот тут бы я на компилятор не надеялся бы. Компиляторы C/C++ глупее даже чем компиляторы фортрана, тот же алиасинг памяти, например, не обойдет если не прописать квалификатор restrict там где надо. Ну эт так пример, первый какой в голову пришел.
Тут вот поминали всякие бласы и лппаки, так вот, в том же openBLAS жесткий си-хардкод, в том числе и с заточкой под конкретную архитектуру CPU
Г) CUDA. На сайте nvidia висит халявный тулкит с примерами. Только надо иметь ввиду, что максимальный перфоманс достигается тогда, когда объем входных данных приближается к 0.4 от размера видеопамяти.
Что же касается функций всяких, ну abs — дешевая функция. А вот косинусы-синусы — очень дорогие, на синус потребуется тактов в несколько раз больше чем на операцию деления. Так что их надо избегать по максимуму, можно еще лук-ап тейбел использовать (хэш-таблицы значений синусов-косинусов) если не боитесь потерять в точности. Если же синус от малого угла — то он равен собственно аргументу. Ну и т.д.
У вас неверные цифры. Доступ к L1 — 4 такта, L2 — 10 тактов, и только к L3 от 40 тактов начинается. Это вот у всяких Скайлейков.
Чисто операция сложения — 1 такт, целочисленного умножения — 3 такта, для чисел с плавающей запятой — 4 такта, для деления — 25 тактов, и эти циферки уже с учетом ч0рной магии, т.е. Циферки уже познакомились с Dispatch Unit их построили в рядочек и отправили куда надо, а к нему еще нужно попасть (а откуда они попадают? Явно что не из Нарнии) а число вычислительных блоков не впечатляет: у Бульдозера как я выше написал всего 4 вещественные умножалки с плавающей запятой на 64 бита, а у Скалэйк вероятно 12 штук, так что обращаться к кэшу в любом случае придется часто. А для тех же комплексных чисел потребуется по 3 умножалки и и по 5 сумматоров или 4 умножалки и 2 сумматора, кому-что нравиться — так шо кватернионам например будет уже грустно, а это все операции поворота в 3D.
Что касается сравнительно дешевых операций на видеокартах, то да, [sarcasm]видеокарты были разработаны именно для того чтобы складывать два целых числа, однозначно, а циферки в регистры CPU падают из Нарнии, бесплатно, инфа 145%[/sarcasm] Если говорить о всяких load/store в любом случае придется протаскивать данные из ОЗУ и обратно, пофиг, CPU это или GPU, ну а внутри процессоров еще предстоят увлекательные путешествия по кэшам разных уровней. Разница только в том, что видеокарта будет потолще по количеству вычислительных боков и реализует MIMD, а не SIMD как обычные процы, и пропускная способность GRAM-GPU, несколько побольше (так что L3 им и не нужен), чем RAM-CPU, так что вектора, матрицы и тензоры, пока видеопамяти хватает, GPU будет переваривать на порядок быстрее, не смотря на то что тактовая частота у видюшек все же ниже, чем у CPU. Есть только один способ обогнать видеокарты в матричных вычислениях с большим числом операций умножения/деления — фигачить вычислительные кластеры из Xeon Phi или делать свой ASIC под конкретные задачи, но это уже решения совершенно другого уровня.
А) Операции умножения бывают разными. Какая именно операция умножения?
Б) Памяти бывают тоже разные. К какой памяти обращение?
В) Любая операция подразумевает обращение к памяти. Хорошо если данные уже лежат в регистрах процессора, только вот им туда надо сначала попасть.
Г) Умножение в общем случае всегда дороже. Оно не просто само по себе медленнее сложения, оно принципе отжирает немалую часть кристалла, так что много их в ЦП не будет — места всем не хватит. Например, в Ьульдозере всего одно 256 битное FPU состоящие из 4-х блоков сложения-умножения по 64 бита каждое, в Skylake уже 4 FPU, но 256-и битных FPU максимум 3 (что кагбэ намекает на ч0рную магию) — для векторных вычислений это ниачом, так что любая нормальная видеокарточка (не заглушка, конечно же) сделает любой ЦП (Quadra P5000 vs двухголовый Intel Xeon на 64 ядра, ну примерно ~24:1, мобильная 960 vs Intel i7 ну примерно ~16:1), т.к. там нет недостатка в умножителях… зато там есть есть недостаток быстрой памяти...
Так что нет. Размен памяти на производительность — нормальная практика, даже не смотря на то что у нас есть бутылочное горлышко межу ЦП и ОЗУ, в разумных пределах конечно же.
А никакого. Кто-давно ляпнул глупость (хз, то ли в Симуле, то ли в Смоллтолке — меня тогда не было) и все давай ее использовать, не смотря на проблемы с инкапсуляцией, хрупкость классов, возрастающую цикломатическую сложность, фрагментацию данных и методов, да ряд других проблем (например с производительностью, при переопределении).
Вот только наследование реализации — это и есть собственно наследование :-) То что в статье выдается за наследование (очень распространенная ошибка) — это разные механизмы реализации полиморфизма: параметрический полиморфизм (генерики и шаблоны) и полиморфизм подтипов, вот полиморфизм подтипов можно реализовать либо системой включения подтипов (интерфейсы), либо системой включения подклассов — наследованием или композицией. Ну есть еще и третий вариант — перегрузка.
Ну вот композиция для повторного использования кода куда более прозрачна, вот только вот разработка атомарных и выделение общих компонент — долгое и нудное занятие. Куда проще нашлепать public class B:A, потом C:B, потом D:C, E:D и т.д. (видел как-то калокод с иерахией в 40 классов). Потом правда кто-нибудь влезет в В или А и все сломается, но автора уже не будет и чинить будут другие люди.
А. Все равно, несильно отличается от публикации на Хабре. Другое дело, шо большинство публикаций на Хабре не тянут на статью в журнал, а эта тянет. Я правда хз что там публикуют в статьях по этой тематике. Но опубликовать действительно можно.
Хз. Не уверен что это сработает. В самой идее (как и в статье про Рэндом) есть один фундаментальный изъян — нужно много итераций.
На самых нижних уровнях это наверное еще сработает — ибо насяльников много обновлять их можно относительно часто, а что бы более верхние уровни затронулись… в общем придется либо часто трясти кубики, а это неэффективно, либо трясти на протяжении сотен лет.
Ну а самый главный изъян — такой подход приведет к тому, что выигрывать будут только средние, и походу модель в этом случае не учитывает, что тогда лучшие будут оставаться не удел и начнут уходить (ибо амбиции и нет мотивации), так что после каждой итерации правый хвосты распределения будет усекаться и матожидание будет от итерации к итерации двигаться в сторону худших.
В общем работать это будет наверное только в каких-нибудь макдональдсах, где народу много и текучка высокая.
Ну и рэндом штука такая, без дополнительных эвристик приводит к длительным блужданиям.
Хм. Вот это похоже на то что в реальных компаниях происходит. Сначала они растут, достигают пика, а потом в течении десятилетий скатываются на дно, банкротятся или покупаются другими.
А добиться осциляций в этой моделе как-то можно? Что надо сделать что бы она начала выкарабкиваться со дна после нашествия нуннов-топоменеджеров?
Про витаминчики А и Е лучше бы подробнее раскрыть, т.к. при передозировки они токсичны, а разбросы дозировок: От 100ME до 100000ME.
И при этом любое вменяемое лечение многих кожных проблем в итоге завязано на том же витамине А и его метаболизме
Ньютоновская механика — частный случай СТО для малых скоростей. СТО — частный случай ОТО без учета гравитации.
Теория тут тоже одна и они [элементарные частицы] проявляют одновременно и свойства частиц, и свойства волн. В каких-то условиях можно упростить вычисления и пренебречь некоторыми особенностями: чисто волновое описание является опять таки частным случаем: просто для того что бы нам рассчитать антенны, нам не нужно городить формулы из квантовой электродинамики, а вот для описания фотоэффекта чисто волновое представление уже не проканает.
Физика — она как Шрек, который как луковица :-) представляет из себя слои разных теорий разной степени приближенности к одной основной (пока неизвестной). Реально то теорий сейчас всего две — квантовая механика, да теория относительности, остальные можно рассматривать как их производные, да частные случаи и то, это только потому что КМ и ОТО не очень совместимы друг с другом.
А зачем их собственно много? Я еще понимаю ассемблер — он для каждого процессора свой нужен, хотя один фиг, все ассемблеры (по крайней мере для одного типа вычислительных машин) будут пересекаться друг с другом основным набором команд.
А вон у совсем брутальных хардварщиков языка вообще два — Verilog, да VHDL, да их производные и справляются как-то.
А для языков высокого уровня — действительно нет никакой фундаментальной причины плодиться и размножаться, кроме как различия платформ (а их не так уж и много). Т.е. все то многообразие что мы наблюдаем — просто разная степень кривизны реализации, да вкусовщина.
Собственно реально массово используемых действительно не так уж и много языков, а все современные языки происходят либо от Fortran'а и его прямых потомков: Algol и Basic, либо от более поздних независимых веток: APL, Lisp (точнее IPL), COMIT и Cobol (точнее FLOW-MATIC) — больше чойт на память и не приходит, либо их комбинации.
С точки зрения работы над ошибками и наличия строгого обоснования, самые подкованные это APL и Lisp — их приемы много куда проникли, но между тем я что-то не вижу орд программистов на Scheme (хотя именно на нем идет обучение в MIT) и Haskell со всякими F# (на Scala вроде как кто-то пишет)
Вообще первый объектный язык — SIMULA (SIMUlation LAnguage) был создан именно что для описания объектной картины мира и последующей её симуляции. Сам язык был создан для научно-исследовательских задач, а не для прикладных… потом уже всякие Страуструпы и Аланы Кейны переврали его, кто как мог :-)
А еще там есть примитивные типы: byte, short, int, long, char, float, double и boolean, которые живут сами по себе. Забудете про разницу между Long и long — наткнетесь на упаковку-распаковку.
Хз, наверное как посмотреть: математически для каждого множества определяется свой набор арифметических операций, порой с особыми правилами (например, умножение матриц), так что арифметические операции именно что являются свойствами множества, то бишь классов и типов по программерски
Вот в этом то вся бяда. Нет точных определений, т.е. да, действительно, у ООП есть проблема с фундаментальным теоретическим обоснованием.
Вы наверное фанат декларативного программирования :-) Угадал? :-)
Но там вообще-то ограничения всегда присутсвуют — в ряде штатов, например, требуется чтоб 10 лет прожили вместе причем так, что один из супругов сколько-то лет вел хозяйство и потерял квалификацию. Ну и рассматривается эта фигня как форма раздела имущества, например, в некоторых штатах ученая степень, полученная в браке тоже вот внезапно считается совместным имуществом — теперь делите её как хотите :-)
И логика здесь именно в том, что прекращение брачных отношений, не освобождает кормильца от финансовой ответственности за тех, кто находится у него на иждивении :-) Т.е. это отношения не ПОСЛЕ, а именно что продолжение прежних [финансовых] обязательств не смотря на развод.
И кстати зачастую не требуется наличие зарегистрированного брака (palimony) — достаточно доказать факт сожительства (хотя тут сложнее) и факт нахождения на иждивении в этом сожительстве. Естественно это в равной мере относится и к супругам и к детям (сhild support)… и кстати к родителям: иск от родителей к детям на содержание тоже может быть — деньги на образование, лечение и т.п. и т.д. В общем долг платежом красен.
1) Запрет на работу у конкурента — попытка монополизации трудовых ресурсов. Любая монополия оказывает разрушительное действие на рынок.
2) Основа рынка — конкуренция: работодатели конкурируют между собой за работников, работники конкурируют между собой за вакансию, производители конкурируют между собой за долю в рынке, покупатели конкурируют между собой за товар и т.д. Если какой-то умник пытается такими договорами ограничить конкуренцию, то см. пункт 1.
3) Вторая основа рынка — свобода. Все участники рынка находятся в равных правах. Навязывая такой пункт в договоре, работодатель хочет нечестным способом повысить свою позицию в этой бизнес игре. А это смотри пункт 1
4) В принципе рынок строится на компромиссах. Так что если одна сторона где-то забирает, то должна где-то что-то дать, материальное вознаграждение за подписание такого пункта, вполне себе ассиметричная игра. Но вот такая уловка как раз таки неоднозначная, т.к. смотри пункт 1
5) Ну это является дискриминацией, увы но после полюбовного завершения договорных отношений ни одна сторона уже не может ничего предъявить другой.
6) Крепостное право и рабство вроде как во всех развитых странах отменили. Вон даже штат Миссисипи подтянулся.
а) Любое односторонние ограничение должно компенсироваться — пусть тогда платит, зарплату пока действует соглашение, а работник уже не работает.
б) Это выходит за пределы компетенции работодателя.
в) Это форма монополизации трудовых ресурсов.
г) Это бессмысленно и намекает на то, что бизнес-процесс построен хреново, раз один рядовой сотрудник, уйдя к конкуренту порушит весь это проебизнес.
Это не юридическое ограничение, а обязательство по содержанию детей, к браку вообще не относится.
Потому что кредитный договор не заканчивается пока не будет полностью выплачен кредит.
Не должен, т.к. это никак не связано с увольнением и службой. Должен если подписал отдельный договор — подписку о неразглашении за доступ к данным, которая подписывается на определенный срок. Можно не подписывать. Сам тип договора, аналогичен:
Потому что допрос часть следственного процесса, в течении которого и действует подписка о неразглашении. Следственный процесс не заканчивается после допроса если что.
Это вообще к чему? Не «после», а «за», а именно за нарушение общественного договора — ПДД. Собственно лишают их именно с момента свершения события, а срок лишений — мера пресечения.
Если думайте что это все грустно, то доя сравнения, в РФ работник трудится почти 2000 часов в год, а в США и Китае — 1800 часов, в Японии — 1700, в Германии — 1400 часов. Так что российские 28 дней в году — это волшебный розовый невидимый единорог.
У них трудового законодательства как такового нет, так шо таблички по всем этим соцпакетам бесполезные. Обычно со второго года договариваются на 2x10 дней в году отпуска + дней 20 больничных (100% оплачиваемых), больничные могут аккумулироваться. При этом надо иметь ввиду, что имеются ввиду оплачиваемые дни, за свой счет можешь наотдыхаться хоть пол года — это в РФ 3 зафиксированных опаздания и уволен, а на каждый пропуск — нужна отписка, там могут уволить в принципе в любой момент (если у тебя не пожизненное владение, но это особый случай), поэтому бюрократическим формализмом не страдают (точнее он у них другой).
Но это так, средняя температура по больнице: Все очень сильно зависит от штата, отрасли и профсоюзов (в южных штатах позиции профсоюзов традиционно слабее, обычные айтишники тоже слабо приспособлены к ведению профсоюзной деятельности). Еще на рынок труда очень сильно влияет госсектор.
Короче все сильно индивидуально, а в статье нет никакого анализа.
Проблема даже не в туториалах.
Проблема глубже: архитектурного и идеологического плана.
В Жабе, stack наследуется от Vector, который в свою очередь наследуется от ArrayList. Стек — это просто же просто коллекция в которой последним пришел и первым вышел, все, положил да взял, больше ничего. К чему тогда все это, зачем стэку метода вектора, такая глубокая иерархия наследования — хз. Или написал Long и long, и все, хана, нарвался на упаковку-распаковку. Врожденных дефектов в Жабе море. Богатая история Жабы — с одной стороны достоинство, но учитывая костылестроение — одновременно и проклятие.
А уж туториалы — это уже следствие. Внезапное их устаревание — тоже (хотя .NET генетики тоже не с первого раза дались, но сейчас про костыль ArrayList и не вспомнит уже). А основная масса изменено .NET как правило синтаксический сахар, сама же платформа очень хорошо проработана и жестко стандартизирована (увы, на этом преимущества заканчиваются)
B) Вообще размерность результата матричных операций всегда можно предсказать, зная размерность входных массивов. Поэтому лучше использовать сразу заготовленные массивы. А с указателями на память в условиях неопределенности (хз какой участок потребуется) — можно нарваться на кучу неприятных ошибок, а всякие контейнеры с динамически изменяемым размером, тот же vector например — резервируют память всегда с запасом, как только коэффициент заполнения станет большим — он расширит область памяти под свои нужды, опять таки с запасом. Неоптимально.
В) Вот тут бы я на компилятор не надеялся бы. Компиляторы C/C++ глупее даже чем компиляторы фортрана, тот же алиасинг памяти, например, не обойдет если не прописать квалификатор restrict там где надо. Ну эт так пример, первый какой в голову пришел.
Тут вот поминали всякие бласы и лппаки, так вот, в том же openBLAS жесткий си-хардкод, в том числе и с заточкой под конкретную архитектуру CPU
Г) CUDA. На сайте nvidia висит халявный тулкит с примерами. Только надо иметь ввиду, что максимальный перфоманс достигается тогда, когда объем входных данных приближается к 0.4 от размера видеопамяти.
Что же касается функций всяких, ну abs — дешевая функция. А вот косинусы-синусы — очень дорогие, на синус потребуется тактов в несколько раз больше чем на операцию деления. Так что их надо избегать по максимуму, можно еще лук-ап тейбел использовать (хэш-таблицы значений синусов-косинусов) если не боитесь потерять в точности. Если же синус от малого угла — то он равен собственно аргументу. Ну и т.д.
У вас неверные цифры. Доступ к L1 — 4 такта, L2 — 10 тактов, и только к L3 от 40 тактов начинается. Это вот у всяких Скайлейков.
Чисто операция сложения — 1 такт, целочисленного умножения — 3 такта, для чисел с плавающей запятой — 4 такта, для деления — 25 тактов, и эти циферки уже с учетом ч0рной магии, т.е. Циферки уже познакомились с Dispatch Unit их построили в рядочек и отправили куда надо, а к нему еще нужно попасть (а откуда они попадают? Явно что не из Нарнии) а число вычислительных блоков не впечатляет: у Бульдозера как я выше написал всего 4 вещественные умножалки с плавающей запятой на 64 бита, а у Скалэйк вероятно 12 штук, так что обращаться к кэшу в любом случае придется часто. А для тех же комплексных чисел потребуется по 3 умножалки и и по 5 сумматоров или 4 умножалки и 2 сумматора, кому-что нравиться — так шо кватернионам например будет уже грустно, а это все операции поворота в 3D.
Что касается сравнительно дешевых операций на видеокартах, то да, [sarcasm]видеокарты были разработаны именно для того чтобы складывать два целых числа, однозначно, а циферки в регистры CPU падают из Нарнии, бесплатно, инфа 145%[/sarcasm] Если говорить о всяких load/store в любом случае придется протаскивать данные из ОЗУ и обратно, пофиг, CPU это или GPU, ну а внутри процессоров еще предстоят увлекательные путешествия по кэшам разных уровней. Разница только в том, что видеокарта будет потолще по количеству вычислительных боков и реализует MIMD, а не SIMD как обычные процы, и пропускная способность GRAM-GPU, несколько побольше (так что L3 им и не нужен), чем RAM-CPU, так что вектора, матрицы и тензоры, пока видеопамяти хватает, GPU будет переваривать на порядок быстрее, не смотря на то что тактовая частота у видюшек все же ниже, чем у CPU. Есть только один способ обогнать видеокарты в матричных вычислениях с большим числом операций умножения/деления — фигачить вычислительные кластеры из Xeon Phi или делать свой ASIC под конкретные задачи, но это уже решения совершенно другого уровня.
А) Операции умножения бывают разными. Какая именно операция умножения?
Б) Памяти бывают тоже разные. К какой памяти обращение?
В) Любая операция подразумевает обращение к памяти. Хорошо если данные уже лежат в регистрах процессора, только вот им туда надо сначала попасть.
Г) Умножение в общем случае всегда дороже. Оно не просто само по себе медленнее сложения, оно принципе отжирает немалую часть кристалла, так что много их в ЦП не будет — места всем не хватит. Например, в Ьульдозере всего одно 256 битное FPU состоящие из 4-х блоков сложения-умножения по 64 бита каждое, в Skylake уже 4 FPU, но 256-и битных FPU максимум 3 (что кагбэ намекает на ч0рную магию) — для векторных вычислений это ниачом, так что любая нормальная видеокарточка (не заглушка, конечно же) сделает любой ЦП (Quadra P5000 vs двухголовый Intel Xeon на 64 ядра, ну примерно ~24:1, мобильная 960 vs Intel i7 ну примерно ~16:1), т.к. там нет недостатка в умножителях… зато там есть есть недостаток быстрой памяти...
Так что нет. Размен памяти на производительность — нормальная практика, даже не смотря на то что у нас есть бутылочное горлышко межу ЦП и ОЗУ, в разумных пределах конечно же.
А никакого. Кто-давно ляпнул глупость (хз, то ли в Симуле, то ли в Смоллтолке — меня тогда не было) и все давай ее использовать, не смотря на проблемы с инкапсуляцией, хрупкость классов, возрастающую цикломатическую сложность, фрагментацию данных и методов, да ряд других проблем (например с производительностью, при переопределении).
Вот только наследование реализации — это и есть собственно наследование :-) То что в статье выдается за наследование (очень распространенная ошибка) — это разные механизмы реализации полиморфизма: параметрический полиморфизм (генерики и шаблоны) и полиморфизм подтипов, вот полиморфизм подтипов можно реализовать либо системой включения подтипов (интерфейсы), либо системой включения подклассов — наследованием или композицией. Ну есть еще и третий вариант — перегрузка.
Ну вот композиция для повторного использования кода куда более прозрачна, вот только вот разработка атомарных и выделение общих компонент — долгое и нудное занятие. Куда проще нашлепать public class B:A, потом C:B, потом D:C, E:D и т.д. (видел как-то калокод с иерахией в 40 классов). Потом правда кто-нибудь влезет в В или А и все сломается, но автора уже не будет и чинить будут другие люди.
На самых нижних уровнях это наверное еще сработает — ибо насяльников много обновлять их можно относительно часто, а что бы более верхние уровни затронулись… в общем придется либо часто трясти кубики, а это неэффективно, либо трясти на протяжении сотен лет.
Ну а самый главный изъян — такой подход приведет к тому, что выигрывать будут только средние, и походу модель в этом случае не учитывает, что тогда лучшие будут оставаться не удел и начнут уходить (ибо амбиции и нет мотивации), так что после каждой итерации правый хвосты распределения будет усекаться и матожидание будет от итерации к итерации двигаться в сторону худших.
В общем работать это будет наверное только в каких-нибудь макдональдсах, где народу много и текучка высокая.
Ну и рэндом штука такая, без дополнительных эвристик приводит к длительным блужданиям.
Хм. Вот это похоже на то что в реальных компаниях происходит. Сначала они растут, достигают пика, а потом в течении десятилетий скатываются на дно, банкротятся или покупаются другими.
А добиться осциляций в этой моделе как-то можно? Что надо сделать что бы она начала выкарабкиваться со дна после нашествия нуннов-топоменеджеров?
Про витаминчики А и Е лучше бы подробнее раскрыть, т.к. при передозировки они токсичны, а разбросы дозировок: От 100ME до 100000ME.
И при этом любое вменяемое лечение многих кожных проблем в итоге завязано на том же витамине А и его метаболизме
Как правило в большинстве случаев — это варикоз. Вены еще не видно, ток крови уже нарушен.