Насколько мне известно, ключевая вещь там — да, либо андерфил, либо крепление по углам, между тем эти меры так себе (и вы тоже на это обращали внимание в одной из статей). То есть если бы были еще и PCSB, то было бы совсем красиво, но об их применении в коммерческих изделиях лично я вообще ничего не слышал. Ну, за исключением LGA-корпусов, где вы сами можете паять, как вам угодно, это производителю не важно.
Ну хз вообще-то, мы как-то для научных целей покупали металлизированные шарики из полиэтилена — копейки стоят в пересчете на шарик.
И потом, я ж говорю не совсем про все отрасли, а, например, про automotive (которая тоже массовая и дешевая, но все-таки уровнем повыше, чем электрочайники). Ну вот реально не хочется на полной скорости оказаться без brake-by-wire из-за перепадов температуры и тряски (а их там дай Боже, не хуже, чем в космосе).
Ну, статья про MCS например от 2011 года. Можно конечно сказать, что в НАСА сидят некрофилы, но в целом информация актуальная.
И хотя процитированный вами вывод содержит долю категоричности, но вообще автор же выше сам написал, что, дескать, можно и пластик, но при вот таких вот условиях и с такими вот ограничениями, а если не хотите конопатить себе мозги или боитесь за АМС-миссию в дальнем космосе, то будьте любезны CGA+MCS+LTCC. Разумеется упомянутые в комментариях к предыдущей статье решения других космических агентств говорят о наличии интереса к пластику, но там тоже, знаете, не истина в последней инстанции. Ну и давайте уже будем объективны — керамика не стоит практически ничего в сравнении с остальными затратами при разработке и производстве космических приборов, изделия из керамики стоят чуть дороже, чем ничто, платы из керамики также недороги, так что за чем собственно дело?
Я вот чего не могу понять — почему PCSB-выводы не заняли значимой ниши? Ведь это, по сути, уже совсем не припойный шарик, а вполне себе припаянный к РСВ медный вывод (просто со стороны корпуса он тоже припаян, а не приделан «намертво»), то есть это заметно лучшее решение, но при этом не сильно уж дорогое. Пусть для космоса нашли лучшее решение (MCS), но почему не использовать в коммерческих изделиях? Проблема ведь остро стоит, некоторые люди в интернете пишут, что якобы для любой BGA-микросхемы можно заказать исполнение со свинцовыми шариками (хотя бы из Sn63Pb37), но это же вранье какое-то, для многих микросхем вообще никакого выбора нет, только бессвинцовые выводы (еще хорошо, если флип-чип чипа на чип-кэрриер выполнен традиционным способом). Реболлинг — так себе затея, и вот если бы хотя бы, например, для automotive выпускались корпуса с PCSB-выводами, это же как было бы здорово.
Спасибо (искренне) автору за статью и Терехову за рассказы, только рассказы какие-то уж больно прохладные. Особенно трудно было руку от лица оторвать в истории про "трёх парней, пиплайн и драку в коридоре ИТМиВТ".
И ещё — этим мемуарам, как я вижу, не удается избежать частой проблемы советских мемуаров о становлении чего-то секретного. А именно "вот это вот все сделали мы, и вот это тоже", и хрен проверишь, все же секретное. Один мой дальний родственник, не первое десятилетие пенсионер, секретный трудовой путь которого более-менее известен родственникам, регулярно рассказывает малознакомым людям о причастности буквально ко всему. Например он в строительстве "Восточного" принимал участие, конечно не лично, но с ним все советовались, звонили по ночам, ну и т.д.
В моем сообщении «он» — программист. На ассемблере.
Очевидно для того чтобы сделать код быстрее. Не точнее а быстрее. Точность же будет одной и той же.
Не обязательно. Вот вы написали некий код, переменные таки объявили как long double, они легли в регистры, но порядок вычислений был один, стало быть и результат один. А потом вы написали аналогичный по сути алгоритм напрямую, и ради каких-то соображений об эффективности сделали другой порядок вычислений. Результат будем другим, хотя это все те же лонгдаблы (не углубляясь в то, когда это различие в результатах вообще станет значимым).
На ассемблере можно было только ускорить код, не более того
Ну, не только. В зависимости от того, как в целях оптимизации разложены переменные по регистрам и как сделан алгоритм, пересылок в память (с округлением, если оно нужно) могло быть больше или меньше. Результат при этом конечно будет отличаться (если его эквивалентность — на самоцель, например).
Неожиданностей может быть меньше только если можно гарантировать какой-то новый детерминированных их порядок — к примеру, полное отсутствие округлений
И именно на это уповает автор поста.
Но для подавляющего большинства задач ожидать что результаты будут все время храниться в quire-регистрах нереально. Время от времени их понадобится выгружать в память и тут сразу возникнет вопрос — как гарантировать что выгрузки (и возникающие округления) будут детерминированными.
Ну выше как раз и говорится о том, что надо больше регистров богу регистров. И конечно вы правы, что когда-то их не хватит (да и за имеющиеся придется неслабо так заплатить), и тогда мы вернемся на круги своя.
У long double это хотя бы решается тем что ldouble таки туда выгружабелен, но если у quire такой возможности не будет, то компилятор просто не сможет не делать округления столкнувшись с нехваткой регистров.
И в конечном итоге потребуется некая оптимизация (коей по сути и является 64-битный Posit), чтобы все-таки и выгружать, и точность при округлении терять поменьше. То есть… ну, да, очередной long double получится, только более точный. Об этом и говорят те комментаторы, которые пишут про «те же яйца, только в профиль».
Вам не надо использовать ассемблер чтобы работать со стеком x87. Пишите long double и компилятор все отлично сам соберет
Речь не шла о том, что работать со стеком х87 можно только на ассемблере, но для эффективного его использования — людям приходилось. Как-то вот не всегда компилятор мог удачно расположить переменные в регистрах. Поэтому среди прочего поднимается вопрос о том, что в Quire должно быть побольше регистров.
Компилятор не имеет права выполнять описанную оптимизацию без явного одобрения программиста, т.к. это приводит к непредсказуемому результату
Вот это и есть предмет обсуждения, начатого этим постом. Типа (в определенных случаях) описанных неожиданностей с новым форматом должно стать меньше.
Вот чертовщина какая-то, ей Богу: все, что вы пишете, я понимаю по сути (банальные вещи потому что), но какую в точности генеральную идею вы хотите высказать — не могу понять. :(
Единственная фраза, за которую я могу ухватиться — "если long double не используют то quire тоже не будут". Вы таким образом хотите сказать, что идея вычислений на увеличенных регистрах на самом деле не имеет соответствующей success story и стало быть Quire тоже не взлетит? Я правильно вас понял? Если да, то я должен заметить: вы свое утверждение базируете на постулате о том, что во-первых никто не юзает long double, и во-вторых компилятор С/С++ ничего не может сделать с предложенным ему кодом в части перестановки операций (и не может даже в том числе убрать «лишние» пересылки в память с соответствующим округлением). И если с первым я просто не согласен (ну, да, кому не надо — те не используют, много кто и double не использует), то второе — вопрос оптимизации. Повторюсь, немало вещей с использованием FPU-стека прямо на ассемблере херачилось, ну, потому что так надо, и получаемые результаты (в том числе эффекты округления) принимал на себя программист. Если мы постулируем, что создать достаточно умный компилятор невозможно (ну или мы не хотим этого во имя сохранения целостности некоторых базовых вещей), а кроме того любой программист с удовольствием пренебрежет такой возможностью в пользу более простого и переносимого кода, то тогда конечно и Posit/Quire не взлетит. Но это аргумент, знаете ли, из серии «и это тоже делать не надо, не взлетит, слишком революционно», так можно отказ от любых новшеств обосновать.
Мы выше обсуждали как раз тот факт, что если писать на ассемблере (или если есть умный компилятор), то некоторые вычисления могут делаться без выгрузки промежуточных результатов в память, при этом точность каждого числа в стеке FPU x87 — тот самый long double. И это многолетняя практика, следовательно идея длинных регистров Quire — по сути лишь совершенствование этой практики, кажется вполне эффективное (с чем не все выше согласны). С чем из написанного вы не согласны?
А иначе действительно смысла нет в регистрах большей точности, если при каждой операции операнды из регистров преобразуются обратно в память в меньшую точность
Э, ну нет. Многие классические задачки отлично целиком помещаются на FPU-стеке, в пределах классических восьми регистров расширенной точности, и когда наружу в переупакованном виде выходит только результат — это хорошо (хотя само по себе такое программирование может быть изунряющим). Так что сама по себе идея правильная, и если регистров сделать больше, а компилятор научить их использовать, то вообще-то можно отлично жить.
Ну, тут дело как раз в том, что у инвара очень маленький КТЛР, и я хз у какого текстолита он может быть таким же (если про керамику не говорить, но и там все не так легко). Традиционно же все пляшут вокруг семерки — кремний, ковар, стекло, некоторые стали, идти ниже обычно нет смысла.
Дадада, то же самое хотел написать. ФПУ-стек 8087 состоит из восьми 80-битных регистров, которые потом ужимаются до 32/64. Так что по сути речь про ещё большее расширение (причем сразу так радикально, без потери точности) и другой формат упаковки. И вот в первом пункте есть проблема....
И потом, я ж говорю не совсем про все отрасли, а, например, про automotive (которая тоже массовая и дешевая, но все-таки уровнем повыше, чем электрочайники). Ну вот реально не хочется на полной скорости оказаться без brake-by-wire из-за перепадов температуры и тряски (а их там дай Боже, не хуже, чем в космосе).
И хотя процитированный вами вывод содержит долю категоричности, но вообще автор же выше сам написал, что, дескать, можно и пластик, но при вот таких вот условиях и с такими вот ограничениями, а если не хотите конопатить себе мозги или боитесь за АМС-миссию в дальнем космосе, то будьте любезны CGA+MCS+LTCC. Разумеется упомянутые в комментариях к предыдущей статье решения других космических агентств говорят о наличии интереса к пластику, но там тоже, знаете, не истина в последней инстанции. Ну и давайте уже будем объективны — керамика не стоит практически ничего в сравнении с остальными затратами при разработке и производстве космических приборов, изделия из керамики стоят чуть дороже, чем ничто, платы из керамики также недороги, так что за чем собственно дело?
Совершенно верно. Ничего сверхнормативного Эльбрус не требовал, разве что много электричества ел. Все остальное — норма жизни.
А уж рассказы про немедленные искры — просто трололо.
Вы какую-то чушь написали. Нанимают и ещё как.
К слову, некоторые уважаемые софтверные компании тоже имеют буквально одного тестера.
Спасибо (искренне) автору за статью и Терехову за рассказы, только рассказы какие-то уж больно прохладные. Особенно трудно было руку от лица оторвать в истории про "трёх парней, пиплайн и драку в коридоре ИТМиВТ".
И ещё — этим мемуарам, как я вижу, не удается избежать частой проблемы советских мемуаров о становлении чего-то секретного. А именно "вот это вот все сделали мы, и вот это тоже", и хрен проверишь, все же секретное. Один мой дальний родственник, не первое десятилетие пенсионер, секретный трудовой путь которого более-менее известен родственникам, регулярно рассказывает малознакомым людям о причастности буквально ко всему. Например он в строительстве "Восточного" принимал участие, конечно не лично, но с ним все советовались, звонили по ночам, ну и т.д.
Я вам скажу как чертановец — местные его называют Чертановский ЛЕжачий Небоскреб, а точнее обычно используют понятно какую аббревиатуру.
"Километр дураков" — это все итмивтовские обидки. И похуже были названия, типа "Дворца спорта" с тем же намеком.
В моем сообщении «он» — программист. На ассемблере.
Не обязательно. Вот вы написали некий код, переменные таки объявили как long double, они легли в регистры, но порядок вычислений был один, стало быть и результат один. А потом вы написали аналогичный по сути алгоритм напрямую, и ради каких-то соображений об эффективности сделали другой порядок вычислений. Результат будем другим, хотя это все те же лонгдаблы (не углубляясь в то, когда это различие в результатах вообще станет значимым).
Да, да, да — если там long double. Выше уже сто раз про это написали друг другу )))
Нет, не будет, банально потому, что он порядок вычислений на ассемблере по-другому сделает. Иначе зачем бы он вообще полез в ассемблер?
Конечно. Но в обычной жизни оно сопровождается округлением (с 80 бит регистра до 64/32 бит в памяти). Я об этом говорил.
Я же говорил о сравнении сгенерированного компилятором и написанного урками ассемблерного кода.
Ну, не только. В зависимости от того, как в целях оптимизации разложены переменные по регистрам и как сделан алгоритм, пересылок в память (с округлением, если оно нужно) могло быть больше или меньше. Результат при этом конечно будет отличаться (если его эквивалентность — на самоцель, например).
И именно на это уповает автор поста.
Ну выше как раз и говорится о том, что надо больше регистров богу регистров. И конечно вы правы, что когда-то их не хватит (да и за имеющиеся придется неслабо так заплатить), и тогда мы вернемся на круги своя.
И в конечном итоге потребуется некая оптимизация (коей по сути и является 64-битный Posit), чтобы все-таки и выгружать, и точность при округлении терять поменьше. То есть… ну, да, очередной long double получится, только более точный. Об этом и говорят те комментаторы, которые пишут про «те же яйца, только в профиль».
Речь не шла о том, что работать со стеком х87 можно только на ассемблере, но для эффективного его использования — людям приходилось. Как-то вот не всегда компилятор мог удачно расположить переменные в регистрах. Поэтому среди прочего поднимается вопрос о том, что в Quire должно быть побольше регистров.
Вот это и есть предмет обсуждения, начатого этим постом. Типа (в определенных случаях) описанных неожиданностей с новым форматом должно стать меньше.
Единственная фраза, за которую я могу ухватиться — "если long double не используют то quire тоже не будут". Вы таким образом хотите сказать, что идея вычислений на увеличенных регистрах на самом деле не имеет соответствующей success story и стало быть Quire тоже не взлетит? Я правильно вас понял? Если да, то я должен заметить: вы свое утверждение базируете на постулате о том, что во-первых никто не юзает long double, и во-вторых компилятор С/С++ ничего не может сделать с предложенным ему кодом в части перестановки операций (и не может даже в том числе убрать «лишние» пересылки в память с соответствующим округлением). И если с первым я просто не согласен (ну, да, кому не надо — те не используют, много кто и double не использует), то второе — вопрос оптимизации. Повторюсь, немало вещей с использованием FPU-стека прямо на ассемблере херачилось, ну, потому что так надо, и получаемые результаты (в том числе эффекты округления) принимал на себя программист. Если мы постулируем, что создать достаточно умный компилятор невозможно (ну или мы не хотим этого во имя сохранения целостности некоторых базовых вещей), а кроме того любой программист с удовольствием пренебрежет такой возможностью в пользу более простого и переносимого кода, то тогда конечно и Posit/Quire не взлетит. Но это аргумент, знаете ли, из серии «и это тоже делать не надо, не взлетит, слишком революционно», так можно отказ от любых новшеств обосновать.
Мы выше обсуждали как раз тот факт, что если писать на ассемблере (или если есть умный компилятор), то некоторые вычисления могут делаться без выгрузки промежуточных результатов в память, при этом точность каждого числа в стеке FPU x87 — тот самый long double. И это многолетняя практика, следовательно идея длинных регистров Quire — по сути лишь совершенствование этой практики, кажется вполне эффективное (с чем не все выше согласны). С чем из написанного вы не согласны?
Э, ну нет. Многие классические задачки отлично целиком помещаются на FPU-стеке, в пределах классических восьми регистров расширенной точности, и когда наружу в переупакованном виде выходит только результат — это хорошо (хотя само по себе такое программирование может быть изунряющим). Так что сама по себе идея правильная, и если регистров сделать больше, а компилятор научить их использовать, то вообще-то можно отлично жить.
Дадада, то же самое хотел написать. ФПУ-стек 8087 состоит из восьми 80-битных регистров, которые потом ужимаются до 32/64. Так что по сути речь про ещё большее расширение (причем сразу так радикально, без потери точности) и другой формат упаковки. И вот в первом пункте есть проблема....