все дальнейшие наработки других компаний по этой фиче будут также ей доступны, причём сразу.
Кто то где то пытается продать ядро Linux и обязан вернуть изменения? Обычно свои изменения возвращают просто потому, что сихронизация изменений с чужим кодом это время и деньги. А если код не даёт конкурентного преимущества то в чём смысл им его зажимать? Это чистый убыток. А если преимущества он таки даёт, то для ядра пишутся обёртки, позволяющие важному закрытому коду легко прилинковываться.
Вот если инициатива действительно пройдёт, тогда и посмотрим, сколько крыс сбежит с тонущего корабля.
Для NVidia ещё есть ЦОДы, но кроме CUDA там быть ничего не должно, иначе оно может замедлить CUDA, то есть растрачивать потенциал железа. А если сервер нужен только под CUDA, то зачем ему огромный Linux?
Виртуальные методы не выкидываются никогда, даже если нет ни единого их вызова. Так же естественно подключаются все методы которые они используют и все виртуальные методы созданных объектов и т.д. Если в функции будет условный блок, которой не будет вызван никогда, он как правило всё равно будет засчитан, потому, что компилятор не сможет оптимизировать это.
Пример заставляющий VC++ генерировать большой бинарник без необходимости
//ни один другой объектный файл не увидит эту функцию
static int func() {
// и этот массив тоже
// собственно он будет вырезан компилятором, если не вызвать эту процедуру
const static char arr[30 * 1024 * 1024] = { 50 };
int retval = 0;
// используем только пять первых байт, вероятность доступа к остальным 0%
for (int i = 0; i < 5; i++)
retval += arr[i];
// очевидно, что процедура вернёт 250
return retval;
}
int main()
{
printf("%d\n", func());
}
Чего по факту не происходит. Исходят из того, что раз оно популярно то и оптимизировать незачем, лучше потратить деньги на новые фичи из за которых будет лагать ещё больше.
Эта цитата выдрана из контекста.
Полная цитата
Another important aspect of program quality is the efficiency with which the computer's resources are actually being used. I am sorry to say that many people nowadays are condemning program efficiency, telling us that it is in bad taste. The reason for this is that we are now experiencing a reaction from the time when efficiency was the only reputable criterion of goodness, and programmers in the past have tended to be so preoccupied with efficiency that they have produced needlessly complicated code; the result of this unnecessary complexity has been that net efficiency has gone down, due to difficulties of debugging and maintenance.
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
We shouldn't be penny wise and pound foolish, nor should we always think of efficiency in terms of so many percent gained or lost in total running time or space. When we buy a car, many of us are almost oblivious to a difference of $50 or $100 in its price, while we might make a special trip to a particular store in order to buy a 50 cent item for only 25 cents. My point is that there is a time and place for efficiency; I have discussed its proper role in my paper on structured programming, which appears in the current issue of Computing Surveys
Не стоит оптимизировать код вообще, если это в конечно счёте даст процент разницы. Но когда речь про изменение производительности в разы, то не оптимизировать крайне глупо!
За последние 10 лет производительность одного ядра и выросла примерно в 2 раза. Дальше производительность растёт только если программист осилил многопоточность.
Он может их не брать только если на 100% уверен, что условие их вызывающее не выполнится никогда. Беда в том, что программы так разжирели, что компилятор не может вычислить все возможные состояния программы. Соответственно тянет всё, что указано в коде. А алгоритмы позволяют оптимизировать только узкие места, но у современной программы, весь её код работает одинаково медленно. А ещё благодаря ООП подходу объекты инициализируют другие объекты, которые могут лезть к диску или сети. А результат окажется абсолютно ненужен!
USB-C это НЕ USB. Он просто отдаёт часть контактов для передачи DisplayPort/HDMI. В случае с HDMI ещё остаются свободные контакты для USB 3.1. Работа переходника соответственно заключается в том, чтобы договорится с хостом и перекоммутировать контакты. И никакого преобразования изображения не происходит вообще.
Работодатель как правило технически безграмотен. Откуда у него могут браться технические идеи и способы оценки результата? Он просто доверяет друзьям или известному специалисту. Вот нам тут и представляют историю успеха такого "специалиста".
Потому что деньги платят не за знание инструментов, а за участие в создании дохода компании.
Нет, платят за веру в приумножение своих вложений с максимально возможным коэффициентом. Людям и воздух можно продавать, пока они верят, что выгодно тратят деньги. Но разводить людей на деньги это совсем не технический навык.
Не обязательно менять всю систему. Есть удлинители pci-e, так, что тут всё скорее зависит от самих видеокарт и корпуса. Хотя их можно вообще выкинуть из корпуса и будет дополнительная коробочка на системном блоке.
Вы мыслите по ноутбучному. Шумные они от того, что пытаются продуть огромным количеством воздуха в узенькую щель, которая очень быстро забивается пылью. А видеокартам нужны свои просторные башни и вентиляторы соответствующего размера. Которые и будут дуть наружу. Естественно всё это не влезет в 2 pci слота. Но производители не горят желанием увеличивать габариты.
Очевидно, что это финальная сборка, ведь никакие иностранцы не будут производить никаких дальнейших манипуляций с сервером. Главное, чтобы блейд не считался тем самым российским продуктом.
Только вот для достижения этих 30% российскости довольно просто и нет необходимости заморачиваться с производством радио-электронных блоков. Достаточно, чтобы системный софт считался российским и чтобы финальная сборка производилась в России. Это даст целых 40% по существующей методике подсчёта.
Загляните в электрический чайник на раннем этапе. Видите огромные пузыри пара? Если нет, то значит его мощности недостаточно, чтобы нагреть пластину до 100 градусов. То есть естественной циркуляции воды вполне хватает, чтобы её охладить. В принципе если поставить на процессор стакан с медным дном и залить в него этанол, то он будет прекрасно работать пока большая часть этанола не выкипит. Но обычно такой фокус проделывают с жидким азотом.
А вот тут уже у вас противоречие: если штука, которую вы делаете нужна людям, почему это не радостно?
У каждого человека своё понимание нужности. Возьмите в руки пачку денег и прочувствуйте счастье, что они дарят. Можете? Я нет. Соответственно не смогу сострадать желанию получить побольше денег.
Конечно. Теория коммунизма строится на том, что из за роста эффективности труда реализовать базовые потребности всех людей, плёвое дело. А вот капитализм должен придумывать, как заставить всех работать до потери пульса, а затем потратить заработанное. Что обычно приводит к росту цен, социальному расслоению и периодическим взрывом экономических пузырей.
Начнем с того, что альтруистические отношения — химера. Под ними лежит потребность в близости.
Вот и корень нашего противоречия. Альтруизм это форма сострадания, если Вам кажется, что другие испытывают положительные эмоции от Вашего кода, то сами получаете те же эмоции, как будто Вы его делали для себя. И зачастую эмоции эти приходят в умноженном виде. Ясное дело, что свистоперделка, которая с точки зрения продажников принесёт им бабла, никогда не даст положительный эмоциональный отклик при разработке. И никакие деньги тут не помогут.
Вот если инициатива действительно пройдёт, тогда и посмотрим, сколько крыс сбежит с тонущего корабля.
Эта цитата выдрана из контекста.
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
We shouldn't be penny wise and pound foolish, nor should we always think of efficiency in terms of so many percent gained or lost in total running time or space. When we buy a car, many of us are almost oblivious to a difference of $50 or $100 in its price, while we might make a special trip to a particular store in order to buy a 50 cent item for only 25 cents. My point is that there is a time and place for efficiency; I have discussed its proper role in my paper on structured programming, which appears in the current issue of Computing Surveys
Нет, платят за веру в приумножение своих вложений с максимально возможным коэффициентом. Людям и воздух можно продавать, пока они верят, что выгодно тратят деньги. Но разводить людей на деньги это совсем не технический навык.