Что, господа суровые С++ программисты, поспорим быстродействием с отстойной Джавой? ;)

Nikita> Ну разумеется, потому что Вы напишите её только к концу жизни Вселенной

определенно ... потому что даже начинать не буду ...

Nikita> Ерунда. Сделаете действительно крутой софт - к Вам все сразу прибегут. И всё будет сделано за Вас

ох что-то не верится мне что кто-то что-то будет делать за меня ...

Nikita> Мы про "простой текстовый редактор". Который на самом деле настолько непрост, что никто пока даже и близко не подобрался к нему.

а - ну да ... а notepad не оно, нет ?

Nikita> Отличный пример!!! Java-клиент полностью портабельный и работает везде где эта самая Java есть, а вот uTorrent - Windows-only.

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

V.Stepan> На текущий момент Java-клиенты могут работать только под виндой.

во - хороший пример "портабельности"

Nikita> Механизм поддержки написания итераторов в C# относится к разряду "синтаксического сахара". То бишь мы ваяем какой-то очень простой код, а за кадром происходит жуткий разврат: прямо в MSIL генерится куча каких-то классов, методов, всяческого оборачивающего кода и т.д.
Nikita> В нашем случае процесс выглядит примерно так: генерится код для сохранения/восстановления контекста нашего метода - локальные переменные, данные для поддержки наших using/try/catch/finally; генерится машина состояний, для отслеживания на каком yield return'е мы сейчас находимся; генерится Dispose() для поддержки using/try/catch/finally (кстати, распространённая грабля; когда итератор берут не foreach/using, а "руками", и забывают что он IDisposable)

Nikita> AsyncEnumerator ae = new AsyncEnumerator();
Nikita> ae.Execute(HtmlToFile(
Nikita> ae,
Nikita> "http://www.Wintellect.com/",
Nikita> "LocalFile.html"));

типичная энтерпрайзнутая #бля мозгов себе и окружающим ... из совершенно простой задачи наворотили столько фигни ... уж сколько там ошибок и как это отлаживать вообще сложно представить ...

Balancer> Преимущества Java не в коде. А в системе.

Когда употребляются такие слова как C/C++, Java, C#, то разумеется речь идёт о языке как части соответствующей платформы. "Сферический язык в вакууме" никакого интереса не представляет, странно что приходится это объяснять...

Nikita> Ничего подобного. Это 100% проблемы ПО. Такие железки уже стояли бы у нас на столах, если бы мы умели их нормально программировать.

вот опятьже, а зачем ? ... чтобы качать файл из интернета в 64 потока, каждый из которых будет 99,9% времени проводить в ожидании ввода/вывода ...

Nikita> "Сферический язык в вакууме" никакого интереса не представляет, странно что приходится это объяснять...

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

А редкие конкретные примеры тут же разбиваются абстрактными обобщениями.

Сергей-4030> Ну да. Если что-то ходит, как утка и крякает, как утка, но кажется Никите слоном - значит, это слон.

Вы по теме скажите что-нибудь.

Сергей-4030> Ах препроцессор, как способ расширения языка...

"The implementation can process and skip sections of source files conditionally, include other source files, and replace macros. These capabilities are called preprocessing, because conceptually they occur before translation of the resulting translation unit."

Вот так стандарт определяет возможности препроцессора. А #pragma определяется как implementation-defined конструкция, и в случае OpenMP она работает на фазе трансляции, бо ей нужна семантическая информация. И если Вы включите в том же VC++ генерацию preprocessed-кода, то увидите, что #pragma никуда не развёртываются, а остаются в своей исходной форме.

*Вы меня удручаете, Сергей-4030. Ваши представления о C/C++ находятся на уровне первокурсника прочитавшего какую-нибудь книжку из серии "для чайников"

Сергей-4030> Как бы то ни было,

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

Сергей-4030> Ну, покажите класс, за чем дело стало?

Мне сейчас сложно показать класс на Java, бо я уже три года на ней не пишу и не совершенствуюсь. Но могу показать класс на C# 3.0 Интересно ?

Nikita>> Ерунда. Сделаете действительно крутой софт - к Вам все сразу прибегут. И всё будет сделано за Вас
anonymous_lor> ох что-то не верится мне что кто-то что-то будет делать за меня ...

А зря. Это ведь всего лишь элементарное разделение труда, и выгода его очевидна.

Nikita>> Мы про "простой текстовый редактор". Который на самом деле настолько непрост, что никто пока даже и близко не подобрался к нему.
anonymous_lor> а - ну да ... а notepad не оно, нет ?

Вы ещё vi предложите, что мелочиться-то...

*М-да, и эти люди пишут софт... Я, конечно, вижу такую ерунду постоянно, но до сих пор не могу понять и принять такое отношения к профессии, к пользователям, к коллегам...

anonymous_lor> вот опятьже, а зачем ? ... чтобы качать файл из интернета в 64 потока, каждый из которых будет 99,9% времени проводить в ожидании ввода/вывода ...

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

Например, нормальная IDE: с IntelliSense; code inspector'ами; могучими интегрированными отладчиками всех уровней; средствами разработки удобных, эффективных, красивых UI; средствами рефакторинга, анализа, моделирования, тестирования, профилировки всего этого добра; средствами поддержки разработки в группе и т.д. Только одна эта задача требует огромной вычислительной мощи, и её решение невозможно без эффективных средств поддержки параллелизма в языках/платформах.

Nikita> Как загрузить такую штуку на полную катушку и при этом эффективно ? Допустим для задачи блочного умножения матриц ? Когда количество логических потоков в алгоритме плавает в зависимости от шага ? А ежели у нас параллельно на этой штуке запущен пяток виртуальных машин ? Да ещё и виртуализация приоритизированная ? То бишь с постоянно меняющимся количеством ядер на ВМ в зависимости от условий ? И нужно на ходу перестраивать расклад алгоритма ? Как Вы будете всё это добро на thread'ах программить ???
С трудом. Но буду А как, интересно, не на thread'ах это программировать? Осваивать новые концепции? Нейронные сети с нефиксированной топологией?

Balancer> Во-первых, у нас в проекте параллельных модификаций хэш-таблиц (а также списков) не меньше, чем чтений,

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

Balancer> во-вторых, и на параллельном чтении ConcurrentHashTable у нас был медленнее, чем FastTable.

Так вот и пишите, что "медленнее был". Lock'и-то тут причём ? Консенсус.

Balancer> А так - параллельная работа с объектами требует особых объектов же, но при это м трудно назывыть ConcurrentHashMap отдельным пакетом, так как он входит в стандартную библиотеку.

Это он сейчас входит.

Nikita> Вы ещё vi предложите, что мелочиться-то...

а что ... vim и emacs люди и сейчас пользуются, в том числе и для разработки программ ...

Nikita> *М-да, и эти люди пишут софт...

ровно тоже самое я могу сказать и про вас ... лично мне немного страшно пользоваться программой в которой есть что-то подобное ...
Nikita> AsyncEnumerator ae = new AsyncEnumerator();
Nikita> ae.Execute(HtmlToFile(
Nikita> ae,
Nikita> "http://www.Wintellect.com/",
Nikita> "LocalFile.html"));

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

на ум приходит только работа с огромными обемами данных ... типа перекодирования видео ...

Nikita> Например, нормальная IDE: с IntelliSense; code inspector'ами; могучими интегрированными отладчиками всех уровней; средствами разработки удобных, эффективных, красивых UI; средствами рефакторинга, анализа, моделирования, тестирования, профилировки всего этого добра; средствами поддержки разработки в группе и т.д. Только одна эта задача требует огромной вычислительной мощи, и её решение невозможно без эффективных средств поддержки параллелизма в языках/платформах.

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

..
Nikita> ..Но могу показать класс на C# 3.0 Интересно ?

Безусловно. Я-то как раз на C# пишу.. (правда к сожалению класс показать не могу)

Kernel3> С трудом. Но буду А как, интересно, не на thread'ах это программировать?

Так же как и всегда. Придумать более высокоуровневый язык. Мы же вот пишем сейчас на всяких C++/Java/C#, а ведь ещё совсем недавно народ всё колбасил в голимом машинном коде.

И здесь ровно то же самое. Thread'ы, примитивы синхронизации - это машинный код параллелизма. Да, можно на нём писать, только вот зачем ?

Kernel3> Осваивать новые концепции?

Конечно. Проблема только в том, что пока тут ещё поле непаханное. Можете посмотреть StreamIt, например, как одно из направлений. Вобщем работы навалом. Однако вместо того чтобы думать, изобретать, пробовать, ошибаться, пробовать снова, большинство ведет себя как anonymous_lor...

Nikita> Так же как и всегда. Придумать более высокоуровневый язык. Мы же вот пишем сейчас на всяких C++/Java/C#, а ведь ещё совсем недавно народ всё колбасил в голимом машинном коде.
Nikita> И здесь ровно то же самое. Thread'ы, примитивы синхронизации - это машинный код параллелизма. Да, можно на нём писать, только вот зачем ?
Аа. Ну, это называется переложить всю работу на разработчиков компиляторов/платформ. В принципе, выход, да Для большинства В данном-то случае "синтаксический сахар" (с) внутри, очевидно, будет реализован на потоках. Я к этому, собственно

Kernel3> Аа. Ну, это называется переложить всю работу на разработчиков компиляторов/платформ.

Разработчики платформ решат только одну сложную задачу. Однако её решение позволит другим решать на порядки более сложные задачи.

Kernel3> В принципе, выход, да Для большинства

Вы можете предложить другой вариант ?

Kernel3>> Аа. Ну, это называется переложить всю работу на разработчиков компиляторов/платформ.
Nikita> Разработчики платформ решат только одну сложную задачу. Однако её решение позволит другим решать на порядки более сложные задачи.
Ага.
Kernel3>> В принципе, выход, да Для большинства
Nikita> Вы можете предложить другой вариант ?
А я с этим не спорю Типа, выяснение терминологии.

anonymous_lor> вот вы это все зачем придумали ? ...

Я ничего не придумываю. Я описал реальную задачу для реальной библиотеки. Вы представляете как выглядит код этой C/C++ либы ?

anonymous_lor> тоесть просто ради того чтобы было, а не чтоб пользоваться ...

Именно для того, чтобы пользоваться. Реальное ПО это Вам не Hello World...

anonymous_lor> вот опять что-то напридумывали ... непонятно зачем ...

Я ничего не придумываю. Это всё было на самом деле. Пока под мобилы можно было писать только на этих жутких C/C++ SDK - отрасль стояла раком. Как только пошла поддержка J2ME - на рынке мгновенно начался бум, и вышла масса отличных приложений.

sxam>>> Nikita, не понял, как yield return помогает с "асинхронным I/O"?
Nikita>> ..
Nikita>> Надеюсь что-то понятно Рихтер пишет лучше меня, поэтому почитайте http://msdn.microsoft.com/en-us/magazine/cc546608.aspx
sxam> Спасибо! Завтра поторможу немного, надеюсь пойму.

Прочитал.
Хитро
Про такое использование yield я, конечно, не думал

V.Stepan>> Положа руку на серде - ну неужели ни разу не встречал:
Balancer> На самом деле всё проще. Я давно для оценки уровня языка не смотрю на качество проектов на нём. Корреляция тут убедительная отсутствует.
А как же классическое:
"Теория, мой друг, суха,
Но зеленеет жизни древо"
и
"Практика - критерий истины"?

Nikita>> Вы ещё vi предложите, что мелочиться-то...
anonymous_lor> а что ... vim и emacs люди и сейчас пользуются,

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

anonymous_lor> в том числе и для разработки программ ...

Вот в том числе поэтому мы и имеем такие программы какие имеем.

*Кстати, ещё один штрих отлично характеризующий Ваш уровень. В 2008 году человек разрабатывающий ПО считает, что текстовый редактор это софт "в том числе и для разработки программ"...

anonymous_lor> ровно тоже самое я могу сказать и про вас ... лично мне немного страшно пользоваться программой в которой есть что-то подобное ...
Nikita>> AsyncEnumerator ae = new AsyncEnumerator();
Nikita>> ae.Execute(HtmlToFile(
Nikita>> ae,
Nikita>> "http://www.Wintellect.com/",
Nikita>> "LocalFile.html"));

Совершенно не понимаю, что Вас так напугало. Два оператора, вся семантика как на ладони. Если Вы её не понимаете, то я бы порекомендовал Вам сменить профессию. Принесёте меньше вреда...

Или Вы мечтаете о shell-скрипте с вызовом wget ?

anonymous_lor> типичная энтерпрайзнутая #бля мозгов себе и окружающим ...

Ничего подобного, это просто Ваша безграмотность, необразованность и непрофессионализм..

anonymous_lor> из совершенно простой задачи наворотили столько фигни ...

Это пример. Задача же звучит так: "максимально эффективное I/O при минимальных затратах на разработку". Вы не можете сообразить где это нужно ?

anonymous_lor> уж сколько там ошибок и как это отлаживать вообще сложно представить ...

Гы! Параллелизм и асинхронное I/O это Вам не фигушки воробьям. И Вы вот просто боитесь подступаться к этим проблемам, потому как действительно, если решать такие задачи на C/C++, то "уж сколько там ошибок и как это отлаживать вообще сложно представить"...

А вот на C# это делается влёт, как было продемонстрировано. И отлаживается с минимальными затруднениями. Но можно сделать ещё лучше и проще, если, например, специально доточить механизм yield return (который был придуман совсем для другого) в этом направлении.

Сергей-4030>> Ну да. Если что-то ходит, как утка и крякает, как утка, но кажется Никите слоном - значит, это слон.
Nikita> Вы по теме скажите что-нибудь.

Что ж вам еще сказать. Есть имплементации систем, использующих треды, но не использующие util.concurrent. И не просто использующих, а повышающих эффективность и/или упрощающих дизайн многократно за счет использования тредов. Для вас же если util.concurrent не используют, значит и multithreading им не нужен. С таким определением, конечно, легко получить вывод, что без util.concurrent никакого multithreading нету.

Сергей-4030>> Ах препроцессор, как способ расширения языка...
Nikita> "The implementation can process and skip sections of source files conditionally, include other source files, and replace macros. These capabilities are called preprocessing, because conceptually they occur before translation of the resulting translation unit."
Nikita> Вот так стандарт определяет возможности препроцессора. А #pragma определяется как implementation-defined конструкция, и в случае OpenMP она работает на фазе трансляции, бо ей нужна семантическая информация. И если Вы включите в том же VC++ генерацию preprocessed-кода, то увидите, что #pragma никуда не развёртываются, а остаются в своей исходной форме.

И что? Я не понял, что с того? pragma есть указания компилятору, pragma ничем концептуально не отличается от задания ключей компилятора. Или вы и с этим несогласны?

Nikita> *Вы меня удручаете, Сергей-4030. Ваши представления о C/C++ находятся на уровне первокурсника прочитавшего какую-нибудь книжку из серии "для чайников"

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

Сергей-4030>> Как бы то ни было,
Nikita> Как бы то ни было, а Ваше утверждение об "исключительности" и "незначительности" - ложно. Только у Microsoft это десятки миллиардов долларов продаж ежегодно.

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

Сергей-4030>> Ну, покажите класс, за чем дело стало?
Nikita> Мне сейчас сложно показать класс на Java, бо я уже три года на ней не пишу и не совершенствуюсь. Но могу показать класс на C# 3.0 Интересно ?

Ага, вот как. Ну, покажите на C# 3.0, очень будет интересно.

ЗЫ А в каком направлении вообще будет двигаться показ класса? UML нам напишете и design specifications? Ума не приложу, как это на чисто алгоритмической задачке вы будете это все показывать. Ну да посмотрим, учение - свет, будем рады просветиться.

PS Я нигде не сказал, что C# - отстой или что util.concurrent не нужен. С# - мощная платформа, а util.concurrent - очень полезная библиотека.