В этой статье я хочу поделиться несколькими нестандартными алгоритмами для быстрого возведения числа в степень, а также продемонстрировать их реализацию и сравнить их быстродействие в C++, C# и Java.
Сравнить точность алгоритмов можно прямо сейчас на этой странице.
Я одержим оптимизацией производительности и максимальным повышением эффективности программ. За многие годы я сталкивался с конкретными случаями и распространёнными паттернами, замедляющими работу ПО или компьютеров. В этом посте я расскажу о некоторых из них.
Я назвал пост Surprisingly Slow потому, что замедление было для меня неожиданным, или неоптимальные практики, ведущие к замедлению, настолько распространены, что многие программисты будут удивлены их существованию.
Разделы поста чаще всего никак не связаны друг с другом, поэтому можете выбирать самые интересные для вас.
Читать полностью »
Давным-давно, во времена студенчества в колледже я немного занимался разработкой компьютерных видеоигр. Это была эпоха 8-битных PC, когда игровое оборудование по современным стандартам было почти невозможно медленным.
Поэтому вас не должно удивлять, что программисты игр придумывали всевозможные безумные трюки, чтобы их игры работали с приемлемой скоростью. Безумные, безумные трюки.
Это история об одном из таких трюков.
Я постараюсь припомнить все важные подробности, однако в чём-то могу ошибиться. Если так случится, простите меня, это было очень давно.
Мой друг, одарённый программист, почти закончил свою новую игру. Каким-то образом ему удалось почти без изменений уместить в компьютер эпохи 1980-х довольно впечатляющую графически на то время игру, популярную на аркадных автоматах.
Единственная проблема заключалась в том, что его версия игры оказалась неиграбельной. Она работала слишком медленно, а дёрганые движения мешали вовлечённости игрока, ведь игра была сайд-скроллером.
Мой друг, работавший над игрой параллельно с учёбой в колледже, начал уже ощущать себя немного вымотанным. Опасаясь, что мог упустить какую-нибудь простую оптимизацию, он попросил посмотреть код меня.
Я посмотрел. Но там нельзя было найти никакой простой оптимизации.Читать полностью »
В этой серии статей мы хотим рассмотреть вопросы, которые возникают у людей при работе с хостинг-провайдерами и выделенными серверами в частности. Большинство из обсуждений мы вели на англоязычных форумах, стараясь пользователям в первую очередь помочь советом, а не саморекламой, дав максимально подробный и беспристрастный ответ, ведь наш опыт в сфере уже свыше 14 лет, сотни успешных реализованных решений и тысячи довольных клиентов. Тем не менее наши ответы не следует воспринимать, как единственно правильные ответы первой инстанции, они вполне могут содержать неточности и даже ошибки, никто не идеален. Будем признательны, если вы дополните или исправите их в комментариях.
Начнём с того, что я обожаю сериализацию в Unity. Она надёжна и очень проста в использовании. Я просто расширяю MonoBehaviour, ScriptableObject и подобные классы и настраиваю сериализуемые поля экземпляров в инспекторе.
Но у неё есть и слабости. Одна из них ― человеческий фактор. Представьте себе огромный проект, который живёт несколько лет и над которым работает около сотни человек. И любой из них может совершить ошибку: оставить пустую ссылку на объект, указать число вне диапазона, ввести строку в неверном формате, заполнить массив слишком маленьким или, наоборот, слишком большим количеством объектов. Уверен, у каждого из вас найдутся такие примеры из своего опыта. Причин и оправданий тоже множество: невнимательность, неожиданные последствия слияния веток, сбои редактора… И никто от этого не застрахован.
Такие ошибки до поры до времени остаются незаметными: компилятору до них нет дела, в отличие от опечаток в коде. Особенно неприятны они тем, что проявляются часто уже во время выполнения кода. Только тогда вы начинаете читать журнал сообщений и идёте проверять данные: тыкать их в редакторе или листать YAML. Но объектов может быть достаточно много, есть риск что-то пропустить или попросту залениться.
Конечно, можно добавить проверок в коде, но от этого он загрязнится. Иногда эти проверки негативно влияют на производительность. А ещё не всегда однозначно понятно, как именно обработать каждую конкретную ошибку.
Универсального или даже штатного метода бороться с подобным в Unity нет. Поэтому мы в Pixonic реализовали свою систему валидации ассетов. И это очень помогает нам жить.
Сейчас я опишу, как там всё устроено.
Читать полностью »
CoLab блокнот с примерами
Возможно сделать скользящее окно (rolling window, sliding window, moving window) по массивам NumPy на языке программирования Python без явных циклов. В данной статье рассматривается создание одно-, двух-, трех- и N-мерных скользящих окон по массивам NumPy. В результате скорость обработки данных увеличивается в несколько тысяч раз и сравнима по скорости с языком программирования С.
Cкользящее окно применяется в: обработке изображений, искусственных нейронных сетях, интернет протоколе TCP, обработке геномных данных, прогнозировании временных рядов и т.д.
Отказ от ответственности: в исходном коде могут быть ошибки! Если вы видите ошибку, пожалуйста, напишите мне.
Вопрос производительности PHP-кода для Badoo один из самых важных. От качества PHP-бэкенда напрямую зависят количество ресурсов, которые мы тратим на разработку и эксплуатацию, скорость работы сервиса и впечатление, которое он производит на пользователей.
Поэтому темой третьей встречи сообщества PHP-разработчиков в нашем офисе мы сделали производительность бэкенда и пригласили к обсуждению коллег из Авито и «Мамбы».
Читайте под катом расшифровку дискуссии, в которой мне повезло быть модератором: как устроена инфраструктура трёх компаний, как мы измеряем производительность и на какие метрики ориентируемся, какие инструменты используем, как делаем выбор между железом и оптимизацией.
А 15 февраля приходите на следующий Badoo PHP Meetup: обсудим легаси.
Читать полностью »
Это небольшое подведение итогов на пост “Быстрее, чем C++; медленнее, чем PHP”
Неблагодарное дело — «спорить» в комментариях, поэтому формулирую несколько мыслей в отдельный пост. Автор утверждал тут, тут, и еще много где, что у него большой стаж и богатый опыт в программировании на С++.
Читать полностью »
