Nikita: Все сообщения за 19 Июля 2008 года

Сергей-4030> Мгновенно? Практика вас благополучно опровергает.

С точностью до наоборот. Практика добавила java.util.concurent в стандартную библиотеку.

Сергей-4030> Вполне благополучно во многих и многих приложениях та оптимизация, которая вам кажется абсолютно необходимой попросту не нужна.

Значит им и многопоточность не нужна. Всё очень просто.

Сергей-4030> А какие основания сомневаться?

Читайте переписку комитета, публикации его участников... То что уже 2008 год на дворе, а нового стандарта до сих пор нет это ведь не просто так...

Сергей-4030> Но тем не менее из сишного кода сишному компилятору неизвестно, что это код предназначен для параллельного исполнения.

Неправда. В случае OpenMP #pragma как раз именно способ расширения языка. И при этом во многих случаях даже совместимость получается сохранить. Кто не понимает OpenMP, тот получит обычный последовательный код.

Сергей-4030> Ага. Майкрософт, конечно, большой. Но в процентах ко всей индустрии ПО - совсем не так уж.

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

Сергей-4030> Ну тогда укажите, что вам казалось бы полезным. Принимая во внимание необходимость оптимизации по скорости. Дабы было о чем говорить. java.util.concurrent?

java.util.concurrent это где-то в конце самом. Я бы начал с дизайна приложения. И с методологии разработки...

•  23
•  инфо
•  инструменты
• Ответить на сообщение

Balancer> Ну, мы, например, очень давно отказались от j.u.c в пользу javolution.

Как пакет зовётся это уже неважно, важно что он есть и нужен.

Balancer> Очень уж у concurrent.HashTable оверхед на залочках большой

Ничего не понял. java.util.concurrent.ConcurrentHashMap на чтение не блокируется. А количество потоков способных без блокировки одновременно работать на запись управляется соответствующим параметром.

•  2
•  инфо
•  инструменты
• Ответить на сообщение

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

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

•  1
•  инфо
•  инструменты
• Ответить на сообщение

Сергей-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 Интересно ?

•  21
•  инфо
•  инструменты
• Ответить на сообщение

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

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

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

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

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

•  2
•  инфо
•  инструменты
• Ответить на сообщение

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

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

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

•  2
•  инфо
•  инструменты
• Ответить на сообщение

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

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

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

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

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

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

•  инфо
•  инструменты
• Ответить на сообщение

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

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

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

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

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

•  3
•  инфо
•  инструменты
• Ответить на сообщение

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

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

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

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

•  1
•  инфо
•  инструменты
• Ответить на сообщение

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

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

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

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

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

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

•  2
•  инфо
•  инструменты
• Ответить на сообщение

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 (который был придуман совсем для другого) в этом направлении.

•  инфо
•  инструменты
• Ответить на сообщение

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

Каков ум, таковы и результаты...

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

Ну что тут можно сказать, видимо масштаб Ваших работ никогда не выходил за пределы "Hello, World!". И Вы даже не представляете какое ПО существует (и разрабатывается) в мире...

•  инфо
•  инструменты
• Ответить на сообщение

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

Это правда.

Сергей-4030> Для вас же если util.concurrent не используют, значит и multithreading им не нужен.

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

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

С этим несогласен стандарт. Ещё раз повторяю: реакция на #pragma является implementation-defined. Компилятор волен делать что угодно. В случае OpenMP #pragma являются расширением языка. Можете считать их операторами.

Вот как выглядит Ваш код портированный (за 10 минут) на C++/OpenMP:

1.     static int solve(const int size, bool checkTransitions) {
2.         setLimits(size, false, checkTransitions);
3.         known_positions.clear();
4.         solution_pointer = 0;
5.  
6. #pragma omp parallel for num_threads(size)
7.         for (int i = 0; i < size; i++) {
8.             Solution s(i);
9.             s.arrange();
10.         }
11.  
12.         return solution_pointer;
13.     }

1. #pragma omp critical
2. {
3.             if ((!CHECK_TRANSITIONS) || (known_positions.end() == known_positions.find(desk))) {
4.                 addKnownPosition(desk);
5.                 solutions[solution_pointer++] = desk;
6.                 result = true;
7.             }
8. }

Теперь расскажите как такое сделать ключами компилятора

*А ведь ещё совсем недавно Вы издевались над Eretik'ом: "Я про С++ знаю более-менее все ... Вы же про Яву читаете из бульварных журналов" Как выяснилось, на самом деле обе стороны достойны друг друга

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

Не извиняю. Мои проекты не имеют никакого отношения к вопросам знания языка/платформы.

*Чисто для справки. Свой крайний коммерческий проект на C++ я выполнил ещё до принятия стандарта Потом работал в основном с Java во всех её ипостасях. Ну а три года назад перешёл на .NET (направление и скорость развития Java перестали меня устраивать)

Сергей-4030> Но ее главная направленность - операционные системы и продукты для "десктопного" пользователя, что накладывает отпечаток. И такая направленность - отнюдь не самая распространенная, более того - вполне исключительная.

Чушь. Десктопных приложений навалом, это мэйнстрим, как на массовом бытовом рынке, так и в enterprise'е.

Сергей-4030> ЗЫ А в каком направлении вообще будет двигаться показ класса?

Ну-у-у, например, полагаю интересно будет показать как выглядят unit test'ы и соответствующие фрэймворки на топовой платформе.

Сергей-4030> UML нам напишете и design specifications? Ума не приложу, как это на чисто алгоритмической задачке вы будете это все показывать.

Как раз вычислительные задачи и требуют самых точных спецификаций. Только не в том смысле в каком Вы их себе представляете. Слышали такие термины: "корректность", "частичная корректность", "предусловие", "постусловие", "инвариант", "сходимость", "устойчивость" ???

•  17
•  инфо
•  инструменты
• Ответить на сообщение