>> Просто почитайте по Вашей же ссылке, что именно было сделано.
> With the release of GCC 4.8.0, the developers of the GNU Compiler Соболезную. Не осилить пару страниц, на которых перечислено то, что было модифицировано - это уже диагноз )))
> Ну так это - твои проблемы, если ты захотел в написанном на
> C интерпретируемом
> языке почему-то не использовать предоставленные в интерпретаторе типы.
Нет этого в интерпретаторе и языке. Есть модуль-wrapper в функцию на C.
> Формулировка твоей задачи - бессмысленна. Попробуй, например,
> перегрузить C++ класс, если пользоваться родительским классом - запрещено.
Родительский класс уже на C++. Могу его скопировать, если Вы настаиваете )
Все равно ограничусь только средствами C++. И именно это я прошу продемонстрировать на Python )
>>> Нам это нравится. Лучше потратить месяц машинного времени, чем времени программиста.
>> Я так понимаю, для Вас удивительно то, что код, который пишет программист,
>> выполняется не 1-2 раза за свою жизнь, а, в среднем, по пять раз на день сотней пользователей.
> Бывает, что и 1-2 раза. Во-вторых, и что?
Да, бывает. И именно в этом назначение интерпретаторов, один из них - Python. Я ровно с этого и начинал: "Кесарю - кесарево" (с)
>> Осознайте, что увеличение времени ожидания
>> результата пользователем даже на одну секунду больше при каждом использовании кода,
>> приводит к суммарным трудозатратам в человекомесяц ежегодно.
> А с чего ты решил, что реализация на питоне увеличит время ожидания
> на секунду,
> а не на миллисекунду или год? Или вовсе наоборот.
Вы говорили о месяце, я же пересчитал всего для секунды. Вам принципиально, что я взял для примера? Вас больше устроило бы то, что Ваша реализация даст результат через месяц, тогда как он нужен не позже, чем через 6 часов?
Я сам прототипы пишу на T-SQL, PL/pgsql, Perl или R. Аналитик мой предпочитает Python. Но в продуктив в любом случае попадает код на C/C++ или C#. Потому что, как я уже писал выше, даже миллисекунда потери производительности в одной функции, которая вызывается миллион раз за одину обработку приводит более чем к 15 минутам ожидания пользователями.
Это прогнозирование именно с Python и начинали. Вот только, даже за сутки на 64 ядрах не успевало посчитаться то, что сейчас считается за четыре с половиной часа на 32 ядрах. А прогноз нужен каждый день к началу рабочего дня, да еще и, желательно, с возможностью пересчета в течении рабочего дня, если что напутали в параметрах.
Давайте так. Сделайте на Python элементарный медианный фильтр окном в 5 элементов по двум миллионам временных рядов суммарной длиной три миллиарда. Причем время - uint24_t, а значение - FP24. Исходные и выходные файлы бинарные по 48 бит на элемент. 64-х битное представление не предлагать, так как лишние 6 гигабайт чтения и столько же записи тут существенны. На C это писалось минут 15. А я опубликую видео, где будет сравниваться производительность реализации моей на C и Вашей на Python на одном и том же компе под Oracle Linux. Память для этой задачи ограничена 1ГБ (без буферизации и readahead оно не жилец).
Ведь на Python быстрее писать, чем на C? Минут за 10 точно управитесь? Или питонисты только трепаться умеют и примера от Вас я не дождусь?
