Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Мысли о выборе технологий

10 комментариев

Мне кажется, что идеальной состояние любой технологически ориентированной компании — это диверсификация. Иначе просто рискуешь нарваться на то что ты внезапно нерелевантен. Хороший пример – это разработчики Windows Mobile (это то, что предшествовало Windows Phone) — их по сути всех «кинули», и все их скилы (там .NET Compact Framework и иже с ним) внезапно стали бесполезны.

Я тут думал на тему того, на базе чего имеет смысл сегодня начинать писать новый продукт. Идеи у меня конечно все направлены в сторону «веба», т.к. и ежу понятно, что идеальная стратегия для конечного пользователя – это «облако», даже если это облако приватное, т.е. существует в пределах инфраструктуры компании, а не отдано «на аутсорс» всяким Amazon, Microsoft и так далее.

Так вот, все равно, в большинстве случае, на стороне сервера я прихожу к тому, что единственный возможный вариант для создания back-end’а чего бы то ни было это С++, и что все Java/.NET решения особого смысла для высокотехнологичных решений (а не решений в стиле «база для веб-мордочки») не имеют. Агрументация моя примерно такая:

  • Мы просто не можем позволить себе ограничивать себя в плане операционной системы. А это значит что можно использовать только то, что работает везде. Следовательно, сразу «отпадает» .NET т.к. при всей возможной опенсорсности Roslyn, использовать Mono я пока как-то не хочу.

  • Мы не можем себе позволить использовать новые, непроверенные, экспериментальные языки. Мне нравится язык D, например, но ему нужено еще очень много времени чтобы библиотеки во-первых починить где они не работают а во-вторых чтобы появились те либы, которых не хватает; ну и конечно вопрос с инструментарием и поддержкой тоже не решен.

  • Единственный способ воспользоваться интересным железом, которое на сервере совсем не зазорно размещать, это C/C++. Хотя по правде сказать, у Java есть поползновения сделать поддержку GPU на базе Aparapi (этот фреймворк в свое время поставляла ATI для использования OpenCL из Java), но GPU – это ведь только одна, причем не самая гибкая, технология ускорения вычислений.

Можно, конечно, использовать целый набор языков программирования — все равно в вебе придется использовать JS, например — но мне кажется что если использовать С++ как основу, то уже распыляться не имеет особого смысла. .NET и Java являются языками производительности (productivity languages), но мне кажется что они скорее являются языками лени. Конечно, разработка на С++ на первом этапе медленнее, зато преимущества, мне кажется, очень даже существенны:

  • Инструментарий (профиляторы, анализаторы) намного более зрелый

  • Библиотеки тоже намного более зрелые

  • Возможность оптимизации для конкретной архитектуры. (Надеяться на то векторизацию от какого-нть JIT компилятора – наивно.)

  • Намного более вменяемые подходы к параллелизации, как на декларативном (OpenMP) так и императивном уровне.

  • И да, тот факт что специфичные устройства (в моем случае – Tesla, Xeon Phi и FPGA) — всем могут быть запрограммированы на С++. Хотя в последнем случае все сложнее, т.к. OpenCL, который доступен для этих целей, мне пока не импонирует. Но рано или поздно придется и на него посмотреть.

Нравится вам это или нет, но типичные процессы рано или поздно все-таки перетекут в «удаленные» структуры, которые будут выделять на наши тривиальные задачи намного бо́льшие ресурсы чем те, которые может предоставить ваш ноутбук или рабочая станция. А соответственно, все эти кластеры тоже нужно программировать так, чтобы взаимодействие между машинами было наиболее прозрачным. И для этих целей у нас есть такие вещи как MPI, которые позволят строить гетерогенные сети как из машин, так и из устройств вроде Xeon Phi.

Конечно все это идиллия, и C#/Java программисты будут ругаться и плеваться от одного вида ручного управления памятью. Но зато если вы с самого начала работаете с ручным выделением/уничтожением, умными указателями и соответствующими паттернами использования, то вас уже ничего не должно пугать.

Advertisements

Written by Dmitri

18 апреля 2014 в 23:40

Опубликовано в Technology

комментариев 10

Subscribe to comments with RSS.

  1. Дима, ты начинаешь терять марку! Почитал твой опус, но даже дыбы маркетологов не могли тебя заставить написать эту ерунду (деликатно выражаясь).
    1. M$ — далеко не та компания, которой нужна «диверсификация» (и кстати, это ПРОЦЕСС, а не состояние). Мобильная разработка — верное направление, но засранное «эффективными менеджерами». Выбери хоть тысячу сиплюсплюсов, мудаки на воеводстве испоганят всё.
    2. Про какой «новый продукт» речь? Конь в вакууме? НЕТ «абстрактного продукта», есть конкретный рынок и конкретные инструменты. Без конкретики, твои рассуждения о плюсах, многоплатформенности, облаках и прочем — абстрактная чушь.
    3. Если ты знаешь о «Ди», вдвойне позорно слышать про какое-то сипиписное мракобесие — ты или не понял целей Ди, либо недооцениваешь маразм С++ в современных реалиях.
    4. Забудь про свои «удалённые облака»: ДАЖЕ если по какой-то дичайшей щедрости каждый житель земли будет одарен гигабитным анлимом, даже тогда никто не будет рисковать, оставляя важные данные в чьих-то руках. Или запуская ни бог весть что из браузера, когда связь элементарно может отвалиться. Просто держи в голове: журавль в небе никогда не будет лучше синицы в руках. Да и возможности железа сейчас на 200% перекрывают потребности, вопрос лишь в уродах, не умеющих распорядиться гигагерцовыми мощностями. Зато «тырнетные» возможности отстают и намного! Блюрэй выпустили? Выпустили! Сколько лет мне надо ждать, чтобы скачать один диск? 15 минут — вот психологический барьер, после которого я начну считать, что мой тырнет — говно. Итого, 15Гиг/15 мин = 1 Гиг/минуту, вот МИНИМУМ, который обязаны обеспечивать всякие облако-проталкиватели, чтобы я вообще обратил внимание на эту технологию. Вопрос безопасности, есессно, остаётся под громадным вопросом.

    Ivan

    19 апреля 2014 at 2:37

    • Я даже не знаю стоит ли на этот комментарий отвечать, но все же попробую.

      1. M$ — далеко не та компания, которой нужна “диверсификация” (и кстати, это ПРОЦЕСС, а не состояние). Мобильная разработка — верное направление, но засранное “эффективными менеджерами”. Выбери хоть тысячу сиплюсплюсов, мудаки на воеводстве испоганят всё.

      Единственный вариант не диверсифицироваться – это быть системообразующим монополистом. И когда Windows была основной системой – действительно можно было не нервничать.

      2. Про какой “новый продукт” речь? Конь в вакууме? НЕТ “абстрактного продукта”, есть конкретный рынок и конкретные инструменты. Без конкретики, твои рассуждения о плюсах, многоплатформенности, облаках и прочем — абстрактная чушь.

      Ну представьте что-то, что крутится в back-end’е, не важно что. Сделаем вид что задача не ложится на экзотику вроде Erlang.

      3. Если ты знаешь о “Ди”, вдвойне позорно слышать про какое-то сипиписное мракобесие — ты или не понял целей Ди, либо недооцениваешь маразм С++ в современных реалиях.

      Обычно такие комментарии пишут те, кто ни о D ни о С++ должного понятия не имеет. «Мракобесие» — это проблема восприятия и лени. D дает очень хорошие возможности, но у него недопиленный GC и недопиленные библиотеки, есть основные конструкты языка которые попросту not implemented, инструментарий не ахти (по С++ сейчас положение меняется). Соответственно, если выбирать основной язык, D пока — не вариант.

      4. Забудь про свои “удалённые облака”: ДАЖЕ если по какой-то дичайшей щедрости каждый житель земли будет одарен гигабитным анлимом, даже тогда никто не будет рисковать, оставляя важные данные в чьих-то руках. Или запуская ни бог весть что из браузера, когда связь элементарно может отвалиться. Просто держи в голове: журавль в небе никогда не будет лучше синицы в руках. Да и возможности железа сейчас на 200% перекрывают потребности, вопрос лишь в уродах, не умеющих распорядиться гигагерцовыми мощностями. Зато “тырнетные” возможности отстают и намного! Блюрэй выпустили? Выпустили! Сколько лет мне надо ждать, чтобы скачать один диск? 15 минут — вот психологический барьер, после которого я начну считать, что мой тырнет — говно. Итого, 15Гиг/15 мин = 1 Гиг/минуту, вот МИНИМУМ, который обязаны обеспечивать всякие облако-проталкиватели, чтобы я вообще обратил внимание на эту технологию. Вопрос безопасности, есессно, остаётся под громадным вопросом.

      Да что вы говорите! Все это уже произошло. Любой владелец Gmail дает Гуглу сканировать всю его почту, и доволен. Возможности железа сейчас дотягивают до потребностей обывателей, но никаким образом не дотягивают до потребностей программистов, иначе бы мы не стоили рабочии станции с 192Gb RAM, не ставили бы FusionIO, и не использовали бы CUDA/XeonPhi/FPGA т.к. смысла вообще не было бы ни в чем этом.

      И еще, я уже это написал но напишу еще раз: есть такая штука как private cloud, i.e. on-premise установка. За безопасность отвечаем сами.

      P.S.: чтобы купить Blue-Ray диск нужно отодрать зад от кресла, дойти до магазина и купить. А если лень – продолжаем стримить Netflix.

      Dmitri

      19 апреля 2014 at 10:03

  2. Есть еще Go, который мне нравится больше, чем C/C++, D etc. С инструментами и библиотеками пока еще не все радужно, но в целом вектор направления задан верно.

    Andrey Krisanov (@akrisanov)

    19 апреля 2014 at 8:20

    • Ну с Go та же проблема что и с другими языками — они еще очень молодые. То есть, если видно что задача четко ложится на этот язык и ничего особенного от библиотек не нужно, то можно конечно использовать. Но на практике нужен то сериализация, то regex’ы то еще что-нибудь, и выбор сразу сокращается до C++/C#/Java.

      Dmitri

      19 апреля 2014 at 9:46

  3. Я так понимаю, что «новый продукт» — это то, что ты собираешься продавать людям для работы в корпоративном облаке? Типа GitHub Enterprise? Так тебе все равно придется делать публичную версию для проверки коммерческой целесообразности, и чем меньше ты потратишь на это усилий, тем лучше — иначе есть риск, что ты делаешь продукт, который никому не нужен. Значит, надо брать язык «для ленивых» (не будем здесь обсуждать, что лень часто путают с желанием быть более эффективным при наименьших затратах), и выкатывать MVP как можно быстрее. Тут уж не до ручного управления памятью.

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

    Artyom Smirnov (@uluhonolulu)

    19 апреля 2014 at 11:29

    • Мне кажется что никто толком никогда не делал деконструкцию процесса разработки ПО на составляющие. Например, поиск символа – это фактически поиск строки в наборе строк. Можно ли это оптимизировать? Определенно да – задача очень хорошо ложится на GPU. Но все видят разработку как holistic experience, что главное это огромный набор фич. А может оказаться так, что вовсе не огромный, а небольшой, но по принципу do no harm.

      Приведу тебе такой пример: Visual Studio есть 32-битный процесс. Это значит что плагин под нее теоретически не может вылезти за 4Гб, от которых еще сама Студия откусит. Это ограничение синтетическое, можно плодить неуправляемую память, но сам понимаешь, ситуация не из лучших.

      Если говорить про влияние железок, то я вижу это так:

      • Задачи которые ложатся на GPU делаются на GPU

      • Задачи которые не ложатся на GPU но параллелизуются делаются на Xeon Phi

      • Единичные задачи которые являются дорогими но не паралллелизуются (например поиск по regex’у) делаются в железе; я фанат FPGA но если есть ASIC-и, почему бы и нет.

      • Задачи которые не попали под все это или которые слишком сложно – их можно делать на CPU

      Хех, конечно это все идиллия. Но иначе технологии становятся как-то совсем уж неинтересными.

      Dmitri

      19 апреля 2014 at 13:56

  4. Мне лично больше нравится солянка из языков с единым удобным путём их скрещивать. Например, через протобаф и его RPC. Тогда необходимость ограничивать себя до одного наименее ущербного инструмента отпадает сама собой.

    Alexander Buryak (Rageous)

    19 апреля 2014 at 16:40

    • Но тогда нужен вагон скилов. Разработчики с 10+ опытом недешевы.

      Dmitri

      19 апреля 2014 at 16:57

  5. Вот допилит Microsoft язык Native C# в течении пару лет и будет у нас что то близкое к D + GUI на базе WPF, плюс mobile, хотя конкурентом сего детища будет Rust.
    А C++ это конечно кОшмар с наиболее стабильными инструментами и библиотеками, и будет путаться есче под ногами.в течении лет 15и. Надеюсь на стабильное вытеснение C++ с рынка языком D с момента выхода Native C#, так как это ослабит интерес разработчиков к C++ и D станит в относительном измерении более перспективным.

    tivadj

    19 апреля 2014 at 18:00

    • Да, но что-то странно… C# Native делают сейчас для W8/WP8 вместо того чтобы честно делать для Windows/Linux/OSX под x64… я не смотрел, но как-то там все странно. Пусть делают аналог C++, который работает везде — тогда посмотрим. Хотя по-хорошему, BCL, в частности коллекции… это что-то с чем-то, как вы думаете почему C5 используют?

      И что все так помешались на D? Скажите, как использовать SIMD на D? Какой набор механизмов для многопоточности существует под D? Я не против D но для начала нужно допилить GC, сделать поддержку xml, regex’ов и еще вагона всего.

      Вообщем никто С++ не вытеснит, в ближайшие лет 10 точно. Так что не надейтесь.

      Dmitri

      19 апреля 2014 at 18:13


Оставить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: