Программирование для математиков: класс Polynomial

[photon]

Munin в сообщении #1386177 писал(а):

Согласен. Но и сами сферы можно оценить по, грубо говоря, объёму рынка вакансий.

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

-- Fri Apr 05, 2019 17:43:18 --

realeugene в сообщении #1386178 писал(а):

Кнут большой любитель микрооптимизированных алгоритмов.

Кнут, поставленный в начало предложения, оставляет возможность для разночтений

[realeugene]

photon в сообщении #1386182 писал(а):

Кнут, поставленный в начало предложения, оставляет возможность для разночтений

Я порку нерадивых программистов не подразумевал.

[Munin]

realeugene в сообщении #1386178 писал(а):

Кнут большой любитель микрооптимизированных алгоритмов. :mrgreen:

Это в какую эпоху было. Он даже 6-битовые байты застал.

photon в сообщении #1386182 писал(а):

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

Согласен с каждым предложением.

[Geen]

Надо ещё различать оптимизацию на уровне кода и на уровне алгоритма. Вторую надо делать всегда/с самого начала (ИМХО).

[Munin]

Geen
Тут это различие с самого начала и назвали.

[realeugene]

Munin в сообщении #1386190 писал(а):

Это в какую эпоху было. Он даже 6-битовые байты застал.

Последний том 4A его Искусства программирования был издан в 2011-м. Например, алгоритмы синтеза бинарных деревьев решений в нём головоломные именно из-за микрооптимизаций. Всё, чтобы сэкономить лишний указатель на узел. А в электронном препринте 5C тома 4B, между прочим, напечатана дата 2 апреля 2019 года. И в нём 268 страниц. Ссылки для скачивания препринтов есть тут: https://en.wikipedia.org/wiki/The_Art_o ... rogramming Так что, Кнут и сейчас активно пишет свой учебник, несмотря на возраст.

[Munin]

Вот только все тома, боюсь, не напишет...

[Yuri Gendelman]

Munin в сообщении #1386239 писал(а):

Вот только все тома, боюсь, не напишет...

IMHO 6-й и 7-й тома можно было бы и опустить.

[Munin]

Ну вообще первоначальный план цикла на сегодняшний день не столь уж актуален. Что-то можно выбросить, что-то сильно ужать, чего-то, напротив, добавить.

[realeugene]

Ему уже 81. Боюсь, он и запланированные комбинаторные алгоритмы не напишет полностью.

Кстати, согласно инфе с Амазона, том 4B будет продаваться с 17 мая 2019 года:
https://www.amazon.com/Art-Computer-Pro ... 0201038064

PS Блин. Вот тут вот: https://www.bookdepository.com и чуть дешевле, и бесплатная доставка по всему миру, но РФ нет в списке стран, куда они доставляют книги. Китай есть, Бруней есть, Фиджи есть, Украина есть, а РФ в списке стран нет.

[eugensk]

realeugene

Чую, у сервисов типа pregrad.net наступает вторая молодость. Можете уже сейчас обратиться, они доставят.

[ozheredov]

mihaild в сообщении #1386145 писал(а):

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

Можно какой нибудь пример?

-- 30.04.2019, 05:43 --

realeugene в сообщении #1386147 писал(а):

Думаю, что в HFT это может быть разница между богатством и банкротством.

Может, для hft (если это high frequency trading) комп получше прикупить, чем возиться с копейками оптимизации производительности?

[mihaild]

ozheredov в сообщении #1390298 писал(а):

Можно какой нибудь пример?

Например если этот код работает на сотнях тысяч машин (принадлежащих одной компании). Скажем поиск гугла.
Или какие-нибудь встраиваемые устройства, где железо хилое (потому что или производится очень массово и потому берется дешевое, или устойчивое к чему-нибудь), а работать всё равно надо шустро.

ozheredov в сообщении #1390298 писал(а):

Может, для hft (если это high frequency trading) комп получше прикупить, чем возиться с копейками оптимизации производительности?

Все итак купили лучшие из существующих машин на рынке. И распараллелили, пока параллелилось. Но хочется еще быстрее (поскольку тут скорость является важным конкурентным преимуществом).

[ozheredov]

mihaild в сообщении #1390301 писал(а):

Например если этот код работает на сотнях тысяч машин (принадлежащих одной компании). Скажем поиск гугла.
Или какие-нибудь встраиваемые устройства,

И реально 2% решают, богатство или банкротство?

-- 01.05.2019, 00:12 --

mihaild в сообщении #1390301 писал(а):

Все итак купили лучшие из существующих машин на рынке

Лучшие из существующих на рынке стоят под сто миллионов рублей. Кто эти все, которые их купили (надеюсь, вы не из их числа? )

-- 01.05.2019, 00:26 --

График котировок же непрерывен в среднеквадратичном, значит по идее матожидание доходности стратегии должно гладко зависеть от времени реагирования на изменения ситуации . Или нет?

[mihaild]

ozheredov в сообщении #1390504 писал(а):

И реально 2% решают, богатство или банкротство?

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

Про HFT я знаю довольно мало, но там важно, как соотносится скорость системы и конкурентов. Если мы на каком-то классе транзакций начали стабильно работать быстрее конкурентов - то это может быть большой плюс.

Системы за сотни миллионов рублей хороши в некотором ограниченном наборе задач. В HFT нам критически важно latency - есть скажем 10мс, и нужно посчитать как можно более сложную модель за это время. При этом совершенно неважно, сколько всего мы сможем посчитать за 30мс.