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

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

Неожиданные изменения в экосистеме .NET

Думаю многие из вас смотрели вчерашний Connect(); — там Microsoft в очередной раз показывали что происходит в плане технологий и инструментария для разработки. Но мало кто ожидал что .NET (конечно не весь, а только некое «ядро») будет выпущен в опенсорс, да еще с гарантией отказа от судебного преследования.

На текущий момент у нас, правда, уже много всего в Open Source, включая языки C#/F#/VB.NET, ASP.NET а также (удивительно) Entity Framework, не говоря о более мелких проектах вроде MEF. Так вот, теперь о ядро дотнета, включая такие сакральные вещи как GC (сборщик мусора, чей алгоритм держался в строжайшем секрете) теперь тоже идут на GitHub (да-да, не на CodePlex а туда, где реально сидят разработчики).

.NET Core

Вот что уже было выложено на GitHub:

  • Immutable Collections — те самые немутабельные коллекции о которых я писал.

  • SIMD — т.е. поддержка длинных регистров которые используются для SSE/AVX. Что ж, хорошо! Пока что доступ к SIMD возможен только через С++, правда основная головная боль по использованию SIMD уже ушла благодаря умным компиляторам. Писать assembler или использовать intrinsics нужно только в очень крайних случаях.

  • AssemblyMetadataReader — всякие там CustomAttribute и иже с ним. Странно как-то отделять это от всего остального, ну да ладно.

  • XDocument и XmlDocument — ну то есть поддержка Xml и в частности моего любимого (хоть и бажного, увы) System.Xml.Linq.

Одна из идей всего этого – нечто под названием Core CLR, т.е. возможность шипить некое ядро CLR вместе с вашей собственной программой. Это даст некую отвязку от ситуации когда ваше ПО не поставить, не выкачав предварительно из интернета еще 100Мб файлов .NET Framework 4 (по собственному опыту). И да, урезанная версия .NET Framework проблему эту не решила, увы.

Visual Studio Community

Основная пробема была и есть что VS бесплатной редакции не дает шипить ПО и не дает ставить плагины. Проехали! Теперь VS Community – новая редакция, которая

  • Поддерживает расширения

  • Позволяет распостранять ПО в коммерческих целях

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

In non-enterprise organizations, up to 5 users can use Visual Studio Community. In enterprise organizations (meaning those with >250 PCs or > $1MM in annual revenue), no use is permitted beyond the open source, academic research, and classroom learning environment scenarios described above.

Понятие «enterprise» еще нужно объяснить, но по крайней мере любая команда из 5 человек может смело брать и использовать, и при этом поставить на студии ReSharper без каких-либо проблем.

ASP.NET vNext

Дино Эспозито обещал на киноуте .NEXT как раз и рассказать поподробнее про ASP.NET vNext, но тот факт что эта технология теперь едет и на Linux/OSX — это серьезно. У меня, например, все сайты используют ASP.NET (большинство – MVC, но один старый сайт 2003 года все еще на WebForms), и мне развитие ASP.NET только на руку – я вряд ли буду изучать такие вещи как Node/Ruby/PHP/whatever.

С другой стороны, я признаю что все классные фреймворки где-то за пределами .NET области: я про WordPress по сравнению с Orchard, например. Мне разработчики написали, что Orchard не будет работать с моим IIS 6 (да, у меня старый IIS, и что?), а мои попытки использовать .NETные блогодвижки, в т.ч. всякий адъ вроде N2… не, ну хорошо что такие фреймворки есть, но я честно, не фанат.

Что меня радует так то, что скорее всего мы увидим C# Native на не-Windows системах. А вот это уже интересно, т.к. нужно оно не только для вебного быстродействия, но и для того чтобы в некоторых случаях можно было не страдать с С++ (хотя я уже практически привык).

C++

Да, над С++ тоже поработали (что неудивительно), добавив помимо всего прочего поддержку мобильной разработки на С++ (не забываем, что теперь и Microsoft производит Android-телефоны, если что), ну и конечно же некоторые подвижки в плане C++11/14/17, такие как generic лямбды, await, и много всего другого.

Заключение

Не знаю насчет C++, а вот за .NET беспокоиться не стоит. Такая демократизация на руку всем, и я доволен что >10 лет назад я выбрал направление, которое пока и не думает умирать.

Если вас впечатляют эти подвижки и хочется «проникнуться» средой .NET, то все просто: приходите на .NEXT 8 декабря. Это большая .NET конфа в Москве. Там буду я, коллеги из комманды ReSharper, многие известные эксперты (в т.ч. много людей из «топа» .NET-секции Хабра), и много .NET разработчиков. До встречи!

Written by Dmitri

13 Ноябрь 2014 at 12:30

Опубликовано в .NET

Фотоотчет с конференции .NEXT

Я должен признаться, что я редко участвую в конференциях. Во встречах юзер-групп – да, бывает, но на конференции меня мало кто зовет (хотя доклады я подаю постоянно). Поэтому тот факт что я не только участвовал в конференции спикером но еще и принимал участие непосредственно в организации – это исключение из правил. А если учесть что конференция была в России — вообще курьез!

То что следует ниже – это небольшой фотоотчет о том что же собственно было, а также немного инфы о том кто на картинках. Основная программа пероприятия находится на http://dotnext.ru, но читать ее наверное не так интересно.

Итак, поехали.

Общая часть

Прежде всего, вот он – Алексей Федоров, человек без которого бы ничего этого не произошло. Алексей организует много конференций, в т.ч. Joker и JPoint, также именно он придумал логотип .NEXT (все варианты от дизайнеров были унылыми). Вообщем, respect!

Собственно сам киноут делал я :) рассказывал про то как эволюционируют процессы разработки, что нового и интересного, под конец поотвечал на вопросы зрителей, в очередной раз показал в деталях поддержку в R# интерфейса INotifyPropertyChanged :)

Далее в главном зале доклад делал Станислав Сидристый – рассказывал он про детали реализации CLR. Очень хардкорно, и насколько я знаю он теперь делает мероприятие в Москве, workshop как раз в продолжение этой темы.

Впрочем, меня там уже не было т.к. я в это время был у нашей «будки» вместе с еще одним соорганизатором конференции – Филиппом Торчинским:

Будка выглядит как-то одиноко, но на самом деле в перерывах там была масса людей, у меня даже голос сел после нескольких часов общения.

Часть 1я

Тем временем, конференция разделилась на 2 трека. В большом зале делал доклад Сергей Шкредов, тим лид команды ReSharper. Доклад был про организацию системы зависимостей в большом продукте, а Решарпер по меркам индустрии о-о-очень большой продукт, 300+ проектов.

В малом зале в это время выступал Рома Здебский, обсуждались новости с недавно прошедшей конференции BUILD. Многие пришли к нам как раз за этим докладом. Ну и конечно после конференции Рома еще долго общался с посетителями в кулуарах.

Далее в главном зале Кирилл Скрыган, который тоже работает в команде ReSharper, рассказывал про оптимизацию приложений. Согласно рейтингам, доклад Кирилла был самый популярный на конференции, мне же в свою очередь осталось лишь довольствоваться 2-м местом.

В малом зале доклад делал Алексей Садомов. Алексей – в прошлом один из активных участников Петербургской Группы Alt.Net – приехал к нам из Финляндии. Рассказывал он про интеграцию ASP.NET MVC приложений с Yandex.Market.

На этом этапе был кофе-брейк…

Часть 2я

После перерыва, в главном зале Влад Чистяков, наш коллега из JetBrains Moscow, рассказывал про фреймворк Nitra.

В это же время, Юлия Фаст из компании М13 (тоже кстати из Москвы) рассказывала про автоматизацию приемочного тестирования с помощью Fitnesse и TeamCity.

Далее, в главном зале был еще один доклад по TeamCity, уже непостредственно от сотрудника команды TeamCity. Евгений Кошкин расскывал про feature branches и их роль в процессе непрерывной интеграции.

А в малом зале, доклад проводил… я! Ну, как вы знаете, на любом эвенте бывают косяки и в этом случае, докладчик Виталий Баум (кстати тоже один из основателей Петербургской Группы Alt.Net) не смог к нам приехать, поэтому доклад мы делали по Скайпу. Виталий рассказал про то, как их компания использует Windows Azure для автоматизации управления функционалом автомобилей, а я в это время играл роль «ведущего телемоста» :)

Далее, Роман Белов (тоже из JetBrains) рассказал про профилировщик памяти dotMemory.

…а Станислав Сидристый в это время сделал короткий доклад на тему использования Xamarin для кроссплатформенной разработки.

Ну и в заключение, Антон Оникийчук (еще один человек из нашей ALT.NET тусовки) рассказал про использование TDD для MVVM приложений…

…а Павел Цытович из Luxoft Training в это время рассказал про использование WF для построения WCF сервисов. Я правда почему-то думал что WF уже умер в силу невостребованности, а оказывается нет.

Заключение

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

Мысли о следующией .NET конференции уже витают в облаках, но я пока обещать ничего не могу в силу огромных геополитических рисков. Надо еще посмотреть, выключат ли VISA/Mastercard 1го Июля, введут ли выездные визы, отменят ли двойное гражданство? Кто знает, кто знает…

Да, и кстати, вот все видеозаписи с конференции:

Written by Dmitri

18 Май 2014 at 15:13

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

Tagged with

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

Мне кажется, что идеальной состояние любой технологически ориентированной компании — это диверсификация. Иначе просто рискуешь нарваться на то что ты внезапно нерелевантен. Хороший пример – это разработчики 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 программисты будут ругаться и плеваться от одного вида ручного управления памятью. Но зато если вы с самого начала работаете с ручным выделением/уничтожением, умными указателями и соответствующими паттернами использования, то вас уже ничего не должно пугать.

Written by Dmitri

18 Апрель 2014 at 23:40

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

Мысли об облачных IDE

Мне кажется что никто на сегодняшний день не понимает, что такое облачные IDE. Если посмотреть на то, что люди реально пишут, получается у них следующее

  • Редактор в облаке который пусть и имеет подсветку синтаксиса, но остается достаточно рудиментарным и не обладает даже сотой долей набора фич, которые нужны современным пользователям всяких IDE.

  • Возможность сразу использовать 100500 языков, т.к. все компиляторы уже установлены и настроены. (Только в большинстве случаев разработчик использует один язык, но выбор – это все равно хорошо.)

  • Возможность компилировать и запускать программы в облаке соответствующий код в sandbox-е, так чтобы нельзя было снести к чертям всю систему. EdX даже умудрился сделать подобную штуку для CUDA, что не тривиально.

  • Коллаборативные возможности вроди sharing (a la GitHub Gist), ветвления (как в IdeOne) и прочие возможности, которые являются фактически source control-ом.

Социальная составляющая кодинга, как показывает GitHub – это очень хорошо. Но не хватает понимания того, что на практике нужны еще и

  • Работающий отладчик, который непонятно как делать в облаке т.к. это существенно понижает возможность разделения ресурсов: пока у меня стоит задетый breakpoint никто не имеет права трогать эту машину.

  • Поддержка тестирования — хочется иметь возможность запускать вагон тестов и фактически использовать серверную часть не только для continuous integration (это слишком просто), но именно для continuous testing в стиле NCrunch и подобных

  • Поддержка профилирования — это проще чем отладка и в принципе должно быть как-то реализуемо.

  • Поддержка деплоймента — чтобы готовые приложения сами разворачивались, клались в NuGet, и все такое

  • Поддержка мониторинга — раз уж на то пошло, почему бы не мониторить приложения и выдавать статистику по ним? Кстати, именно это уже делается в VS Monaco/Azure.

Основная проблема с Cloud IDE – это то что все забыли зачем облако. То есть облака рассматриваются как «социальный дропбокс», хотя на самом деле, облако – это место где хорошо масштабируются ресурсы. Зачем нужны ресурсы?

  • Во-первых, на (общих) серверах можно ставить более серьезное железо. Если учесть что разработчики для всех целей кроме CI не используют все мощности компа постоянно, покупка 32-процессорных систем с FusionIO и прочими вещами уже не кажется такой страшной.

  • Многие вещи параллелизуются. Например компиляция. Я уже какой год использую IncrediBuild вместо встроенного MSBuild. В облаке можно отмасштабировать компиляцию пропорционально размеру проекта.

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

  • Тестовое покрытие (code coverage) – тоже штука дорогая и в принципе на него можно выделать машины побыстрее.

Думаю идея понятна – эластичный рост облака до объема задачи позволит разработчику получать больше информации о своих наработках, и получать эту информацию быстрее (и в идеале – непрервыно). Но самое интересное я оставил напоследок, а именно:

  • Более глубокий анализ кода, включая спекулятивный анализ – это когда мы например меняем код в нужном (как нам кажется) направлении, перепрогоняем все тесты (ибо ресурсы позволяют) и замеряем перформанс дабы понять что лучше работает.

  • Перекрестный анализ проектов на предмет использования того или иного API. Мне почему-то кажется, что modus operandi взаимодействия с типовой библиотекой «шаблонизируется», и тем самым может быть использован для предоставляния пользователю более умных подсказок.

  • Можно использовать специализированное железо (например Xeon Phi) – возможность, которая недоступна большинству разработчиков ввиду дороговизны а также невозможности втиснуть такую карту в типичный MBP. (В теории, можно строить специализированное железо для ускорения задач программирования, но боюсь индустрия на такое не способна – не хватает кругозора и понимания вещей.)

Я надеюсь что рано или поздно можно будет использовать эти и другие возможности в облаках и на кластерах тоже. Когда – понятия не имею. Но мысли пока вот такие. А как еще можно использовать облако для разработки? Напишите в комментариях. ■

Written by Dmitri

10 Март 2014 at 23:23

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

Tagged with , , , ,

Мысли о «новом» обещанном нам C#

Как вы понимаете, Microsoft сейчас толком не до языковых фич т.к. сам компилятор переделали и даже уже сами переключились на Roslyn в процессе разработки, что как бы намекает на большие планы на 2014. Соответственно, те фичи которые Мадс осветил на NDC London не являются системообразующими, поэтому получите список:

  • Первичный конструктор в стиле class Size(int cx, int cy) { ... }, где как вы догадались, cx и cy это значения которые потом можно присвоить пропертям. Позволяет писать new Size(320,240), и вообще своровано с F#.
  • Возможность задавать значения readonly свойствам в стиле public int Width { get; } = cx. Даже не знаю что тут сказать – у меня часто свойства еще и в UI используются, а там все равно будет поле, так что нет разницы. (Ждите от Roslyn автореализации INPC? Не дождетесь.)
  • Property expressions, т.е. возможность писать property get без собственно блока get{}, return и прочих излишеств:
    public int Area => Width * Height;
    
  • Та же тема для методов. Фактически, просто удаление скобочек и return, но я уже вижу как новички пихают в эти стейтменты всякий мусор:
    public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
    
  • params IEnumerable, потому что когда хочется неограниченное число аргументов, то IEnumerable удобнее чем массив? На самом деле, могли как в D попробовать делать вещи через convention over configuration, т.е. вместо ключевого слова params просто сказать, что если есть только один параметр и он IEnumerable<T> или T[], то давать пользователям передавать массив через Foo(a,b,c) – и все были бы довольны.
  • Monadic null checking означает что вместо person.With(x => x.Address).With(x => x.HouseName) можно написать person?.Address?.HouseName, и везде будут проверки на null. Шикарно конечно, может немного поздновато, к тому же как показала практика, проверка на null – это не единственный concern, которых можно вкладывать в цепочки из лямбд.
  • Вывод типов для конструкторов, т.е. вместо Tuple.Create(foo,bar) можно наконец-то писать new Tuple(foo,bar)
  • Инлайновые декларации для out параметров по мне так самый большой фейл, пожалуй. Идея в том чтобы можно было писать
    if (foo.TryGetValue(out int x))
    {
      // use x, it's already been declared!
    }
    

    Ну и конечно идея в том что если параметров возврата несколько, то это как бы упрощает жизнь. Знаете что еще упрощает жизнь?

    let (x1,x2) = SolveQuadratic(1,10,16);
    

    И не важно, получили ли мы кортеж из (x1,x2) или просто две переменных – главное что результат метода записывается в том месте, в котором вы ожидаете, а не в аргументе, где декларации переменной – явно не место.

  • Импорт типа в пространство имен: уже хорошо, сделаем using System.Math чтобы не пользоваться поистине невменяемыми с точки зрения здравого смысла конструкциями вроде Math.Sin(). Хотя это только полумера: еще нужно удалить заглавные буквы (ну зачем они?), добавить оператор возведения в степень (с целочисленной перегрузкой), и уже будет можно дышать. Но разве ж кто-то об этом думает?

Ничего из списка выше особо не впечатляет. Гораздо интересней сам Roslyn (все же надеюсь что он будет «готов» к VS2014), ну и как это не странно, С++ сейчас развивается как-то быстрее, причем без всякого переписывания компилятора. ■

Written by Dmitri

21 Декабрь 2013 at 13:36

Опубликовано в C#

Коротко про Xeon Phi

Программирование высокопроизводительных систем невозможно в принципе. Вот несколько причин почему это настолько сложно что мало кто напрягаться будет:

  • SIMD сложно использовать потому, что нужно конвертировать обычные вычисления в абсолютно другой синтаксис, где, во-первых, другие типы данных (__m128i и подобные), работают далеко не все операции (например, в SIMD может не оказаться деления) и используются они не через обычные операторы: например вместо a*b нужно писать _mm_mul_ps(a,b). Понятно что мало кто будет напрягаться с этим, для этого даже отдельное расширение языка есть. Нет, я не шучу, пожалуйста: Intel Extensions for SIMD. Вы только вдумайтесь – отедльное расширение языка чтобы пользоваться чем-то, что присутствовало в процессорах со времен MMX! Я уже не буду говорить про то насколько все это эволюционирует и что писать для этого портативный код фактически невозможно.

  • CUDA это еще один гвоздь. Казалось бы, что плохого, модель более менее понятна. Но! Оно во-первых не особо портируется между девайсами (сам PTX портируется, но речь не об этом), т.к. девайсы все разные и никакого… свопа на диск и прочего нет, у всех свои параметры, писать обобщенный код нудно. Ну и потом, на CUDA нельзя гнать ничего кроме параллельных вычислений. Параллельных. Вы не можете делать 1024 разные вещи на CUDA. Только одинаковые, или с небольшими вариациями. Для обработки картинок? Супер. Для анализа кода? Да вы издеваетесь… (В эту же корзину идут OpenCL, которым никто не пользуется, и AMP, которым тоже никто не пользуется.)

  • FPGA разработка это вообще рецепт «как сделать классные технологии недоступными для простых смертных». То есть в отличии от SIMD, который у вас поддерживается в проце, и CUDA, которая в любой карте NVIDIA поддерживается в каком-то (порой, правда, весьма унылом) состоянии, FPGAшки остались чем-то на уровне шаманства. И языки другие (VHDL это нечто), и парадигма другая, и самое главное что разработчики не понимают нафиг это надо если не купить COTS продукт и не засунуть его быстренько в комп. На самом деле купить, и засунуть, просто это чертовски дорого, а все хотят выгоду здесь и сейчас. Не получится, товарищи.

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

И казалось бы, идея «купи компьютер и вставь в компьютер» фактически умерла, если только у вас не одна математика (тогда вы в шоколаде). Что же делать? Но недавно мне попалась новая партия добра (24шт.) под названием Xeon Phi. Думаете «еще одна проприетарщина»? А вот нет. Phiшка – это 60 процов которые – важно –

поддерживают x86

Может кто-то из вас не вкурил насколько это круто. Ладно. Попробую объяснить.

В ваш комп, условно говоря, воткнут еще один комп на PCI шине. Этот комп может работать в двух режимах: либо вы его просто используете как, эмм, отдельный комп – у него там Linux на борту, с ним вполне можно общаться; либо же вы отгружаете часть ваших задач на него.

Intel Xeon Phi Card

Вообщем шикарно, да? Вы фактически можете поставлять решения (т.е. полнофункиональные решения software+hardware) на таком девайсе. Но стоп, не все так просто. На самом деле, было бы даже странно, если бы наша лодка счастья не разбилась бы о быт в той или иной форме.

Итак, как вы уже догадались, для использования Фишки нужно

  • Отдельный компилятор

  • Тулзы для коммуникации с Фишкой

  • Магия в коде :(

То, что нужно как-то общаться с девайсом это понятно. Отдельный компилятор понять тоже можно: это конечно продукция Intel, но продукция эта использует другие процы, соответственно внутренняя реализация может как-то отливаться… хотя стоп, это же x86.

На самом же деле, поддержка Intel MIC (MIC = many integrated cores, то есть «очень много ядер к нам пришло») с точки зрения кода выглядит очень похоже на CUDA. Серьезно, посмотрите:

  • Для того чтобы что-то отгрузить на Фишку, можно либо использовать __declspec(target(mic)) int* stuff либо же сделать pragma push/pop.

  • Есть два режима как передавать данные – data sharing и data marshaling. В CUDA тоже вариантов всяких аллокаций и sharing’а вагон.

  • Модель отгрузки поддерживает разные парадигмы, например OpenMP. В этом случае просто пишем #omp parallel for и так далее.

  • В прагме для отгрузки идут отметки о том что отсылается и что получается (in/out/inout), прямо в лучших традициях COM. Я правда не уверен что читатели моего блога знают что такое COM :)

  • В случае с отгрузкой, вызов отгруженной функции выглядит как-то брутально: _Cilk_offload_to (target_id) foo().

  • Если данные шарятся, их нужно по-особенному создавать и удалять: как вам _Offload_shared_align_free(vals).

Вообще смотря на это мне как-то не особенно страшно. Ну да, чуточку прагм и немного головной боли в плане определения того, что дескать я именно вот этот массив хочу получить как результат, и вот тебе его длина. Да, это кстати намек на то что variable-size структуры могут как-то не сростись.

Пока у меня про Фишки все. Признаюсь, что с ними интересней играть чем писать про них. Но что я хочу чтобы вы поняли так это то, что это революция. Только пришла она поздно: сейчас у нас «облака» и уже локально что-то тяжелое гнать не так важно. К тому же, непонятен выигрыш для не-math задач. Нужно поизучать.

И да, судя по тому что пишут, для numerics эта штука послабее CUDA будет. Но это не важно!

Written by Dmitri

1 Декабрь 2013 at 19:10

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

Tagged with , ,

Что нового в С++ под Visual Studio 2013

В прошлом посте речь шла про нововведения в F# 3.1, в этом же мы немного поговорим про то, что нового в поддержке С++ в Visual Studio 2013. Заметьте что нам обещали что обновления компилятора С++ будут out of band, но как-то этого не произошло — а может просто совпало с релизом студии. Так или иначе, вот очень прозаичный список того, что появилось:

  • Поддержка однородной инициализации объектов с использованием фигурных скобок. Вот несколько примеров:
    int meaningOfLife {42};
    int meaningOfLife2 = {42}; // можно и с =
     
    Address a(100, "London road"); // обычный конструктор
    Address a2 { 100, "London road" }; // то же самое через инициализатор
     
    vector<int> v { 0, 1, 2 }; // ну наконец-то!
    

    К вопросу о том как это делается: вот эта штука { a, b, c } называется initializer list ну или std::initializer_list если точнее. Соответственно если вы хотите инициализировать имя (+ возможно фамилию и отчество), нужно писать что-то вроде:

    class Name
    {
      string firstName, lastName;
      vector<string> otherNames;
    public:
      Name(initializer_list<string> stuff)
      { 
        // у initializer_list нет оператора []
        auto b = begin(stuff), e = end(stuff);
        firstName = *b;
        if (++b != e)
          lastName = *b;
        while (++b != e)
          otherNames.push_back(*b);
      }
    }
    

    Вот как-то так. Интересный вопрос в том как передать произвольный набор данных. В .NET мы пишем params object[], а тут с этим сложнее, хотя… читайте дальше.

  • Введен аналог make_shared для единичных инстансов (т.е. unique_ptr) под названием make_unique. Напоминаю что предпочтительно как раз использовать эти методы нежели писать например shared_ptr foo(new Bar). Но вообще это конечно читинг – тащить фичи из Буста :)
  • Строковые литералы в которых не производится замена escape sequences, т.е. raw string literals. В .NET мы используем префикс @, а тут это префикс R:

    string s = R"c:\windows"; // backslash!
    string s2 = R"Hello
    world!"; // line breaks!
    
  • В предыдущих версиях С++, дефолтные параметры шаблонных аргументов могли фигурировать только в параметрах типа. Сейчас это можно делать и в функциях.
    template <typename T, typename U = less<T>> T FindSomething(vector<T>& v, U u = U())
    
  • Кортежи! Опять же, из Буста. Определается как tuple<int,string,Foo>, использует списки инициализации (см. выше) или же специальную конструкцию make_tuple() (эти две вещи эквивалентны), достается адским (по сравнению с .NET) способом через get<2>(myTuple) что я считаю просто кошмарно хотя наверняка появилось из-за того, что в отличии от C# у нас есть вариадичность.
  • Вариадические шаблоны — ухх, фича чтобы сломать кому-нибудь мозг. Вариадические шаблоны позволяют иметь неопределенное количество шаблонных аргументов у типа. Намек: а как кортеж работает? Ведь у него может быть сколько угодно аргументов с разными типами, так?

    Вообщем, это С++11я фича языка, которая как раз дает возможность использовать такие вещи как make_shared/make_unique. Точнее вещи такие раньше просто использовали вагон перегрузок (до N=5), а теперь мы можем вздохнуть т.к. теперь можно иметь 25 параметров, если действительно нужно.

    Работает эта штука и для функций и для классов, и выглядит прозаично:

    template <typename... Ts> class Stuff {};
    templat <typename... Ts> void func(Ts... values) {}
    

    Также у нас есть оператор расширения этих «неопределенных» параметров ..., что используется например для форвардинга (т.е. return new Foo(forward<Ts>(args)...)). Этот хитрый оператор собственно просит компилятор развернуть параметры как список (например a, b, c). Соответственно, есть 2 варианта:

    • Отослать параметры кому-то, возможно в функцию которая принимает фиксированное кол-во аргументов.
    • Замутить рекурсию. Например если у вас есть T... то можно сделать функцию foo(T a, T b, T... rest) и просто рекурсивно вызывать эту функцию с (b,rest) или просто (rest), тем самым отсекая первые 1/2 элемента.

Ну вот как-то так. ■

Written by Dmitri

26 Октябрь 2013 at 14:14

Опубликовано в С++

Отслеживать

Get every new post delivered to your Inbox.

Join 106 other followers