Часть 1 >> Часть 2 >> Часть 3 >> Часть 4 >> Часть 5 >> Часть 6 >> Часть 7 >> Часть 8 >> Часть 9 >> Часть 10 >> Часть 11 >> Часть 12 >> Часть 13 >> Часть 14 >> Часть 15 >> Часть 16

Сегодня речь у нас пойдет о всякого рода отчетах и индикаторах. Из этой главы вы узнаете, насколько страшно это зло. А также поймете, почему оно неизбежно, если вы работаете в софтварном подразделении «железной» конторы.

Бастарды и нелюбимые дети

Все свои 22 года в Интел я проработал в Software Solutions (Services) Group — подразделении, которое занималось экосистемным программным обеспечением. И все это время меня преследовал некий дуализм бытия. C одной стороны, залогом величия Интел стали последовательные инвестиции в экосистему программного обеспечения. Компания одной из первых осознала ее значимость для продвижения процессоров на рынке. Интел построил очень разумную организацию, занимавшуюся software enabling. Часть людей (Developer Products Division) работала над программными инструментами: компиляторами, библиотеками, отладчиками, профилировщиками и т.п. Другая часть (Development Relаtions Division) отвечала за взаимодействие со сторонними разработчиками софта. Его сотрудники (аpplication engineers) помогали производителям программных продуктов оптимизировать их под интеловое железо. Когда было осознано значение Open Source, OTC (Open Source Tecnhology Center) также выделился в отдельное подразделение и вывел Интел на лидирующие позиции по модификациям ядра Linux. Благодаря многолетним усилиям всех этих людей x86 стала самой востребованной архитектурой среди программистов и еще долгое время ей останется.

С другой стороны, разработчики этого самого экосистемного софта (операционные системы, инструменты, приложения) очень долгое время оставались в компании на положении «бастардов и нелюбимых детей», как говорил известный персонаж «Игры престолов». Начальство (а первые СЕО Интела были выходцами из разработки железа или производства) на нас, софтовиков, посматривало косо. Рассуждало оно примерно так. «Вот возьмем продажников — от них понятная польза. Они продают чипы и приносят в клювике денежку в контору. Рабочие на фабрике эти чипы производят. Разработчики железа — проектируют. Тут тоже все ясно. А от программистов этих какая польза?» Неудивительно, что жизнь наша была далеко не сахар. Но справедливости ради отметим, что были люди, которым жилось еще хуже. Это ученые из Intel Labs. Они занимались долгосрочными фундаментальными исследованиями, напрямую не связанными с продуктовой линейкой. Intel Labs был, наверно, самой интеллектуальной частью конторы. Но как только в квартальных отчетах что‑то не ладилось, попадал под безжалостный нож бухгалтерии первым (чуть подробнее об этом будет в следующей главе). Очередь SSG была сразу за ними.

Впрочем, бывали праздники и на нашей улице. Они случались тогда, когда вся остальная контора погружалась в траур. ???? Первый «золотой век софта» в Интел пришелся на начало нулевых. В «погоне за гигагерцами» фирма выпустила на свет божий архитектуру Netburst c ее сверхдлинным конвейером и доступом к памяти через «северный мост». Вышедший следом AMD Opteron быстро показал всю утопичность этой затеи. Интел начал проигрывать сделку за сделкой и стремительно терять долю рынка. Продукт АМD, обладавший существенно более коротким пайплайном и инновационным (на тот момент) интегрированным контроллером памяти, оказался значительно лучше «приспособленным» к существующему набору приложений. Netburst же столкнулся с целым ворохом проблем. При неправильном предсказании ветвлений полная очистка конвейера могла занимать до сотни тактов. Промах в кэш оборачивался длительным походом в память (через North Bridge!). Это приводило это к тому, что железка вхолостую молотила на бешеной частоте и безбожно грела Вселенную.

И вот тут‑то на арену и вышли софтовики, прикрывая просчеты в дизайне железа. Приходилось «распрямлять» (уменьшать количество ветвлений), заботиться о локальности данных (процент попаданий в кэш), уменьшать количество обменов с памятью и тп. Работы было навалом, но это позволяло Интел держаться на плаву и по крайней мере делать хорошую мину при плохой игре. Видимо, именно в этот момент интеловый менеджмент впервые осознал, что от софтовиков тоже есть определенная польза. И на фоне общего падения финансовых показателей конторы SSG начал стремительно расти. Такой вот пир во время чумы. Однако продолжался он недолго. Сначала Israel Development Center выкатил Merom — первый чип семейства Core, куда больше похожий на Pentium 3. А в 2006 Ронак Сингал выпустил Nehalem — первый серверный чип от Интел с интегрированным контроллером памяти. Контора вернула технологическое лидерство и рост SSG прекратился. Однако, этот кризис, кажется, научил интеловое начальство слушать не только маркетологов кричавших «Gigahertzs sell themselves!», но и скромных «тружеников клавиатуры», говоривших, что legacy software в одночасье не переделаешь.

Впрочем, подобные «минуты славы» выпадали на долю SSG довольно редко. Netburst был первым золотым веком, сейчас мы, возможно, наблюдаем второй, связанный с технологическим отставанием Интел от AMD и NVidia. В остальное же время софтовикам приходилось иметь дело с неприятной дилеммой. Вроде бы польза от вложений в экосистему программного обеспечения есть, но как можно это доказать? В бесплодных попытках измерить собственную значимость мы плодили всевозможные типы отчетов и индикаторов. Их у нас было больше, чем у железячников. И иногда мы сами в них тонули. С этим у меня связано несколько веселых историй.

Трехгрошовая опера или сага о 9 долларах

Одну памятную попытку предприняли руководители Developer Products Division во главе с Биллом Сэвиджем. Они поставили перед собой амбициозную задачу — определить, как наличие инструментов разработки влияет на отпускную цену процессора. Поначалу над ними все смеялись: задача представлялась неразрешимой даже для экономистов, не говоря уже об инженерах. Вспоминали известную пословицу «Никто не сделал денег на инструментах разработки. Даже Майкрософту это не удалось» ???? Но Сэвиджа, известного своим упрямством, это не останавливало. Длительное время десять очень неглупых мужчин и женщин из его прямого подчинения пытались построить модель расчета стоимости. Я поначалу следил за их усилиями, а потом бросил, сочтя попытку бесперспективной. Но инженерную мысль не остановит даже пуля ???? Спустя полгода они вернулись и выдали вердикт: для определенной модели серверного процессора (не помню какой уже) с ценой примерно 1000$ наличие компилятора позволяет продать его на 9 долларов дороже. Ну то есть наличие компайлера повышает цену камня примерно на один процент. Это смелое заявление имело некоторый резонанс внутри конторы. Я по крайней мере внимательно ознакомился с построенной DPDшниками моделью. Не буду сильно вдаваться в детали, но предложенный ими метод показался мне оригинальным и остроумным. Некоторые предположения были конечно немного притянуты за уши, но большинство выглядело стройно и логично. Очень жалею, что этот документ был для служебного пользования и у меня не сохранился — он мог бы послужить хорошей основой для диссертации по экономике. ????

Воодушевившись, Сэвидж сделал следующее далеко идущее заявление: 1% от цены процессора Интел должен вкладывать в содержание и развитие компиляторной команды. Это, конечно, было гораздо проще сказать, чем легитимизировать. С этой целью Билл решил заручиться поддержкой Sales and Marketing Group и послал им свои расчеты. Увы, продажники в расклад не вписались. Прочитав документ, они прислали Савагу короткое резюме «Спасибо, Билл. Давно так не смеялись». ???? Мечта Сэвиджа так и осталась мечтой. А идея‑то была хорошая. ????

Важнейшие задачи менеджмента

Я в то время работал в Developer Relations Division и занимался технической поддержкой продаж в области High Performance Computing. Схема была такая: кто-то из клиентов покупал большую распределенную вычислительную систему (кластер). Обычно это были университеты, исследовательские институты и другие правительственные организации. В таких случаях объявлялся тендер и публиковался документ под названием RFP (Request for proposal). Он специфицировал желаемые физические размеры системы, вес, давление на пол, энергопотребление и тп. И среди прочего содержал набор бенчмарков, который будет использован для измерения производительности системы. Игроками в этих тендерах были OEMы (IBM, Dell, SGI, HP…), а Интел входил как субподрядчик с теми из них, кто использовал наши процессоры для построения системы. В задачу нашей команды Сompetitve Response Team (CRT) входило предоставить данные о производительности этих бенчмарков на интеловом железе и, по возможности, (не во всех сделках это разрешалось) оптимизацию их с точки зрения производительности. СRT, вероятно, ближе всех в SSG подошел к идеалу — измерить влияние софта на бизнес в честных долларах. Нас оценивали по количеству сделок, в которых мы поучаствовали, проценту выигранных и суммарной выручке. И пусть это был indirect revenue, никто в SSG близко не имел даже этого. Но сказать, что проблема отчетов и индикаторов полностью обошла нас стороной, нельзя. Их у нас тоже было выше крыши. Более того, число их все время росло, и каждый новый вызывал всеобщее возмущение.

В тот раз нам добавили новый индикатор, что‑то вроде посчитать diversity ratio в команде — отношение diversity members (latin, afroamerican, sexual minorities) к общей численности. Но даже эта пустяковая задача вызвала бурю негодования. Выразителем народного гнева в тот раз выступил Ланс Шулер.

— Доколе они будут подсыпать нам все новые и новые метрики? — вопрошал он нашего начальника Пареша Паттани. — У меня и так половина рабочего времени уходит на эти отчеты и индикаторы. — Паттани по прозвищу Царь покачал головой и ответил так:

— Все понимаю, Ланс. Но ты забываешь о важнейшей задаче менеджмента.

— Это о какой же?

— Приоритизация. Давай подумаем, что из твоих индикаторов можно деприоритизировать. Или, проще говоря, забить.

— Давай...

— Вот смотри, — начал загибать пальцы Паттани. Месячный отчет — это святое, потому что из ваших я собираю свой. Отчет по сделкам СRT тоже надо, потому что его я отправляю в SMG. Индикаторы по стратегическим вендорам программного обеспечения (ISV) с меня требует Христос. Отчет по OEM Win Rooms (по сути та же самая СRT‑ cтатистика, только разбитая по OEMам, которых мы поддерживали) Дон Харберт... — и, порассуждав в таком духе еще некоторое время, Пареш пришел к неутешительному выводу. — Получается, что все это нужно мне. А значит идет с приоритетом 1. Точнее, даже с приоритетом 0.

— Вот видишь? — торжествовал Шулер.

— Все так, Ланс, — ответствовал Паттани, — но ты забываешь о второй важнейшей задаче менеджмента.

— ??

— Делегирование. Теперь давай смотреть, что из своих индикаторов ты можешь поручить кому‑то из подчиненных. Вот мог бы ты поручить месячный отчет, скажем Резе Рахману?

— Резе? Да он там такую фигню напишет, что мне неделю краснеть придется. Нет, уж лучше сам.

— А статистику по стратегическим ISV может сделать Лео Борхес?

— Лео? Наверно, может. Только я с этим за час управляюсь, а Лео провозится целый день. Так что и тут лучше сам.

— А отчет по Dell Win Room может Нарен Наяк осилить?

— Хмм.. А это идея.

— Ну вот видишь, — теперь уже торжествовал Паттани. — Не все так уж плохо, Ланс. Иди, рисуй индикаторы по diversity… ????

Наследие Энди Гроува

Последние годы в Интел я провел, руководя разработкой VTune в Developer Products Division. Моим прямым начальником был Шринивас, который помимо VTune отвечал еще за ряд продуктов: Advisor, Inspector и тд. Шри был невысокого роста лысоватым индусом с маленькими бегающими глазами. Имидж пройдохи и жулика, видимо, прилип к нему с детства. Но это тот случай, когда внешность обманчива: Шринивас был нормальным парнем, и у меня всегда были с ним хорошие отношения. Боссом Шри был Санжив Шах, которого я почитаю наряду с Паттани одним из лучших начальников в своей карьере. Санжив обладал хорошим чувством юмора и любил пошутить, но вот шутки его далеко не всегда были безобидными.

В конце 2019 на общем собрании начальства нашей организации мы подводили итоги года по IMBO. Эти «имбосы» (Intel Management by Objectives) были придумкой третьего СEO Интел Энди Гроува. В начале года мы придумывали себе цели (objectives) а потом раз в квартал отчитывались о их выполнении. Понятно что парадигма «сам придумал — сам сделал — сам отчитался» появилась задолго до Гроува, но в Интеле ее ввел в моду именно Энди. У моей команды в том году было 8 целей, и все мы смогли достичь к концу отчетного периода. О чем Шри бодро отрапортовал Санживу.

— Прекрасно, прекрасно... — отреагировал Санжив. — А я помню, в третьем квартале у вас 7 из 8 было сделано? — Он всегда отличался хорошей памятью и вниманием к деталям.

— Да, вроде бы... — замялся Шринивас. 

Он‑то как раз в детали своих продуктов особо не лез и тонкостей таких, конечно, не помнил.

— А какой имбос вы добили в четвертом квартале?

— Cанжив, разреши я отвечу, — влез ваш покорный, чтобы разрядить обстановку. — В четвертом квартале мы сделали...

— Молчи, — оборвал меня Санжив. — Ясно, что ты знаешь. Но я хочу, чтобы ответил Шри. 

Видимо, Шринивас сумел где‑то проштрафиться перед Санживом, и тот решил устроить ему показательную выволочку.

— Эээ... Mмм...Ну... — Шринивас аж покраснел и бешено вращал глазами. А Санжив пристально смотрел на него с хитрым прищуром. Спас положение Пол Питерсон (из параллельной организации), которого я пихнул ногой под столом.

— Так это же, наверно, был Processor Trace? 

Дело в том, что это был наш единственный совместный проект с Полом. И завершился он как раз в четвертом квартале.

— Вот видишь, Шри, — усмехнулся Санжив. — Даже Пол знает. А ты — нет. Но я тебя понимаю и где‑то даже сочувствую. Как человек, который постоянно врет, ты должен помнить, что соврал, кому, где и когда. Просто чтобы не проколоться. Но удержать в голове такой объём информации практически невозможно...

Вот оказывается, в чем был смысл выволочки. Шри чуть не плакал. Мне было его искренне жаль. Но его растерянный ответ заставил меня просто зарыдать...от хохота.

— Так а что делать-то?

После этого нашу аудиторию целую минуты сотрясали раскаты исступленного истерического смеха. Наконец, отсмеявшись и утерев выступившие слезы, Санжив подытожил.

— Может, все‑таки правду говорить? Глядишь, и жизнь твоя немного легче станет...

Комментарии (42)


  1. exTvr
    13.07.2023 14:10
    +2

    В тот раз нам добавили новый индикатор, что-то вроде посчитать diversity ratio в команде – отношение diversity members (latin, afroamerican, sexual minorities) к общей численности.

    Это шесть по пятибалльной шкале.
    Спасибо, шикарный цикл статей.


  1. eton65
    13.07.2023 14:10
    +3

    Упс, а как это я пропустил такие интересные статьи?


    1. vvvphoenix Автор
      13.07.2023 14:10
      +9

      Enjoy :)


  1. vkni
    13.07.2023 14:10
    +6

    Они поставили перед собой амбициозную задачу — определить, как наличие
    инструментов разработки влияет на отпускную цену процессора.

    Нехилый у нас кризис управления... Умные люди, а ни до кого не доходит, что у единой системы нельзя определить важность отдельной части. Простейший пример — человек, у которого нельзя сказать, что важнее: голова, желудок или лёгкие.

    измерить влияние софта на бизнес в честных долларах.

    Без сопутствующего софта железки не нужны. В принципе, как ваша умная голова в отдельности от тела.


    1. avshkol
      13.07.2023 14:10

      Вообще можно оценить стоимость покупки софта у стороннего разработчика по сравнению с содержанием собственного подразделения.


      1. vkni
        13.07.2023 14:10

        Можно. Но эта оценка покажет погоду на Марсе — внешний подрядчик кардинально отличается от своего подразделения, куда можно просто подойти, где можно сформировать железячно-софтовую рабочую группу. Разница по скорости взаимодействия просто на порядки.

        Но именно так и делают, да. Это и есть кризис управления.


      1. vvvphoenix Автор
        13.07.2023 14:10
        +4

        Тоже не особо канает. Для того чтобы хорошо сделать софтину надо было разбираться в некоторых интимный деталях архитектуры. А их на сторону предпочитали не отдавать...


        1. vkni
          13.07.2023 14:10
          +1

          И правильно. Скажем, инструкция FJCVTZS у ARM, которая помогает выполнять JavaScript быстрее, требует определённого взаимодействия железячников и программистов.

          Или, вот, у Петра Советова недавно был доклад по разработке спецпроцессоров, когда компиляторщик и железячник работают в единой рабочей группе.


    1. Spartak13
      13.07.2023 14:10
      +2

      Это логичное желание бизнеса - что потеряем, если закроем?
      Тот же пример с человеком - можно и руку отрезать, жить будет. Еще можно ноги почикать, и посадить за сидячую работу. <Сарказм> Еще и на брюках экономия </Сарказм>
      Но бизнес не догадывается, что может быть нелинейная зависимость, т.е. не просто x+y, а x + x*y, и проценты влияния здесь полезны только в моменте, при всех прочих постоянных. А такого в реальной жизни вряд ли можно найти


      1. vkni
        13.07.2023 14:10
        +1

        может быть нелинейная зависимость

        Это называется системный эффект или синергия. Проблема в том, что бизнес ещё и со временем не умеет работать — отрезание руки часто даёт эффект не сразу.


      1. ioccy
        13.07.2023 14:10
        +1

        В бизнесе (кстати, "бизнес" это что? Это куча разнородных подразделений) тоже не инфузории-туфельки работают. Обо всем "в бизнесе" догадываются. Именно благодаря "бизнесу" контора не идет по миру и платит зарплаты сотрудникам.


    1. thevlad
      13.07.2023 14:10
      +1

      Есть Intel Compiler(icc), в начале нулевых имел некоторую популярность, за счет того, что практически первым умел в авто векторизацию(simd/sse), и давал +10/20% на тяжелом коде, по сравнению с msvc/gcc. Но с каждым годом gcc становился лучше, а так же появился и llvm. Со временем отрыв icc стал около нулевым так же как и его популярность. А деньги в разработку думаю были вложены не малые.

      Лично я знаю только три инструмента от intel, которые более менее получили распространение: это MKL (Math Kernel Library ), VTune (микропрофайлер) и OpenVINO (инференс нейросеток на CPU). Да и наверное за коммиты в Linux можно сказать спасибо. И критичного из этого пожалуй только VTune, без микропрофайлера, делать низкоуровневые микро оптимизации, разработчикам совсем тяжко.


      1. vkni
        13.07.2023 14:10
        +1

        А драйвера — нет?

        Но с каждым годом gcc становился лучше

        Интересно, почему... :-)


        1. vvvphoenix Автор
          13.07.2023 14:10
          +5

          Интел в него прям конкретно вкладывался


          1. vkni
            13.07.2023 14:10
            +1

            Это был риторический вопрос. :-) Очевидно же, что кроме Интел никто это сделать (не в теории, а на практике) не мог.

            Очень правильное мероприятие, надо сказать.


            1. thevlad
              13.07.2023 14:10

              В современных компиляторах, большинство оптимизаций больше всего добрасывающих, имеют обобщенный характер, завязанных на конкретный процессор оптимизаций там совсем немного.

              https://gcc.gnu.org/onlinedocs/gccint/Passes.html

              https://gcc.gnu.org/onlinedocs/gccint/RTL-passes.html


              1. thevlad
                13.07.2023 14:10
                +2

                Да и главный легко проверяемый аргумент - те же самые оптимизации, примерно столько же добрасывали и на AMD, за исключением случаев когда intel напрямую решала стрелять по ногам конкурента. (широко известные случаи с фильтрацией по CPUID)


            1. Gumanoid
              13.07.2023 14:10
              +3

              Очень много для поддержки x86 в GCC сделал Uros Bizjak. Он писал патчи задолго до того как интел обратил внимание на опен сорс, затем ревьювил патчи интеловских инженеров (в т.ч. мои), и продолжает этим заниматься по сей день. Но от интела он вообще ничего не получил за это, насколько я слышал.


        1. thevlad
          13.07.2023 14:10

          Драйвера чего?


          1. vkni
            13.07.2023 14:10

            Например периферии.


            1. thevlad
              13.07.2023 14:10

              Какой периферии? Которая была в южном мосте? Там большинство интерфейсов стандартные плюс-минус. Уж не знаю, какой вклад внесла именно intel в написание драйверов и коммиты в ядро linux, или все обошлось обычным раскрытием документации с "барского плеча".


              1. gxcreator
                13.07.2023 14:10
                +10


      1. event1
        13.07.2023 14:10
        +1

        ещё DPDK и OpenCV


    1. Hardcoin
      13.07.2023 14:10

      Простейший пример — человек, у которого нельзя сказать, что важнее: голова, желудок или лёгкие

      А что вам мешает это определить? Психологический барьер, "ведь это же человек"? Желудок явно на последнем месте в списке, без него живут полноценную жизнь (с ограниченнием по питанию)


      1. vkni
        13.07.2023 14:10

        Отдел фентези на другом этаже.


        1. Hardcoin
          13.07.2023 14:10
          +2

          Воинствующее невежество? Гуглите "гастрэктомия".


    1. GBR-613
      13.07.2023 14:10
      +1

      Вот многие люди смеются по поводу того, что в Союзе был по причине зарегулируемости полный бардак и кризис управления. Правильно смеются. Проблема в том, что в любой слишком крупной компании творится такой же бардак и кризис управления. И такое же засилие идеологии. И слишком много внутренней политики в процессе принятия решений. Просто весь Союз был одной большой фирмой.


      1. vkni
        13.07.2023 14:10
        -2

        Просто весь Союз был одной большой фирмой.

        Да, только фирмой, которая воспроизводила свою рабочую силу (обычные фирмы паразитируют на обществе и государстве). У этого, кстати, были чудовищные плюсы, много перебивающие минусы, но народ этих плюсов не видит.


    1. event1
      13.07.2023 14:10
      +2

      Умные люди, а ни до кого не доходит, что у единой системы нельзя определить важность отдельной части

      Нельзя, но надо. Потому что бюджеты. И потому что понять весь бизнес такой огромной махины со всеми взаимосвязями одной головой совершенно не возможно. Приходится придумывать модели. Дело не в уме, а в том что организация большая.


      1. vkni
        13.07.2023 14:10

        Нет. Не по этому, а потому, что в менеджерской иерархии жёсткая конкуренция, нас с вами там съедят и не поморщятся.

        А так бюджет пилится достаточно легко. Бизнес абстрагируется и т.д. Просто для этого нужны хорошие данные и доверие. Если это есть, то можно вообще алгоритм написать, методом динамического программирования, определяющий оптимальный план.

        А там царство лжи, как вы можете увидеть по статьям ув. Автора, тысячу плюсов ему в карму и хорошего здоровья. Вы же не можете доверять условному Васе-менеджеру, который божится, что ему для поддержки системы нужны какие-то деньги, а для нового проекта хватит полугода. Он же наверняка врёт по той или иной причине.


        1. event1
          13.07.2023 14:10

          Нет. Не по этому, а потому, что в менеджерской иерархии жёсткая конкуренция

          Да, и это делает задачу адекватного бюджетирования ещё сложнее. Вместо того, чтобы делом заниматься люди письками меряются.

          А так бюджет пилится достаточно легко. Бизнес абстрагируется и т.д. Просто для этого нужны хорошие данные и доверие.

          И как по хорошим данным можно понять, что подразделение разрабатывающее, например, компилятор пора закрыть? Если его бесплатно раздают. Или что для поддержки ядра линукса можно уполовинить бюджет? Или, наоборот, надо удвоить?

          А там царство лжи, как вы можете увидеть по статьям ув. Автора

          честно говоря, я ничего такого не заметил.

          тысячу плюсов ему в карму и хорошего здоровья

          истинно так!

          Вы же не можете доверять условному Васе-менеджеру, который божится, что ему для поддержки системы нужны какие-то деньги, а для нового проекта хватит полугода

          Я не могу доверять даже программисту, который божится, что для починки бага ему надо две недели. Даже если этот программист — я сам. Но это не от злокозненности, а в силу принципиальной непредсказуемости бытия.


          1. vkni
            13.07.2023 14:10

            И как по хорошим данным можно понять, что подразделение разрабатывающее, например, компилятор пора закрыть?

            Вася-программист, разрабатывающий этот компилятор, если он профи, вполне себе знает, делает ли он что-то полезное или занят просиживанием штанов. Профессионал должен знать про конкурентов. Соответственно, если он знает, что всё из icc перенесено в gcc, что нет завязанных на icc клиентов, что icc нельзя использовать в качестве стенда для новых оптимизаций => потенциал icc кончился => его можно закрыть.

            Но, сами понимаете, это опять вопрос денег, конкуренции и капитализма.

            Я не могу доверять даже программисту, который божится, что для починки бага ему надо две недели. Даже если этот программист — я сам.

            Потому, что в творческом труде есть элемент новизны => элемент риска. Значит оценивать время и трудозатраты надо несколько по-другому, нежели при рытье канавы. Это не новость — посмотрите того же Ди Марко, про медведей.

            То есть, оценка временных затрат идёт с некоторой "вероятностью", которая есть "мера уверенности". То есть, вы когда оцениваете сроки, вы говорите, что с такой-то вероятностью вы сделаете за две недели такой-то кусок сетевого графика. Собственно, весь сетевой график вашего проекта содержит эти распределения сроков, которые по мере выполнения проекта уточняются и переделываются.


            1. event1
              13.07.2023 14:10

              Вася-программист, разрабатывающий этот компилятор, если он профи, вполне себе знает, делает ли он что-то полезное или занят просиживанием штанов

              Во-первых, Петя-программист из того же отдела может иметь отличное от Васи мнение. А во-вторых (и в-главных), там речь про распределение бюджета, а не про техническую полезность той или иной деятельности. Если разработки Васи приносят мало прибыли, то его бюджет надо перераспределить туда где прибыли будет больше. Вместе с самим Васей.


              1. vkni
                13.07.2023 14:10

                А во-вторых (и в-главных), там речь про распределение бюджета, а не про техническую полезность той или иной деятельности. Если разработки Васи приносят мало прибыли, то его бюджет надо перераспределить туда где прибыли будет больше. Вместе с самим Васей.

                Эта лошадь уже сдохла. Мы с вами, собственно, обсуждаем то, как выходить из последствий. Конкуренция, прибыль — они не работают.


          1. vkni
            13.07.2023 14:10

            честно говоря, я ничего такого не заметил.

            Вы просто не хотите этого замечать. Вам набросать цитат?


  1. izard
    13.07.2023 14:10

    "пусть это был indirect revenue, никто в SSG близко не имел даже этого"

    У Application Engineer'ов была такая же метрика. Мой личный счет за 12 лет - 90 миллионов revenue (в-основном Xeon'ы) в design win's когда удалось решить проблему с производительностью, из-за которой клиент точно бы выбрал процессор конкурента. К сожалению, в SSG/DRD основной метрикой для инженеров был architecture feedback, а не деньги.


    1. vvvphoenix Автор
      13.07.2023 14:10
      +2

      Мне трудно выбрать из этих двух, что важнее. Но наверно ты прав, Саш...


      1. izard
        13.07.2023 14:10
        +1

        Для конторы, конечно, architecture feedback важнее. Отличная идея же - AE находят в поле идеи, какие фичи помогут их клиентам в будущем, это где-то консолидируется, и в новых продуктах появляются оптимизации, помогающие настоящим классам ворклоадов, а не спекцпу. Но для решения конкретной проблемы с производительностью надо просто подумать и поработать, а для architecture feedback надо очень много взаимодействовать с разными группами внутри Интела.


      1. vkni
        13.07.2023 14:10

        Опять та же самая дилемма — голова или шея... Оба важны.


  1. TitovVN1974
    13.07.2023 14:10
    +2

    Старый Intel Fortran 7.0 считал в 5 раз быстрее чем Compaq Visual Fortran на Pentium IV (векторизация и префетч)


  1. medstrax
    13.07.2023 14:10
    +2

    У меня одного впечатление, что уроженцев Индии в Интел ну... очень много?