Для чего используется C++? [Re: [C++] как явно отличить ]
Не только в играх, во многих областях, где важна скорость. Ну например, обсчёт сложных моделей.
Не только в играх, во многих областях, где важна скорость. Ну например, обсчёт сложных моделей.
Потом, операционные системы (да, я в курсе про Линукс) вместе со своими программами.
От (хороших) игр, кстати, и до более серьёзных разработок недалеко.
Ну например, обсчёт сложных моделей.там больше фортран используется?
VMWare?
Потом, операционные системы (да, я в курсе про Линукс) вместе со своими программами.эээээ, ты не оджил?
эээээ, ты не оджил?
Следи за словами. Хамить не надо.
Я имел в виду всевозможные Office-ы, Acrobat-ы, Winamp-ы и т.д.
оо на джаве вроде 
оо на джаве вродеНет. Там Java и C++, причём второго в несколько раз больше, чем первого.
полный бред. имхо, кроме геймдева у него применений не осталось.И откуда у людей такая информация? Большое количество mail и search серверов с высокой нагрузкой сделаны на C/C++, по крайней мере в рунете. Ядра баз данных, рендеринга GUI, алгоритмы для переработки среднего и большого количества информации (тот же justification текста ядра самых используемых layout engines (gecko и trident и этот список можно продолжать ещё очень долго.
оо на джаве вродеУпс, а что такое "оо"?
OpenOffice, наверное.
Большое количествопочти все что ты перечислил, корнями уходит еще в 90-е, понятно что оно на C/C++
насколько я понимаю, сейчас примерно переход как от асм-а к C++/паскаль/фортран и т.д.
только теперь переход идет уже от C++.
т.е. низ/старые наработки на C++, а новье/верх уже пишут на C#/Java/Javascript и т.д.
только теперь переход идет уже от C++.
т.е. низ/старые наработки на C++, а новье/верх уже пишут на C#/Java/Javascript и т.д.
вроде свежих c++ проектов хватает. Тот же git, Paludis например.
git на c++?
не на c?
open source проекты чаще используют c, насколько я знаю
не на c?
open source проекты чаще используют c, насколько я знаю
вроде свежих c++ проектов хватает. Тот же git, Paludis например.и какие им преимущества дал С/C++?
имхо, там C/C++ - только потому, что его знали разработчики.
хм, преимущества перед чем? Какой-то холивар получается. Перед явой - скорость работы. Как бы для этого и создавался paludis - чтобы перестать тормозить и отказаться от питона. Я в код не заглядывал, но судя по тому, что в зависимостях стоял boost, шаблонным метапрограммированием люди не брезгуют.
Перед явой - скорость работы. Как бы для этого и создавался paludis - чтобы перестать тормозить и отказаться от питона.а где в пакет менеджере Java может тормозить?
имхо, здесь на скорость скорее влияют алгоритмы, чем язык (единственная расчетная задача - это обработка зависимостей - в крайнем случае, этот алгоритм можно было вынести в C++)
ps
у питона (и иже) может быть еще сам момент старта более долгий, но опять же как раз это можно было и решить.
а где в пакет менеджере Java может тормозить?Сам спросил, сам ответил. Обработка нехилой базы пакетов, версий и зависимостей.
имхо, здесь на скорость скорее влияют алгоритмы, чем язык (единственная расчетная задача - это обработка зависимостей - в крайнем случае, этот алгоритм можно было вынести в C++)
Можешь объяснить мне, какие преимущества мы получили бы, разделив бы проект на два языка, как ты предлагаешь?
Можешь объяснить мне, какие преимущества мы получили бы, разделив бы проект на два языка, как ты предлагаешь?имхо, как раз всякие хитрости проще делать на чем-нибудь повыше.
портировать кстати тоже проще было бы: спортировать фрейморк (а он уже скорее всего спортирован) + пересобрать чисто расчетную либу, а так надо весь system портировать: файлы, треды, синхронизацию и т.д.
для последнего вроде уже давно есть портируемые либы.
для последнего вроде уже давно есть портируемые либы.вот именно что вроде: так сразу не скажу кто держит что-нибудь типа: linix, *bsd, windows, solaris
насколько я понимаю, сейчас примерно переход как от асм-а к C++/паскаль/фортран и т.д.Ага. Вот и получается, что layout 1мб текста с картинками IE делает меньше чем за секунду, а WPF FlowDocumentScrollViewer - за пол минуты. И кому это надо? Никуда от Си++ не денутся, вы пророчите ему смерть вот уже лет пять или шесть, как я тусуюсь в девелопменте.
только теперь переход идет уже от C++.
т.е. низ/старые наработки на C++, а новье/верх уже пишут на C#/Java/Javascript и т.д.
люди, которые занимаются кросс программированием наверняка знают какие либы нужно юзать. То, что предлагаешь ты не намного удобнее: написать свой интерфейс общения java-c++ только для того, чтобы в яве управлять файлами и потоками. Получается, что вместо нативной приплюснутой либы мы банально используем яву.
Получается, что вместо нативной приплюснутой либы мы банально используем яву.да, потому что java всяко стандартнее, чем какая-то приплюснутая либа...
Никуда от Си++ не денутся, вы пророчите ему смерть вот уже лет пять или шесть, как я тусуюсь в девелопменте.если судить по форумам, то уже умирает.
например, в этом форуме, из C/C++ - молодежи, либо ученики, которые делает расчетные задачи, либо хардкор-фанаты метапрограммирования типа .
если судить по форумам, то уже умираетНачну с тобой соглашаться, когда хотя бы простенькие GUI решения на C# перестанут тормозить.
да, потому что java всяко стандартнее, чем какая-то приплюснутая либа...ну если ты опсаешься нестандартного поведения либы, то можно её статикой вставлять
Начну с тобой соглашаться, когда хотя бы простенькие GUI решения на C# перестанут тормозить.дык, даже достаточно сложный gui на .net бегает с той скоростью, что достаточно для пользователя.
где ты увидел критические тормоза?
Net - он же вроде под линукс не портирован/криво портирован. Лучше рассматривать гуи на яве, будет более показательно. Чистое гуи работает быстро, полное приложение на яве - медленно.
.Net - он же вроде под линукс не портирован/криво портированчто значит криво портирован?
Лучше рассматривать гуи на яве, будет более показательно.Gui на java - тормознее, потому что сама java такая.
дык, даже достаточно сложный gui на .net бегает с той скоростью, что достаточно для пользователя.Если ты хочешь сделать не "достаточный для пользователя", а качественный GUI, то в случае Windows Forms тебе придётся долго допиливать напильником. В случае с WPF - ждать нового патча, потому что это поделие совершенно сырое, несмотря на свои 3 года возраста. Я уже писал о производительности контролов, вполне себе стандартных для современной GUI технологии.
где ты увидел критические тормоза?
Кроме того, я не согласен, что все названные мною области применения C++ относятся к 90-ым годам. Многие вполне современные высокопроизводительные серверы разрабатываются именно на C/C++, о Java/C# там речи даже не идёт.
Edit: я об этом всём знаю, потому что пол года общался с человеком, который знает (знал) внутреннее устройство многих высоконагруженных рунетовских ресурсов.
что значит криво портирован?значит с отставанием по версии и неполнотой фич. То есть ничем не лучше слабостандартизированных библиотек для c++.
Gui на java - тормознее, потому что сама java такая.быть может и тормознее, но работает уже достаточно быстро. Тут вроде уже упоминался опенофис.
так сразу не скажу кто держит что-нибудь типа: linix, *bsd, windows, solarisнавскидку - apr (Apache Portable Runtime) и nspr (Netscape Portable Runtime)
Многие вполне современные высокопроизводительные серверы разрабатываются именно на C/C++, о Java/C# там речи даже не идёт.угу, сам работаю с подобным поделием - проектировалось 2 года назад.
убил бы на%уй и архитектора, и программистов, у которых, оказывается, традиция не комментировать их говнокод. Конкуренты по-человечески пишут на Java/Python/etc, а мы как ебанаты боремся с утечками памяти и по полгода выкатываем новые фичи.
а качественный GUI, то в случае Windows Forms тебе придётся долго допиливать напильником.в чем отличие от C++?
на C++ весь этот качественный gui обычно еще и падает
например, по крайней мере, все известные мне коммерческие grid-ы еще года четыре назад портили память.
В случае с WPF - ждать нового патча, потому что это поделие совершенно сырое, несмотря на свои 3 года возрастапонятно, что сырое.
но так можно использовать пока winforms.
в чем отличие от C++?В современной практике он падает из-за того, что как ты любишь говорить, нету бинарной совместимости. Какая-нибудь лажа, из реальной практики: вызываются деструкторы глобальных переменных, отрабатывают на сингтонах Qt, которые не отвязываются от колбэков openssl dll, который всё ещё загружен из-за libcurl, из-за которого эти колбэки всё ещё вызываются, и всё падает.
на C++ весь этот качественный gui обычно еще и падает
например, по крайней мере, все известные мне коммерческие grid-ы еще года четыре назад портили память.
Впрочем Qt - то ещё сиподобное гавнецо.А вот у меня падает WPF RichTextBox. Сначала он для 300 маленьких картинок размером меньше 512 байт каждая выделяет 150МБ памяти, а потом во время ресайза окна умирает. Не всегда, но в одном случае из десяти. А в виртуальной машине Java, ещё три года назад утекала память. Это разговор ни о чём.
Конкуренты по-человечески пишут на Java/Python/etc, а мы как ебанаты боремся с утечками памяти и по полгода выкатываем новые фичи.Боюсь, что такие разработчики и на Java/Python/etc. будут бороться с чем-нибудь.
Нет. Там Java и C++, причём второго в несколько раз больше, чем первого.А вообще java там нужна для чего-нибудь? Я его всегда без поддержки java использовал, поэтому и не знаю.
А вот у меня падает WPF RichTextBox. Сначала он для 300 маленьких картинок размером меньше 512 байт каждая выделяет 150МБ памяти, а потом во время ресайза окна умирает.вот видишь ты хотя бы можешь описать ситуацию когда это происходит, и как-то сделать, чтобы это не допускать - например, неиспользовать 300 маленьких картинок
а вот C++, когда падает, то внешне хрен поймешь, что ему не понравилось.
вот видишь ты хотя бы можешь описать ситуацию когда это происходит, и как-то сделать, чтобы это не допускать - например, неиспользовать 300 маленьких картинокВ том то и беда, что могу описать, а исправить не могу. Мне просто критически необходимо, чтобы эти картинки были на своём месте. А тут задача не решается просто из-за того, что этого не позволяет сделать фреймворк (который нельзя исправить и до внутренностей которого нельзя добраться) и/или виртуальная машина (которую опять же нельзя исправить).
а вот C++, когда падает, то внешне хрен поймешь, что ему не понравилось.
А вот на Си++ я смогу исправить всё. И даже если надо будет что-то переписывать или напильником допиливать, то там рукой подать до системного уровня.
А вот на Си++ я смогу исправить всё. И даже если надо будет что-то переписывать или напильником допиливать, то там рукой подать до системного уровня.я считаю это опасным и ненужным заблуждением, что можно объять необъятное.
как минимум у тебя еще есть проблемы на уровне ОС, драйвера, процессора, железа.
т.е. я признаю, что чужие модули могут быть не идеальны, но мне нужно, чтобы они вели себя при этом адекватно (понятно как возникает проблема, и внешний инструмент достаточный гибкий, чтобы это можно было обойти)
на C++ очень тяжело делать модули с адекватным поведение
ps
я правильно, тебя понял, что если ты увидешь, что mysql начал падать на твоем запросе, то ты залезешь в исходники mysql, разберешься, поправишь и пересоберешь его из исходников?
как минимум у тебя еще есть проблемы на уровне ОС, драйвера, процессора, железа.Задача отобразить текст с картинками успешно решалась ещё на 386dx33. И для этого не надо было идти править какой-то код.
т.е. я признаю, что чужие модули могут быть не идеальны, но мне нужно, чтобы они вели себя при этом адекватно (понятно как возникает проблема, и внешний инструмент достаточный гибкий, чтобы это можно было обойти)И причём тут Си++? Дискуссия опять свелась к ранее повторявшимся вещам. Я два года пилил напильником проект на C#/DevExpress и каждый раз "адекватные модули" находили новый способ привести GUI в нерабочее состояние. И хотя многие мои проекты на Си++ не падают, ещё спорный вопрос, что лучше: остаться работать в состоянии, когда программой вообще нельзя пользоваться или грохнуться, отправить дамп разработчикам и перезапуститься.
я правильно, тебя понял, что если ты увидешь, что mysql начал падать на твоем запросе, то ты залезешь в исходники mysql, разберешься, поправишь и пересоберешь его из исходников?
Когда-то я так сделал. (Падал на слэшах в винде.) Но сейчас у меня на всё это нету времени. И C# никак не даёт мне это время сэкономить. И пока он не даёт хотя бы этого, Си++ жив и будет жить.
Чистое гуи работает быстро, полное приложение на яве - медленно.примеры?
вот азуреус например, очень быстро все работает
у меня там 500 фильмов включено с разных торрент серверов, он их и скачивает и выкачивает и графики при этом всякие рисует
и все очень быстро
Задача отобразить текст с картинками успешно решалась ещё на 386dx33. И для этого не надо было идти править какой-то код.не используй wpf
C# здесь причем?
И причём тут Си++?а причем здесь c#?
ты говоришь, что ты взял самую новую либу, и она тебя чем-то не устроила на твоих задачах
если спор все-таки идет C++ vs C#, то я утверждаю, что ошибки есть и там, и там, но на C# делать надежные модули проще (даже при наличие ошибок в других модулях).
вот азуреус например, очень быстро все работаетМюторрент быстрее. И в азуреусе интерфейс медленный, который не простой.
Мюторрент быстрее. И в азуреусе интерфейс медленный, который не простой.я не понимаю что значит быстрее
ко мне фильм быстрее прилетит? не понимаю почему вдруг
смотрю на трафик - все 10 мбит используются по полной, может конечно некторые байты и теряются - но это не серьезно
интерфейс медленный? что это значит? у меня на 500 фильмах абсолютно никаких тормозов
и у меня совсем обычный комп по нынешним меркам
или мюторрент просто меньше проца ест? ну не знаю
азуреус в пик свой около 30% ест, мне не жалко, я hdtv фильмы при этом смотрю без всяких тормозов
не используй wpfПри том, что тут некоторые напирают на язык+фреймворки для языка. Что, конечно, логично, и будь эти фреймворки хоть немного впереди Си++сных, ещё можно было бы начать заикаться о смерти С++.
C# здесь причем?
а причем здесь c#?И с чего бы отсюда следовал вывод, что Си++ умирает? Возьмём, например, докризисную задачу от РБК: разработать xmpp сервер с нагрузкой до 5.000.000 пользователей одновременно. Какой C#, какая Java, здесь язык один и это Си/Си++, и ни о каком умирании речи быть не может.
ты говоришь, что ты взял самую новую либу, и она тебя чем-то не устроила на твоих задачах
если спор все-таки идет C++ vs C#, то я утверждаю, что ошибки есть и там, и там, но на C# делать надежные модули проще (даже при наличие ошибок в других модулях).
имхо, кроме геймдева у него применений не осталось.А можете предложить альтернативу С++ для обработки и сжатия видео? Чтобы можно было DirectShow фильтры писать?
вот азуреус например, очень быстро все работаетАзуреус использует SWT - достаточно простые биндинги к нэйтив апи. Это, естественно, не тормозит и не может тормозить. Но обычно требует большого количества доработок.
разработать xmpp сервер с нагрузкой до 5.000.000 пользователей одновременноя не достаточно компетентен в таких вопросах, но вроде в .NET есть особая фича - пулы приложений. которая позволяет выделять/жрать меньше ресурсов на каждое соединение с клиентом, чем в традиционной реализации на с++
И с чего бы отсюда следовал вывод, что Си++ умирает? Возьмём, например, докризисную задачу от РБК: разработать xmpp сервер с нагрузкой до 5.000.000 пользователей одновременно. Какой C#, какая Java, здесь язык один и это Си/Си++, и ни о каком умирании речи быть не может.почему java/.net для этого не подойдут?
пулы приложенийЕдинственное определение "пула приложений", которое приходит в голову мне, никак не связано с поставленной задачей.
ну там вроде что-то типа того, что не нужно создавать процесс на каждого пользователя/каждое подключение, а создадим всего-лишь нить, и несколько нитей в один процесс запихнем и получим экономию. возможно я не правильно понял задачу
почему java/.net для этого не подойдут?похоже он считает, что не справятся из-за высокой нагрузки
почему java/.net для этого не подойдут?Ну потому что в Java, например, скорость выделения объектов я могу регулировать параметром командной строки "-Xmx". Потому что когда C# переезжает жить в своп, работа программы похожа на скорость перемещения маленькой черепашки. Потому что если в любой из виртуальных машин есть какая-то скрытая особенность, которая покажет себя при такой высокой нагрузке, ситуацию ты уже никак не исправишь. И так далее. Причём C++ это вообще не мой выбор и не моя идея, в рунете есть люди, которые занимались серверами с такой нагрузкой (на разных технологиях и языках программирования) и представляют, что к чему.
ну там вроде что-то типа того, что не нужно создавать процесс на каждого пользователя/каждое подключение, а создадим всего-лишь нить, и несколько нитей в один процесс запихнем и получим экономию. возможно я не правильно понял задачуНикто и не собирался этого делать. То, о чём ты пишешь, это процессно-потоковый подход, который вообще слабо подходит для решения задач такого уровня, если ты конечно не используешь вместо потоков фиберы и их линуксовые аналоги. Причём у C# по сравнению с C++ в данном случае никаких преимуществ нет.
примеры?вот, замечательный пример. В своё время делал выбор, каким torrent клиентом пользоваться. Тогда был azureus второй серии. Собственно в полтора раза больше процессора жрал и в два с половиной раза больше памяти, чем uTorrent. Это и решило.
вот азуреус например, очень быстро все работает
А ещё могу рекомендовать сравнить скорость работы Rational Rose и Rational Software Atchitect. Производитель один, цели одни, разнятся реализации. Второе тормозит значительно больше первого. Да, на современных компах уже работают удоволетворительно, но я полагаю, что ресурсы лишними не бывают.
И с чего бы отсюда следовал вывод, что Си++ умирает? Возьмём, например, докризисную задачу от РБК: разработать xmpp сервер с нагрузкой до 5.000.000 пользователей одновременно.
гыгы
чуваки не осилили эрланг?
почему java/.net для этого не подойдут?Кстати, вот пример успешного проекта на .NET именно в этой области. Описание одной из проблем, с которой столкнулись разработчики: http://www.coversant.net/Coversant/Blogs/tabid/88/EntryID/9/Default.aspx Я читал отзывы и советы этих ребят на форумах, они описывают разные проблемы, которые возникали у них. В целом им удалось стабильно поддерживать 20к соединений на одном сервере.
В целом им удалось стабильно поддерживать 20к соединений на одном сервере.это на 32-битном, на 64 - много, много больше
причем насколько я понял - это скорее ограничение windows, а не .net.
Every time your application creates a new Socket, Windows pulls memory from it's Nonpaged Kernel memory, which is simply physical memory that is reserved by the kernel and will never be paged out to disk
В целом им удалось стабильно поддерживать 20к соединений на одном сервере.здесь пишут, что стресс тесты у них гоняют до 100тыс
http://www.coversant.net/Products/SoapBoxServer/Features/tab...
Scalability
Independently verified tests show SoapBox Server 2007 Enterprise Edition scales to over 100,000 simultaneous users on a single machine. The server is designed for high traffic volumes.
здесь пишут, что стресс тесты у них гоняют до 100тысЕсли почитать их блоги и посты на форумах, то становится понятно, что это больше маркетинг, чем реальность. Но нам-то нужны нагрузки гораздо выше, чем 100к.
а вот здесь пишут, что по масштабируемости на 64-битной архитектуре у них ограничений нет
http://www.coversant.com/Coversant/Blogs/tabid/88/EntryID/10...
The SoapBox Server scales to a frightening number of simultanious users. This is due to the inherent scalability of Windows Sockets and .NET, as well as the architecture chosen inside the application. With the arrival of 64 bit hardware, .Net 2.0, and the addition of some blood, sweat and tears, it appears that the SoapBox Server can vertically scale high enough to handle any load that is realistically going to be thrown at it.
http://www.coversant.com/Coversant/Blogs/tabid/88/EntryID/10...
The SoapBox Server scales to a frightening number of simultanious users. This is due to the inherent scalability of Windows Sockets and .NET, as well as the architecture chosen inside the application. With the arrival of 64 bit hardware, .Net 2.0, and the addition of some blood, sweat and tears, it appears that the SoapBox Server can vertically scale high enough to handle any load that is realistically going to be thrown at it.
Если почитать их блоги и посты на форумах, то становится понятно, что это больше маркетинг, чем реальность. Но нам-то нужны нагрузки гораздо выше, чем 100к.скорее это реальность
если у них ограничение по виртуалке, и 20тыс соединений на 2гб
то уж сделать 10 гб виртуалки на 64 бит проблем не составляет.
Если почитать их блоги и посты на форумах, то становится понятно, что это больше маркетинг, чем реальность. Но нам-то нужны нагрузки гораздо выше, чем 100к.а на какой железке это должно крутиться?
Ps
кстати xmpp-сервер что должен делать? получить сообщение и сразу отдать его другому, или еще что-то с ним сделать, куда-то отдать и т.д.?
скорее это реальностьТы забываешь про другие проблемы: нагрузку на процессор из-за GC, implicit locks, и так далее. И заключение, которое человек делает в своём блоге - философское. Ты бы лучше прочитал всё, что там написано.
если у них ограничение по виртуалке, и 20тыс соединений на 2гб
то уж сделать 10 гб виртуалки на 64 бит проблем не составляет.
кстати xmpp-сервер что должен делать? получить сообщение и сразу отдать его другому, или еще что-то с ним сделать, куда-то отдать и т.д.?Получение сообщения от клиента может закончиться чем угодно: от DNS запроса до сохранения offline сообщения в хранилище или добавления пользователя в базу.
Ребята тестировали свой сервер до 100к пользователей (до 500к соединений) в лабораторных условиях, реальность гораздо жёстче.
а в чем проблема вообще распилить xmpp-сервак по юзерам?
дг тут пишет про неограниченную масштабируемость на 64-битной архитектуре.
а масштабировать-то и нечего, распилил по любому ключу и поставил за проксю.
а 4 гига на 20к соединений — это по 200к на соединение. это что, так мало, что надо этим гордиться?
что там в xmpp такого на 200к хранить надо в быстром доступе?
дг тут пишет про неограниченную масштабируемость на 64-битной архитектуре.
а масштабировать-то и нечего, распилил по любому ключу и поставил за проксю.
а 4 гига на 20к соединений — это по 200к на соединение. это что, так мало, что надо этим гордиться?
что там в xmpp такого на 200к хранить надо в быстром доступе?
дг тут пишет про неограниченную масштабируемость на 64-битной архитектуре.Такие решения тоже требуют масштабирования. Только уже других мест: прокси, межсерверного взаимодействия, и т.п. Ну и в том числе кошелька заказчика.
а масштабировать-то и нечего, распилил по любому ключу и поставил за проксю.
а 4 гига на 20к соединений — это по 200к на соединение. это что, так мало, что надо этим гордиться?
В Win32 эта цифра 3 гига. Этим никто не гордится, разработчики это приводят как факт. Хранить можно гораздо меньше, просто в .NET есть оверхед на данные, причём иногда весьма приличный, а в Си++ его бы не было.
да прокся-то в последнюю очередь поломается.
а какое в xmpp межсерверное взаимодействие?
а какое в xmpp межсерверное взаимодействие?
а какое в xmpp межсерверное взаимодействие?Это instant messanging протокол. Ты предложил распилить один сервер на части. Значит, эти серверы должны будут взаимодействовать между собой и с хранилищем, причём весьма активно. (Кроме того, по стандарту они обязаны уметь взаимодействовать и с другими серверами, но это не относится к задаче.)
так оно же по юзерам хорошо локализуется. хранится все локально на каждом из кусков, а между собой они
через проксю говорят по аналогии с обращением на другие сервера. т.е. друг о друге вообще ничего не знают.
вроде никаких проблем не вылезет, если сделать так.
(я так понимаю, именно поэтому существует успешная реализация на эрланге?).
т.е. зачем серверу, который обслуживает васю, знать о локальных данных пети?
через проксю говорят по аналогии с обращением на другие сервера. т.е. друг о друге вообще ничего не знают.
вроде никаких проблем не вылезет, если сделать так.
(я так понимаю, именно поэтому существует успешная реализация на эрланге?).
т.е. зачем серверу, который обслуживает васю, знать о локальных данных пети?
так оно же по юзерам хорошо локализуется. хранится все локально на каждом из кусков, а между собой ониНу так я и говорю, что при большом количестве пользователей у этого кластера могут возникнуть проблемы. Если сделать просто распределённую программу, это может значительно повысить производительность и снизить требования к сети и компьютерам.
через проксю говорят по аналогии с обращением на другие сервера. т.е. друг о друге вообще ничего не знают.
т.е. зачем серверу, который обслуживает васю, знать о локальных данных пети?
Если он их не знает, то ему придётся обращаться на сервер, который это знает. При этом обоим серверам придётся уведомлять друг-друга о событиях этих двух пользователей. Изменение статуса Пети должно уйти на сервер Васи. Так что здесь огромное поле для улучшения scalability.
я так понимаю, именно поэтому существует успешная реализация на эрланге?
Не знаю, насколько ejabberd успешен, но РБК сначала от него отказалось после тестирования. Впрочем, сейчас у них работает как раз массив ejabberd, т.к. из-за кризиса они отказались от всех новых проектов.
а что значит "просто распределенная программа"?
а что значит "просто распределенная программа"?Некоторым образом отличное от предложенного тобою решения, если я правильно тебя понял.
не, ну о сферических конях совсем не интересно разговаривать.
поэтому в рбк эрланг и работает, а не какое-то эфемерное распределенное приложение.
поэтому в рбк эрланг и работает, а не какое-то эфемерное распределенное приложение.
не, ну о сферических конях совсем не интересно разговаривать.Ну это и не сферические кони, ты просто задаёшь странные вопросы. Чем может отличаться кластер модулей распределённого сервера от прокси с кластером обычных серверов? В способе обмена данными, в меньшем объёме этих данных, в меньшем количестве продублированных данных, в сложности разработки, и так далее.
я не знаю, как устроен "распределенный сервер". =)
я не знаю, как устроен "распределенный сервер". =)Могу только предложить погуглить.
в гугле по запросу "распределенный сервер" лидирует глупая простыня "Распределенный сервер и круговой DNS".
там написано, что распределять нагрузку можно с помощью DNS. получается балансировка, но плохая, потому что все серверы рАЗныЕ.
там написано, что распределять нагрузку можно с помощью DNS. получается балансировка, но плохая, потому что все серверы рАЗныЕ.
в гугле по запросу "распределенный сервер" лидирует глупая простыня "Распределенный сервер и круговой DNS".Ну а ты поищи по другим словам, которые там сверху написаны.
где? какие слова? я не понимаю!
Впрочем, сейчас у них работает как раз массив ejabberd, т.к. из-за кризиса они отказались от всех новых проектов.какой порядок денег они хотели потратить на разработку сервера про который ты говоришь (с 5 млн. юзеров)?
Сетевые службы всегда представляют собой распределенные программы. Распределенная программа - это программа, которая состоит из нескольких взаимодействующих частей (в приведенном на рис. 1.5 примере - из двух причем каждая часть, как правило, выполняется на отдельном компьютере сети.
: DD
: DD
а что значит "просто распределенная программа"?фактически - это тоже самое, что ты и предложил, но с основным отличием, что программа-сервер изначально знает, что она может быть запущена в таком виде (в виде нескольких параллельных экземпляров
и соответственно этот факт активно использует в своей работе, добиваяь большей оптимальности, чем если мы просто бы внешним способом разнесли нагрузку.
ну мой поинт был в том, что в реализации xmpp на этом нельзя ничего выиграть,
а майку лень прув ми вронг, к сожалению. =(
а майку лень прув ми вронг, к сожалению. =(
какой порядок денег они хотели потратить на разработку сервера про который ты говоришь (с 5 млн. юзеров)?Такой информации у меня нет.
Думаю, что около 10-15 миллионов рублей, явно не больше.ну мой поинт был в том, что в реализации xmpp на этом нельзя ничего выиграть,Ну конечно мне лень. Сидеть и писать какие-то банальные выкладки, типа того, что послать сообщение бинарным пакетом по UDP быстрее, чем выполнить полный межсерверный обмен по протоколу XMPP в xml-ях. И так далее, сам можешь это прекрасно найти, прочитать и понять.
а майку лень прув ми вронг, к сожалению. =(
А вот на Си++ я смогу исправить всё. И даже если надо будет что-то переписывать или напильником допиливать, то там рукой подать до системного уровня.ОМГ, чувак, а кто тебе мешает на сишарпе написать свой контрол, а? Функции выведения текста и полосочек в битмап у тебя есть, возможность быстро отрисовывать этот битмап по WM_PAINT есть, хуки на вообще все юзер-генерейтед эвенты есть.
Или ты считаешь, что это займёт больше времени, чем допиливание плюсового контрола? Вот что-то я дико сомневаюсь, видал я те плюсовые контролы. Собственно, я в какой-то момент окончательно понял, что винформы действительно ставят меня перед выбором юзать что дают и не выпендриваться, пытаться написать что-то своё, или использовать какой-нибудь GTK#, и я посмотрел на GTK#, и понял, что одним вариантом у меня стало меньше, чисто из-за архитектурных особенностей.
И, кстати, перестань говорить про тормозящий GC, пожалуйста. Если б ты был геймдевелопером и статически выделял арены я бы ещё понял претензии, но человек, практикующий дефенсив программирование при помощи *_ptr, и при этом заикающийся о производительности, вполне буквально кидается камнями в стеклянном замке.
ОМГ, чувак, а кто тебе мешает на сишарпе написать свой контрол, а?Чувак, ты не в теме этой дискуссии, так что остынь.
Оставить комментарий
sergeikozyr
это что, прикол такой?полный бред. имхо, кроме геймдева у него применений не осталось.