Да, я понял, что вы CDS имеете ввиду :) Изначально я имел ввиду CDO, и прочую не слишком тривиальную "финансовую магию", и писал в этом контексте. Про CDS, полностью с вами согласен. По поводу практической части, прайсинга CDS, я уже давно "не в теме", поэтому вряд ли что-то могу прокомментировать.
>Это вы описали uOPs cache. Но он не всеобемлющ, это всего лишь очень >маленький кеш.
"Маленький" зависит от вероятности необходимости повторного декодирования и связанных с этим задержками. 2К uop это совсем не маленький.
>Или вы под декодером понимаете сразу всю конвейерную группу, или > застряли во времена 486. Потому как два конвейерных декодера уже были в > Pentium, четверть века назад.
Pentium был классическим супер-скаляром, в котором если была возможность две соседние инструкции могли исполнится параллельно. Опять же никакой абстракции над исходной ISA, в виде OoO(хотя бы register renaming) и построения динамического графа исполнения там не было. Все это начали подвозить только в Pentium III. Под декодером я понимаю функциональный блок который на входе получает буфер, а на выходе выплевывает микро-инструкции удобоваримые остальными частями OoO движка.
>Синхронный конвейр на дюжину стадий с производительностью декодирования >гораздо выше чем инструкция-такт?
Не понимаю о чем вы говорите. Давайте условимся, что рассматриваем некоторый современный процессор с развитым OoO. Это означает, что у вас по определению есть:
некоторый механизм построения динамического графа исполнения (зависимостей инструкций)
качественное предсказание ветвлений с средней вероятностью по больнице где-то 99%. Применяя предсказания ветвлений, программа разворачивается в граф исполнения
есть некоторое окно инструкций, которые еще "в воздухе", то есть декодированные и к которым применен первичный механизм разрешения зависимостей в графе исполнения. Если мы говорим про классику, то это будет register renaming, с регистровым файлом от 100 элементов. Соответственно, примерно столько же инструкций внутри этого окна.
front-end дополняет этот граф исполнения сверху, то есть делает префетч на подгрузку инструкций и их декодирование, преобразование в микро-инструкции. В более продвинутом варианте у нас скорее всего даже есть кэш микро-инструкций, который даже не смотря на свой небольшой размер, будет существенно снижать нагрузку на декодер.
back-end состояит из execution units(integer/fp) и load/store. Каждый свободный unit получает от OoO движка микро-инструкцию и ее входящие параметры. Эта инструкция для которой входные зависимости уже готовы, OoO движок это знает так как у него есть граф исполнения(в простейшем случаи это реализация в духе register renaming). Таким образом back-end всегда оптимально загружен во "всю ширину". Если нам попался плохой участок кода, с длинной цепной зависимостью, то да их придется исполнить одна за одной. Но обычно граф исполнения, гораздо более разряжен, что позволяет исполнять значительное количество инструкций параллельно.
OoO за счет "окна инструкций", которые содержат текущий кусок графа исполнения, позволяет сделать развязку front-end и back-end. По сути нам важно лишь чтобы средний throughput front-end и back-end совпадали.
самая плохая вещь, это сброс графа исполнения OoO конвеера из-за не предсказанного ветвления, что заставляет отбрасывать спекулятивность и "раскручивать" другую ветку
>Ну, с этим параллелизмом обратно к синхронному конвейру, зависимостям данных >и вычислимым частям CISC-инструкций.
>Нет, вы правы в том, что аппаратные компараторы используются при >декодировании и работают они асинхронно. Но только в этом.
Декодер в OoO подходе это просто штука, которая преобразует некоторый буфер в входной набор микро-инструкций и обладает нужной пропускной способностью. Под "параллельностью" я естественно имею ввиду реализацию в виде комбинаторно-регистровой схемы, которая декодирует с пропускной способностью гораздо больше чем инструкция за такт. (компаратор это к слову по определению аналоговое устройство, и как его применять в данном вопросе цифровой схемотехники, я не представляю. а так да, цифровая схема, состоит из параллельно работающих логических элементов и регистров)
>Вы буквально на несколько предложений выше сказали: скорость >декодирования гораздо выше чем инструкция-такт. А теперь говорите о >большой сложности.
Естественно, чтобы получить IPC >> 1, необходима скорость декодирования значительно больше 1, для любого декодера. Реализация декодера(как функционального блока в рамках OoO процессоора) для CISC сложнее, из-за переменной длины инструкций. Естественно, это будет выливаться как в усложнение алгоритмов, схемотехники, так и увеличение транзисторного бюджета. Но принципиально это ничего не меняет. Даже в самом оптимистичном сценарии, вы сэкономите 5-10% транзисторов, от бюджета всего ядра.
>tail risk безусловно учитывается, это и есть базис между кэшем >и деривативом.
Не, ну как? ) Давайте на простом примере. Берем модель Блэка-Шоулза, для прайсинга опционов. При допущении, что у нас независимые приращения с одним и тем же распределением, получаем такую красивую Гаусиану, у которой дисперсия растет как sqrt(t). Только в реальности, цена у нас с не стационарной волатильностью, с локальными трендами и вообще приращения с "длинными хвостами". Если вы будете прайсить опционы по модели Блэка-Шоулза у вас будет какая-то цена, которая естественно не учитывает некоторые характеристики того, что может происходить в реальности. К примеру, модельная вероятность, что цена достигнет дальний страйк, будет на порядок отличаться от, той что будет при торговле в реальности. К чему я это все. В любой модели всегда есть некоторые предпосылки(рыночные или математико-статистические), которые могут в реальности при определенных условиях ломаться. Поэтому есть некоторая оценка доходности и риска(условно говоря среднее и дисперсия) полученные из модели, верные при выполнении заложенный предпосылок. А так же если вы не первый день в индустрии и не хотите закончить банкротством, то так же у вас есть оценки при различных не благоприятных сценариях, при которых те или иные предпосылки моделей будут ломаться. Таким образом те оценки, что посчитаны в модели получают некоторый дополнительный "хвост". И за этот хвост кому-то на дистанции 10-20 лет, крайней вероятно придется платить. И тут у вас два варианта, либо вы действуете как классическая страховая компания, то есть оплачиваете хвост из своих прошлых прибылей, но нормальные люди так естественно не делают. Либо классика жанра, финансовой инженерии, это трансформировать и спрятать куда-то этот хвост, желательно так чтобы это "куда-то" можно было продать "дурачкам с деньгами".
>Но в целом CDS это сильно проще опциона, тейл рисков там >сильно меньше. > Главные - в левередже, так как чтобы купить кэш инструмент, >надо найти > продавца, а CDS - это просто договор.
Да, я за давностью лет перепутал CDS и CDO, которые прайсились с использованием gaussian copula и все в этом духе.
Вообще если бы я анализировал, модель прайсинга какого-то финансового инструмента в разрезе "бахнет или нет". Меня прежде всего интересовал бы механизм реализации tail risk, при различных неблагоприятных сценариях. А не то, что обычно учитывают люди, которые строят эти модели, так как их оценки практически всегда исходят из тех же математических-статистических допущений, на которых построена модель. И следующий вопрос, кто будет платить за этот tail risk. Потому что альфа и омега, финансовой инженерии это взять себе 95% распределения, которые естественно будут выпадать годами, а оставшиеся "хвосты" на кого ни буть спихнуть, желательно на "дурачков с деньгами".
"They became popular in the early 2000s, and by 2007, the outstanding credit default swaps value stood at $62.2 trillion. During the financial crisis of 2008, the value of CDS was hit hard, and it dropped to $26.3 trillion by 2010 and $25.5 trillion in 2012." То есть падение, от пика объема рынка 2.5 раза, что уже не плохо.
Tail risk. Условно говоря, нет никаких гарантий, что завтра США с Китаем не начнут более серьезную политико-экономическую-военную конфронтацию, из-за которой пострадают оба, США конечно меньше. Но экономика и индексы серьезно так поедут вниз. При прайсинге всяких сложных финансовых инструментов tail risk, это самая опасная штука. Даже на таких простых вещах как опционы, падение рынка за 1-2 месяца более чем на 40%, может оставить вас без штанов, и заставить еще раз задуматься про всю эту "финансовую магию", хотя до этого вы 10 лет стабильно зарабатывали выстраивая сложные "арбитражные" позиции.
Честно, давно это все было, да и я не человек из индустрии. Не знаю на каких конкретно механизмах это работало. Но в википедии есть мнение с которым я согласен: "The Financial Crisis Inquiry Commission reported in January 2011 that CDS contributed significantly to the crisis. Companies were able to sell *protection to investors against the default of mortgage-backed securities*, helping to launch and expand the market for new, complex instruments such as CDO's. This further fueled the housing bubble."
Не, банки так не работают, по определению это максимально без рисковое предприятие. Условно говоря, берут деньги под 2%, накидывают рисковую модель, и дают под 4%, на эти "2% и живут". Реализация залога для банка всегда риск, именно поэтому существует некоторая скоринговая-рисковая система. Поэтому "добро порядочные заемщики" с рейтингом AAA и "мусорные" с CCC, это совсем ни одно и тоже. Если бы не вот это массовое перекрашивание "мусора" в AAA при помощи "магии" CDS, то и поведение банков и общая динамика рынка была бы иная, а значит и такого "бабаха" скорее всего бы не было бы. Просто мы имеем ситуацию, в которой каждый отдельный "винтик", ни делал ничего не законного или даже особо предосудительного. С фундаментально-прямолинейной точки зрения, виноваты инвест-конторы-банки, которые продавали слишком дешевые CDS не отражающие реальные риски, а когда пришло время платить бабки за страховку, завыли - "мы слишком большие чтобы упасть", и вообще это не мы виноваты ("у нас лапки").
Всегда думал, что настоящая "твердая" наука, она про фальсификацию, построение моделей и их экспериментальную проверку. То в какую социальную и экономическую конструкцию это обличено, вопрос конечно важный для эффективности функционирования, но не краеугольный.
Так вопрос был в том можно ли заменить все на memmove. 10 тактов это как раз примерно столько, сколько надо для того чтобы посчитать, что диапазоны не пересекаются и использовать максимально оптимизированную реализацию memcpy, иначе стандартную memmove.
Ох... В исходном посте ясно же описано, что ISA никакой современный производительный процессор не исполняет. ISA преобразуется один раз декодером в микро-инструкции, микро-инструкции сохраняются в кэше микро-инструкций, когда OoO ядро надо получить данные по инструкциям они берутся из кэша. И естественно, даже декодирование исходной ISA происходит, ни так как вы описываете. Декодер должен быть один, так как вам нужно пройтись по всем инструкциям и получить из них один "поток исполнения". И работает он примерно так - на вход загружается буфер, на выходе за счет "параллелизма логических элементов"(то есть скорость декодирования гораздо выше чем инструкция-такт), получается нужный связанный набор микро-инструкций. Для CISC из-за переменной длины инструкций сделать хороший декодер, сложнее чем для RISC, что выливается в некоторый дополнительный транзисторный бюджет. Но на фоне остальных блоков эффект от увеличения достаточно минорный.
Да уж, ну вы и замахнулись. Все современные высоко производительные ядра процессоров, построены по схеме в которой главным компонентом является Out-of-Order engine. По сути, он отвечает за спекулятивное исполнение всего, что только можно(предсказание ветвлений, параллельное выполнение независимых веток инструкций, префетчинг дотсупа к памяти и т.д). И внутри этот движок оперирует некоторыми микро-инструкциями в которые транслируются исходная ISA(instruction set architecture, то что по русски называется набором команд или ассемблером процессора). Поэтому CISC, там или RISC, не имеет никакого решающего значения, влияет это всего лишь на транзисторный бюджет декодера, который и так достаточно минорный. Что имеет значение, так это то насколько продвинутый OoO движок вам удалось сделать. Intel и AMD в этом условно говоря "собаку съели". Но вот и Apple подтянулось в их клуб, при этом какую бы ISA они ни взяли, вопрос с точки зрения производительности - глубоко вторичный. Сила RISC и ARM в частности, это когда никакой слишком высокой производительности на такт не надо, и можно сделать тупой и простой процессор который будет оперировать ISA, без каких либо OoO прослоек. Тогда действительно мы получаем, и уменьшенный транзисторный бюджет, и меньшее энергопотребление, и относительно более высокую частоту, а так же производительность.
Так насколько я понимаю, если не брать всякие причуды стандарта, то memmove можно было бы и оставить, так как memcpy является ее строгим подмножетством. Вопрос условно говоря, в десятке тактов на определение не пересечения двух диапазонов.
На момент кризиса, считалось, что вся фишка была в "финансовой магии". Банки более менее понимают, качество выдаваемых кредитов и присваивают им разные уровни AAA-BBB-CCC и т.д. таким образом имея прогноз воздействия различных рисков на состояние своего баланса. Так вот, что происходило: брались мусорные кредиты, на них бралась "защита от банкротства"(да, те самые CDS), после чего мусор становился AAA и продавался дальше пенсионным фондам. И все это прокручивалось круг за кругом. В результате "дерьма" в системе стало слишком много, и она лопнула, а CDS послужили таким очень хорошим мультипликатором всего процесса. То как вообще прайсились CDS и почему CDS на мусор, стоили так дешево, это вообще отдельная история. То есть проблема даже не в том, что были плохие кредиты, и пузыре на рынке недвижимости. Если бы ситуация была более прогнозируемая для участников рынка, с этим можно было как-то жить, а не бабахнуть все разом. В случаи 2008го года было так, что когда к тем кто выпускал страховки на мусор пришли с вопросом "где деньги Зин", они сказали "извините но денег нет", и это были крупнейшие корпорации вроде AIG и инвест банки. После этого все и зашаталось.
Ошибся с датой, это не такой простой вопрос как кажется. Конечно если использовать линейный инструмент(акции/фьючерс) в шорт(на понижение), то надо платить деньги за взятые в залог активы и высиживать просадку. Но если мы говорим по дальние опционы и в определенной степени близкие к ним CDS, то ситуация иная. В какой-то степени это близко к тому, что описывает Талеб в своих книгах - ловля "черных лебедей". Конечно, если вы будете постоянно покупать дешевые дальние опционы, и никакого серьезного кризиса не будет, то в среднем потраченные на них деньги не компенсируют одного удачно пойманного "черного лебедя". Поэтому крайне важен процесс формирования позиции. Мы ведь только знаем, что он сделал прогноз в 2004, и начал формировать позицию, какими темпами и когда она достигла максимума - у нас информации нет.
Да, конечно, можно говорить об "ошибке выжившего" особенно применительно к биржевой торговле. Скажу достаточно резкую вещь, но индустрия активного управления это во многом узаконенный и индустриализированный scam. Уже давно показано, что в среднем за вычетом комиссии активно управляемые фонды показывают результаты хуже, пассивного инвестирования в индексы. Какие-то хедж фонды показывают результат чисто случайно лучше среднего, часто беря на себя лишние риски, в них несут деньги - результат "возвращается к среднему" или вообще происходит банкротство, фонд закрывается, управляющие берут свою комиссию и отправляются на "почетный отдых" или открывают новый фонд.
Поэтому относительно героя про которого идет можно сказать следующее:
У него был долгосрочный view, который оказался верным.
Он сумел сформировать, а главное "высидеть" позицию в подходящем инструменте. При этом, основную проблему составляло, скорее не то как позиция была сформирована, а нервирующие инвесторы требующие назад свои деньги.
Ситуации в которых возможно сделать иксы на бирже, единичны. И они всегда связаны с определенным mindset, тех кто их решил разыграть. Поэтому и "пророков" искать особо не стоит. Удачные истории всегда будут единичными.
Немного позанудствую. Но если использовать типичную реализацию memcpy для копирования пересекающихся областей, то он будет работать лишь в одном случаи. Либо когда адрес destination < source, либо наоборот. Что по определению является дурно пахнущим кодом.
Только не в компиляторе, а в glibc. И конкретно, там была история, что все сломалось из-за того, что бравый парень из intel решил в рамках оптимизации, для ускорения копировать области памяти задом наперед. В результате generic версия работало нормально, а оптимизированная крашилась в Adobe Flash.
В моем понимании, человек который может в машинное обучение, какую-то прикладную математику и алгоритмы со структурами данных, в современных реалиях называется data scientist. Может ли инженер АСУ ТП переквалифицироваться в дата сайнтиста? Может, но при прочих равных это наверное будет один из наиболее трудных путей для "вливания в IT". Конечно, если мы говорим про студентов, и предлагаем им "бежать куда только можно", то да можно рассмотреть дата сайнс, особенно, если есть интерес и "глаза горят". Только причем тогда знания АСУ ТП, которые по сути будут являются балластом с очень низким КПД?
Разработка современных систем управления, на основе сложных математических/физических моделей это вообще несколько другая реальность по сравнению с тем, что описал автор статьи и IT вообще. Тут скорее больше нужна профильная математика/физика и специализация в области ТАУ(теория автоматического управления, как это называлось очень давно и сейчас существует в виде множества разнообразных направлений). И конечно нужен опыт. В конечном итоге может оказаться, что количество вакантных мест в несколько раз меньше количества студентов выпускаемых топовыми ВУЗами(МФТИ и т.д.) по специальности.
Да, я понял, что вы CDS имеете ввиду :) Изначально я имел ввиду CDO, и прочую не слишком тривиальную "финансовую магию", и писал в этом контексте. Про CDS, полностью с вами согласен. По поводу практической части, прайсинга CDS, я уже давно "не в теме", поэтому вряд ли что-то могу прокомментировать.
>Это вы описали uOPs cache. Но он не всеобемлющ, это всего лишь очень >маленький кеш.
"Маленький" зависит от вероятности необходимости повторного декодирования и связанных с этим задержками. 2К uop это совсем не маленький.
>Или вы под декодером понимаете сразу всю конвейерную группу, или
> застряли во времена 486. Потому как два конвейерных декодера уже были в
> Pentium, четверть века назад.
Pentium был классическим супер-скаляром, в котором если была возможность две соседние инструкции могли исполнится параллельно. Опять же никакой абстракции над исходной ISA, в виде OoO(хотя бы register renaming) и построения динамического графа исполнения там не было. Все это начали подвозить только в Pentium III. Под декодером я понимаю функциональный блок который на входе получает буфер, а на выходе выплевывает микро-инструкции удобоваримые остальными частями OoO движка.
>Синхронный конвейр на дюжину стадий с производительностью декодирования >гораздо выше чем инструкция-такт?
Не понимаю о чем вы говорите. Давайте условимся, что рассматриваем некоторый современный процессор с развитым OoO. Это означает, что у вас по определению есть:
некоторый механизм построения динамического графа исполнения (зависимостей инструкций)
качественное предсказание ветвлений с средней вероятностью по больнице где-то 99%. Применяя предсказания ветвлений, программа разворачивается в граф исполнения
есть некоторое окно инструкций, которые еще "в воздухе", то есть декодированные и к которым применен первичный механизм разрешения зависимостей в графе исполнения. Если мы говорим про классику, то это будет register renaming, с регистровым файлом от 100 элементов. Соответственно, примерно столько же инструкций внутри этого окна.
front-end дополняет этот граф исполнения сверху, то есть делает префетч на подгрузку инструкций и их декодирование, преобразование в микро-инструкции. В более продвинутом варианте у нас скорее всего даже есть кэш микро-инструкций, который даже не смотря на свой небольшой размер, будет существенно снижать нагрузку на декодер.
back-end состояит из execution units(integer/fp) и load/store. Каждый свободный unit получает от OoO движка микро-инструкцию и ее входящие параметры. Эта инструкция для которой входные зависимости уже готовы, OoO движок это знает так как у него есть граф исполнения(в простейшем случаи это реализация в духе register renaming). Таким образом back-end всегда оптимально загружен во "всю ширину". Если нам попался плохой участок кода, с длинной цепной зависимостью, то да их придется исполнить одна за одной. Но обычно граф исполнения, гораздо более разряжен, что позволяет исполнять значительное количество инструкций параллельно.
OoO за счет "окна инструкций", которые содержат текущий кусок графа исполнения, позволяет сделать развязку front-end и back-end. По сути нам важно лишь чтобы средний throughput front-end и back-end совпадали.
самая плохая вещь, это сброс графа исполнения OoO конвеера из-за не предсказанного ветвления, что заставляет отбрасывать спекулятивность и "раскручивать" другую ветку
>Ну, с этим параллелизмом обратно к синхронному конвейру, зависимостям данных >и вычислимым частям CISC-инструкций.
>Нет, вы правы в том, что аппаратные компараторы используются при >декодировании и работают они асинхронно. Но только в этом.
Декодер в OoO подходе это просто штука, которая преобразует некоторый буфер в входной набор микро-инструкций и обладает нужной пропускной способностью. Под "параллельностью" я естественно имею ввиду реализацию в виде комбинаторно-регистровой схемы, которая декодирует с пропускной способностью гораздо больше чем инструкция за такт. (компаратор это к слову по определению аналоговое устройство, и как его применять в данном вопросе цифровой схемотехники, я не представляю. а так да, цифровая схема, состоит из параллельно работающих логических элементов и регистров)
>Вы буквально на несколько предложений выше сказали:
скорость >декодирования гораздо выше чем инструкция-такт. А теперь говорите о >большой сложности.Естественно, чтобы получить IPC >> 1, необходима скорость декодирования значительно больше 1, для любого декодера. Реализация декодера(как функционального блока в рамках OoO процессоора) для CISC сложнее, из-за переменной длины инструкций. Естественно, это будет выливаться как в усложнение алгоритмов, схемотехники, так и увеличение транзисторного бюджета. Но принципиально это ничего не меняет. Даже в самом оптимистичном сценарии, вы сэкономите 5-10% транзисторов, от бюджета всего ядра.
>tail risk безусловно учитывается, это и есть базис между кэшем >и деривативом.
Не, ну как? ) Давайте на простом примере. Берем модель Блэка-Шоулза, для прайсинга опционов. При допущении, что у нас независимые приращения с одним и тем же распределением, получаем такую красивую Гаусиану, у которой дисперсия растет как sqrt(t). Только в реальности, цена у нас с не стационарной волатильностью, с локальными трендами и вообще приращения с "длинными хвостами". Если вы будете прайсить опционы по модели Блэка-Шоулза у вас будет какая-то цена, которая естественно не учитывает некоторые характеристики того, что может происходить в реальности. К примеру, модельная вероятность, что цена достигнет дальний страйк, будет на порядок отличаться от, той что будет при торговле в реальности. К чему я это все. В любой модели всегда есть некоторые предпосылки(рыночные или математико-статистические), которые могут в реальности при определенных условиях ломаться. Поэтому есть некоторая оценка доходности и риска(условно говоря среднее и дисперсия) полученные из модели, верные при выполнении заложенный предпосылок. А так же если вы не первый день в индустрии и не хотите закончить банкротством, то так же у вас есть оценки при различных не благоприятных сценариях, при которых те или иные предпосылки моделей будут ломаться. Таким образом те оценки, что посчитаны в модели получают некоторый дополнительный "хвост". И за этот хвост кому-то на дистанции 10-20 лет, крайней вероятно придется платить. И тут у вас два варианта, либо вы действуете как классическая страховая компания, то есть оплачиваете хвост из своих прошлых прибылей, но нормальные люди так естественно не делают. Либо классика жанра, финансовой инженерии, это трансформировать и спрятать куда-то этот хвост, желательно так чтобы это "куда-то" можно было продать "дурачкам с деньгами".
>Но в целом CDS это сильно проще опциона, тейл рисков там >сильно меньше.
> Главные - в левередже, так как чтобы купить кэш инструмент, >надо найти
> продавца, а CDS - это просто договор.
Да, я за давностью лет перепутал CDS и CDO, которые прайсились с использованием gaussian copula и все в этом духе.
Вообще если бы я анализировал, модель прайсинга какого-то финансового инструмента в разрезе "бахнет или нет". Меня прежде всего интересовал бы механизм реализации tail risk, при различных неблагоприятных сценариях. А не то, что обычно учитывают люди, которые строят эти модели, так как их оценки практически всегда исходят из тех же математических-статистических допущений, на которых построена модель. И следующий вопрос, кто будет платить за этот tail risk. Потому что альфа и омега, финансовой инженерии это взять себе 95% распределения, которые естественно будут выпадать годами, а оставшиеся "хвосты" на кого ни буть спихнуть, желательно на "дурачков с деньгами".
"Обязательно бахнет, но не сейчас" (с)
С моек колокольни видятся следующие факторы:
"Игра с нулевой суммой", или эффект толпы.
"They became popular in the early 2000s, and by 2007, the outstanding credit default swaps value stood at $62.2 trillion. During the financial crisis of 2008, the value of CDS was hit hard, and it dropped to $26.3 trillion by 2010 and $25.5 trillion in 2012." То есть падение, от пика объема рынка 2.5 раза, что уже не плохо.
Tail risk. Условно говоря, нет никаких гарантий, что завтра США с Китаем не начнут более серьезную политико-экономическую-военную конфронтацию, из-за которой пострадают оба, США конечно меньше. Но экономика и индексы серьезно так поедут вниз. При прайсинге всяких сложных финансовых инструментов tail risk, это самая опасная штука. Даже на таких простых вещах как опционы, падение рынка за 1-2 месяца более чем на 40%, может оставить вас без штанов, и заставить еще раз задуматься про всю эту "финансовую магию", хотя до этого вы 10 лет стабильно зарабатывали выстраивая сложные "арбитражные" позиции.
Честно, давно это все было, да и я не человек из индустрии. Не знаю на каких конкретно механизмах это работало. Но в википедии есть мнение с которым я согласен: "The Financial Crisis Inquiry Commission reported in January 2011 that CDS contributed significantly to the crisis. Companies were able to sell *protection to investors against the default of mortgage-backed securities*, helping to launch and expand the market for new, complex instruments such as CDO's. This further fueled the housing bubble."
https://en.wikipedia.org/wiki/Subprime_mortgage_crisis#Credit_default_swaps
А так вы правы, по поводу секьюритизации.
Не, банки так не работают, по определению это максимально без рисковое предприятие. Условно говоря, берут деньги под 2%, накидывают рисковую модель, и дают под 4%, на эти "2% и живут". Реализация залога для банка всегда риск, именно поэтому существует некоторая скоринговая-рисковая система. Поэтому "добро порядочные заемщики" с рейтингом AAA и "мусорные" с CCC, это совсем ни одно и тоже. Если бы не вот это массовое перекрашивание "мусора" в AAA при помощи "магии" CDS, то и поведение банков и общая динамика рынка была бы иная, а значит и такого "бабаха" скорее всего бы не было бы. Просто мы имеем ситуацию, в которой каждый отдельный "винтик", ни делал ничего не законного или даже особо предосудительного. С фундаментально-прямолинейной точки зрения, виноваты инвест-конторы-банки, которые продавали слишком дешевые CDS не отражающие реальные риски, а когда пришло время платить бабки за страховку, завыли - "мы слишком большие чтобы упасть", и вообще это не мы виноваты ("у нас лапки").
Всегда думал, что настоящая "твердая" наука, она про фальсификацию, построение моделей и их экспериментальную проверку. То в какую социальную и экономическую конструкцию это обличено, вопрос конечно важный для эффективности функционирования, но не краеугольный.
Так вопрос был в том можно ли заменить все на memmove. 10 тактов это как раз примерно столько, сколько надо для того чтобы посчитать, что диапазоны не пересекаются и использовать максимально оптимизированную реализацию memcpy, иначе стандартную memmove.
Ох... В исходном посте ясно же описано, что ISA никакой современный производительный процессор не исполняет. ISA преобразуется один раз декодером в микро-инструкции, микро-инструкции сохраняются в кэше микро-инструкций, когда OoO ядро надо получить данные по инструкциям они берутся из кэша. И естественно, даже декодирование исходной ISA происходит, ни так как вы описываете. Декодер должен быть один, так как вам нужно пройтись по всем инструкциям и получить из них один "поток исполнения". И работает он примерно так - на вход загружается буфер, на выходе за счет "параллелизма логических элементов"(то есть скорость декодирования гораздо выше чем инструкция-такт), получается нужный связанный набор микро-инструкций. Для CISC из-за переменной длины инструкций сделать хороший декодер, сложнее чем для RISC, что выливается в некоторый дополнительный транзисторный бюджет. Но на фоне остальных блоков эффект от увеличения достаточно минорный.
Да уж, ну вы и замахнулись. Все современные высоко производительные ядра процессоров, построены по схеме в которой главным компонентом является Out-of-Order engine. По сути, он отвечает за спекулятивное исполнение всего, что только можно(предсказание ветвлений, параллельное выполнение независимых веток инструкций, префетчинг дотсупа к памяти и т.д). И внутри этот движок оперирует некоторыми микро-инструкциями в которые транслируются исходная ISA(instruction set architecture, то что по русски называется набором команд или ассемблером процессора). Поэтому CISC, там или RISC, не имеет никакого решающего значения, влияет это всего лишь на транзисторный бюджет декодера, который и так достаточно минорный. Что имеет значение, так это то насколько продвинутый OoO движок вам удалось сделать. Intel и AMD в этом условно говоря "собаку съели". Но вот и Apple подтянулось в их клуб, при этом какую бы ISA они ни взяли, вопрос с точки зрения производительности - глубоко вторичный. Сила RISC и ARM в частности, это когда никакой слишком высокой производительности на такт не надо, и можно сделать тупой и простой процессор который будет оперировать ISA, без каких либо OoO прослоек. Тогда действительно мы получаем, и уменьшенный транзисторный бюджет, и меньшее энергопотребление, и относительно более высокую частоту, а так же производительность.
Так насколько я понимаю, если не брать всякие причуды стандарта, то memmove можно было бы и оставить, так как memcpy является ее строгим подмножетством. Вопрос условно говоря, в десятке тактов на определение не пересечения двух диапазонов.
На момент кризиса, считалось, что вся фишка была в "финансовой магии". Банки более менее понимают, качество выдаваемых кредитов и присваивают им разные уровни AAA-BBB-CCC и т.д. таким образом имея прогноз воздействия различных рисков на состояние своего баланса. Так вот, что происходило: брались мусорные кредиты, на них бралась "защита от банкротства"(да, те самые CDS), после чего мусор становился AAA и продавался дальше пенсионным фондам. И все это прокручивалось круг за кругом. В результате "дерьма" в системе стало слишком много, и она лопнула, а CDS послужили таким очень хорошим мультипликатором всего процесса. То как вообще прайсились CDS и почему CDS на мусор, стоили так дешево, это вообще отдельная история. То есть проблема даже не в том, что были плохие кредиты, и пузыре на рынке недвижимости. Если бы ситуация была более прогнозируемая для участников рынка, с этим можно было как-то жить, а не бабахнуть все разом. В случаи 2008го года было так, что когда к тем кто выпускал страховки на мусор пришли с вопросом "где деньги Зин", они сказали "извините но денег нет", и это были крупнейшие корпорации вроде AIG и инвест банки. После этого все и зашаталось.
Ошибся с датой, это не такой простой вопрос как кажется. Конечно если использовать линейный инструмент(акции/фьючерс) в шорт(на понижение), то надо платить деньги за взятые в залог активы и высиживать просадку. Но если мы говорим по дальние опционы и в определенной степени близкие к ним CDS, то ситуация иная. В какой-то степени это близко к тому, что описывает Талеб в своих книгах - ловля "черных лебедей". Конечно, если вы будете постоянно покупать дешевые дальние опционы, и никакого серьезного кризиса не будет, то в среднем потраченные на них деньги не компенсируют одного удачно пойманного "черного лебедя". Поэтому крайне важен процесс формирования позиции. Мы ведь только знаем, что он сделал прогноз в 2004, и начал формировать позицию, какими темпами и когда она достигла максимума - у нас информации нет.
Да, конечно, можно говорить об "ошибке выжившего" особенно применительно к биржевой торговле. Скажу достаточно резкую вещь, но индустрия активного управления это во многом узаконенный и индустриализированный scam. Уже давно показано, что в среднем за вычетом комиссии активно управляемые фонды показывают результаты хуже, пассивного инвестирования в индексы. Какие-то хедж фонды показывают результат чисто случайно лучше среднего, часто беря на себя лишние риски, в них несут деньги - результат "возвращается к среднему" или вообще происходит банкротство, фонд закрывается, управляющие берут свою комиссию и отправляются на "почетный отдых" или открывают новый фонд.
Поэтому относительно героя про которого идет можно сказать следующее:
У него был долгосрочный view, который оказался верным.
Он сумел сформировать, а главное "высидеть" позицию в подходящем инструменте. При этом, основную проблему составляло, скорее не то как позиция была сформирована, а нервирующие инвесторы требующие назад свои деньги.
Ситуации в которых возможно сделать иксы на бирже, единичны. И они всегда связаны с определенным mindset, тех кто их решил разыграть. Поэтому и "пророков" искать особо не стоит. Удачные истории всегда будут единичными.
Немного позанудствую. Но если использовать типичную реализацию memcpy для копирования пересекающихся областей, то он будет работать лишь в одном случаи. Либо когда адрес destination < source, либо наоборот. Что по определению является дурно пахнущим кодом.
Только не в компиляторе, а в glibc. И конкретно, там была история, что все сломалось из-за того, что бравый парень из intel решил в рамках оптимизации, для ускорения копировать области памяти задом наперед. В результате generic версия работало нормально, а оптимизированная крашилась в Adobe Flash.
В моем понимании, человек который может в машинное обучение, какую-то прикладную математику и алгоритмы со структурами данных, в современных реалиях называется data scientist. Может ли инженер АСУ ТП переквалифицироваться в дата сайнтиста? Может, но при прочих равных это наверное будет один из наиболее трудных путей для "вливания в IT". Конечно, если мы говорим про студентов, и предлагаем им "бежать куда только можно", то да можно рассмотреть дата сайнс, особенно, если есть интерес и "глаза горят". Только причем тогда знания АСУ ТП, которые по сути будут являются балластом с очень низким КПД?
Разработка современных систем управления, на основе сложных математических/физических моделей это вообще несколько другая реальность по сравнению с тем, что описал автор статьи и IT вообще. Тут скорее больше нужна профильная математика/физика и специализация в области ТАУ(теория автоматического управления, как это называлось очень давно и сейчас существует в виде множества разнообразных направлений). И конечно нужен опыт. В конечном итоге может оказаться, что количество вакантных мест в несколько раз меньше количества студентов выпускаемых топовыми ВУЗами(МФТИ и т.д.) по специальности.