Intel® Software Network

To alex_kom: Спасибо за пояснения.

Добавлю в наше обсуждение новость: мое решение второй задачи (Совершенные числа) получила на конкурсе максимальную оценку за время исполнения. Таким образом, это решение, написанное на Дельфи, не уступает по скорости решениям на других языках, в частности, на С++ с применением TBB. Как правило, один и тот же алгоритм можно реализовать по-разному, так что решающее значение в конкурсе имеют грамотная реализация и оптимизация алгоритма, а выбор языка и библиотеки – второстепенное (если бы не отмеченная в данной теме искусственная языковая дискриминация). В общем случае убедительно доказать, что Фортран, например, быстрее Дельфи, пока еще никому не удалось и навряд ли такое вообще возможно.

Методы статистической оценки по Google популярности какой-либо темы, как правило, вызывают большие сомнения из-за известных свойств Google. Например, недавно в РАН обсуждались отрицательные последствия «гуглизации» студентов и части научных работников. Более надежные сравнения - это сравнение конкретных сайтов Borland, Free Pascal, Torry's Delphi Pages и т.д. - столь масштабных ресурсов в зоне ru не найти. Однако даже приведенные Вами цифры показывают, что популярность Дельфи и Паскаля – не российский феномен. Ведь именно так стоял вопрос (а не в плане сравнения популярности Дельфи и С++ в Интернете). Последнюю пару лет мода на С++ начала заметно спадать, во-первых, потому, что мода – вообще явление не долговечное, кроме того, все больше и больше бывших пользователей С++ «оттягивают» Java и C#, при том, что численность сторонников «классического» С (без плюсов) уменьшается не так резко. Напротив, количество пользователей Дельфи и Паскаля остается примерно постоянной последние 4 года. Думаю, что не переоценю возможности такого индустриального лидера как Интел, если предположу, что ему вполне по силам поддерживать больше распространенных языков и библиотек к ним, тем более, что во многих случаях это и не сложно. Например, адаптация MKL к Дельфи сводится к интерфейсу. Сводится ли к интерфейсу адаптация TBB для других языков? Если «да», то не понятно, почему TBB сразу не приспособили хотя бы к своим языкам: Интел-С и Интел-Фортран? Если «нет», то столь узкая конструктивная ориентация вызывает недоумение – постоянно существует большой риск, что изменчивая мода вдруг превознесет какой-нибудь язык Х, о котором мы сейчас ничего не знаем. И что тогда делать – переписывать TBB с нуля?

Dmitry O. wrote: «Но для того чтобы этот вопрос возник, нужно попробовать перевести алгоритм на TBB… А это, как я понял, сделали не все.»

Да, мне было бы интересно попробовать, если был бы интерфейс с Дельфи. Вот, например,  MKL к Дельфи, мне с помощью специалистов Интела подключить удалось без особых проблем, я попробовал и получил ситуацию, подобную той, о которой написал akukanov, у меня без MKL был более эффективный код под конкретную задачу.

akukanov wrote: “Чтобы услышать личное мнение инженеров продуктовых команд, в частности, моё, нужно задавать вопросы по существу. У всех нас времени не хватает, и я своё время лучше потрачу, отвечая на конкретный вопрос на англоязычном форуме TBB, чем споря об абстрактных материях здесь.”

Зачем это писать? Да еще так раздраженно. Нет времени, считаете обсуждение абстрактным и не по существу – так и не пишите, если, конечно, ответы пользователям и участникам форума не входят в Ваши служебные обязанности ;)

В отношении Вашего предложения у меня конкретный вопрос: во сколько (человеко-месяцев) Вы оцениваете  трудоемкость подобной работы?

MAD\akukanov:

MAD\doganezo:

Большинство спеков, к примеру, все-таки используют C++.

На самом деле, Фортран и Си.

Единого мнения о популярности, похоже, все таки нет ;)

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

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

Относительную востребованность языков программирования можно оценить по количеству вакансий на англоязычных сайтах занятости в разделе IT специальностей. Например на  www.dice.com (центральный US сайт для технических специальностей). Размер базы - 91,178 вакансий.

C/C++      17,190

C++          8,069

Java         15,800

VB            4,225

C#            7,300

.Net          12,773

Cobol       1,133

Ada          151

Fortran    141

Delphi     139

Lisp          27

Pascal      24

Haskel      7

Modula-2  0

Не хочу обижать приверженцев Delphi, но цифры, я думаю, говорят сами за себя. Рынок есть рынок.

Кстати, когда я делал подобную выборку 4 года назад C/C++ уступал по востребованности Java и VB/C#. Правда тогда мировая экономика еще переживала последствия .COM кризиса, и возможно именно это и привело к временно большему переизбытку рабочей силы (и соответственно меньшему числу вакансий) в наиболее густо-населенной нише разработки.

FORTRAN считается самым "быстрым" языком (по крайней мере одним из) из-за того, что программы, написанные на нем поддаются более глубокой оптимизации, чем программы на C/C++. Основная причина - отсутствие в нем указателей и виртуальных функций, которые вынуждают компиляторы C/C++ быть гораздо более консервативными в ряде ситуаций (а также, до некоторой степени, несравнимо более простой синтаксис Фортрана - проще писать и отлаживать компиляторы). Однако Фортран совершенно не приспособлен для разработки сложно-структурированных и многокомпонентных программ. Отсюда его крайне ограниченная распространенность в настоящее время.

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

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

C/C++ это наиболее распространенный язык (по меньшей мере один из). Именно на нем в основном написаны ниболее процессор-интенсивные приложения: операционные системы, драйвера, базы данных, бизнес логика финансовых систем и различных систем управления корпоративного уровня, web-сервера, обработка графики и видео, CADы, движки 3D игр, системы искусстиенного интеллекта, дата-майнинг, поисковыу энджины и т.д.

Java (особенно enterprise версия) широко используется в серверных приложениях, а также частично для написания компонентов уровня бизнес логики. (Intel активно вносит свой вклад в поддержку и развитие Java сообщеста - написана своя оптимизированная имплементация JVM и библиотеки классов, поддерживается Eclipse).

Кроме того C, C++ и Java широко доступны на всех основных ОС и платформах - Windows, Linux, Mac, Unix (во всех их вариациях).

Fortran поддерживается Intel'ом поскольку он до сих пор имеет широкое распространение в сегменте HPC (High Performance Computing). Сегмент сам по себе узкий (<2% рынка), но важный (как Formula-1 для автомобилестроения).

Что касается .Net, то эта технология контролируется Microsoft, и поэтому Intel не вкладывает сюда много ресурсов, хотя определенные работы ведутся и здесь.

С уважением,

Андрей Марочко

mt2,

не стоит делать выводы об эмоциях писавшего, основываясь на собственной интерпретации написанного. Если я не ставлю смайлов, это ещё не значит, что я не улыбаюсь.

На мой взгляд, Вы по-прежнему упорно игнорируете или отметаете приводимые аргументы, продолжая "гнуть свою линию" о языковой дискриминации. Поэтому не думаю, что имеет смысл обсуждать языковую моду, популярность, маркетинговые инициативы, etc и пытаться развеять Ваше недоумение касательно позиционирования библиотеки TBB. Ваши вопросы выдают Ваше неведение; с учётом того, что ссылки на информацию были приведены, оно уже у меня вызывает недоумение.

Здравым зерном среди всего этого прозвучала мысль об грамотной реализации и алгоритмической оптимизации как наиболее весомом вкладе в производительность, тут я с Вами согласен. Осталось и Вам понять, что скорость работы программы - лишь один из факторов для победы в конкурсе. Так и в жизни, кстати - среди требований заказчика быстродействие может вовсе не являться самым главным; иначе не было бы метрик price/performance, watt/performance, usability и т.п.

Ну и касательно трудоёмкости: ядро TBB было написано с нуля (не считая научных публикаций) одним человеком за примерно полгода, дальше шла (и продолжается) доводка и расширение функциональности. Поскольку у меня нет опыта перевода программных проектов с C++ на Delphi, оценку давать не буду; если у Вас есть такой опыт, можете сами прикинуть, с учётом вышеприведённой информации и имеющейся возможности подсчитать количество строк кода.

Всего наилучшего,
Алексей Куканов.

Добавлю ещё, что для "своих" языков C и Fortran компиляторы Intel(R) поддерживают индустриальный стандарт OpenMP, и наша реализация является одной из наиболее эффективных для систем на базе процессоров Intel(R). Стандарт OpenMP с самого начала разрабатывался для распараллеливания вычислительноёмких задач на этих языках. Надеюсь, это снимет часть Вашего недоумения, mt2 (прошу прощения за обращение по нику, но Вы не подписываетесь).

mt2:

Добавлю в наше обсуждение новость: мое решение второй задачи (Совершенные числа) получила на конкурсе максимальную оценку за время исполнения.

Поздравляю! Надеюсь с "расселением" будет так же!

mt2:

Да, мне было бы интересно попробовать, если был бы интерфейс с Дельфи.

Вот это как раз то, что меня беспокоило с самого начала конкурса.

Итак, разобъем участников на три условные группы:

1) Пишут в основном на плюсах, уже используют ТББ. Если рассуждать логически и помнить правила конкурса - они должны занять все первые места, но ничего не дадут нам как организаторам (кроме ПиаР) т.к. и без конкурса все что можно используют и знают :).

2) Пишут в основном на плюсах, но ТББ не используют. Могут попробовать ТББ или свой вариант,  в зависимости от самооценки. Потенциально - кандидаты на первые места. Так же могут стать пользователями ТББ, если привыкнут :). Конкурс в данном его проявлении рассчитан в основном на таких людей.

3) Пишут в основном не на плюсах, как следствие - ТББ НЕ используют. С небольшой вероятностью попробуют решить задачу на плюсах и ТББ, как следствие - с небольшой вероятностью смогут "привыкнуть". С точки зрения конкурса (все еще помним правила?) - не фокусная группа.

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

Да, пока не забыл - идея реверсного маркетинга (сделать что-либо не используя наши инструменты, но быстрее) на самом деле активно обсуждается. Тут я пожалуй не соглашусь с Алексеем - на самом деле попробовать это было бы очень интересно и мы не исключаем, что такого рода акции будут запущены.

MAD\amarochk:

Относительную востребованность языков программирования можно оценить по количеству вакансий на англоязычных сайтах занятости в разделе IT специальностей. Например на  www.dice.com (центральный US сайт для технических специальностей). Размер базы - 91,178 вакансий.

 

Увы, Андрей, эта метода оценки тоже необъективна. Общеизвестен факт, что количество размещенных вакансий на сайтах типа dice.com говорит не о числе рабочих мест, а о том, насколько трудно найти сотрудника с такой специализацией. Так например, на одно место опытного плюсовика может быть размещено несколько десятков вакансий от различный индивидуальных рекрутеров и рекрутинговых агенств. Потому что это спецы дорогие и редкие. Соответственно, за них агенства бъются не на жизнь а на смерть. Что касается популярных и относительно легких языков - большинство компаний нанимают их напрямую.

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

MAD\doganezo:

mt2:

Добавлю в наше обсуждение новость: мое решение второй задачи (Совершенные числа) получила на конкурсе максимальную оценку за время исполнения.

 

Поздравляю! Надеюсь с "расселением" будет так же!

 

Спасибо!

MAD\doganezo:

 

2) Пишут в основном на плюсах, но ТББ не используют. Могут попробовать ТББ или свой вариант,  в зависимости от самооценки. Потенциально - кандидаты на первые места. Так же могут стать пользователями ТББ, если привыкнут :). Конкурс в данном его проявлении рассчитан в основном на таких людей.

 

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

MAD\doganezo:

 

3) Пишут в основном не на плюсах, как следствие - ТББ НЕ используют. С небольшой вероятностью попробуют решить задачу на плюсах и ТББ, как следствие - с небольшой вероятностью смогут "привыкнуть". С точки зрения конкурса (все еще помним правила?) - не фокусная группа.

 

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

MAD\doganezo:

 

Да, пока не забыл - идея реверсного маркетинга (сделать что-либо не используя наши инструменты, но быстрее) на самом деле активно обсуждается. Тут я пожалуй не соглашусь с Алексеем - на самом деле попробовать это было бы очень интересно и мы не исключаем, что такого рода акции будут запущены.

Думаю, что если будет принято решение о подобной акции, материалы данного обсуждения будут полезны при ее планировании. Хотя бы для того, чтобы не наступать на те же грабли ;)

MAD\doganezo:

 Но еще раз повторюсь – из правил видно: этот конкурс суть есть попытка оценить зрелость TBB как продукта относительно массового рынка. По-честному если говорить, этот конкурс посвящен TBB. Надеюсь, все читали правила, и это не для кого не сюрприз!

Если судить по названию, то конкурс прежде всего посвящен многопоточности. Смотрим Официальные правила: «Перед участниками данного конкурса будет поставлена задача выполнить задания на программирование, после чего предоставить исходный код (далее - “Решение”) для оценки жюри конкурса.» Больше о целях ничего не сказано, а где же TBB? Только в одном месте в середине текста между прочим сказано, что за их использование будет начислятся от 0 до 100 очков. А «прочее» - прежде всего - это факт самого решения, затем - изящность, затем - производительность, а уж только потом - TBB, а затем – еще и дополнительные баллы. Таким образом, из правил совершенно не видно, что конкурс посвящен TBB.

К сожалению, судьи не всегда следуют этим Правилам. Так, уже в ходе 2го задания было официально заявлено, что может быть (maybe) мы предложим дополнительные баллы за решения при N>10. (Напомню, что по условиям задачи N не превосходит 10). Более никаких официальных заявлений и обещанного предложения не последовало до самого срока сдачи решений. А потом «бух!» - кто понадеялся на maybe, получают по 50 очков дополнительно за N до 15. Несколько участников, в том числе и я, уже написали в американском форуме, что им бы почти ничего не стоило (минимальные потери производительности) расширить свою задачу до N=15. За 25 лет работы в сферах компьютинга и программинга я убедился, что техническое задание должно выполняться четко и без излишеств (если они заранее не согласованы). Студенты, участвующие в этом конкурсе, видимо не имеют такого опыта, и получают поощрение за maybe. Подобные ситуации называются «плохим примером для молодежи» ;)

MAD\doganezo:

MAD\amarochk:

Относительную востребованность языков программирования можно оценить по количеству вакансий на англоязычных сайтах занятости в разделе IT специальностей. Например на  www.dice.com (центральный US сайт для технических специальностей). Размер базы - 91,178 вакансий.

 

 

Увы, Андрей, эта метода оценки тоже необъективна. Общеизвестен факт, что количество размещенных вакансий на сайтах типа dice.com говорит не о числе рабочих мест, а о том, насколько трудно найти сотрудника с такой специализацией. Так например, на одно место опытного плюсовика может быть размещено несколько десятков вакансий от различный индивидуальных рекрутеров и рекрутинговых агенств. Потому что это спецы дорогие и редкие. Соответственно, за них агенства бъются не на жизнь а на смерть. Что касается популярных и относительно легких языков - большинство компаний нанимают их напрямую.

Я согласен с Дмитрием + еще одно замечание: к сожалению, Вы говорите только об индустриальной сфере, пренебрегая такими областями, как образование и наука. А ведь прогресс  индустриальной сферы целиком и полностью (почти полностью) зависит от образования и науки. Полуграмотные хакеры-самоучки сегодня не смогут удовлетворить запросы компьютерной индустрии… Что касается науки – она кормит индустрию, ведь не секрет, что сегодня практически ни один коммерческий продукт не разрабатывается с нуля фирмой-производителем. И в образовании и, в особенности, в фундаментальной науке положение с языками несколько иное. При том, что в науке занято сильно меньше народу, чем в индустрии, и общий объем спроса от науки может выглядеть мизерным, однако лишите науку нужных ей языков, и прогресс остановится! Мировое индустриальное лидерство, которое по праву принадлежит Интелу, накладывает на него не легкие обязанности руководствоваться не только сиюминутной рыночной конъюнктурой, но и долговременными интересами прогресса цивилизации, без которого и у Интела не будет никакого будущего. Ленин писал о жлобском империализме как последней стадии капитализма, разрушающей себя изнутри. Как только капитализм понял, что пора перестать жлобствовать, так у него появилось будущее. По сути, это же самое пишет и Сорос в своих книгах. При всем неоднозначном отношении к этим двум авторам приходится их упомянуть в контексте данного вопроса (но только как книжных авторов).

MAD\akukanov:

mt2,

не стоит делать выводы об эмоциях писавшего, основываясь на собственной интерпретации написанного. Если я не ставлю смайлов, это ещё не значит, что я не улыбаюсь.

Ok :))

MAD\akukanov:

На мой взгляд, Вы по-прежнему упорно игнорируете или отметаете приводимые аргументы, продолжая "гнуть свою линию" о языковой дискриминации. Поэтому не думаю, что имеет смысл обсуждать языковую моду, популярность, маркетинговые инициативы, etc и пытаться развеять Ваше недоумение касательно позиционирования библиотеки TBB. Ваши вопросы выдают Ваше неведение; с учётом того, что ссылки на информацию были приведены, оно уже у меня вызывает недоумение.

И Вам, и другим участникам этого обсуждения я со своей стороны могу сказать то же самое, что Вы упорно продолжаете гнуть свою линию. Насчет моего неведения TBB – Вы совершенно правы, я поэтому и спрашиваю. В частности, из приведенной по ссылкам информации у меня сложилось впечатление, что TBB был задуман, как мультипоточное расширение языка С++ (правильно?). Но я не понял из этой информации, почему Интел не хочет применить ту же методику для расширения других языков: то ли по соображениям бизнеса, то ли по принципиальным (TBB настолько зависим от специфики языка С++, что попытка сделать что-то подобное для другого языка будет противоречить дизайну этого языка и поэтому в принципе не имеет смысла). Если второе верно, то Ваше предложение в отношении Дельфи также не имеет смысла. В Дельфи (и в Kylix) изначально (на уровне дизайна языка) реализованы достаточно мощные средства управления потоками и процессами. Считаете ли Вы, что перевод всего исходного кода TBB на Дельфи/Kylix даст что-либо дополнительно полезное (к уже имеющемуся)? Про производительность Вы уже сказали – что не даст. Может быть, заметное сокращение исходного кода? Удобство отладки? Оптимизацию во время исполнения программы в плане оптимальной загрузки процессоров, определение оптимального количества потоков в зависимости от конкретной конфигурации системы и железа? Что-нибудь еще?

MAD\akukanov:

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

Рад, что Вы согласны со мной. Однако в рамках данного конкурса это порождает еще одно недоумение. Конкурс преследует в общем-то инженерную задачу многопоточности. Но задания конкурса подобраны так, что их успешное решение гораздо больше зависит от общих математических познаний участника.  К примеру, если решать второе задание, ничего не зная о тесте Лукаса, грамотная реализация многопоточности не спасет. Ситуация, похожая на неудачную школьную олимпиаду: хотели устроить соревнование по химии, а получилось соревнование по математике, где нужен минимум химических знаний и никаких практических навыков (все на бумаге), но хорошее (в рамках школы) умение составлять и решать системы линейных уравнений. Лично мне такой оборот кажется гораздо интереснее, чем тупая реализация и оптимизация строго оговоренного алгоритма. А вот зачем это нужно организаторам конкурса, я не понимаю.

MAD\akukanov:

Осталось и Вам понять, что скорость работы программы - лишь один из факторов для победы в конкурсе. Так и в жизни, кстати - среди требований заказчика быстродействие может вовсе не являться самым главным; иначе не было бы метрик price/performance, watt/performance, usability и т.п.

Безусловно, Вы совершенно правы, для реальных заказных программ, как правило, существует множество требований, и быстродействие может быть лишь одним из многих. Однако любой подобный конкурс обречен на радикально искусственное упрощение списка факторов, влияющих на оценку. Согласно правилам, в данном конкурсе учитываются всего три фактора: изящность, производительность и TBB (дополнительные баллы за участие в форуме к программному продукту прямого отношения не имеют). Первый фактор (изящность) в правилах не определен, и я уже спрашивал, не считается ли образцом изящества программирование на С++? Остаются всего два четких фактора -производительность и TBB