tag:blogger.com,1999:blog-10303035.post27634178848784965..comments2024-02-04T23:20:04.066+03:00Comments on Алёна C++: Опубликован драфт C++0xAlenahttp://www.blogger.com/profile/09389124127364799922noreply@blogger.comBlogger24125tag:blogger.com,1999:blog-10303035.post-56371218589515572262008-12-10T00:43:00.000+03:002008-12-10T00:43:00.000+03:00классный обзор. .но серверная ява быстрее сей..Пос...классный обзор. .но серверная ява быстрее сей..<BR/>После других языков на сей обратно не хочется, в основном из-за юзабилити. Слишком мелочный он какой-то.foregroundhttps://www.blogger.com/profile/11320766351507712662noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-87656827205295180522008-11-29T01:14:00.000+03:002008-11-29T01:14:00.000+03:00Maniac wrote:Самая большая проблема потоков -- это...<B>Maniac wrote:</B><BR/><I>Самая большая проблема потоков -- это то, что по умолчанию доступ к общей памяти всем разрешен...</I><BR/>Ну что поделаешь... такая архитектура процессоров ) Причем это на самом деле не самая большая проблема.<BR/><BR/><I>закрывается локами только точечно по факту того, что к этой точке памяти нельзя обращаться одновременно.</I><BR/>Да, точечно, по необходимости, а не все сразу. Причем совсем необязательно "нельзя обращаться одновременно", вполне оба потока могут читать из одного буфера, заблокировав его с доступом на чтение.<BR/><BR/><BR/><I> многотредные программы обычно растут только до того размера, пока умещаются в голове программиста целиком. По крайней мере, мой опыт показывает именно это.</I><BR/>Вопрос дизайна.<BR/><BR/><I>Во-первых это нарушает функциональную абстракцию.</I><BR/>Каким образом?<BR/><BR/><I>потому что две такие функции, работающие параллельно могут обращаться к памяти друг друга в непредсказуемые моменты.</I><BR/>Непонятно, к какой "памяти друг друга" )) Имеются в виду общие ресурсы?<BR/><BR/><I>А раз абстракция кусков программы в изолированные функции не работает, ... </I><BR/>Что-то я не понял... декомпозиция задачи на подзадачи не работает в случае потоков? Имхо прекрасно работает, каждая подзадача выполняет свой объем работ, при необходимости синхронизируясь с другими подзадачами. Отличие от event-driven system минимально.<BR/><BR/><I>Вторая большая проблема тредов -- потеря производительности на локах. Локов в большой программе становится много, потому что надо решать многочисленные проблемы из первого пункта. Часто локи ставятся "на всякий случай", потому что лучше перестраховаться, чем получить падающую программу с race condition'ами. </I><BR/>Да, это верно, причем в большой степени число локов зависит от структуры системы.<BR/><BR/><I>Но захват и освобождение локов -- операции не бесплатные, и чем больше тредов одновременно работает, тем больше на это тратится времени. В результате программа большую часть времени тратит на то, чтобы закрывать и открывать локи.</I><BR/>Не надо демонизировать локи... они используются только там, где необходимо расшарить ресурс. Захват лока - операция практически бесплатная (закрывать локи - тем более), ожидание ресурса - это да... но это вопрос дизайна и оптимального распределения ресурсов по потокам. Обычно стремятся к тому, чтобы минимизировать число общих ресурсов (например, thread domains).<BR/><BR/><I>В общем и целом народ сходится на том, что лучшая модель -- это процессы с раздельной памятью и обменом сообщениями в контроллируемые моменты времени.</I><BR/>Я не знаю, что за народ там сходится :-D я думаю, что народ скорее сойдется на том, что переключение контекстов процессов гораздо более дорогостоящая операция, чем смена контекстов потоков.<BR/><BR/><I>Поставил чайник. Смотришь телек. Каждую секунду выключаешь звук телека и слушаешь чайник. А если не дай бог чайник засвистит одновременно с работающим звуком телека, то его в лучшем случае будет просто не слышно, а в худшем он почему-то расплавится.</I><BR/>Это называется polling )) какое он имеет отношение к потокам? А гудок чайника - сработавшее событие/аппаратное прерывание... поток, ожидающий на событии, времени не потребляет, спит спокойно, и именно в этом плюс.<BR/><BR/>Вопрос - какие реальные альтернативы многопоточности?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-37850940891248619662008-11-28T20:04:00.000+03:002008-11-28T20:04:00.000+03:00Я потестировал на быстродействие D, .NET C#, Mono ...Я потестировал на быстродействие D, .NET C#, Mono C#, Mono AOT(Ahead of Time) C# на одном простом примере милярд сложений с умножением одного аргумента и делением другого. Результат : время работы D = время работы C#(на любой платформе, и под линуксом и под виндоуз), а С++ в 4 раза быстрее. AOT в принцепе не помогает, одна секунда из 14.5 не результат.NotACodeMonkeyhttps://www.blogger.com/profile/16552173399882951705noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-65437432021721149502008-11-12T16:05:00.000+03:002008-11-12T16:05:00.000+03:002Анонимный:а что насчет легковесных потоков аля Er...<B>2Анонимный:</B><BR/><I>а что насчет легковесных потоков аля Erlang ? там реально идет просто обмен сообщениями, и потоков можно запустить несколько тысяч без зависонов. </I><BR/><BR/>Я читала про эрланговские потоки, очень понравились. Это реализация потоков, как она должна быть.<BR/><BR/>Если их еще на CUDA можно было бы запускать, получилась бы вообще мегавещь :-)Alenahttps://www.blogger.com/profile/09389124127364799922noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-13916186513193641192008-11-12T14:32:00.000+03:002008-11-12T14:32:00.000+03:00Очень много всего вкусного добавили в С++. Язык ст...Очень много всего вкусного добавили в С++. Язык становится просто потрясающим.<BR/>По поводу D. ИМХО, язык не очень удачные. Кроме того, существует он уже достаточно давно, а результатов не видно. А C# это совсем другая история, он скорее конкурент java, чем С++...<BR/>Александреску, конечно, гуру, но слегка "своеобразен", даже Саттер немного подшучивает (очень по доброму)периодически над ним и его шаблономанией ;) . Например в "Exceptional c++ style"...<BR/>Относительно thread'ов. Я их не очень уважаю, но без прямой их поддержки С++ смотреться немного хуже...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-82729940608336218582008-11-11T09:31:00.000+03:002008-11-11T09:31:00.000+03:00а что насчет легковесных потоков аля Erlang ? там ...а что насчет легковесных потоков аля Erlang ? там реально идет просто обмен сообщениями, и потоков можно запустить несколько тысяч без зависонов. в D подобную концепцию уже реализовываютAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-30436116735065072362008-11-05T02:32:00.000+03:002008-11-05T02:32:00.000+03:00Асинхронные операции -- это не обязательно потоки....<I>Асинхронные операции -- это не обязательно потоки. И заблуждение думать, что потоки -- единственный способ делать что-то асинхронно. </I><BR/>Этого не говорил, а Какие другие знаете?<BR/><BR/><I>Во-первых это нарушает функциональную абстракцию. Обычно, если функция написана и отлажена, ее можно вызывать извне, зная, что она будет нормально работать. Треды нарушают это, потому что две такие функции, работающие параллельно могут обращаться к памяти друг друга в непредсказуемые моменты.</I><BR/>Треды нарушают? А может ф-ия неидеальная, раз ее реализацией не предусмотрен вызов ее в нескольких тредах? И вообще слово "нарушают" - слишком сурово. В конце концов, треды и их контексты - костяк архитектуры многозадачности. Может их выбросить, раз уж они нарушают "функциональную абстракцию"? :)<BR/>"зная, что она будет нормально работать"... добавляю... в ситуации, когда не будет ее одновременных несинхронизированных вызовов в нескольких потоках. Треды виноваты или наша непредусмотрительность?<BR/>Если всё о том, что для таких ситуаций нам нужно дописывать ф-ию до состояния Thread-safe, то да, неприятно делать доролнительные действия, которые к семантике ф-ии не имеют отношения, а только обеспечат ей корректное выполнение во всех случаях.<BR/><BR/><I>А раз абстракция кусков программы в изолированные функции не работает, многотредные программы обычно растут только до того размера, пока умещаются в голове программиста целиком. По крайней мере, мой опыт показывает именно это.</I><BR/>Мне бывает достаточно знать пересечения тредов в плане доступа к общим ресурсам (память, как пример), т.к. это критично, их синхронизация.<BR/><BR/><I>Вторая большая проблема тредов -- потеря производительности на локах. Локов в большой программе становится много, потому что надо решать многочисленные проблемы из первого пункта. Часто локи ставятся "на всякий случай", потому что лучше перестраховаться, чем получить падающую программу с race condition'ами. Но захват и освобождение локов -- операции не бесплатные, и чем больше тредов одновременно работает, тем больше на это тратится времени.</I> <BR/>Ну может в тех случаях, когда затраты процессорного времени на локи соизмеримы с временами выполнения "полезного" функционала. <BR/>Часто ли локи - существенная причина проседания? Интересно узнать примеры, когда это важно.<BR/><BR/><I>В результате программа большую часть времени тратит на то, чтобы закрывать и открывать локи.</I><BR/>БОльшую? Бывает и такой код, но часто ли? Думаю, что всё-таки, в большинстве случаев процессорное время тратится на исполнение "полезного" кода, а не блокировок, но таких оценок не делал, тем более, это очень сильно зависит от самого кода. Шифрование или дисковые операции, как пример.<BR/><BR/>Кстати, вроде ничё так статья<BR/>http://software.intel.com/en-us/articles/choosing-between-synchronization-primitives<BR/><BR/><I>В общем и целом народ сходится на том, что лучшая модель -- это процессы с раздельной памятью и обменом сообщениями в контроллируемые моменты времени.</I><BR/>Переключение процессов - более длительная операция, чем переключение контекстов потоков одного процесса.<BR/><BR/><I>И кстати, в своем примере с чайником вы описали именно эту модель, заметив, что она выглядит естественно. В тредах было бы не так:<BR/>Поставил чайник. Смотришь телек. Каждую секунду выключаешь звук телека и слушаешь чайник. А если не дай бог чайник засвистит одновременно с работающим звуком телека, то его в лучшем случае будет просто не слышно, а в худшем он почему-то расплавится.</I><BR/><BR/>"Каждую секунду выключаешь звук телека и слушаешь чайник."<BR/>А вы видите разницу с "процессы с раздельной памятью и обменом сообщениями в контроллируемые моменты времени"?<BR/>Цикла обработки сообщений нигде там нет? :)Vitalyhttps://www.blogger.com/profile/02975471885421793475noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-47687949163027364762008-11-04T21:28:00.000+03:002008-11-04T21:28:00.000+03:00Поставил чайник. Смотришь телик. Засвистел чайник,...<I>Поставил чайник. Смотришь телик. Засвистел чайник, выключил, налил, смотришь дальше. Т.е. асинхронные операции. Сама идея потоков интуитивна. В чем минусы?</I><BR/><BR/>Асинхронные операции -- это не обязательно потоки. И заблуждение думать, что потоки -- единственный способ делать что-то асинхронно. Самая большая проблема потоков -- это то, что по умолчанию доступ к общей памяти всем разрешен, и закрывается локами только точечно по факту того, что к этой точке памяти нельзя обращаться одновременно. <BR/><BR/>Во-первых это нарушает функциональную абстракцию. Обычно, если функция написана и отлажена, ее можно вызывать извне, зная, что она будет нормально работать. Треды нарушают это, потому что две такие функции, работающие параллельно могут обращаться к памяти друг друга в непредсказуемые моменты. А раз абстракция кусков программы в изолированные функции не работает, многотредные программы обычно растут только до того размера, пока умещаются в голове программиста целиком. По крайней мере, мой опыт показывает именно это.<BR/><BR/>Вторая большая проблема тредов -- потеря производительности на локах. Локов в большой программе становится много, потому что надо решать многочисленные проблемы из первого пункта. Часто локи ставятся "на всякий случай", потому что лучше перестраховаться, чем получить падающую программу с race condition'ами. Но захват и освобождение локов -- операции не бесплатные, и чем больше тредов одновременно работает, тем больше на это тратится времени. В результате программа большую часть времени тратит на то, чтобы закрывать и открывать локи.<BR/><BR/>В общем и целом народ сходится на том, что лучшая модель -- это процессы с раздельной памятью и обменом сообщениями в контроллируемые моменты времени. И кстати, в своем примере с чайником вы описали именно эту модель, заметив, что она выглядит естественно. В тредах было бы не так:<BR/><BR/>Поставил чайник. Смотришь телек. Каждую секунду выключаешь звук телека и слушаешь чайник. А если не дай бог чайник засвистит одновременно с работающим звуком телека, то его в лучшем случае будет просто не слышно, а в худшем он почему-то расплавится.Ivan Sagalaevhttps://www.blogger.com/profile/08658726720189436784noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-39422503495854813782008-11-04T15:38:00.000+03:002008-11-04T15:38:00.000+03:002isagalaev:Мне кажется, вы (плюсисты) не понимаете...<B>2isagalaev:</B><BR/><I>Мне кажется, вы (плюсисты) не понимаете своего счастья. Народ в мире потихонечку приходит к мысли, что треды -- неудачный подход к параллельной обработке. </I><BR/>Поставил чайник. Смотришь телик. Засвистел чайник, выключил, налил, смотришь дальше. Т.е. асинхронные операции. Сама идея потоков интуитивна. В чем минусы?Vitalyhttps://www.blogger.com/profile/02975471885421793475noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-46835272226696563722008-11-03T14:09:00.000+03:002008-11-03T14:09:00.000+03:00>от того, что D обрастет >библиотеками, стар...>от того, что D обрастет >библиотеками, старый код автоматом >не перепишется<BR/><BR/>Дело даже не в библиотеках и старом коде. Всё это не помешало победоносному шествию шарпа, например. Волосатая рука крупной компании решает. Потому что это развивающийся компилятор, совершенствующиеся средства отладки и т.п. Без всего этого язык не завоюет массы. Но чтобы забодать С++ и этого мало. Нужен очень оптимальный кодогенератор, решение основных проблем с менеджментом памяти, гибкий синтаксис, позволяющий дописать то, чего в языке не хватает.<BR/><BR/>dtjurev (ЖЖ авторизация почему-то не работает)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-62581308240716160002008-10-30T21:20:00.000+03:002008-10-30T21:20:00.000+03:002sadПо запросу в гугле draft c++0x этот твой пост ...<B>2sad</B><BR/><I>По запросу в гугле draft c++0x этот твой пост на первом месте в выдаче оказывается!</I><BR/><BR/>Я знаменита! :-)Alenahttps://www.blogger.com/profile/09389124127364799922noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-67449989746525625432008-10-30T17:45:00.000+03:002008-10-30T17:45:00.000+03:00Хы хы!По запросу в гугле draft c++0x этот твой пос...Хы хы!<BR/>По запросу в гугле draft c++0x этот твой пост на первом месте в выдаче оказывается!sadhttps://www.blogger.com/profile/17717428922027050177noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-14343498706283867412008-10-30T17:43:00.000+03:002008-10-30T17:43:00.000+03:00если бы все было так оптимистично, то про кобол и ...если бы все было так оптимистично, то про кобол и фортран даже не вспоминали бы :-)<BR/>от того, что D обрастет библиотеками, старый код автоматом не перепишетсяAlex Otthttps://www.blogger.com/profile/13001951608173211050noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-48647356570070829212008-10-30T17:32:00.000+03:002008-10-30T17:32:00.000+03:00to Алёначем дальше, тем более данный факт будет вс...to Алёна<BR/><BR/>чем дальше, тем более данный факт будет все менее влиять на ситуацию.D стабилизируется, обрастает библиотеками, и лет через 5 думаю ситуация будет уже совсем другая.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-81264924281117914892008-10-30T17:23:00.000+03:002008-10-30T17:23:00.000+03:002Анонимный:D развивается семимильными шагами без г...<B>2Анонимный:</B><BR/><I>D развивается семимильными шагами без геммороя с инcтитутами стандартизации, скоро он наберет критическую массу и молодое поколение плюсистов перейдут на него</I><BR/><BR/>На С++ уже написано огромное количества библиотек и кода, который надо поддерживать. А это огромное количество рабочих мест. И это будет очень сложно забодать.Alenahttps://www.blogger.com/profile/09389124127364799922noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-90259922502106554332008-10-30T16:53:00.000+03:002008-10-30T16:53:00.000+03:00D развивается семимильными шагами без геммороя с и...D развивается семимильными шагами без геммороя с инcтитутами стандартизации, скоро он наберет критическую массу и молодое поколение плюсистов перейдут на него. кстати Александреску , уважаемый опытными плюсистами ныне один из архитекторов D, а C++ развивается слишком медленно, плюс траблы с обратной совместью с СAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-64093975080085772752008-10-29T19:52:00.000+03:002008-10-29T19:52:00.000+03:00isagalaev> Имеете ввиду треды vs event-driven п...isagalaev> Имеете ввиду треды vs event-driven подход, или что-то еще?<BR/><BR/>А если говорить о плюсах, все равно на тредах написано очень много ценного (легаси) кода, и стандартная библиотека с синхронизацией и тредами здесь была бы очень полезна. А радикально переписывать этот код все равно никто не будет, проще цпп выкинуть.lrrrhttps://www.blogger.com/profile/12742106367384624657noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-77332638946865605042008-10-29T19:29:00.000+03:002008-10-29T19:29:00.000+03:002isagalaev:Мне кажется, вы (плюсисты) не понимаете...<B>2isagalaev:</B><BR/><I>Мне кажется, вы (плюсисты) не понимаете своего счастья. Народ в мире потихонечку приходит к мысли, что треды -- неудачный подход к параллельной обработке. </I><BR/><BR/>Ну мое отношение к тредам тебе известно :-). Только с альтернативами-то плохо. Процессы? Они тоже не стандартизованы.Alenahttps://www.blogger.com/profile/09389124127364799922noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-4133192556799098162008-10-29T18:42:00.000+03:002008-10-29T18:42:00.000+03:00> Меня очень огорчает, что с потоками они до ко...> Меня очень огорчает, что с потоками они до конца не разобрались.<BR/><BR/>Мне кажется, вы (плюсисты) не понимаете своего счастья. Народ в мире потихонечку приходит к мысли, что треды -- неудачный подход к параллельной обработке. Поэтому то, что их не вшили жестко в язык и не заставили всех их поддерживать -- это благо. Мне думается.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-90292844954935840922008-10-29T17:30:00.000+03:002008-10-29T17:30:00.000+03:002Alex Ott:это все хорошо, но много чего нужного не...<B>2Alex Ott:</B><BR/><BR/><I>это все хорошо, но много чего нужного не вошло - networking, file system manipulation и т.д. А без стандартной библиотеки всем приходится изобретать велосипеды :-(</I><BR/><BR/>Меня очень огорчает, что с потоками они до конца не разобрались. Если какие-то отдельные вещи, но полной стандартизации не было.<BR/><BR/><B>2Alexey Bobyakov:</B><BR/><I>VC10 уже поддерживает некоторые нововведения</I><BR/><BR/>gcc тоже уже кое-что поддерживает.<BR/><BR/><B>2isagalaev:</B><BR/><I>А Освящение когда?</I><BR/><BR/>:-)Alenahttps://www.blogger.com/profile/09389124127364799922noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-84588603983350319802008-10-29T15:18:00.000+03:002008-10-29T15:18:00.000+03:00> это что-то вроде бета версии. Планируется, чт...> это что-то вроде бета версии. Планируется, что после нее будет еще одна бета, а потом уже релиз.<BR/><BR/>А Освящение когда?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-2784486276471193762008-10-29T14:57:00.000+03:002008-10-29T14:57:00.000+03:00че так все ждут его выхода. То что там будет - в о...че так все ждут его выхода. То что там будет - в общих словах уже всем известно. Ну выйдет стандарт, нам то как потребителям что с этого - еще пройдет куча времени пока выйдет компилятор с его поддержкой. (Скорее всего это будет g++)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-91120125278170270392008-10-29T14:55:00.000+03:002008-10-29T14:55:00.000+03:00VC10 уже поддерживает некоторые нововведения (lamb...VC10 уже <A HREF="http://blogs.msdn.com/vcblog/archive/2008/10/28/lambdas-auto-and-static-assert-c-0x-features-in-vc10-part-1.aspx" REL="nofollow">поддерживает</A> некоторые нововведения (<B>lambda</B>, <B>auto</B>, <B>static_assert</B> и <B>rvalue references</B>), но concepts поддерживаться не будут. Похоже, поддержки нового стандарта современными компиляторами придётся ждать как минимум 4 года…Anonymoushttps://www.blogger.com/profile/00195363512347208156noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-42822325958012581772008-10-29T14:46:00.000+03:002008-10-29T14:46:00.000+03:00это все хорошо, но много чего нужного не вошло - n...это все хорошо, но много чего нужного не вошло - networking, file system manipulation и т.д. А без стандартной библиотеки всем приходится изобретать велосипеды :-(Alex Otthttps://www.blogger.com/profile/13001951608173211050noreply@blogger.com