?

Log in

No account? Create an account

Entries by category: it

Ответ на бнопню по C++

Код, который напрямую зовёт std::vector{std::move(foo)} на данных в ощущениях компиляторах (gcc, clang) будет медленнее, чем construct_vector(std::move(foo)), где:

std::vector construct_vector(Foo && foo) {
    std::vector vec;
    vec.emplace_back(std::move(foo));
    return vec;
}


Почему это так случается? Из-за отсутствия оптимизации std::initializer_list. Конструкция вектора через std::vector{} создаёт initializer_list, мувает в него один элемент foo, затем копирует из initializer_list внутрь вектора. К сожалению.

construct_vector же копированием foo не занимается, а делает move construction. Значение вектора попадает в место вызова без копирования, через RVO.

Ну вот так хреново пока работаем с std::initializer_list. В стандарте C14 про это вот что есть: "the underlying array is copy-initialized". Опаньки.

Типичный C++, что ни фича, то засада. JavaScript и то без копирования передавал бы всё :)

P.S. По поводу «почему C++» (mpd) — это было не моё решение. Нам и на Эрланге с сишными вставками неплохо работалось, правда, в сервис работал в десять раз медленнее. Но если у компании есть ресурсы и время на то, чтобы создать поддерживать в тонусе команду C++-програмистов, почему бы и нет? :)

Ключевой момент тут такой: если не заниматься байтодрочерством, C++ из-за подобных недофич (чуть что — копируем! ну или не смогли понять жизненный цикл — тоже на всякий случай скопируем) будет работать не сильно быстрее остальных дефолтных языков, а то и медленнее и/или глючнее. Только если действительно понимать, что происходит, можно выжрать нетривиальный буст по производительности, и, если повезёт, не сильно потерять в безопасности. Но это если такая производительность действительно нужна. На мобилке она, за редкими исключениями, вряд ли нужна. В датацентре (если это не cuda) — уже более интересное распределение. Разница между десятью нодами и сотней нод в плане управления — колоссальна. Между сотней и тысячью — уже речь встаёт о дешевизне датацентра по сравнению с рабочим временем программиста.

Если C++ на вашем продукте позволяет обеспечить эту разницу в 10x, есть средства на программистов и время на их реализацию, почему бы и нет? У нас в MZ — есть. Компания зарабатывает несколько миллионов долларов в день. А в вашем НИИГиТ наверняка нет ни таких средств, ни таких требований к производительности, которые бы требовали кластера из более чем десятка машин, а их оптимизация явно встанет зарплатой программистов дороже, чем выгода от их сокращения.

Pandoc and Manual Pages

Итак, надоело мне рисовать мануальные страницы через nroff. Как в asn1c, например:



Проблемы с подготовкой документации в nroff такие:
Проблемы с nroffCollapse )
Что-то я не понимаю эти вот страдания по поводу того, что покрытие кода не 100%. Ну допустим ваша тулза показывает 100%. Что это значит, можно конюшни больше не чистить? А вот и нет:

int f(int a, int b) {
  int arr[2] = { 0, 0 };
  int i = 1;

  if(a == 1) i--;

  if(b == 1) i--;

  return arr[i];
}

И что это вам дало? Покрытие по строчкам 100%, а всё падает.

По опыту, у 84% программистов какой-то blind spot, не позволяющий ощутить масштаб проблемы.

Чувствую себя капитаном, пиша этот пост. Но он нужен.

Keyless SSL™ (shameless plug)

CloudFlare анонсировал, что теперь можно не раздавать сертификаты точкам, которые терминируют SSL трафик.

[1] http://blog.cloudflare.com/announcing-keyless-ssl-all-the-benefits-of-cloudflare-without-having-to-turn-over-your-private-ssl-keys/
[2] https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

И это на самом деле здорово. Только они так говорят, как будто это инжениринговый прорыв нереальный.

В начале двухтысячных у нас в Netli (продались Akamai) появилось желание терминировать SSL, причём, чтобы наши датацентры, стоящие в Китае, Бразилии, России и ещё чёрт-те где, не имели бы приватного SSL-сертификата. Потому что несекьюрно и может утечь. Среди наших клиентов были такие компании, как Dell (dell.com), HP (hp.com), и сертификаты этих сайтов было бы очень грустно утратить в процессе обработки их на этих разнесённых датацентрах.

В районе 2003-2004 я имплементировал этот процесс в виде расширения OpenSSL (добавил туда fibers, чтобы можно было асинхронизировать запросы; изначально в OpenSSL этот процесс синхронен), и набора софта "keyserver", при котором бы ключи хранились на центральных машинах в штатах, а на краевых машинах, в левых датацентрах, терминация SSL приводила бы к асинхронному запросу на генерацию pre-master ключа. На централизованных keyservers ключи на диске хранились в зашифрованном блобе, а ключ от блоба хранился в HSM (от nCipher) в центральном сервере, и передавался кейсерверам только временно.

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

С тех пор эта же технология безключевого SSL светилась несколько раз в разных патентных аппликациях:

http://www.google.com/patents/US20070074282 (Certeon)
http://www.google.com/patents/US20130156189 (Akamai) — это выглядит ровно как описание моей работы — ну да не мудрено, потому что Akamai купил Netli целиком вместе с её кодом и клиентами, использовавшими безключевую терминацию SSL.

Но эти апликации не прошли. А вот более поздняя апликация от CloudFlare — прошла, и превратилась в патент:

https://www.google.com/patents/US8782774 (CloudFlare)

Вывод? Молодцы, я рад за них ;) Только патент у них non-enforceable, потому что есть prior art, закреплённый в патентах от Certeon и Akamai.

Tags:

Serendipities in Silicon Valley

Когда я переехал в Долину, столкнулся здесь с одной из необычных забав в разговорах. Люди вспоминают, кого куда "звали", а они решили туда не пойти, потом жалели. Один из первых запомнившихся мне разговоров был чем-то вроде «Тут ко мне подходит чувак, говорит что он Джерри, и у них наклёвывается такая клёвая новая конторка и нужен сисадмин. Я ему говорю, нет, мол, работа есть уже. Этой конторкой оказалось Yahoo и я был бы сотрудником номер 5, и мог бы купить остров.»

Я теперь тоже могу участвовать в таких разговорах ;)

лева привет

меня зовут ян.

you probably don't now me. i am CEO and co-founder of WhatsApp. i see you done some erlang/server stuff work in the past which is pretty amazing.

[...]

-- jan


2011 год. Блин.

P. S. 19 миллиардов долларов. Я рад за них! :)

Tags:

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

Яков-зачинатель: http://jakobz.livejournal.com/236681.html
Ваня-продолжатель: http://gliv.livejournal.com/125078.html
Никита-тролль: http://tonsky.livejournal.com/285722.html

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

1. Очень разнятся скиллы тех, кто приходит в отрасль. От учителей истории, которые переучились на курсах (если повезёт), до дизайнеров и программистов на коболе. У них всех очень разные представления о том, что такое программирование. Очень разная толерантность к крутизне кривых обучения. Очень разные задачи. Поэтому будет продолжаться наблюдаться множество локальных оптимумов языков, фреймворков, и их комбинаций.
2. Веб-программирование как ниша развивается очень быстро. Ещё недавно SPA не было и JS использовался в качестве свистелок и перделок для статического сайта. Теперь на нём и SPA, и мобайл, и энтерпрайз. Пока эта область развивается (а она всё ещё развивается, краёв почти не видно), будет постоянный импеданс между возможностями, предоставляемыми подходами к программированию (нарисуйте и продолжите вектор от jquery как энхансер до Flight как фреймворк, и далее), и требованиями очередного витка развития.
3. Интерплей между языками программирования и фреймворками очевидно, порождает "косые" решения и неоптимальности, когда замечательный язык не имеет хорошего сопряжения с замечательным фреймворком (Roy/Elm + React?), и наоборот. Придётся страдать.
4. Некоторые подходы в программировании, такие как в FP, требуют отдельной фазы погружения программиста в них. Желательно, через что-нибудь чистое, типа хаскеля. Немногие хьюманы смогут пройти этот энергетически-временной барьер, поэтому объективно более лёгкие в использовании и развитии (при наличии в голове уже готовой и прогретой FP-парадигмы и, скажем, STM) фреймворки не смогут набрать себе критическую массу пользователей, а значит, будут всё время отставать с точки зрения развитости фреймворков и способности на них быстро набросать какой-нибудь state of the art интерфейс.
5. Разговор о языках и фреймворках остаётся не более чем вкусовщиной вплоть до тех пор, пока не начинает влиять на бизнес. Разговор об интересных языках и фреймворках сам по себе может усиливать вероятность успеха компании, потому что компания будет иметь возможность легче привлекать интересных людей. Или снижать вероятность успеха, потому что вместо практичных людей будет набирать черт-знает кого, кто понапихает в проект каких-нибудь скобок, потом хрен с ними разберёшься, хоть индусам раздавай переписывать всё нафиг. В любом случае не исключена парадоксальная ситуация, когда 1) компания наняла умных людей; 2) у компании таки будет успех; 3) но при этом те инструменты, которые они используют, являются энергетически даже менее оптимальными, более проблемными, чем обычнейшая связка из традиционнейших инструментов типа JS+Bootstrap.

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

Clojure at Echo

Originally posted by tonsky at Clojure at Echo
Провел в команде опрос на тему Кложи. Опрошено три респондента с 4-5 месячным опытом использования (основные разработчики нашего clojure-driven продукта) и двое с 1-2 месячным (переключились на другой проект). Результаты анонимизированы и подсокращены до смысловой части.

Насколько сложно читать?

— Несложно, дело привычки
— Читать сложнее Эрленга
— Python (2,3) < Java, Erlang (4) < Clojure(6,7)
— Примерно Ruby (без Rails)
— Очень зависит от автора

Насколько сложно писать?

— Очень легко
— Легче, чем в ООП языках
— Меньше кода, только суть
— Упирается в понимание кода
— Проблем с отладкой не возникает (отладочная печать она и в Африке отладочная печать)

Как быстро начинает получаться писать что-то полезное?

— Неделя
— Недели две
— От недели и больше
— С учетом, что есть опыт в ФП

Наиболее сложные области

— Concurrency примитивы
— Двухсторонний interop
— Meta параметры
— Идеология

Стала ли Clojure естественным, «своим» языком?

Все: Пока нет, но потенциально да.

Полезно

— Гибкость, лаконичность
— Особенно чувствуется при переключении на другой язык
— Скорость написания кода («опа-опа и готово»)
— Java—библиотеки
— Синтаксис удобен для файлов конфигурации

Раздражает

— Скобки (1 чел.)
— Привязанность к Java (2 чел.)
— Непрозрачность кода из-за макросов (2 чел.)
— Медленный старт, тяжеловесность платформы (2 чел.)

Общее впечатление

— Писать на Clojure очень легко. Видимо поэтому мы так много пишем и переписываем то, что пишем.

— Большая неограниченная свобода. Можно писать как угодно и в любом стиле. Код становится зеркалом разработчика.

— Clojure идеально подходит для соло проектов и достаточно плохо подходит для командной разработки.

Наиболее полезные ресурсы

clojure.org
clojuredocs.org
— The Joy of Clojure
— Clojure Programming
— Programming Clojure


От себя (lionet). Вот этот пункт — ключевой:

— Clojure идеально подходит для соло проектов и достаточно плохо подходит для командной разработки.

Именно из-за особенностей влияния среды на командную работу, в Echo на серверной стороне использует в основном Erlang, и только в тех местах, где активный народ принципиально прётся от какой-то альтернативной технологии (i.e., OCaml, Clojure) написано на них.

Tags:

Выдвигаю предложения по усовершенствованию синтаксиса языка JavaScript.

Для примера разберём такую простую конструкцию, как функция, генерирующая замыкания.

function foo(filter, pattern) {
    var f = function(list) { return filter(pattern, list); };
    return f;
};

Конечно, в JavaScript есть опциональные точки с запятыми. Их можно не ставить, если это не приведёт к синтаксическим проблемам. Поэтому предлагаю завершающие точки с запятыми из языка убрать, а в язык добавить правило, что если строка кончается и при этом на строке находится полностью завершённое выражение (то есть, все открывающие скобки уже закрыты), то считаем, что выражение действительно завершено. При этом точки с запятыми становятся не нужны:
Далее:Collapse )

Tags:

Подсыплю ложку первоклассного дёгтя.

Слышали про Сколковский/Казанско-IT-парковский проект распознавания речи при помощи, в том числе, информации о движении губ с видеокамеры?

http://realspeaker.net/ru/

Они получили 9 миллионов финансирования, etc.

Что представляет собой проект? Это программа, которая комбинирует готовые открытые библиотеки распознавания лиц из проекта OpenCV/Emgu.CV (Open Computer Vision) и готового же онлайнового гугл-сервиса по распознаванию аудио (Google Speech Recognition API — то же самое, что происходит при распознавании речи в каждом Андроиде, ровно то, что уже доступно каждому JavaScript-программисту в браузере Chrome, и ровно то, на основе чего мы с sidentdv за одну ночь на ульяновском хакатоне написали проект AudioSMS).

Как комбинирует? Берёт аудио с микрофона и по сети посылает в гугл API, пока губы движутся, и не посылает, пока губы не движутся. Эта зависимость от движения губ называется «детекцией пауз». Сервер гугла в ответ присылает в текстовом виде распознанный текст.

Почему это не прорыв? Потому что если не обладать возможностью действительно встроиться в алгоритмы распознавания аудио, нельзя сделать глубокий фидбэк видео от губ. Например, подмешать видеопоток в bayesian language model. То есть, нельзя сделать так, чтобы губы действительно влияли на качество распознавания аудио. Максимум что можно сделать — вот это самое распознавание пауз, при котором шум с микрофона не посылается в гугл.

Может быть это какое-то демо, а у них в лаборатории готовится реальный прорыв? Да, они пишут, что это прототип. Хотя и продают его Pro версию за 1000 рублей. И хочется верить, что у команды есть более тяжёлая артиллерия. Но не думаю, что это так.

Кстати, интересно что у ребят нет договора с Гуглом по коммерческому использованию их API по распознаванию речи.

Ещё интересно, что вся информация, которую я написал, доступна в интервью и в описаниях почти прямым текстом. Но когда чиновники хвалятся этим проектом, то создаётся впечатление неокосмических технологий и искусственного интеллекта, который читает прямо по губам.
На последнем экспертном совещании ульяновского министерства информационных технологий был вскользь затронут вопрос об обучении людей элементам информационных технологий, чтобы потом их задействовать в относительно простых работах. Примером работ была оцифровка загсовских записей числом около 5 миллионов. Мол, можно научить людей и посадить их за эту работу.

Давайте посмотрим. Пять миллионов записей. Шесть тысяч рублей в месяц зарплата легковооружённого дроида, 6 часов работы в день. Каждая загсовская запись — это, скажем, 30 секунд работы по вбиванию. Может даже минута.

5000000 / (4 * 5 * 6 * 60) / 2 = 347 месяцев работы одного человека, или около двух миллионов рублей денег только на зарплату. Если мы хотим оцифровать пять лямов за год, а не за 30 лет, нам понадобятся 30 человек.

Никакой погоды эти тридцать data-entry человек в масштабах Ульяновского «айти» не сделают.

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

Почему машинное распознавание рукописного текста в данном случае не является бредом?

  • Это считывание из фиксированной формы, это упрощает.
  • Имена, отчества, названия населённых пунктов повторяются, и OCR может быть натренирована на них целиком.
  • Данные не являются секретными, поэтому то, что не распозналось, можно засылать в РеКапчу. Ну или сделать какой-нибудь порносайт, и в качестве пароля туда просить распознать задетектированное слово или предложение.

Если области хочется вложиться в IT (на самом деле, CS, Computer Science), то на порядок лучше вложить его в политех, где есть необходимая компетенция по нейронным сетям и машинному обучению, чем тренировать 30 бабушек.

Tags:

Profile

lionet
Lev Walkin
Website

Latest Month

December 2016
S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728293031

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by yoksel