Re[36]: Конец нересурсов
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 23.11.11 07:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

V>>Да это неважно. Оппонент старательно обходит утверждение, что ошибка на управляемой платформе "сглаживалась". Какая разница в подробностях, коль сие св-во платформы гарантируется алгоритмом GC? Ну и к тому же программисту под веб, как видно, предварительно надо объяснять, почему довольно большие куски программ порой пишут принципиально как однопоточные, где о лишней синхронизации не может быть и речи. А это уже за рамками обсуждения.

G>довольно большие куски программ порой пишут принципиально как однопоточные потому что люди не умеют их писать как многопоточные

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

Зато теперь ясно, почему ты стал ёрничать, когда я сказал, что защита от параллельного обращения была убрана для оптимизации.

G>Надо не пытаться "бороться" с многопоточностью, надо убирать shared state из логики.


Спасибо за совет, только он не к месту. Вроде ж ясно было сказано: я не собираюсь сейчас обсуждать архитектуру или спрашивать советов по проектированию.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[37]: Конец нересурсов
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.11.11 08:19
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, gandjustas, Вы писали:


V>>>Да это неважно. Оппонент старательно обходит утверждение, что ошибка на управляемой платформе "сглаживалась". Какая разница в подробностях, коль сие св-во платформы гарантируется алгоритмом GC? Ну и к тому же программисту под веб, как видно, предварительно надо объяснять, почему довольно большие куски программ порой пишут принципиально как однопоточные, где о лишней синхронизации не может быть и речи. А это уже за рамками обсуждения.

G>>довольно большие куски программ порой пишут принципиально как однопоточные потому что люди не умеют их писать как многопоточные

ГВ>И ты, естественно, предположил, что обозначенный код выполнен однопоточным только из-за такого "неумения"? Силён, бродяга, ничего не скажешь.

Да, я уверен в этом. Ты же сам говорил что код "читает из большой базы данных", но все известные мне движки СУБД отлично работают с несколькими соединениями из разных потоков. Потом привел код, который использует состояние объекта для передачи данных внтури метода, что тоже является признаком неумения.

ГВ>Зато теперь ясно, почему ты стал ёрничать, когда я сказал, что защита от параллельного обращения была убрана для оптимизации.

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

G>>Надо не пытаться "бороться" с многопоточностью, надо убирать shared state из логики.

ГВ>Спасибо за совет, только он не к месту. Вроде ж ясно было сказано: я не собираюсь сейчас обсуждать архитектуру или спрашивать советов по проектированию.
Очень даже к месту, потому что ты обсуждаешь проблемные места в каком-то коде не понимая причин.
Re[17]: Конец нересурсов
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.11.11 09:05
Оценка:
Здравствуйте, Banned by IT, Вы писали:

I>>Кто тебе такое сказал ?

BBI>Реальность. Тупо пошарился по всем доступным компам.

А в инет пробовал выходить или сайты-сервисы-серверы это по твоему не софт или их писать не надо ?
Re[26]: Более того
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.11.11 09:07
Оценка:
Здравствуйте, Banned by IT, Вы писали:

I>>Вот вот. А между тем они работают в тч. сиплюсниками на самых разных конторах и можешь быть спокоен — я тут абсолютно ни при чём.

BBI>Не, из этих персонажей один сидит на жаббе, двое вовсе потерялись из программирования.

Работают сиплюсниками. Щас многие конторы берут на работу чуть не гуманитариев, так что меня ничего не удивляет.

I>>Собственно судя по отзывам людей с твоей конторы про с++ на лялихе ...

BBI>С моей конторы?

Да.
Re[17]: Конец нересурсов
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.11.11 09:12
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Дык, я же говорю, дефицит.


Странный какой то дефицит. В других областях дефицит разрабов — растет ЗП. Дефицит проектов — ЗП падает. А с С++ какой то особый дефицит

V>Вижу так же, что по грамотным плюсистам работают исключительно headhunters у нас, сами дергают конкретных людей, исключительно переманивая с места на место.


Это вобщем признак того, что область сокращается и превращается в кружок по интересам, если приходися хедхантеров нанимать. У лисперов всяких еще лучше — "стукнул в аську и трое отозвались". Тонкость в том, что любой в городе кому нужны лисперы и так знает этих трёх С С++ скоро будет точно так же.
Re[21]: Конец нересурсов
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.11.11 09:17
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Ты не понял. 80-е — это слишком недавно. Когда язык Си был придуман?

I>>У меня нет хороших примеров софта, который начал писаться раньше 80х. У тебя есть ?

ГВ>Unix.


Юник давно здох, его убил лялих который вышел в начале 90х. Остатки юникса это соляра, кое где еще встречается, да.
Re[21]: Конец нересурсов
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.11.11 09:25
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

I>>Корпоративные сайты включают достаточно много функционала, часто это часть большей системы управления предприятием(чтото вроде), которая нынче редко пишется в нативном виде. В любом случае веб это вагоны проектов самых разных масштабов. А Офисов, к слову, хорошо если десяток наберется.


ГВ>Ну и что?


Цитирую себя:
"на менеджед пишется примерно 99% всех проектов"

I>>Корпоративный, заказной и тд софт как то странно исключать из рассмотрения. Не совсем ясно, почему нужно учитывать количество инсталяций.


ГВ>Потому что это единственный критерий, однозначно определяющий популярность.


"на менеджед пишется примерно 99% всех проектов"
А какое отношение к нашему вопросу имеет эта популярность ? Или идея в том, что писать надо только популярные проекты ?

ГВ>Размер кодовой базы — это просто размер кодовой базы. Максимум, о чём он может сказать, так это о том, какой язык популярен у разработчиков.


Размер кодовой базы позволяет оценить трудозатраты и худо бедно масштабы проекта. Это как раз к твоему вопросу про batch файлы. Но если хочешь, можешь все скрипты записывать в софт. Тогда и считать будем соответсвенно и доля с++ даже по популярным программам сокращается до нуля.

I>>Потому batch-файлы это круто, но если они мелкие, то не годятся для рассмотрения, а если крупные, то это не нативная разработка.


ГВ>ИМХО, главное — это то, что популярность публично распространяемого софта прямо зависит от его потребительских качеств. Тут всё вместе: и выбор функциональности, и надёжность, и требовательность к ресурсам, и совместимость с неизвестно-каким-зоопарком.


РСДН как пример проекта который менеджед, годится или нет ? Если нет, то почему ?

>А корпоративный софт — совсем другая песня. Хотя бы потому, что затраты на него зачисляются на капитализацию, требования к аппаратуре и ПО может выставить и исполнитель, многое зависит от личных договорённостей или традиций "отдела автоматизации", а пользователи по указанию руководства сожрут любой кактус. То есть это совсем другая штука, на которую влияют другие факторы.


И что с того ? Это все равно индустрия софтописания и от этого никуда не деться. Сейчас в большинстве случаев кроме игр и единичных тобой перечисленых выгоднее иметь серверный софт == web == managed процентов на 90. Корпоративный это слабо сказал. Web будет гораздо лучше.
Re[38]: Конец нересурсов
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 23.11.11 09:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

V>>>>Да это неважно. Оппонент старательно обходит утверждение, что ошибка на управляемой платформе "сглаживалась". Какая разница в подробностях, коль сие св-во платформы гарантируется алгоритмом GC? Ну и к тому же программисту под веб, как видно, предварительно надо объяснять, почему довольно большие куски программ порой пишут принципиально как однопоточные, где о лишней синхронизации не может быть и речи. А это уже за рамками обсуждения.

G>>>довольно большие куски программ порой пишут принципиально как однопоточные потому что люди не умеют их писать как многопоточные
ГВ>>И ты, естественно, предположил, что обозначенный код выполнен однопоточным только из-за такого "неумения"? Силён, бродяга, ничего не скажешь.
G>Да, я уверен в этом.

На каком основании?

G>Ты же сам говорил что код "читает из большой базы данных", но все известные мне движки СУБД отлично работают с несколькими соединениями из разных потоков. Потом привел код, который использует состояние объекта для передачи данных внтури метода, что тоже является признаком неумения.


1. Я сказал, что "движок СУБД" к делу не относится.
2. Ручаюсь, ты знаешь не про все "движки СУБД".

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

На всякий случай ограничу контекст ещё раз:

— Код однопоточный и целесообразность такого решения не обсуждается;
— Многопоточность стряслась по ошибке, и причины этой ошибки тоже не обсуждаются (как бы тебе ни хотелось помахать жезлом архитектора);
— Квалификация специалистов, обратно, не обсуждается;
— Ошибки случаются у всех, тем более, если речь идёт об "исторических причинах";

Важно только то, что managed-среда молча проглотила коллизию, которая наверняка привела бы к падению unmanaged-аналога. Это самое проглатывание весьма затруднило поиски причин сбоя.

ГВ>>Зато теперь ясно, почему ты стал ёрничать, когда я сказал, что защита от параллельного обращения была убрана для оптимизации.

G>Ага, то есть саначла написали локи, потом оно начала дико тормозить,

Смешно. Где я говорил "локах", тем более, во множественном числе?

G>потом локи убрали возложив отвественность за синхронизацию на вызывающий код. А вызывающий код был написан вообще без мыслей о многопоточности, а потом она внезапно появилась. Причем как ты сам пишешь что race появился по ошибке.


О! Единственное более или менее правильное предположение (правда, оно почти полностью повторяет то, что я сказал). Да, код "стал многопоточным" по ошибке. Но ошибка была не где-то там в архитектуре (к чему ты клонишь), а в коде управления пуском-остановкой соответствующего потока. Однако, в чём конкретно она заключалась — снова выходит за рамки рассмотрения.

G>В итоге одна ошибка на другой.


Ну да, только с поправкой, что перечисленные тобой ошибки существуют исключительно в твоём воображении.

G>>>Надо не пытаться "бороться" с многопоточностью, надо убирать shared state из логики.

ГВ>>Спасибо за совет, только он не к месту. Вроде ж ясно было сказано: я не собираюсь сейчас обсуждать архитектуру или спрашивать советов по проектированию.
G>Очень даже к месту, потому что ты обсуждаешь проблемные места в каком-то коде не понимая причин.

Конечно я не понимаю, куда мне? Один только gandjustas, который и рядом не стоял, уже разобрался в причинах, вплоть до архитектурных и готов развешивать всем сёстрам по серьгам.

Короче, перестань играть в Шерлока Холмса, у тебя не получается.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[38]: Конец нересурсов
От: vdimas Россия  
Дата: 23.11.11 09:39
Оценка: +3
Здравствуйте, gandjustas, Вы писали:

G>>>Надо не пытаться "бороться" с многопоточностью, надо убирать shared state из логики.

ГВ>>Спасибо за совет, только он не к месту. Вроде ж ясно было сказано: я не собираюсь сейчас обсуждать архитектуру или спрашивать советов по проектированию.
G>Очень даже к месту, потому что ты обсуждаешь проблемные места в каком-то коде не понимая причин.

По-моему, тут все проще. Называется недостаток воображения.

Панимаешь... Твой shared state, к которому ты апеллируешь, коль речь идет не о глобальных переменных, не в состоянии самостоятельно быть не-shared, кроме как через примитивы синхронизации. А их договорились не использовать, и было почему. В этом случае shared он может стать только из-за внешнего кода, из-за того, как его использует тот самый внешний код. Не понимаешь? Этот внешний код и сделал некое состояние shared, хотя не должен был его таким делать, согласно спецификации. Непреднамернно, господи, у кого багов не бывает?.. А случай был интересен лишь тем, что в managed такую ошибку найти гораздо сложнее из-за того, что ничего не падает, а якобы работает. Обычная была бы такая плавающая ошибка, ничего нового.

Я понимаю, что твой веб-сценарий малость другой, у тебя каждый раз с 0-ля воссоздаются объекты, что-то делают и умирают. Это просто идеальный лабораторный сценарий. Жаль только, не развивает воображение.
Re[22]: Конец нересурсов
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 23.11.11 09:50
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

ГВ>>Ну и что?

I>Цитирую себя:
I>"на менеджед пишется примерно 99% всех проектов"

Хорошо. Ты меня убедил, что мне не стоило лезть в эту ветку. В сущности, обсуждать тут становится нечего сразу после "99%".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Конец нересурсов
От: Константин Л.  
Дата: 23.11.11 09:55
Оценка: +1
Здравствуйте, c-smile, Вы писали:

G>>Evernote был написан толпой C++ программистов. Думаю одна из причин низкой производительности была именно в этом.


CS>Тут одно утверждение и одно предположение. Оба неверные. Толпы в EverNote никогда не было это точно.


CS>По поводу WPF и .NET UI вообще.


CS>UI использующий DOM (например WPF и web, browser based UI) это как правило большой набор достаточно мелких объектов которые живут в GC heap.

CS>При этом в WPF DOM существенно низкоуровневый. Там где в browser используется один объект DOM элемент и его субобъект style (в терминах GCable сущностей) в WPF появляется примерно десяток отдельных GCable things. Т.е. WPF своей моделью создает существенную нагрузку на GC.

что это за десяток things?

CS>Особенно на этапе запуска / инициализации всего хозяйства. Для Evernote как приложения запуск как раз и есть один из частых моментов. Приложение предполагается быть легковесным в этом смысле: открыл — сделал заметку — закрыл. Нужно вспомнить что-то: открыл — посмотрел — закрыл.

CS>Т.е. WPF для такого типа приложений очень неудачный инструмент. Для вещей типа Paint.Net он подходит наверное лучше.

CS>Ну и потом HTML DOM скажем оперирует более высокоуровневыми конструкциями чем набор примитивов WPF. Т.е. в HTML DOM больше доля native code и memory management не связанной с GC. HTML DOM потенциально более GPU friendly. В WPF же надо конкретно знать детали имплементации чтобы достичь приемлемого результата.


я не знаю что такое абстрактный HTML DOM, он везде свой, конкретный. как можно сравнивать WPF OO и абстрактную OO HTML DOM мне не ясно.
Re[18]: Конец нересурсов
От: hattab  
Дата: 23.11.11 10:13
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I> I>>Кто тебе такое сказал ?


I> BBI>Реальность. Тупо пошарился по всем доступным компам.


I> А в инет пробовал выходить или сайты-сервисы-серверы это по твоему не софт или их писать не надо ?


А что сайты? Сайты крутятся на вполне себе нативных серверах Ну а что там используется в роли скриптового клея вообще параллельно. Впрочем, до распространенности похапэ, аспнету усе равно как до луны.
avalon 1.0rc3 rev 419, zlib 1.2.3
Re[19]: Конец нересурсов
От: Константин Л.  
Дата: 23.11.11 10:15
Оценка:
Здравствуйте, vdimas, Вы писали:

[]

V>Только что с предыдущего проекта сделал глобальный поиск по new:

V>[ccode]

V>restartMutex (new Mutex) // приватное поле


меня всегда смущало default-initialization вместо value-init. (если я верно помню термины из стандарта, но ты понял о чем я)

[]
Re[39]: Конец нересурсов
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.11.11 10:37
Оценка: -2 :))
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:


G>>>>Надо не пытаться "бороться" с многопоточностью, надо убирать shared state из логики.

ГВ>>>Спасибо за совет, только он не к месту. Вроде ж ясно было сказано: я не собираюсь сейчас обсуждать архитектуру или спрашивать советов по проектированию.
G>>Очень даже к месту, потому что ты обсуждаешь проблемные места в каком-то коде не понимая причин.

V>По-моему, тут все проще. Называется недостаток воображения.


V>Панимаешь... Твой shared state, к которому ты апеллируешь, коль речь идет не о глобальных переменных, не в состоянии самостоятельно быть не-shared, кроме как через примитивы синхронизации.


Еще как в состоянии. Достаточно сделать данные immutable.

V>А их договорились не использовать, и было почему. В этом случае shared он может стать только из-за внешнего кода, из-за того, как его использует тот самый внешний код. Не понимаешь?

Прекрасно понимаю. А также я прекрасно понимаю что это ошибка. А вот ты на пару с ГВ — это понимать не хотите. Вам наверное удобнее быть героями, которые борятся с кучей сложностей, чем попытаться разделить аспекты и уменьшить сложность за счет этого. Например ввести изоляцию с помощью агентов и очередей.

V>Этот внешний код и сделал некое состояние shared, хотя не должен был его таким делать, согласно спецификации. Непреднамернно, господи, у кого багов не бывает?.. А случай был интересен лишь тем, что в managed такую ошибку найти гораздо сложнее из-за того, что ничего не падает, а якобы работает. Обычная была бы такая плавающая ошибка, ничего нового.

Тут между managed и unmanaged нету разницы, код который случайно начинает шарить может быть написан на чем угодно. Кроме того тут ГВ использует демагогический прием, рассматривая managed и unmanaged отдельно, хотя они являются связанными. В частности unmanaged зависит от того как его вызывают.

По сути то что он рассказывает не является проблемами managed и unmanaged, а просто является проблемами плохо кода независимо от того на чем он был написан.

V>Я понимаю, что твой веб-сценарий малость другой, у тебя каждый раз с 0-ля воссоздаются объекты, что-то делают и умирают. Это просто идеальный лабораторный сценарий. Жаль только, не развивает воображение.

Это отличный сценарий, особенно если учесть еще два фактора: распределенность и client state. Такая архитектура на десктопе в принципе не встречается.

С другой стороны никто не мешает мешает перенести такой подход на десктоп. Только воображения у тех кто десктоп пишет не хватает
Re[40]: Конец нересурсов
От: vdimas Россия  
Дата: 23.11.11 11:13
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

V>>Панимаешь... Твой shared state, к которому ты апеллируешь, коль речь идет не о глобальных переменных, не в состоянии самостоятельно быть не-shared, кроме как через примитивы синхронизации.


G>Еще как в состоянии. Достаточно сделать данные immutable.


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


V>>А их договорились не использовать, и было почему. В этом случае shared он может стать только из-за внешнего кода, из-за того, как его использует тот самый внешний код. Не понимаешь?

G>Прекрасно понимаю. А также я прекрасно понимаю что это ошибка. А вот ты на пару с ГВ — это понимать не хотите. Вам наверное удобнее быть героями, которые борятся с кучей сложностей, чем попытаться разделить аспекты и уменьшить сложность за счет этого. Например ввести изоляцию с помощью агентов и очередей.

А почему ты так уверен, что баг был не в коде реализации как раз агентов и очередей?
Какие ты еще знаешь способы реализации архитектур СМО, интересно?

V>>Этот внешний код и сделал некое состояние shared, хотя не должен был его таким делать, согласно спецификации. Непреднамернно, господи, у кого багов не бывает?.. А случай был интересен лишь тем, что в managed такую ошибку найти гораздо сложнее из-за того, что ничего не падает, а якобы работает. Обычная была бы такая плавающая ошибка, ничего нового.

G>Тут между managed и unmanaged нету разницы, код который случайно начинает шарить может быть написан на чем угодно. Кроме того тут ГВ использует демагогический прием, рассматривая managed и unmanaged отдельно, хотя они являются связанными. В частности unmanaged зависит от того как его вызывают.

Описание факта не может являться демагогией, в отличие от навешивания ярлыков, которое ты демонстрируешь. Сухое такое описание банальной ситуации. Подставить туда managed-реализацию вместо unmanaged — ошибка себя в этом месте не проявляет, но она есть, и периодически неуловимо портит важные бизнес-данные. Вот и все, что было сказано.

G>По сути то что он рассказывает не является проблемами managed и unmanaged, а просто является проблемами плохо кода независимо от того на чем он был написан.


Т.е. баги бывают исключительно в плохом коде, что ле?.. договорились... И у тебя за всю жизнь не бывает багов в процессе разработки? А тестеров ваших вы зачем кормите? А юнит тесты (я уверен) нафига исопльзуете? Ведь достаточно же писать "хороший код", это сам по гарант надежности программ...

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

V>>Я понимаю, что твой веб-сценарий малость другой, у тебя каждый раз с 0-ля воссоздаются объекты, что-то делают и умирают. Это просто идеальный лабораторный сценарий. Жаль только, не развивает воображение.

G>Это отличный сценарий, особенно если учесть еще два фактора: распределенность и client state. Такая архитектура на десктопе в принципе не встречается.

G>С другой стороны никто не мешает мешает перенести такой подход на десктоп. Только воображения у тех кто десктоп пишет не хватает


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

Кароч, не бери в голову, всё равно не унесешь.
Re[19]: Конец нересурсов
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.11.11 11:25
Оценка:
Здравствуйте, hattab, Вы писали:

H>Здравствуйте, Ikemefula, Вы писали:


I>> I>>Кто тебе такое сказал ?


I>> BBI>Реальность. Тупо пошарился по всем доступным компам.


I>> А в инет пробовал выходить или сайты-сервисы-серверы это по твоему не софт или их писать не надо ?


H>А что сайты? Сайты крутятся на вполне себе нативных серверах Ну


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

>а что там используется в роли скриптового клея вообще параллельно.


Там в качестве того что ты называешь клеем используются вещи, которые даже с натягом сложно назвать нативными.

>Впрочем, до распространенности похапэ, аспнету усе равно как до луны.


И то и другое не нативная разработка, так что все в порядке.
Re[40]: Конец нересурсов
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.11.11 11:41
Оценка: 22 (3) +2
Здравствуйте, gandjustas, Вы писали:

G>Прекрасно понимаю. А также я прекрасно понимаю что это ошибка. А вот ты на пару с ГВ — это понимать не хотите. Вам наверное удобнее быть героями, которые борятся с кучей сложностей, чем попытаться разделить аспекты и уменьшить сложность за счет этого. Например ввести изоляцию с помощью агентов и очередей.

Не, это уже дебри.
Весь хрен до копейки сводится вот к чему:
1. Бывают ошибки некорректного доступа к разделяемому состоянию
2. В С++ эти ошибки быстро ловятся потому, что программа зрелищно падает.
3. А в дотнете они ловятся долго потому, что программа падает незрелищно.

С пунктом первым спорить бессмысленно. В некоторых, особо упрощённых случаях, у нас есть способ поставить ограждающий забор — например, все контролы winForms выкидывают внятное исключение при попытке обращения не из того потока.
И стоило бы задуматься о способах построения такого ограждающего забора в более общем случае.
Но вместо этого оппоненты начинают обсуждать совершенно неинтересные вещи. Ну повезло г-ну ГВ с тем, что в его случае в двух потоках пробовали сделать delete, и это привело к зрелищному падению. Но ведь это — уникальное стечение обстоятельств; полагаться на него в диагностике багов — это как раз занимать позицию "сферического дотнетчика", который якобы преувеличивает частоту ошибок, связанных с проходом по памяти.

Значительно более весёлый класс ошибок случается тогда, когда никаких delete и в помине нет.
Вот, к примеру, был в моей давней java-практике случай, когда наша программа глючила совершенно неподетски. У матёрых разработчиков глаза лезли на лоб.
Оказалось, что в разных потоках использовались объекты, у которых один мембер (_socket) по ошибке оказался статиком.
И всё было в полном порядке — потому, что каждый поток думал, что сокет его, и спокойно писал себе в него свои данные. И сильно удивлялся, когда приходил всякий мусор.
Причём, понятное дело, в низкой нагрузке всё работало великолепно — даже если работало несколько потоков, каждый диалог с POP3-сервером успевал закончиться до того, как сосед влезет.

И вот такого рода баги не ловятся ни в плюсах, ни в дотнете — потому что нечему зрелищно ломаться.
Это возвращает нас к п.1 — как статически гарантировать отсутствие неверного доступа к разделяемому состоянию.
Ошибки реинтерпретации и прохода по памяти мы победили в самом начале.
Потом победили ошибки, связанные с опечатками в SQL-запросах и некорректной конкатенацией (см. тж. linq)
Теперь давайте займёмся этим отловом shared state access violation. Подход C++ — "если что и случится, то мы быстро это обнаружим по крэшу". Подход managed code — давайте придумаем среду, в которой такие ошибки невозможны в принципе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Конец нересурсов
От: hattab  
Дата: 23.11.11 11:59
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I> I>> А в инет пробовал выходить или сайты-сервисы-серверы это по твоему не софт или их писать не надо ?


I> H>А что сайты? Сайты крутятся на вполне себе нативных серверах Ну


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


То есть именно слой клея ты назвал серверными приложениями?

I> >а что там используется в роли скриптового клея вообще параллельно.


I> Там в качестве того что ты называешь клеем используются вещи, которые даже с натягом сложно назвать нативными.


А я о чем написал?

I> >Впрочем, до распространенности похапэ, аспнету усе равно как до луны.


I> И то и другое не нативная разработка, так что все в порядке.


Так я не против Крутятся себе скриптики на нативных серверах, дергают нативные базы... И с чего бы их считать менеджед софтом? Этак и WoW с Lua кишками можно назвать ненативным
avalon 1.0rc3 rev 419, zlib 1.2.3
Re[11]: Конец нересурсов
От: vdimas Россия  
Дата: 23.11.11 12:32
Оценка: 64 (1)
Здравствуйте, AndrewVK, Вы писали:

AVK>>>А ты смотрел? Навскидку — основные изменения в 4 рантайме?


V>>Я изменения смотрю по замерам, с некоторых пор.


AVK>Ясно. Т.е. не смотрел.


Описания изменений оптимизатора (коль такое есть в природе) действительно не смотрел. Потому что запускал такое:

  Скрытый текст
using System;
using System.Diagnostics;

namespace ConsoleApplication6
{
    struct Filter
    {
        float z1, z2;
        public float K0, K1, K2;

        public float Process(float sample)
        {
            var tmp = z1;
            z1 = sample * K0 + z1 * K1 + z2 * K2;
            z2 = tmp;
            return z1;
        }
    }

    class Box<T>
    {
        public T Value;
    }

    class Program
    {
        static void Main(string[] args)
        {
            var rnd = new Random();

            const int N = 1000000;
            var data = new float[N];

            for (int i = 0; i < N; i++)
                data[i] = (float)rnd.NextDouble();

            var filter = new Box<Filter>();
            filter.Value.K0 = (float)rnd.NextDouble();   // для исключения "случайных" оптимизаций
            filter.Value.K1 = (float)rnd.NextDouble();
            filter.Value.K2 = (float)rnd.NextDouble();

            var timer = new Stopwatch();

            // разогрев
            timer.Start();
            timer.Stop();
            Test1(filter, data);    
            Test2(filter, data);

            timer.Reset();
            timer.Start();
            Test1(filter, data);
            timer.Stop();

            Console.WriteLine("Result1: " + timer.ElapsedTicks);

            timer.Reset();
            timer.Start();
            Test2(filter, data);
            timer.Stop();

            Console.WriteLine("Result2: " + timer.ElapsedTicks);

            timer.Reset();
            timer.Start();
            Test1(filter, data);
            timer.Stop();

            Console.WriteLine("Result1: " + timer.ElapsedTicks);

            timer.Reset();
            timer.Start();
            Test2(filter, data);
            timer.Stop();

            Console.WriteLine("Result2: " + timer.ElapsedTicks);

            Console.WriteLine("Press enter...");
            Console.ReadLine();
        }

        static float Test1(Box<Filter> filterObj, float[] data)
        {
            float value = 0;

            for (int i = 0; i < data.Length; i++)
                value = filterObj.Value.Process(data[i]);

            return value;
        }

        static float Test2(Box<Filter> filterObj, float[] data)
        {
            float value = 0;
            Filter filter = filterObj.Value;

            for (int i = 0; i < data.Length; i++)
                value = filter.Process(data[i]);

            filterObj.Value = filter;
            return value;
        }
    }
}

Результаты тестов отличаются на 1.5%, и практически одинаковы соответствующие результаты для 2-го и 4-го фреймворка (в пределах погрешности)...
Сгенеренный ассемблерный код тупой до безобразия, в цикле загружает данные в плавающие регистры каждый раз заново, вместо перемещения м/у регистрами. Про неиспользование SSE/SSE2 я уже даже не заикаюсь. Использовал клиентский профайл.
Re[27]: Более того
От: Banned by IT  
Дата: 23.11.11 12:32
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Вот вот. А между тем они работают в тч. сиплюсниками на самых разных конторах и можешь быть спокоен — я тут абсолютно ни при чём.

BBI>>Не, из этих персонажей один сидит на жаббе, двое вовсе потерялись из программирования.

I>Работают сиплюсниками. Щас многие конторы берут на работу чуть не гуманитариев, так что меня ничего не удивляет.

Ну так это проблемы с головой у этих контор.

I>>>Собственно судя по отзывам людей с твоей конторы про с++ на лялихе ...

BBI>>С моей конторы?
I>Да.
Можно ознакомиться?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.