По всей видимости, Сандерсу надоело жить в тени Intel в качестве подрядчика, либо же внутренние амбиции компании пересилили. Может быть, виной стали сверхдоходы Intel, но в 1995 году случился перелом: все серии, которые AMD выпускала по лицензии, были закрыты (соответственно, лицензия была отозвана), в том числе прекратился выпуск совсем свежих, по меркам тогдашнего рынка, двухлетних am486. Состоялся официальный развод Intel и AMD, последняя обрела независимость.
Как-то неполно и однобоко подано. Как будто Intel и AMD жили не тужили, но внезапно и вероломно AMD 1995 решили разрушить старую "дружбу". На самом деле конфликт начался раньше, ещё в 80-ых, и всё было немного сложнее.
На первых порах, в 70-ых, AMD не стеснялась без разрешения реверс-инженерить процессоры Intel, пользуясь несовершенством законодательства того времени (микроархитектуру нельзя было защитить копирайтом) и выпускать свои допиленные аналоги. Интелу поначалу это не очень нравилось, но они поняли, что им это выгодно, по следующим причинам:
Крупные покупатели того времени: военка, IBM и прочие имели политику закупать чипы только тех моделей, которые могут поставлять несколько производителей, причём местных, американских. Чтобы был выбор и по цене и по качеству. Тендеры по-нашему
В те времена существовал зоопарк производителей и архитектур и Intel'у было выгодно увеличивать экспансию своей x86 архитектуры, выдавливая конкурентов
Можно было взамен получать от AMD полезные технологии
Поэтому в 1976 конторы подписали соглашение, легализовав выпуск своей продукции синих красными и договорившись обмениваться технологиями. В те времена фирмы были в хороших отношениях, а их директора и вовсе были друзьями ИРЛ.
Изначальное соглашение от 1976 покрывало лишь процессор 8086. В 1982 конторы подписали дополнительное соглашение сроком на 10 лет, расширив его на будущие модели. В те времена процессоры были достаточно нишевой и не очень дорогой в разработке производстве продукцией, поэтому непривычный по нашим временам взаимный обмен технологиями был нормой.
В середине 80-ых ситуация переменилась. Во-первых начался взрывной рост распространения персональных компьютеров. Во-вторых стоимость производства процессоров выросла. На момент 1984 Intel ещё планировала, чтобы AMD продолжит сотрудничать с ней, выпуская новые 186 и 286 процессоры. Но при этом Intel уже стала задумываться над тем, что от соглашения она теряет больше, чем получает. Она отдаёт AMD наработки процессоров, которые нынче крайне ценны, взамен получает лишь какие-то наработки по периферийным узлам, которые имеют значительно меньший рыночный потенциал. Поэтому Intel в одностороннем порядке изменила соглашение, подняв стоимость лицензирования некоторых важных узлов процессора. Напряжение между фирмами стало нарастать.
В 1985 Intel выпустила 386 процессор, который стал очень удачным и популярным. Посмотрев на это, Intel окончательно решила перестать делиться наработками с AMD, отказавшись отдавать чертежи 386 - "такая корова нужна самому". Стороны начали переругиваться. Intel публично заявляла, что не получает от AMD взамен технологии аналогичного уровня ценности. AMD отвечала, что у неё технологии отличные, это Intel страдает синдромом "Not invented here". Intel парировала, что продукция AMD бестолковая и та намеренно переусложняет её внутреннее устройство, чтобы формально соответствовать сложности продукции Intel по соглашению об обмене.
Пока шли все эти тёрки, Intel 386 расходился как горячие пирожки, принеся синим миллиард долларов. AMD, видя это, в 1987 подала на Intel в суд, требуя предоставить ей чертежи процессора 386 и математического со-процессора 8087, считая что тот 10-летний договор распространяется и на них. Intel же считала, что он распространяется только на старые модели до 286 включительно.
Суды шли долгие-долгие годы, заставляя вскипать мозги у дедушек-судей, пытавшихся разобраться что такое эти ваши новомодные процессоры и что такое микрокод, относится ли он к софту или к железу. Всего между Intel и AMD было подано 6 исков. В ходе них AMD подсуетилась и реверс-инженернула 386, готовя его к выпуску, чтобы не упускать драгоценное время. Ещё до выпуска Intel узнал об этом благодаря невероятному случаю. По словам Intel, в одном отеле остановился директор по маркетингу AMD некто Майк Вебб. И по случайному совпадению в это же самое время в том же отеле остановился его полный тёзка, Майк Вебб, но уже работающий в Intel. AMD'шному Майку были направлены секретные документы о 386, которые из-за ошибки работников отеля, были переданы работнику Intel. И дескать так Intel узнала о ходе реверс-инженеринга и заявила об этом в суде.
AMD в свою очередь не поверила в эту историю и обвинила Intel в промышленном шпионаже. Судья почесал голову и всё-таки разрешил AMD выпускать 386, посчитав что он входит в 10-летнее соглашение. Intel в свою очередь пытались запретить выпуск 386 красными, объявив что "386" это торговая марка, принадлежащая Intel. Судья постановил, что "386" это общее название и не может служить торговой рамкой. После этого Intel стал добавлять к своим процессорам приставку, именовать их Intel 386 или i386, что уже можно защитить торговой маркой. А вскоре и вовсе перешёл на термин Pentium, сразу защитив его.
В итоге AMD в 1991 успешно начала начала выпуск 386, причём на более тонком техпроцессе, чем оригинальный 386, с доработками, и, несмотря на 6-летнее опоздание (что по меркам тех времён просто пропасть), чип вышел удачным, по производительности конкурировал с преемником - Intel 486, разошёлся к 1992 году 9.5 миллионным тиражом, принёс красным миллиарды прибыли и даже заставил Intel снизить цены на свою продукцию.
Аналогично AMD реверс-инженерила 486, попутно судясь за право выпускать и его. Причём к тому времени 10-летнее соглашение уже явно истекло, но суд продлил его на 2 года, в ответ на это Intel подали аппеляцию, что суд превысил полномочия. На это AMD подали ответную аппеляцию. Короче там происходил суд через суд, аппеляция через аппеляцию, просто настоящая битва. А газеты, не стесняясь, освещали жаркие баталии. В итоге суд решил, что 486 красным выпускать можно, но то точно последний проц от Intel, которую получает AMD и "дальше вы уже как-нибудь сами". AMD 486 вышел в 1993, тоже с большой задержкой в 4 года относительно выпуска синими, но был допиленным и удачным. А в 1995 Intel наконец-то с неохотой, но передала AMD оригинальный микрокод и та какое-то время выпускала аж 2 версии 486: реверс-инженернутую и копию оригинальной.
Так что 1995 это не просто случайная точка в календаре, после которой AMD ВДРУГ решила на ровном месте начать самостоятельную жизнь. Это финальная точка в многолетней и тяжёлой судебной борьбе, что в статье почему-то совсем не раскрыто. Судебные тяжбы не прошли для фирм легко, AMD так понесла $100 миллионов потерь, чуть не обанкротилась в 1987. Но всё-таки выстояла, что есть несомненное благо для всех нас, ибо чем больше конкуренции, тем лучше для нас, потребителей.
Кто тут прав, а кто виноват, и кто корпорация Добра, а кто Зла предлагаю вам решить самим.
Оптимизация, которая там делается (превратить *q в 1, а *p в 2) в некотором смысле напрашивается. Но она опасна. Валидна только тогда, когда можно доказать, что *p и *q укаывают в разные места памяти.
И, разумеется, это не новая проблема. Ещё во время первоначальной стандартизации C была сделана попытка добавить ключевое слово noalias, чтобы эту проблему решить.
Возражения некоего частного лица привели к тому, что эту затею, в тот раз отставили.
В C99 к этой затее вернулись и добавили в язык __restrictсо слегка другой семантикой.
Однако это тоже, особо не сработало: люди редко исползуют __restrict и ещё реже — правильно.
А к этому моменту уже ж разработали C++ и, что важнее, STL. Который, блин, оказался завязан на то, что компилятор может вот подобные как раз оптимизации делать — но без малейших объяснений того, как это сделать безопасно.
И вот тут-то кому-то из разработчиков компиляторов в голову пришла мысля (скорее всего не одному): у нас же в языке имеются десятки разных интересных UB (которые там появились по совсем другому поводу) и у нас есть разрешение в случае возникновения UB делать что угодно (такое разрешение, кстати, тоже появилось в C99, не в C89, некоторые даже приписывают соотвествующему изменению злой умысел, хотя на самом деле, почти наверняка, просто потому что ограничения на то, что такое UB, прописанные в C89, опираются на понятия, в нём не описанные и, конечно, гораздо проще их снять, чем формализовать). давайте их активно находить и тот факт, что они не выполняются — использовать (программа же их не исполняет, ей запрещено, значит код, вещущий к UB, тоже не исполняется, значит его можно выкинуть).
Начавшаяся после этого борьба брони и снаряда — почти привела к катастрофе: оказалось, что люди, в общем, когда программы пишут решают прикладные задачи и тесты гоняют, а не ребусы на тему “а нет ли у нас тут UB? а если покреативней поинтерпретировать — всё равно нет? а если воображение напрячь?”.
Оказалось, что, в общем, воображение у разработчиков компиляторов посильнее, чем у остальных программистов (см. обоснование безумия с realloc в C99).
Но настоящая катастрофа произошла тогда, когда разработчикам компиляторов оказалось и этого мало, они выбили себе разрешение прописать себе в стандарт дополнительные UB (читаем внимательно: it would be desirable for the Standard to mean это ни разу не mean, это всего лишь позволение изменить стандарт, не признание того, что стандарт что-то там кому-то позволяет), но не сделав этого, начали этим фиговым листком прикрываться.
В результате мы получили язык для которого не существует ни одного современного компилятора! Да, вот так, просто: ни одного!
Поскольку разработчики компиляторов полагаются на то, что разработчики будут соблюдать запреты, которых в стандарте просто нету! Совсем нету, ни в каком виде!
Кстати ваш пример с преобразованием указателей в intptr_t и обратно как раз и является одним из камней предкновения. Ибо в соотвествии с буквой стандарта он валиден, а объявить его невалидным и сказать, что какой-нибудь XOR-связный список — невалидная конструкция у них наглости пока не хватает. А без этого у них никак не получается (уже второй десяток лет не получается!) придумать непротиворечивые правила работы с указателями, которые позволили бы им ломать программы и дальше делать те оптимизации, которые они уже делают.
Вот такая вот ужасная драма, где никто, вроде, не виноват, а убытки исчисляются миллиардами (хорошо если не триллионами).
Проблема в том, что долгое время никто не мог придумать: что же, всё-таки, с этим делать. Понятно, что хочется как-то сделать так, чтобы в языке UB не было совсем (во многих других языках их нет: C#, Java, JavaScript и так далее), но было непонятно как удалить UB из языка без GC: у вас же, в таком языке, можно удалить объект, на который, где-то там ещё, есть “живые ссылки”! А можно ведь, ко всему прочему, из разных потоков, параллельно, память менять, там тоже разные процессоры много разного интересного может насчитать.
Решение Swift было промежуточным, почти как у языков с GC: а давайте мы сделаем малоинвазивный GC на счётчиках, тяжёлый рантайм ему не нужен, но безопасность можно обеспечить. А все опасные конструкции вынесем в стандартную бибиотеку.
Такой себе недо-managed язык. Если компилятор сможет, в некоторых местах, манипуляции со счётчиками извести — он может даже достаточно быстрым оказаться. Вроде как проблемы скорости всё равно не решились, впрочем (Apple, по итогу, сделала аппаратное ускорение в свои процессорах, но такое могут себе позволить себе не все).
А вот Rust сделал куда более интересную вещь: предложил отдельно пометить все места в программе, где ипользуются конструкции, которые могут вести к UB! И оказалось, что, при должном упорстве, можно сделать так, чтобы в большой программе так было пемечено где-то 1% года!
А в остальной программе пусть UB не будет (утечка памяти — это не UB).
Это было смелое решение, в которое, если честно, я много лет не очень верил. Смотрел на то, как они барахтаются, но не верил, что они могут сделать язык, близкий по выразительности и скорости к C++, но без UB (ну Ok, “почти без” UB, “минное поле” в 1% кода это куда лучше, чем “минное поле” в 100% кода).
Но судя по тому что происходит в последние год-два (поддержка крупными компаниями, попытки переписать драйвера в Linux на Rust и так далее) — они смогли.
Оперевшись на весьма интересное наблюдение: программисты на “современном C++” и без того очень часто используют std::unique_ptr и часто действуют в парадигме блокировки-чтения записи, когда у вас в программе есть, у каждого объекта, либо один писатель, либо много читателей (но писателей тогда нет ни одного, XOR а не OR).
Это позволяет решить проблему с UB, но некоторые конструкции оказываются невозможными (например банальную очередь создать уже нельзя).
С другой стороны — так ли часто вы пишите неблокирующие стеки и очереди? Я наблюдал как-то за этим увлекательным процессом. Там на примерно 100 строк кода ушло две недели написания, а количество строк с описанием было примерно на порядок больше, чем кода. И это после того, как описание сильно упорядочили и порезали (добавив ссылок на несколько статей).
Уж если вам что-то такое захочется ещё раз сделать — добавить туда немного меток unsafe проблемой явно не будет.
Создание клона процесса (местный аналог fork), система без антивируса:
~1.5 мс используя NtCreateUserProcess.
~0.9 мс используя NtCreateProcessEx + NtCreateThreadEx.
В то же время, создание нового потока занимает всего ~0.03 мс, что намного быстрее.
Упомянутый выше NtCreateProcessEx имеет интересную особенность - он создаёт только объект процесса, без изначального потока. Поскольку драйвера, которые подписываются на синхронные уведомления о создании процессов (посредством PsSetCreateProcessNotifyRoutine) получают их только при создании первичного потока в целевом процессе, мы получаем возможность измерить "чистое" время создания процессов, без вклада от сторонних драйверов. В этом случае NtCreateProcessEx тратит ~0.6 мс.
Наличие в системе дополнительных драйверов (вроде антивируса или EDR), может существенно повлиять на результаты. Так, включённый Windows Defender даёт примерно +90% замедления, заставляя CreateProcess тратить по ~2.1 мс. Но это ещё ничего, если взять какой-нибудь откровенно плохой антивирус, например, китайский 360 Security, то можно замедлить CreateProcess в 200 (!) раз, до ~240 мс.
Вам спасибо за отзыв! В древнерусском и старославянском почему-то "идти" в этом значении не использовалось. Вот табличка, из которой видно какие глаголы и примерно когда помогали выражать будущее время
Новый трекер самая бесячая вещь в новом дизайне. Старый у меня был постоянно открыт в закрепленной вкладке, и я по наличию свободного времени читал комментарии, затем страницу трекера обновлял. Теперь стоит обновить страницу трекера и я больше не знаю что я читал а что нет. Снова откатываюсь на старую версию, это не просто бред, а бред в квадрате.
В условиях тотальной безграмотности на старте СССР нужно было создать страну строителей будущего.
На самом деле в Российской Империи всё было не так однозначно, как говорили большевики:
Уже в 1911 году грамотных новобранцев было больше 90%. По некоторым уездам значительно выше: так, в Тверском уезде из 838 рекрутов неграмотными были только пятеро, менее одного процента.
Конечно, грамотность новобранцев была значительно выше средней: мужчины были грамотнее женщин, а молодёжь была грамотнее старших поколений. В среднем по России к 1917 году уровень грамотности составлял примерно 42%.
Теперь посмотрим, как быстро обучалась Россия. Десятки тысяч открытых при Николае II школ, трёхкратное увеличение числа учащихся, десятикратное увеличение числа студентов — это всё лирика, это всё к делу не пришьёшь. Важнее другое — в период с 1909 по 1914 год средний ежегодный прирост числа учащихся определяется в 5%. Учеников становилось каждый год больше на 3%, учениц — на 8%, таким образом диспропорция между мальчиками и девочками выравнивалась.
Всего в 1914 году в школах учились 9,7 млн человек. Предполагая, что самое массовое образование было тогда четырёхлетним, можно заключить, что каждый год в школы поступали 2,4 млн человек.
Общую численность детей, по возрасту готовых пойти в школу, можно грубо оценить в 2% от общего населения империи в 1914 году, то есть в 3,6 млн человек.
Таким образом, для решения проблемы безграмотности количество учащихся следовало увеличить в полтора раза. Это можно было сделать моментально, по щелчку пальцев, снизив продолжительность обучения до 2-3 лет. Или можно было просто продолжать, ничего не меняя, и тогда, наращивая количество учащихся на 5% в год, империя охватила бы школами каждого ребёнка в… 1925 году. С учётом прироста населения, в школах в 1925 году учились бы 16,5 млн детей.
К сожалению, революция внесла свои коррективы — из-за разрухи и гражданской войны количество школ сократилось, реальное число учащихся составило в 1925 году всего лишь 10 млн человек. Даже с учётом огромных потерянных территорий, это меньше, чем было бы при условии сохранения императорской власти.
Горсовету подчинено примерно 10 разного рода сел. В каждом, разумеется, имеются улицы Ленина и 8 марта.
Помимо этого сам город состоит из пяти районов. Многие районы исторически когда-то были отдельными поселками. Поэтому в городе имеется четыре улицы Кирова. Тройных улиц несколько штук, двойных — и вовсе не сосчитать. Некоторые двойные улицы встречаются в одном и том же районе, поэтому дополнительно район хранить недостаточно, нужно еще какое-нибудь историческое название вроде Ломбардо.
Некоторые дома приписаны вовсе не к улицам, а к топонимам вроде «микрорайон „Центральный“», «квартал 13», «1105 км», «пос. Ленина В», «Больничный городок», «Подсобное хозяйство», «Старая Химколония», «Северный Батман» и т.д.
Часть улиц имеет переулки, которые получают названия вроде «улица 26 Бакинских комиссаров 3-й проезд».
На одной улице номера домов могут запросто повторяться. Если посреди улицы построен какой-нибудь завод или контора, то они непременно получат номер 1, хотя первый дом там уже был.
Одна улица вообще имеет нумерацию из одинаковых чисел, возрастающих с двух сторон навстречу друг другу.
Центр города состоит из пересекающихся улиц в клеточку. Поэтому дома могут иметь двойную нумерацию. А могут и не иметь. Один и тот же дом называется «Островского 3/18», «Плеханова 18/3», «Островского 3», «Плеханова 18». Это правильные названия. Но «девочки», записывающие адреса, могут еще изобрести дома Плеханова 18/3 и даже Островского 318. Им это запросто — изобрели же они когда-то улицу имени 250-летия СССР.
Ну и в качестве курьеза самое крутое название: улица Западный вентилятор.
Отличный модем. Самое медитативное было смотреть в ME PCeye. К сожалению не нашел ни одной картинки в гугле. Програмка показывала текущую АЧХ. По картинке было видно протокол. v92 это 2 горизонтальные линии точек, а v34 это кластер скопления точек). Так же, было отлично видно когда кто то брал трубку, или начинались другие помехи.
Схематично это должно выглядило как то так (вроде)
Или он может только мне палки в колеса совать, когда мне это нафиг не надо, вроде «unused import»?
Это, в общем-то, главная проблема языка. Разработчики думают, что лучше меня знают, как мне писать мой код. Это же надо додуматься, специально дополнительно рандомизировать перебор мапы.
А на самом деле, вы должны знать что всегда периодически чтото падает у банков… если вы периодически общаетесь со своим коллцентром, то должны знать что существует такое событие как «сбер упал», когда это к вам никакого отношения не имеет но телефоны обрывают — вам и насколько часто такое происходит.
Не… Мы с коллцентром не общаемся. Есть сопровождение, есть поддержка. Их задача обеспечивать бесперебойную работу. В том числе и откатить или остановить что-то из процессов.
Мы вообще на 95% общаемся только с аналитиками. Они получают дефекты от сопровождения, задания на разработку от бизнеса.
потом есть ночные остановки у всех банков на обновление ПО
На самом деле, это не остановка. Это переход на новый банковский день. Сведение баланса и прочие операции. В терминах АБС это называется EOD — End Of Day. Где-то в рекламе какого банка даже было что-то типа «платежи проводятся с 4 утра и до полуночи». Так вот с полуночи до 4 утра как раз и идет EOD. И новые внедрения на пром проводятся в рамках него.
У нас чуть сложнее. У нас все платежи круглосуточно. Перед началом EOD создается копия промюнита — юнит ночного ввода и все операции переводятся туда. Там как бы еще продолжается день. А в основном юните начинается процесс EOD. Когда он закончится, начинается накат из ночного юнита в новый день. Накат осуществляется по журналам (каждая таблица имеет т.н. «журнал» в котором фиксируются все изменения для каждой записи). Все записи в таблице изменяются толок через специальный RR модуль — модуль внешнего ввода, который вызывает другой модуль — UR, апдейт модуль, передавая ему нужные данные. А тот уже отвечает за журналирование изменений.
У RR модуля три режима — внешний ввод, накат (по журналу из юнита ночного ввода) и рекавери — восставноление по журналу текущего юнита.
Есть еще «головной журнал» где хранятся заголовки всех детальных журналов. По нему видно в каких таблицах были изменения и как получить соответсвующие записи из детальных журналов. За его заполнение тоже отвечает UR модуль.
При накате специальный процесс идет по головному журналу и для каждой записи вызывает соотв. RR модуль, передавая ему ключ его детального журнала. А тот уже берет данные по этому ключу из «своего» журнала и передает их в UR. Так все, что было сделано в течении существования юнита ночного ввода, переносится в дневной юнит в новый день.
простая операция:
1) вы перевели 100р через c2c например
2) вам упала смс что пришло 100р
3) вы их сняли в банкомате.
в реальности:
1) у отправителя ставится холд на 100р (на счете 100р, на балансе 0)
2) вам система пишет что у вас 100р (на счете 0р, на балансе 100р)
3) вы снимаете 100р в банкомате (на счете -100р, на балансе 0р, овердрафт!)
4) в течении 5-30 дней реальное бабло приходит и становится 0,0
5) банк начисляет штраф за овердрафт
Я знаю как это бывает и почему. Обслуживался в одном банке, где синхронизация холдов и остатков по счетам проводилась в EODе Там легко было, имея две карты, привязанные к одному счету, уйти в теховердрафт на сумму в два остатка по счету на начало дня.
Правда, за это не штрафовали т.к. считалось что это особенность функционирвания системы.
У нас такого нет — все доступные остатки считаются с учетом холдов. Т.е. послал 100р на крату — сразу видишь их доступными на счете. Расплатился картой — сразу видишь «уход» денег со счета (хотя фактически они еще там, просто сумма встала на холд и тебе показывают что она как будто списана уже). Если операция не прошла, холд снимается, для пользователя это выглядит как отмена операции с возвратом денег.
Хотя я тут могу не до конца быть точным в деталях т.к. вижу это исключительно со стороны как все это работает на уровне АБС с таблицами счетов (в том числе и то, что отдается мобильному клиенту или в инетбанк по запросу через WS).
Но в целом модуль пластиковых карт — это отдельная команда. Я с ними вообще не работал (чуть работал с командой системы расчетов — там была задача на стыке их темы и наших ядровых функций). Но сейчас и от этого ушел, слава богу. Сейчас по комплаенсу — жулики-мошенники, террористы-экстремисты, риски, проверки…
И нет, "всё тоже самое" в unsafe блоке в Rust провернуть нельзя. Потому что unsafe не выключает никаких проверок у стандартных примитивов-контейнеров.
Да, я могу обратиться к чужой памяти если буду действовать через указатель. Но пока я работаю с вектором через итератор — я не получу UB, даже в unsafe блоке. Rust просто не даст сделать активный итератор невалидным.
Вы работаете с полностью несовместимым с мейнстримом стеком технологий.
А что есть мейнстрим? Вебразработка? Мобильная?
А какой стек используется в промавтоматизации? В телекоммуникациях?
Ваши решения и даже ваши задачи оказываются абсолютно другими чем все привыкли. В обычном мире разработки всего этого нет, зато есть все другое. Подозреваю что с совместимостью у вас тоже не очень.
Совсем не очень. В силу того, что мы работаем на платформе, которая очень мало где используется в РФ.
Тут лучший пример это наши банки. Без тонн легаси на Коболе. Тинек, Альфа и далее по списку. Они уже на голову выше всех типовых иностранных банков. По качеству софта и обслуживания клиентов.
Судя по их рассказам они все делают на типовых технологиях. И это хорошо работает.
Так вот позвольте представиться — Альфа-Банк, Управление разработки центральных банковских систем, главный разработчик.
То, что делается на «типовых технологиях» — это верхушка. То, что обсепечивает внешние интерфейсы.
Но опирается все это на код, написанный на 80% на RPG (остальное — C/C++) и работающий на платформе IBM i (бывшая AS/400) на серверах PowerS.
А то, что работает на типовых технологиях общается с нами через MQ и вебсервисы (которые сами ничего не не делают а только вызывают наши внутренние процедуры, передавая им набор параметров и получая ответ). А прямого доступа к данным ни у одной внешней системы нет.
А всю работу системы в плане обработки данных обеспечиваем мы. На своих «немейнстримных технологиях».
Тут такой слоеный пирог и в каждом слое свой стек и свои требования. И свои тараканы.
Как-то неполно и однобоко подано. Как будто Intel и AMD жили не тужили, но внезапно и вероломно AMD 1995 решили разрушить старую "дружбу". На самом деле конфликт начался раньше, ещё в 80-ых, и всё было немного сложнее.
На первых порах, в 70-ых, AMD не стеснялась без разрешения реверс-инженерить процессоры Intel, пользуясь несовершенством законодательства того времени (микроархитектуру нельзя было защитить копирайтом) и выпускать свои допиленные аналоги. Интелу поначалу это не очень нравилось, но они поняли, что им это выгодно, по следующим причинам:
Крупные покупатели того времени: военка, IBM и прочие имели политику закупать чипы только тех моделей, которые могут поставлять несколько производителей, причём местных, американских. Чтобы был выбор и по цене и по качеству. Тендеры по-нашему
В те времена существовал зоопарк производителей и архитектур и Intel'у было выгодно увеличивать экспансию своей x86 архитектуры, выдавливая конкурентов
Можно было взамен получать от AMD полезные технологии
Поэтому в 1976 конторы подписали соглашение, легализовав выпуск своей продукции синих красными и договорившись обмениваться технологиями. В те времена фирмы были в хороших отношениях, а их директора и вовсе были друзьями ИРЛ.
Изначальное соглашение от 1976 покрывало лишь процессор 8086. В 1982 конторы подписали дополнительное соглашение сроком на 10 лет, расширив его на будущие модели. В те времена процессоры были достаточно нишевой и не очень дорогой в разработке производстве продукцией, поэтому непривычный по нашим временам взаимный обмен технологиями был нормой.
В середине 80-ых ситуация переменилась. Во-первых начался взрывной рост распространения персональных компьютеров. Во-вторых стоимость производства процессоров выросла. На момент 1984 Intel ещё планировала, чтобы AMD продолжит сотрудничать с ней, выпуская новые 186 и 286 процессоры. Но при этом Intel уже стала задумываться над тем, что от соглашения она теряет больше, чем получает. Она отдаёт AMD наработки процессоров, которые нынче крайне ценны, взамен получает лишь какие-то наработки по периферийным узлам, которые имеют значительно меньший рыночный потенциал. Поэтому Intel в одностороннем порядке изменила соглашение, подняв стоимость лицензирования некоторых важных узлов процессора. Напряжение между фирмами стало нарастать.
В 1985 Intel выпустила 386 процессор, который стал очень удачным и популярным. Посмотрев на это, Intel окончательно решила перестать делиться наработками с AMD, отказавшись отдавать чертежи 386 - "такая корова нужна самому". Стороны начали переругиваться. Intel публично заявляла, что не получает от AMD взамен технологии аналогичного уровня ценности. AMD отвечала, что у неё технологии отличные, это Intel страдает синдромом "Not invented here". Intel парировала, что продукция AMD бестолковая и та намеренно переусложняет её внутреннее устройство, чтобы формально соответствовать сложности продукции Intel по соглашению об обмене.
Пока шли все эти тёрки, Intel 386 расходился как горячие пирожки, принеся синим миллиард долларов. AMD, видя это, в 1987 подала на Intel в суд, требуя предоставить ей чертежи процессора 386 и математического со-процессора 8087, считая что тот 10-летний договор распространяется и на них. Intel же считала, что он распространяется только на старые модели до 286 включительно.
Суды шли долгие-долгие годы, заставляя вскипать мозги у дедушек-судей, пытавшихся разобраться что такое эти ваши новомодные процессоры и что такое микрокод, относится ли он к софту или к железу. Всего между Intel и AMD было подано 6 исков. В ходе них AMD подсуетилась и реверс-инженернула 386, готовя его к выпуску, чтобы не упускать драгоценное время. Ещё до выпуска Intel узнал об этом благодаря невероятному случаю. По словам Intel, в одном отеле остановился директор по маркетингу AMD некто Майк Вебб. И по случайному совпадению в это же самое время в том же отеле остановился его полный тёзка, Майк Вебб, но уже работающий в Intel. AMD'шному Майку были направлены секретные документы о 386, которые из-за ошибки работников отеля, были переданы работнику Intel. И дескать так Intel узнала о ходе реверс-инженеринга и заявила об этом в суде.
AMD в свою очередь не поверила в эту историю и обвинила Intel в промышленном шпионаже. Судья почесал голову и всё-таки разрешил AMD выпускать 386, посчитав что он входит в 10-летнее соглашение. Intel в свою очередь пытались запретить выпуск 386 красными, объявив что "386" это торговая марка, принадлежащая Intel. Судья постановил, что "386" это общее название и не может служить торговой рамкой. После этого Intel стал добавлять к своим процессорам приставку, именовать их Intel 386 или i386, что уже можно защитить торговой маркой. А вскоре и вовсе перешёл на термин Pentium, сразу защитив его.
В итоге AMD в 1991 успешно начала начала выпуск 386, причём на более тонком техпроцессе, чем оригинальный 386, с доработками, и, несмотря на 6-летнее опоздание (что по меркам тех времён просто пропасть), чип вышел удачным, по производительности конкурировал с преемником - Intel 486, разошёлся к 1992 году 9.5 миллионным тиражом, принёс красным миллиарды прибыли и даже заставил Intel снизить цены на свою продукцию.
Аналогично AMD реверс-инженерила 486, попутно судясь за право выпускать и его. Причём к тому времени 10-летнее соглашение уже явно истекло, но суд продлил его на 2 года, в ответ на это Intel подали аппеляцию, что суд превысил полномочия. На это AMD подали ответную аппеляцию. Короче там происходил суд через суд, аппеляция через аппеляцию, просто настоящая битва. А газеты, не стесняясь, освещали жаркие баталии.
В итоге суд решил, что 486 красным выпускать можно, но то точно последний проц от Intel, которую получает AMD и "дальше вы уже как-нибудь сами". AMD 486 вышел в 1993, тоже с большой задержкой в 4 года относительно выпуска синими, но был допиленным и удачным. А в 1995 Intel наконец-то с неохотой, но передала AMD оригинальный микрокод и та какое-то время выпускала аж 2 версии 486: реверс-инженернутую и копию оригинальной.
Так что 1995 это не просто случайная точка в календаре, после которой AMD ВДРУГ решила на ровном месте начать самостоятельную жизнь. Это финальная точка в многолетней и тяжёлой судебной борьбе, что в статье почему-то совсем не раскрыто. Судебные тяжбы не прошли для фирм легко, AMD так понесла $100 миллионов потерь, чуть не обанкротилась в 1987. Но всё-таки выстояла, что есть несомненное благо для всех нас, ибо чем больше конкуренции, тем лучше для нас, потребителей.
Кто тут прав, а кто виноват, и кто корпорация Добра, а кто Зла предлагаю вам решить самим.
Информация взята из хорошего ролика (англ)
https://www.youtube.com/watch?v=kZ9ntfjytTI
Нашёл! Вербицкая, "Давайте говорить правильно" (2001):
Да не держат они в уме всякие Эльбрусы. Забудьте.
Оптимизация, которая там делается (превратить
*qв1, а*pв2) в некотором смысле напрашивается. Но она опасна. Валидна только тогда, когда можно доказать, что*pи*qукаывают в разные места памяти.И, разумеется, это не новая проблема. Ещё во время первоначальной стандартизации C была сделана попытка добавить ключевое слово
noalias, чтобы эту проблему решить.Возражения некоего частного лица привели к тому, что эту затею, в тот раз отставили.
В C99 к этой затее вернулись и добавили в язык
__restrictсо слегка другой семантикой.Однако это тоже, особо не сработало: люди редко исползуют
__restrictи ещё реже — правильно.А к этому моменту уже ж разработали C++ и, что важнее, STL. Который, блин, оказался завязан на то, что компилятор может вот подобные как раз оптимизации делать — но без малейших объяснений того, как это сделать безопасно.
И вот тут-то кому-то из разработчиков компиляторов в голову пришла мысля (скорее всего не одному): у нас же в языке имеются десятки разных интересных UB (которые там появились по совсем другому поводу) и у нас есть разрешение в случае возникновения UB делать что угодно (такое разрешение, кстати, тоже появилось в C99, не в C89, некоторые даже приписывают соотвествующему изменению злой умысел, хотя на самом деле, почти наверняка, просто потому что ограничения на то, что такое UB, прописанные в C89, опираются на понятия, в нём не описанные и, конечно, гораздо проще их снять, чем формализовать). давайте их активно находить и тот факт, что они не выполняются — использовать (программа же их не исполняет, ей запрещено, значит код, вещущий к UB, тоже не исполняется, значит его можно выкинуть).
Начавшаяся после этого борьба брони и снаряда — почти привела к катастрофе: оказалось, что люди, в общем, когда программы пишут решают прикладные задачи и тесты гоняют, а не ребусы на тему “а нет ли у нас тут UB? а если покреативней поинтерпретировать — всё равно нет? а если воображение напрячь?”.
Оказалось, что, в общем, воображение у разработчиков компиляторов посильнее, чем у остальных программистов (см. обоснование безумия с
reallocв C99).Но настоящая катастрофа произошла тогда, когда разработчикам компиляторов оказалось и этого мало, они выбили себе разрешение прописать себе в стандарт дополнительные UB (читаем внимательно: it would be desirable for the Standard to mean это ни разу не mean, это всего лишь позволение изменить стандарт, не признание того, что стандарт что-то там кому-то позволяет), но не сделав этого, начали этим фиговым листком прикрываться.
В результате мы получили язык для которого не существует ни одного современного компилятора! Да, вот так, просто: ни одного!
Поскольку разработчики компиляторов полагаются на то, что разработчики будут соблюдать запреты, которых в стандарте просто нету! Совсем нету, ни в каком виде!
Кстати ваш пример с преобразованием указателей в
intptr_tи обратно как раз и является одним из камней предкновения. Ибо в соотвествии с буквой стандарта он валиден, а объявить его невалидным и сказать, что какой-нибудь XOR-связный список — невалидная конструкция у них наглости пока не хватает. А без этого у них никак не получается (уже второй десяток лет не получается!) придумать непротиворечивые правила работы с указателями, которые позволили бы имломать программы и дальшеделать те оптимизации, которые они уже делают.Вот такая вот ужасная драма, где никто, вроде, не виноват, а убытки исчисляются миллиардами (хорошо если не триллионами).
Проблема в том, что долгое время никто не мог придумать: что же, всё-таки, с этим делать. Понятно, что хочется как-то сделать так, чтобы в языке UB не было совсем (во многих других языках их нет: C#, Java, JavaScript и так далее), но было непонятно как удалить UB из языка без GC: у вас же, в таком языке, можно удалить объект, на который, где-то там ещё, есть “живые ссылки”! А можно ведь, ко всему прочему, из разных потоков, параллельно, память менять, там тоже разные процессоры много разного интересного может насчитать.
Решение Swift было промежуточным, почти как у языков с GC: а давайте мы сделаем малоинвазивный GC на счётчиках, тяжёлый рантайм ему не нужен, но безопасность можно обеспечить. А все опасные конструкции вынесем в стандартную бибиотеку.
Такой себе недо-managed язык. Если компилятор сможет, в некоторых местах, манипуляции со счётчиками извести — он может даже достаточно быстрым оказаться. Вроде как проблемы скорости всё равно не решились, впрочем (Apple, по итогу, сделала аппаратное ускорение в свои процессорах, но такое могут себе позволить себе не все).
А вот Rust сделал куда более интересную вещь: предложил отдельно пометить все места в программе, где ипользуются конструкции, которые могут вести к UB! И оказалось, что, при должном упорстве, можно сделать так, чтобы в большой программе так было пемечено где-то 1% года!
А в остальной программе пусть UB не будет (утечка памяти — это не UB).
Это было смелое решение, в которое, если честно, я много лет не очень верил. Смотрел на то, как они барахтаются, но не верил, что они могут сделать язык, близкий по выразительности и скорости к C++, но без UB (ну Ok, “почти без” UB, “минное поле” в 1% кода это куда лучше, чем “минное поле” в 100% кода).
Но судя по тому что происходит в последние год-два (поддержка крупными компаниями, попытки переписать драйвера в Linux на Rust и так далее) — они смогли.
Оперевшись на весьма интересное наблюдение: программисты на “современном C++” и без того очень часто используют std::unique_ptr и часто действуют в парадигме блокировки-чтения записи, когда у вас в программе есть, у каждого объекта, либо один писатель, либо много читателей (но писателей тогда нет ни одного, XOR а не OR).
Это позволяет решить проблему с UB, но некоторые конструкции оказываются невозможными (например банальную очередь создать уже нельзя).
С другой стороны — так ли часто вы пишите неблокирующие стеки и очереди? Я наблюдал как-то за этим увлекательным процессом. Там на примерно 100 строк кода ушло две недели написания, а количество строк с описанием было примерно на порядок больше, чем кода. И это после того, как описание сильно упорядочили и порезали (добавив ссылок на несколько статей).
Уж если вам что-то такое захочется ещё раз сделать — добавить туда немного меток
unsafeпроблемой явно не будет.Решил более детально замерить различные аспекты производительности создания процессов в Windows, вот мои результаты для Windows 10 20H2.
Обычный запуск, система без антивируса:
~7 мс на ShellExecuteEx - высокоуровневый API оболочки предназначенный скорее для открытия файлов в приложении по умолчанию, чем создания процессов.
~1.1 мс на CreateProcess - основной документированный метод.
~0.8 мс на NtCreateUserProcess - нижележащий системный вызов.
~0.9 мс на NtCreateProcessEx + NtCreateThreadEx - альтернативный (более старый) способ, требующий больше действию вручную.
Создание клона процесса (местный аналог fork), система без антивируса:
~1.5 мс используя NtCreateUserProcess.
~0.9 мс используя NtCreateProcessEx + NtCreateThreadEx.
В то же время, создание нового потока занимает всего ~0.03 мс, что намного быстрее.
Упомянутый выше NtCreateProcessEx имеет интересную особенность - он создаёт только объект процесса, без изначального потока. Поскольку драйвера, которые подписываются на синхронные уведомления о создании процессов (посредством PsSetCreateProcessNotifyRoutine) получают их только при создании первичного потока в целевом процессе, мы получаем возможность измерить "чистое" время создания процессов, без вклада от сторонних драйверов. В этом случае NtCreateProcessEx тратит ~0.6 мс.
Наличие в системе дополнительных драйверов (вроде антивируса или EDR), может существенно повлиять на результаты. Так, включённый Windows Defender даёт примерно +90% замедления, заставляя CreateProcess тратить по ~2.1 мс. Но это ещё ничего, если взять какой-нибудь откровенно плохой антивирус, например, китайский 360 Security, то можно замедлить CreateProcess в 200 (!) раз, до ~240 мс.
Вам спасибо за отзыв!
В древнерусском и старославянском почему-то "идти" в этом значении не использовалось. Вот табличка, из которой видно какие глаголы и примерно когда помогали выражать будущее время
Новый трекер самая бесячая вещь в новом дизайне. Старый у меня был постоянно открыт в закрепленной вкладке, и я по наличию свободного времени читал комментарии, затем страницу трекера обновлял. Теперь стоит обновить страницу трекера и я больше не знаю что я читал а что нет. Снова откатываюсь на старую версию, это не просто бред, а бред в квадрате.
На самом деле в Российской Империи всё было не так однозначно, как говорили большевики:
Пруфы
habr.com/ru/post/146109
habr.com/ru/post/313274
habr.com/ru/post/452584
Заблуждения об именах:
habr.com/ru/post/431866
habr.com/ru/post/146901
Адреса:
habr.com/ru/company/hflabs/blog/260601
Горсовету подчинено примерно 10 разного рода сел. В каждом, разумеется, имеются улицы Ленина и 8 марта.
Помимо этого сам город состоит из пяти районов. Многие районы исторически когда-то были отдельными поселками. Поэтому в городе имеется четыре улицы Кирова. Тройных улиц несколько штук, двойных — и вовсе не сосчитать. Некоторые двойные улицы встречаются в одном и том же районе, поэтому дополнительно район хранить недостаточно, нужно еще какое-нибудь историческое название вроде Ломбардо.
Некоторые дома приписаны вовсе не к улицам, а к топонимам вроде «микрорайон „Центральный“», «квартал 13», «1105 км», «пос. Ленина В», «Больничный городок», «Подсобное хозяйство», «Старая Химколония», «Северный Батман» и т.д.
Часть улиц имеет переулки, которые получают названия вроде «улица 26 Бакинских комиссаров 3-й проезд».
На одной улице номера домов могут запросто повторяться. Если посреди улицы построен какой-нибудь завод или контора, то они непременно получат номер 1, хотя первый дом там уже был.
Одна улица вообще имеет нумерацию из одинаковых чисел, возрастающих с двух сторон навстречу друг другу.
Центр города состоит из пересекающихся улиц в клеточку. Поэтому дома могут иметь двойную нумерацию. А могут и не иметь. Один и тот же дом называется «Островского 3/18», «Плеханова 18/3», «Островского 3», «Плеханова 18». Это правильные названия. Но «девочки», записывающие адреса, могут еще изобрести дома Плеханова 18/3 и даже Островского 318. Им это запросто — изобрели же они когда-то улицу имени 250-летия СССР.
Ну и в качестве курьеза самое крутое название: улица Западный вентилятор.
Схематично это должно выглядило как то так (вроде)
play.golang.org/p/jJveuIrmJY8
Или он может только мне палки в колеса совать, когда мне это нафиг не надо, вроде «unused import»?
Это, в общем-то, главная проблема языка. Разработчики думают, что лучше меня знают, как мне писать мой код. Это же надо додуматься, специально дополнительно рандомизировать перебор мапы.
Не… Мы с коллцентром не общаемся. Есть сопровождение, есть поддержка. Их задача обеспечивать бесперебойную работу. В том числе и откатить или остановить что-то из процессов.
Мы вообще на 95% общаемся только с аналитиками. Они получают дефекты от сопровождения, задания на разработку от бизнеса.
На самом деле, это не остановка. Это переход на новый банковский день. Сведение баланса и прочие операции. В терминах АБС это называется EOD — End Of Day. Где-то в рекламе какого банка даже было что-то типа «платежи проводятся с 4 утра и до полуночи». Так вот с полуночи до 4 утра как раз и идет EOD. И новые внедрения на пром проводятся в рамках него.
У нас чуть сложнее. У нас все платежи круглосуточно. Перед началом EOD создается копия промюнита — юнит ночного ввода и все операции переводятся туда. Там как бы еще продолжается день. А в основном юните начинается процесс EOD. Когда он закончится, начинается накат из ночного юнита в новый день. Накат осуществляется по журналам (каждая таблица имеет т.н. «журнал» в котором фиксируются все изменения для каждой записи). Все записи в таблице изменяются толок через специальный RR модуль — модуль внешнего ввода, который вызывает другой модуль — UR, апдейт модуль, передавая ему нужные данные. А тот уже отвечает за журналирование изменений.
У RR модуля три режима — внешний ввод, накат (по журналу из юнита ночного ввода) и рекавери — восставноление по журналу текущего юнита.
Есть еще «головной журнал» где хранятся заголовки всех детальных журналов. По нему видно в каких таблицах были изменения и как получить соответсвующие записи из детальных журналов. За его заполнение тоже отвечает UR модуль.
При накате специальный процесс идет по головному журналу и для каждой записи вызывает соотв. RR модуль, передавая ему ключ его детального журнала. А тот уже берет данные по этому ключу из «своего» журнала и передает их в UR. Так все, что было сделано в течении существования юнита ночного ввода, переносится в дневной юнит в новый день.
Я знаю как это бывает и почему. Обслуживался в одном банке, где синхронизация холдов и остатков по счетам проводилась в EODе Там легко было, имея две карты, привязанные к одному счету, уйти в теховердрафт на сумму в два остатка по счету на начало дня.
Правда, за это не штрафовали т.к. считалось что это особенность функционирвания системы.
У нас такого нет — все доступные остатки считаются с учетом холдов. Т.е. послал 100р на крату — сразу видишь их доступными на счете. Расплатился картой — сразу видишь «уход» денег со счета (хотя фактически они еще там, просто сумма встала на холд и тебе показывают что она как будто списана уже). Если операция не прошла, холд снимается, для пользователя это выглядит как отмена операции с возвратом денег.
Хотя я тут могу не до конца быть точным в деталях т.к. вижу это исключительно со стороны как все это работает на уровне АБС с таблицами счетов (в том числе и то, что отдается мобильному клиенту или в инетбанк по запросу через WS).
Но в целом модуль пластиковых карт — это отдельная команда. Я с ними вообще не работал (чуть работал с командой системы расчетов — там была задача на стыке их темы и наших ядровых функций). Но сейчас и от этого ушел, слава богу. Сейчас по комплаенсу — жулики-мошенники, террористы-экстремисты, риски, проверки…
В догонку: неплохая статья на тему
Ещё бы кто сам shared_ptr защитил:
И нет, "всё тоже самое" в unsafe блоке в Rust провернуть нельзя. Потому что unsafe не выключает никаких проверок у стандартных примитивов-контейнеров.
Да, я могу обратиться к чужой памяти если буду действовать через указатель. Но пока я работаю с вектором через итератор — я не получу UB, даже в unsafe блоке. Rust просто не даст сделать активный итератор невалидным.
А что есть мейнстрим? Вебразработка? Мобильная?
А какой стек используется в промавтоматизации? В телекоммуникациях?
Совсем не очень. В силу того, что мы работаем на платформе, которая очень мало где используется в РФ.
Так вот позвольте представиться — Альфа-Банк, Управление разработки центральных банковских систем, главный разработчик.
То, что делается на «типовых технологиях» — это верхушка. То, что обсепечивает внешние интерфейсы.
Но опирается все это на код, написанный на 80% на RPG (остальное — C/C++) и работающий на платформе IBM i (бывшая AS/400) на серверах PowerS.
А то, что работает на типовых технологиях общается с нами через MQ и вебсервисы (которые сами ничего не не делают а только вызывают наши внутренние процедуры, передавая им набор параметров и получая ответ). А прямого доступа к данным ни у одной внешней системы нет.
А всю работу системы в плане обработки данных обеспечиваем мы. На своих «немейнстримных технологиях».
Тут такой слоеный пирог и в каждом слое свой стек и свои требования. И свои тараканы.