Драфт C++0x [.pdf]. В нем будут делаться багфиксы, будут некоторые уточнения, но ничего принципиально нового уже не будет. Герб Саттер говорит, что это что-то вроде бета версии. Планируется, что после нее будет еще одна бета, а потом уже релиз.
среда, октября 29, 2008
Подписаться на:
Комментарии к сообщению (Atom)
Atom feed
24 коммент.:
это все хорошо, но много чего нужного не вошло - networking, file system manipulation и т.д. А без стандартной библиотеки всем приходится изобретать велосипеды :-(
VC10 уже поддерживает некоторые нововведения (lambda, auto, static_assert и rvalue references), но concepts поддерживаться не будут. Похоже, поддержки нового стандарта современными компиляторами придётся ждать как минимум 4 года…
че так все ждут его выхода. То что там будет - в общих словах уже всем известно. Ну выйдет стандарт, нам то как потребителям что с этого - еще пройдет куча времени пока выйдет компилятор с его поддержкой. (Скорее всего это будет g++)
> это что-то вроде бета версии. Планируется, что после нее будет еще одна бета, а потом уже релиз.
А Освящение когда?
2Alex Ott:
это все хорошо, но много чего нужного не вошло - networking, file system manipulation и т.д. А без стандартной библиотеки всем приходится изобретать велосипеды :-(
Меня очень огорчает, что с потоками они до конца не разобрались. Если какие-то отдельные вещи, но полной стандартизации не было.
2Alexey Bobyakov:
VC10 уже поддерживает некоторые нововведения
gcc тоже уже кое-что поддерживает.
2isagalaev:
А Освящение когда?
:-)
> Меня очень огорчает, что с потоками они до конца не разобрались.
Мне кажется, вы (плюсисты) не понимаете своего счастья. Народ в мире потихонечку приходит к мысли, что треды -- неудачный подход к параллельной обработке. Поэтому то, что их не вшили жестко в язык и не заставили всех их поддерживать -- это благо. Мне думается.
2isagalaev:
Мне кажется, вы (плюсисты) не понимаете своего счастья. Народ в мире потихонечку приходит к мысли, что треды -- неудачный подход к параллельной обработке.
Ну мое отношение к тредам тебе известно :-). Только с альтернативами-то плохо. Процессы? Они тоже не стандартизованы.
isagalaev> Имеете ввиду треды vs event-driven подход, или что-то еще?
А если говорить о плюсах, все равно на тредах написано очень много ценного (легаси) кода, и стандартная библиотека с синхронизацией и тредами здесь была бы очень полезна. А радикально переписывать этот код все равно никто не будет, проще цпп выкинуть.
D развивается семимильными шагами без геммороя с инcтитутами стандартизации, скоро он наберет критическую массу и молодое поколение плюсистов перейдут на него. кстати Александреску , уважаемый опытными плюсистами ныне один из архитекторов D, а C++ развивается слишком медленно, плюс траблы с обратной совместью с С
2Анонимный:
D развивается семимильными шагами без геммороя с инcтитутами стандартизации, скоро он наберет критическую массу и молодое поколение плюсистов перейдут на него
На С++ уже написано огромное количества библиотек и кода, который надо поддерживать. А это огромное количество рабочих мест. И это будет очень сложно забодать.
to Алёна
чем дальше, тем более данный факт будет все менее влиять на ситуацию.D стабилизируется, обрастает библиотеками, и лет через 5 думаю ситуация будет уже совсем другая.
если бы все было так оптимистично, то про кобол и фортран даже не вспоминали бы :-)
от того, что D обрастет библиотеками, старый код автоматом не перепишется
Хы хы!
По запросу в гугле draft c++0x этот твой пост на первом месте в выдаче оказывается!
2sad
По запросу в гугле draft c++0x этот твой пост на первом месте в выдаче оказывается!
Я знаменита! :-)
>от того, что D обрастет >библиотеками, старый код автоматом >не перепишется
Дело даже не в библиотеках и старом коде. Всё это не помешало победоносному шествию шарпа, например. Волосатая рука крупной компании решает. Потому что это развивающийся компилятор, совершенствующиеся средства отладки и т.п. Без всего этого язык не завоюет массы. Но чтобы забодать С++ и этого мало. Нужен очень оптимальный кодогенератор, решение основных проблем с менеджментом памяти, гибкий синтаксис, позволяющий дописать то, чего в языке не хватает.
dtjurev (ЖЖ авторизация почему-то не работает)
2isagalaev:
Мне кажется, вы (плюсисты) не понимаете своего счастья. Народ в мире потихонечку приходит к мысли, что треды -- неудачный подход к параллельной обработке.
Поставил чайник. Смотришь телик. Засвистел чайник, выключил, налил, смотришь дальше. Т.е. асинхронные операции. Сама идея потоков интуитивна. В чем минусы?
Поставил чайник. Смотришь телик. Засвистел чайник, выключил, налил, смотришь дальше. Т.е. асинхронные операции. Сама идея потоков интуитивна. В чем минусы?
Асинхронные операции -- это не обязательно потоки. И заблуждение думать, что потоки -- единственный способ делать что-то асинхронно. Самая большая проблема потоков -- это то, что по умолчанию доступ к общей памяти всем разрешен, и закрывается локами только точечно по факту того, что к этой точке памяти нельзя обращаться одновременно.
Во-первых это нарушает функциональную абстракцию. Обычно, если функция написана и отлажена, ее можно вызывать извне, зная, что она будет нормально работать. Треды нарушают это, потому что две такие функции, работающие параллельно могут обращаться к памяти друг друга в непредсказуемые моменты. А раз абстракция кусков программы в изолированные функции не работает, многотредные программы обычно растут только до того размера, пока умещаются в голове программиста целиком. По крайней мере, мой опыт показывает именно это.
Вторая большая проблема тредов -- потеря производительности на локах. Локов в большой программе становится много, потому что надо решать многочисленные проблемы из первого пункта. Часто локи ставятся "на всякий случай", потому что лучше перестраховаться, чем получить падающую программу с race condition'ами. Но захват и освобождение локов -- операции не бесплатные, и чем больше тредов одновременно работает, тем больше на это тратится времени. В результате программа большую часть времени тратит на то, чтобы закрывать и открывать локи.
В общем и целом народ сходится на том, что лучшая модель -- это процессы с раздельной памятью и обменом сообщениями в контроллируемые моменты времени. И кстати, в своем примере с чайником вы описали именно эту модель, заметив, что она выглядит естественно. В тредах было бы не так:
Поставил чайник. Смотришь телек. Каждую секунду выключаешь звук телека и слушаешь чайник. А если не дай бог чайник засвистит одновременно с работающим звуком телека, то его в лучшем случае будет просто не слышно, а в худшем он почему-то расплавится.
Асинхронные операции -- это не обязательно потоки. И заблуждение думать, что потоки -- единственный способ делать что-то асинхронно.
Этого не говорил, а Какие другие знаете?
Во-первых это нарушает функциональную абстракцию. Обычно, если функция написана и отлажена, ее можно вызывать извне, зная, что она будет нормально работать. Треды нарушают это, потому что две такие функции, работающие параллельно могут обращаться к памяти друг друга в непредсказуемые моменты.
Треды нарушают? А может ф-ия неидеальная, раз ее реализацией не предусмотрен вызов ее в нескольких тредах? И вообще слово "нарушают" - слишком сурово. В конце концов, треды и их контексты - костяк архитектуры многозадачности. Может их выбросить, раз уж они нарушают "функциональную абстракцию"? :)
"зная, что она будет нормально работать"... добавляю... в ситуации, когда не будет ее одновременных несинхронизированных вызовов в нескольких потоках. Треды виноваты или наша непредусмотрительность?
Если всё о том, что для таких ситуаций нам нужно дописывать ф-ию до состояния Thread-safe, то да, неприятно делать доролнительные действия, которые к семантике ф-ии не имеют отношения, а только обеспечат ей корректное выполнение во всех случаях.
А раз абстракция кусков программы в изолированные функции не работает, многотредные программы обычно растут только до того размера, пока умещаются в голове программиста целиком. По крайней мере, мой опыт показывает именно это.
Мне бывает достаточно знать пересечения тредов в плане доступа к общим ресурсам (память, как пример), т.к. это критично, их синхронизация.
Вторая большая проблема тредов -- потеря производительности на локах. Локов в большой программе становится много, потому что надо решать многочисленные проблемы из первого пункта. Часто локи ставятся "на всякий случай", потому что лучше перестраховаться, чем получить падающую программу с race condition'ами. Но захват и освобождение локов -- операции не бесплатные, и чем больше тредов одновременно работает, тем больше на это тратится времени.
Ну может в тех случаях, когда затраты процессорного времени на локи соизмеримы с временами выполнения "полезного" функционала.
Часто ли локи - существенная причина проседания? Интересно узнать примеры, когда это важно.
В результате программа большую часть времени тратит на то, чтобы закрывать и открывать локи.
БОльшую? Бывает и такой код, но часто ли? Думаю, что всё-таки, в большинстве случаев процессорное время тратится на исполнение "полезного" кода, а не блокировок, но таких оценок не делал, тем более, это очень сильно зависит от самого кода. Шифрование или дисковые операции, как пример.
Кстати, вроде ничё так статья
http://software.intel.com/en-us/articles/choosing-between-synchronization-primitives
В общем и целом народ сходится на том, что лучшая модель -- это процессы с раздельной памятью и обменом сообщениями в контроллируемые моменты времени.
Переключение процессов - более длительная операция, чем переключение контекстов потоков одного процесса.
И кстати, в своем примере с чайником вы описали именно эту модель, заметив, что она выглядит естественно. В тредах было бы не так:
Поставил чайник. Смотришь телек. Каждую секунду выключаешь звук телека и слушаешь чайник. А если не дай бог чайник засвистит одновременно с работающим звуком телека, то его в лучшем случае будет просто не слышно, а в худшем он почему-то расплавится.
"Каждую секунду выключаешь звук телека и слушаешь чайник."
А вы видите разницу с "процессы с раздельной памятью и обменом сообщениями в контроллируемые моменты времени"?
Цикла обработки сообщений нигде там нет? :)
а что насчет легковесных потоков аля Erlang ? там реально идет просто обмен сообщениями, и потоков можно запустить несколько тысяч без зависонов. в D подобную концепцию уже реализовывают
Очень много всего вкусного добавили в С++. Язык становится просто потрясающим.
По поводу D. ИМХО, язык не очень удачные. Кроме того, существует он уже достаточно давно, а результатов не видно. А C# это совсем другая история, он скорее конкурент java, чем С++...
Александреску, конечно, гуру, но слегка "своеобразен", даже Саттер немного подшучивает (очень по доброму)периодически над ним и его шаблономанией ;) . Например в "Exceptional c++ style"...
Относительно thread'ов. Я их не очень уважаю, но без прямой их поддержки С++ смотреться немного хуже...
2Анонимный:
а что насчет легковесных потоков аля Erlang ? там реально идет просто обмен сообщениями, и потоков можно запустить несколько тысяч без зависонов.
Я читала про эрланговские потоки, очень понравились. Это реализация потоков, как она должна быть.
Если их еще на CUDA можно было бы запускать, получилась бы вообще мегавещь :-)
Я потестировал на быстродействие D, .NET C#, Mono C#, Mono AOT(Ahead of Time) C# на одном простом примере милярд сложений с умножением одного аргумента и делением другого. Результат : время работы D = время работы C#(на любой платформе, и под линуксом и под виндоуз), а С++ в 4 раза быстрее. AOT в принцепе не помогает, одна секунда из 14.5 не результат.
Maniac wrote:
Самая большая проблема потоков -- это то, что по умолчанию доступ к общей памяти всем разрешен...
Ну что поделаешь... такая архитектура процессоров ) Причем это на самом деле не самая большая проблема.
закрывается локами только точечно по факту того, что к этой точке памяти нельзя обращаться одновременно.
Да, точечно, по необходимости, а не все сразу. Причем совсем необязательно "нельзя обращаться одновременно", вполне оба потока могут читать из одного буфера, заблокировав его с доступом на чтение.
многотредные программы обычно растут только до того размера, пока умещаются в голове программиста целиком. По крайней мере, мой опыт показывает именно это.
Вопрос дизайна.
Во-первых это нарушает функциональную абстракцию.
Каким образом?
потому что две такие функции, работающие параллельно могут обращаться к памяти друг друга в непредсказуемые моменты.
Непонятно, к какой "памяти друг друга" )) Имеются в виду общие ресурсы?
А раз абстракция кусков программы в изолированные функции не работает, ...
Что-то я не понял... декомпозиция задачи на подзадачи не работает в случае потоков? Имхо прекрасно работает, каждая подзадача выполняет свой объем работ, при необходимости синхронизируясь с другими подзадачами. Отличие от event-driven system минимально.
Вторая большая проблема тредов -- потеря производительности на локах. Локов в большой программе становится много, потому что надо решать многочисленные проблемы из первого пункта. Часто локи ставятся "на всякий случай", потому что лучше перестраховаться, чем получить падающую программу с race condition'ами.
Да, это верно, причем в большой степени число локов зависит от структуры системы.
Но захват и освобождение локов -- операции не бесплатные, и чем больше тредов одновременно работает, тем больше на это тратится времени. В результате программа большую часть времени тратит на то, чтобы закрывать и открывать локи.
Не надо демонизировать локи... они используются только там, где необходимо расшарить ресурс. Захват лока - операция практически бесплатная (закрывать локи - тем более), ожидание ресурса - это да... но это вопрос дизайна и оптимального распределения ресурсов по потокам. Обычно стремятся к тому, чтобы минимизировать число общих ресурсов (например, thread domains).
В общем и целом народ сходится на том, что лучшая модель -- это процессы с раздельной памятью и обменом сообщениями в контроллируемые моменты времени.
Я не знаю, что за народ там сходится :-D я думаю, что народ скорее сойдется на том, что переключение контекстов процессов гораздо более дорогостоящая операция, чем смена контекстов потоков.
Поставил чайник. Смотришь телек. Каждую секунду выключаешь звук телека и слушаешь чайник. А если не дай бог чайник засвистит одновременно с работающим звуком телека, то его в лучшем случае будет просто не слышно, а в худшем он почему-то расплавится.
Это называется polling )) какое он имеет отношение к потокам? А гудок чайника - сработавшее событие/аппаратное прерывание... поток, ожидающий на событии, времени не потребляет, спит спокойно, и именно в этом плюс.
Вопрос - какие реальные альтернативы многопоточности?
классный обзор. .но серверная ява быстрее сей..
После других языков на сей обратно не хочется, в основном из-за юзабилити. Слишком мелочный он какой-то.
Отправить комментарий