АртемЪ: Нет никаких гарантий, что какая-то компания не выдаст кого-то из своих клиентов какой-то интересующейся стороне. Зато есть полная гарантия, что компания, имеющая бизнес в России, обязательно выдаст всех своих клиентов из России российским органам. Эта гарантия фактически прописана в, недавно принятом, законе.
9uvwyuwo6pqt: Сотрудничать приходится тем, кто делает деньги (в том числе) в России. Поэтому следует пользоваться услугами тех, кто не имеет в России коммерческих интересов. Об этом я, кажется, упоминал.
Нет никакого перехвата, есть, налагаемая законом, обязанность хранить всю историю вашей активности всеми площадками, на которые вы заходите через HTTPS.
dimonchik2013: Смотря на сколько требуется расширять горизонты... По сравнению с синхронным I/O в одном потоке - это, конечно, будет прорыв. Но асинхронный I/O + lxml в том же (одном) потоке нагрузит только одно ядро (и упрется в него) на хорошем гигабитном канале при достаточно сложной структуре извлекаемых документов.
Serhiy Romanov: Тут первое, что необходимо сделать, это пустить сетевой ввод/вывод (requests) асинхронно. Для этого существует куча разных вариантов:
1) Использовать asyncio, например, https://stackoverflow.com/a/22414756/5485944 - этот вариант к тому же совместим с threading, то есть можно иметь по несколько короутин внутри каждого потока и по несколько таких потоков на процесс;
2) Использовать gevent, например, https://github.com/kennethreitz/grequests - этот вариант не совместим с threading, поэтому, если вычисления также требуется распараллеливать, то нужно или использовать multiprocessing с симметричными процессами по количеству ядер CPU либо один процесс под чистый ввод/вывод и один многопоточный процесс под вычисления с интерпроцессорными очередями между ними - это довольно экономичный подход в плане потребления памяти, я так часто делаю (с gevent и без него).
3) Использовать threading с большой кучей потоков и синхронным вводом/выводом. Это можно назвать классическим вариантом, самым простым в кодинге, но с известными проблемами: а) высокий расход памяти и потоков ОС; б) если количество ожидающих запросов превысит количество потоков, то CPU останется недонагруженым; в) если ввод/вывод идет слишком быстро, то при большом количестве потоков система окажется перегруженой, вся ОС может начать притормаживать.
4) Вариант (3) с отдельными вычислительными потоками (по количеству ядер CPU) и отдельными потоками ввода/вывода (в безмерном количестве), связанными друг с другом легкими инпроцессорными очередями. Этот вариант решает часть проблем (3).
Это только первое, чего я коснулся - requests. Когда эта задача будет решена, стоит переходить к распараллеливанию вычислительной нагрузки по потокам, там все еще сложнее и интереснее, там начинается борьба с GIL, об этом можно сказать еще стену текста.
Serhiy Romanov: PyPy основан на прекрасной идеи двухступенчатой компиляции с применением JIT, и я надеюсь, когда-нибудь он заменит собой CPython, но пока у него остается большая проблема с совместимостью с Numpy (основным инструментом векторных вычислений на Python, на котором завязаны много других необходимых технологий). Проект https://bitbucket.org/pypy/numpy еще слишком сырой и не готов к серьезному применению. По этой досадной причине на данный момент приходится пока отказаться от использования PyPy.
Что касается общей литературы по теме, то ее практически нет (возможно, за исключением этой книги). Сам я изучал все составляющие технологии по их собственным документациям. Укажите более конкретно, что вас интересует, возможно, я смогу предложить литературу (скорее документацию) по отдельным более узким темам.
Tsimur_S: Во-первых, при расчете даже такого простого выражения Y=2*X*X+2*X+2 на каждое арифметическое действие выделяется память под результат этого действия, то есть, если массив X занимал гигабайт, то при расчете этого выражения гигабайт памяти пять раз будет запрошен у ОС и четыре раза освобожден обратно.
Во-вторых, запись результатов вычисления в другую область памяти (вместо вычисления на месте) это крайне неэффективное использование процессорного кеша, доступ к которому может быть в разы (L2) или десятки раз (L1) быстрее чем промах из него и запись в основную RAM.
Но это все мелочи по сравнению с тем, что творит оптимизатор C/C++ над подобными выражениями, вычисляемыми в цикле. Тут включается мощнейшая внутрифункциональная оптимизация, (которая очевидно недоступна в numpy, где каждому математическому действию соответствует отдельная функция), которая достигает того, что на больных объемах данных, например, полином второй степени считается чуть медленнее, чем одно арифметическое действие над тем же аргументом (а при последовательном вычислении полинома второй степени идет пять арифметическое действий).
Но это еще не все. Современные C/C++ компиляторы умеют использовать SIMD расширения современных процессоров, и за счет этого производить действия над 4 или 8 элементами массива одновременно. Numpy, тоже возможно вручную скомпилировать с поддержкой SIMD, но это не даст значительных преимуществ при вычислении сложных выражений (я даже не говорю про алгоритмы) по той причине, что все арифметическое действия выполняются по одному над целым массивом.
Tsimur_S: Есть два случая:
1) Когда скрипт (я специально так называю Python-код, чтобы акцентировать внимание на его интерпретируемой природе) делает в цикле полный проход по данным (пусть это будет numpy-массив). Это наивный подход, приемлем только для прототипирования сложных задач.
2) Когда он выполняет оперирует только векторами (фактически отдает команды на обработку numpy и другим расширениям), не погружаясь в цикл. Это уже профессиональный уровень, должно, быть большая часть той книги посещена именно этому подходу.
Во втором случае при переписывании на C++ в зависимости от "тяжести" вычислений внутри алгоритма выигрыш может достигать от нескольких десятков процентов до нескольких крат (для тривиальных операций, состоящих из одного математического действия, выигрыш, естественно, нулевой). Если это удивляет, то могу объяснить подробно за счет чего это происходит.
В первом случае (с циклом) при переписывании на C++ иногда удается получить выигрыш в 3-4 порядка, то есть в сотни и тысячи раз. Я нисколько не шучу! Интерпретируемый динамически типизированный язык - адски тормознутая штука, в сравнении с SIMD-инструкциями и прочими чудесами оптимизации, которые способен творить современный компилятор C++.
Если речь о плавной смене цвета, то, как говорит Яков Е , следует пользоваться специальными встроенными средствами, а не изобретать велосипед.
Если 60 раз в секунду менять цвет не плавно, то у юзера мгновенно взорвутся глаза.
"Проекты на Arduino" - это настолько же общая фраза, как "проекты на C++".
Все зависит от конкретного проекта, точнее от предметной области. Arduino - технология общего назначения, к предметным областям своего применения она сама имеет мало отношения.
Therapyx: Множественное наследование не требует, чтобы общий предок был абстрактным. А фигуры там или животные - это уже проблемы предметной области, а не ЯП.
Я далек от всей этой темы, просто мимо проходил, заинтересовало:
Какие такие скриншоты? С чего их снимают? Кому они интересны? И какую роль они играют в бизнесе заказчиков?
