Недавно очередной раз отработал со студентам 2-го курса 2-семестровую дисциплину «Алгоритмические языки». Обзорно рассмотрели несколько дюжин языков программирования. Один из студентов, Вадим Шукалюк, захотел получше с ними познакомиться, получить более четкое представление о каждом из них. Посоветовал ему провести небольшое исследование. Чем и увлёк. Предлагаю свой отчёт по проделанной за несколько месяцев вместе с ним работе.

У каждого языка программирования есть свои достоинства и недостатки. Одна из важнейших характеристик транслятора с любого языка — это скорость исполнения программ. Очень трудно или даже невозможно получить точную оценку такой скорости исполнения. Ресурс http://benchmarksgame.alioth.debian.org/ предлагает игровую форму для проверки такой скорости на разных задачах. Но число языков, представленных на этом ресурсе, довольно невелико. Предельную ёмкость стека, критическую величину для рекурсивных вычислений проверить проще, но она может меняться в разных версиях транслятора и быть зависимой от системных настроек.

Тестировались следующие трансляторы: си (gcc, clang, icc), ассемблер (x86, x86-64), ява (OpenJDK), паскаль (fpc), яваскрипт (Google Chrome, Mozilla Firefox), лисп (sbcl, clisp), эрланг, хаскель (ghc, hugs), дино[1], аук (gawk, mawk, busybox), луа, рубин, бейсик (gambas, libre office), питон-2, пи-эйч-пи, постскрипт (gs), пролог (swipl, gprolog), перл, метапост, Т_EХ, тикль, бэш. Исследовались как собственно скорость исполнения нескольких небольших, но трудоёмких алгоритмов, так и:

• качество оптимизации некоторых трансляторов;
• особенности при работе с процессорами Intel и AMD;
• предельное число рекурсивных вызовов (ёмкость стека).

Существуют различные мнения относительно производительности С++ и C#.

Например, сложно поспорить с тем, что код C# может работать быстрее за счет оптимизации под платформу во время JIT компиляции. Или например с тем, что ядро .Net Framework само по себе очень хорошо оптимизировано.

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

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

Попадались и утверждения о том, что код на С++ примерно в десять раз быстрее кода на С#.

Все это многообразие противоречивых мнений приводит к мысли о том, что нужно самому попробовать написать максимально идентичный и простой код на одном и другом языке, и сравнить время его выполнения. Что и было мною сделано.

При написании приложений, одной из важнейших вопросов являются потребление памяти и отзывчивость (скорость работы).

Считается, что сборщик мусора – черный ящик, работу которого нельзя предугадать.

А еще говорят, что GC в .NET практически не настраиваемый. А еще, что нельзя посмотреть исходники как классов .NET Framework, так и CLR, GC и т.п.

А я скажу как бы ни так!

В данной статье мы рассмотрим:

• структура организации размещения объектов в памяти
• CLR 4.5 Background Server GC
• правильная настройка сборщика мусора
• эффективный апгрейд приложений до .NET 4.0+
• правильное ручное управление памятью

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Здравствуйте, уважаемые читатели.

В последнее время нас заинтересовала серия Зеда Шоу "The Hard Way", которую хотелось бы как минимум частично перевести на русский язык. Поскольку порой мы действительно не ищем легких путей, начать хотелось бы с книги о языке C:



Серия ориентирована в первую очередь на начинающих. Для тех, кто любит язык C, а также для их оппонентов, полагающих, что лучше стартовать с чего-нибудь попроще, мы публикуем немного сокращенную статью Эвана Миллера, написанную в конце прошлого года. Возможно, в зависимости от реакции на эту статью, мы решим дополнительно перевести и опубликовать отрывок из книги мистера Шоу либо даже его ответ на критику, высказанную Тимом Хентенааром, а пока приглашаем вас под кат, где, как нам представляется, изложены самые общие соображения в пользу актуальности этой книги.

Рад представить дополнение оригинального списка из 300 потрясающих бесплатных сервисов. Автор оригинальной статьи Ali Mese добавил ещё +100 новых сервисов, которые помогут найти все — от источников вдохновения и редакторов фотографий до создания опросов и бесплатных иконок.

И еще подборку +500 инструментов от 10 марта 2017 г. смотрите здесь.

A. Бесплатные веб-сайты

• HTML5 UP: Адаптивные шаблоны HTML5 и CSS3.
• Bootswatch: Бесплатные темы для Bootstrap.
• Templated: Коллекция 845 бесплатных шаблонов CSS и HTML5.
• Wordpress.org | Wordpress.com: Бесплатное создание веб-сайта.
• Strikingly: Конструктор веб-сайтов.
• Layers: Создание сайтов на WordPress (new).
• Bootstrap Zero: Самая большая коллекция бесплатных шаблонов Bootstrap (new).
• Landing Harbor:  Продвижение мобильного приложения c помощью бесплатного лендинга (new).

Период таймера Windows по умолчанию составляет 15.6 мс – он тикает 64 раза в секунду. Когда программа увеличивает частоту таймера, растет потребление энергии, что сказывается на расходе батареи. При этом также расходуется вычислительная мощность компьютера, и даже больше, чем я думал – то есть компьютер начинает работать медленнее! Вот почему в течение многих лет Microsoft настоятельно не рекомендует разработчикам поднимать частоту таймера.
Почему же тогда почти каждый раз, когда я вижу разгон таймера, он вызван программой от Microsoft?

C июня этого года мы начали проводить митапы SPB .NET Community в Санкт-Петербурге и за это время у нас скопилось немало видео, которым я и хочу поделиться. Кому интересно посмотреть доклады про новшества в Visual Studio 2015, безопасность платформы ASP .NET, детали разработки многозадачных приложений и про взаимодействие с unmanaged миром из C#, прошу под кат.

Предыдущие части

• Часть первая — habrahabr.ru/post/255361
• Часть вторая — habrahabr.ru/post/255523
• Часть третья — habrahabr.ru/post/255825

В данной части мы рассмотрим

Многотабличные запросы:

• Операции горизонтального соединения таблиц – JOIN
• Связь таблиц при помощи WHERE-условия
• Операции вертикального объединения результатов запросов – UNION

Работу с подзапросами:

• Подзапросы в блоках FROM, SELECT
• Подзапрос в конструкции APPLY
• Использование предложения WITH
• Подзапросы в блоке WHERE:
  
  • Групповое сравнение — ALL, ANY
  • Условие EXISTS
  • Условие IN

В одном из прошлых топиков мы рассмотрели протокол FIX, который был создан для передачи финансовой информации и автоматизации коммуникаций на фондовом рынке. Однако этот протокол оказался не самым идеальным инструментом в условиях все увеличивающихся объёмов финансовых данных, поэтому в качестве его развития был создан новый стандарт — протокол FAST (FIX Adapted for STreaming). Сегодня мы поговорим об этой технологии.

Я поделюсь 30 практиками для достижения максимальной производительности приложений, которые этого требуют. Затем, я расскажу, как применил их для коммерческого продукта и добился небывалых результатов!
Приложение было написано на C# для платформы Windows, работающее с Microsoft SQL Server. Никаких профайлеров – содержание основывается на понимании работы различных технологий, поэтому многие топики пригодятся для других платформ и языков программирования.

Мы в своем проекте занимаемся разработкой сервера на C#. Этот сервер должен выдерживать очень высокие нагрузки, по этой причине мы стараемся написать код как можно оптимальней. C# редко ассоциируют с высокой производительностью, но если с умом подходить к разработке, то можно достичь очень даже неплохого уровня.

Одним из недешевых процессов с точки зрения производительности является boxing и unboxing. Напоминалку о том, что это такое, можно найти тут. Недавно я решил посмотреть весь IL код наших проектов и поискать инструкции box и unbox. Нашлось достаточно много участков, boxing'а в которых можно избежать легким движением руки. Все случаи, приводящие к ненужному boxing'у, очевидны, и допускаются по невнимательности в моменты концентрации на функциональности, а не на оптимизации. Я решил выписать наиболее часто встречающиеся случаи, чтобы не забывать о них, а затем автоматизировать их исправление. В данной статье и перечислены эти случаи.

Эта статья входит в серию статей по улучшению производительности в .NET. Первую статью можно найти здесь.

В этой статье, как и в прошлой, будут рассмотрены неочевидные особенности в работе платформы, и приемы, с помощью которых можно с этими особенностями мирно сосуществовать. Проще говоря, тут будут записаны очередные всякие хаки из жизни нашей лавки, которые хоть немного (или много, как всегда все зависит от контекста), но экономят драгоценные ресурсы в условиях высокой нагрузки. Хаки предельно просты и не влияют на конечную функциональность.

Открывая очередную статью о производительности, пожалуй каждый резонно ищет ответ на вопросы «а как это может помочь в моих проектах» и «бросать ли все и начинать ли срочно исправлять свой код как описано». Исправлю ошибку прошлой статьи, отвечу сразу и подробнее. На мой взгляд, есть смысл использовать наши хаки в следующих случаях:

• Вы пишете новый код и решили делать это немного лучше и с экономией
• Вы дошли до этапа, когда начались оптимизации и рефакторинг, поэтому просматриваете и меняете участки кода, которые выполняются очень часто
• Вы пишете высокопроизводительную систему и экономите на спичках

Я ни в коем случае не призываю вас бежать и исправлять весь код в ваших проектах. Более того, я призываю вас не делать этого, потому что это простые хаки, и скорее всего они будут вноситься бездумно в большое количество кода, а это может повлечь за собой появление новых ошибок. Это не те хаки, которые скинут бабу с воза вашего приложения и заставят кобылу-сервак бежать в десять раз быстрее. В лучшем случае удастся выжать процентов десять. Но с миру по нитке — голому рубашка.

Функция распознавания речи с некоторого времени доступна в браузере Google Chrome. Посмотреть как это выглядит можно, например, здесь.

Так как исходный Chromium открыт, возникает закономерное желание подсмотреть, можно ли использовать технологию в своих корыстных целях наступления мира на земле.

Как это часто бывает, все уже сделано за нас в этой статье. Все оказывается очень просто, необходимо сделать POST запрос на адрес www.google.com/speech-api/v1/recognize со звуковыми данными в формате FLAC или Speex. Реализуем демонстрацию распознавания WAVE-файлов с помощью C#.

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

Те, кто пишет блог, много читает. Это аксиома. Есть наверняка исключения. Но для того и существуют исключения, что бы подтверждать правила.

Как по мне, так и обратное утверждение будет верным. Те, кто много читают, пишут блоги. И одна из наиболее важных причин этого явления, это желание обсудить тот материал, который прочитан. Плюс естественное желание как-то систематизировать имеющиеся залежи, и похвастаться накопанным в сети и придуманным самим. Вот и в этом посте очень хочется поговорить на заявленную тему. Английский первоисточник тут. А мое понимание всего, что в ней написано, ниже.

В современном мире мы вынуждены поглощать все возрастающие объемы информации. Причем делать это на еженедельной, а то и ежедневной основе. В любом случае, если вы ведете бизнес в сети, ведете блог, читаете что-то по работе или просто для удовольствия, я уверен вы можете получить больше выгоды, если будете запоминать больше от прочитанного. Интернет позволяет быстро найти и ознакомится с огромными объемами информации. Первоисточников и переработанного материала. Но насколько много вы можете сохранить в своей долгосрочной памяти? Вот 10 советов, как помочь себе в этом вопросе.

Об этом методе я слышал давно и многократно, в первую очередь от аналитика нашей конторы, рассказывавшем о большом количестве специальной литературы, проработанной таким образом. Я же, честно говоря, страдаю тем, что техническую литературу читаю, как художественную, то есть, после первого прочтения в памяти остается очень далеко не все, да и раскладывание по полочкам не всегда проходит как надо. Такая же проблема возникла и при попытке прослушивания лекций coursera.org — писать от руки быстро я уже не могу, а печатать форматированный текст на лету, ИМХО, сложно.

Переломным оказался момент прочтения одной статьи: http://habrahabr.ru/post/155891/ — уж больно хорошо у автора получалось то, к чему я так стремился. Что ж, подумалось мне — с головой, да в омут, а как иначе?

Привет всем. Основываясь на предыдущем опыте, считаю нужным сразу расставить все точи над ё. Описанная ниже методика — не мое изобретение. Однако из собственного опыта могу уверить вас, что она работает. Ровно так, как обещано.
Идея, описанная в посте, появилась давно (под катом есть история), в том виде, в каком расскажу ее я, по большей части она представлена в чудесных книгах Тони Бузана Use You Head и The Speed Reading Book (в последней много воды).

Пост затрагивает проблемы скорости чтения, понимания текста, а также методы значительного улучшения и того, и другого.

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

Прежде чем приступить к самому главному, прошу вас пройти тест из шести вопросов на Да/Нет.

1. Чтение со скоростью свыше 1000 слов в минуту невозможно?
2. Медленная скорость чтения способствует лучшему пониманию текста?
3. Пропускать слова во время чтения — плохая привычка, ухудшающая понимание текста?
4. По умолчанию мы все читаем с «естественной» для нас скоростью, а следовательно, наилучшей?
5. Если вы не поняли слово или предложение, лучше перечитать его и понять?
6. Ваши глаза находятся в непрерывном движении во время чтения?
За результатами и, наконец-то, интересными штуками добро пожаловать под кат.

Конструктор по умолчанию — это довольно простая конструкция, которая сводится к созданию для типа конструктора без параметров. Так, например, если при объявлении нестатического класса не объявить пользовательский конструктор (не важно, с параметрами или без них), то компилятор самостоятельно сгенерирует конструктор без параметров. Однако когда речь заходит о конструкторах по умолчанию для структур (для значимых типов), то тут все становится не столь просто.

Вот простой пример, как вы ответите на следующий вопрос: сколько значимых типов из .NET Framework содержит конструкторы по умолчанию? Интуитивным ответом кажется "все", и будете не правы, поскольку на самом деле, ни один из значимых типов .NET Framework не содержит конструктора по умолчанию.

Не нравятся новые цветовые темы

Ставим Visual Studio 2012 Color Theme Editor, видим в меню VS новый пункт «THEME», наслаждаемся.

Не нравятся новые иконки в Solution Explorer

Ставим Visual Studio Icon Patcher (VS 2010 должна быть тоже установлена).

Не нравится CAPS в меню

Об этом уже писали.

Спасибо Скотту Хансельману за то, что пишет полезные вещи в свой блог.