Здравствуйте, Сергей, Вы писали:
kuj>> .NET дает более высокую производительность за счет более тонкой оптимизации под целевой процессор (компиляция из байт-кода в машинный производится непосредственно там, где он будет выполняться).
С>У JIT-компиляторов оптимизация получается неважная — потому что важно обеспечить быструю компиляцию.
Хорошо придумал. В действительности, оптимизация на очень достойном уровне. RTFM вообщем.
Здравствуйте, gandjustas, Вы писали:
G>>>В .NET и Java такого вообще нет из-за другой семантики интерфейсов. А при работе с .NET объектами через COM таких проблема не возникает потому что сборщик мусора нормально разруливает подобные ситуации. H>>Ок. Кого он убьет раньше, родителя или дочерний интерфейс? Далее. Если тебе придется работать с COM-интерфейсами и будет аналогичная ситуация, ты без подсчета ссылок усядешься в лужу. G>Ну это ты зря. тебе же дали ссылки на механизм работы GC. CG сам отлично справляется с такой ситуацией. G>Вкратце будет так: когда родитель и дочерние объекты станут недостижимым умрут все.
Кому они станут недостижимы? Родитель ссылается на дочерний, дочерний ссылается на родителя. Кого GC должен убить раньше?
H>>Меня устраивает нативная среда с внятным, полуавтоматическим GC (таким, какой он есть) и развитым языком G>Просто ты в других мало работал. G>Когда у нас на работе пришла девушка я заставлял её писать Linq запросы вместо SQL, хотя она сильно сопростивлялась и говорила что написать JOIN на SQL гораздо легче. Ниче, через месяц привыкла, теперь даже желания не возникает SQLи писать
По моему скромному мнению, расширение семантики языка в угоду прикладному посылу (это я о LINQ) -- дикий кю. На такое способна только MS. Я уже неоднократно слышал от сторонников .Net, что MS все больше и больше изгаживает C#. Просьба, за наезд не считать.
Здравствуйте, hattab, Вы писали:
H>Кому они станут недостижимы? Родитель ссылается на дочерний, дочерний ссылается на родителя. Кого GC должен убить раньше?
Ну почитай ты наконец статьи про GC. Там все написано.
Родитель ссылается на дочерний, дочерний ссылается на родителя, а на них никто не ссылвается — вот они и недостижимы. GC за один проход уберет всех. Думаешь GC настолько дурной что каждый раз проверяет все объекты в куче?
H>По моему скромному мнению, расширение семантики языка в угоду прикладному посылу (это я о LINQ) -- дикий кю. На такое способна только MS. Я уже неоднократно слышал от сторонников .Net, что MS все больше и больше изгаживает C#. Просьба, за наезд не считать.
Ну ведь можно его не использовать.
Здравствуйте, hattab, Вы писали:
H>Delphi тоже сама ссылки считает Но дело в том, что взаимозависимость уже есть, по условию задачи. Т.е. два COM-интерфейса ссылаются друг на друга. Кого и главное, когда убивать?
Вся прелесть .NET, что не нужно думать о том кого и когда убивать — все делает GC. Например:
class Parent
{
Child _child;
public Parent()
{
_child = new Child(this);
}
}
class Child
{
Parent _parent;
public Child(Parent parent)
{
_parent = parent;
}
}
class Program
{
static void Main()
{
var x = new Parent();
// Что-то делаем с x
x = null;
// Объект, на который ссылался x, стал недостижим и x._child стал недостижим.
// GC прибьет их обоих, несмотря на то, что они ссылаются друг на друга,
// т.е. GC отслеживает циклические ссылки.
}
}
Здравствуйте, hattab, Вы писали:
H>…для себя полгода назад писал расчетный (примитивный расчет с использование типов Double) бенч на C# и Delphi. Писал объективно, ибо для себя. Разница почти 2 раза в пользу Delphi…
Без исходников говорить что-либо трудно, так что про данный конкретный случай не стану ничего утверждать. Но несколько раз натыкался на тесты производительности .NET, которые были написаны некорректно. Это и использование DateTime вместо Stopwatch или QueryPerformanceCounter для замера времени, и отсутсвие холостого прогона перед запуском тестов (для того, чтобы JIT-компилятор отработал).
Здравствуйте, gandjustas, Вы писали:
H>>Кому они станут недостижимы? Родитель ссылается на дочерний, дочерний ссылается на родителя. Кого GC должен убить раньше? G>Ну почитай ты наконец статьи про GC. Там все написано. G>Родитель ссылается на дочерний, дочерний ссылается на родителя, а на них никто не ссылвается — вот они и недостижимы. GC за один проход уберет всех. Думаешь GC настолько дурной что каждый раз проверяет все объекты в куче?
Но они-то друг на друга ссылаются, как их можно убивать??? У родителя они (дочерние) лежат в списке интерфейсов, который он (родитель) должен сам в деструкторе почистить (т.е. сам отказаться от ссылки на дочерний интерфейс). А если пред очисткой он (родитель) еще и дернуть должен дочерний интерфейс для каких-либо целей? А если дочерний при смерти должен дернуть родителя? Что значит, GC за один проход уберет их всех? Он деструкторы вызывать будет?
H>>По моему скромному мнению, расширение семантики языка в угоду прикладному посылу (это я о LINQ) -- дикий кю. На такое способна только MS. Я уже неоднократно слышал от сторонников .Net, что MS все больше и больше изгаживает C#. Просьба, за наезд не считать. G>Ну ведь можно его не использовать.
Ты про C# или LINQ? Если про LINQ, то это не меняет общей оценки языка. Если про C#... Он же является основным языком .Net. Его активно развивает MS, под него (наверняка) подкраивается исполняющая среда. Везде (на .Net-форумах) только и разговоров, что о C# (изредка о VB/C++). Я для себя сразу отмел вариант, писать под .Net на ObjectPascal, ибо это будет просто глупо, в силу вышеозначеных причин. Есть Ada под .Net, но опять же считаю это не самой лучшей идеей т.к. основная поддержка со стороны MS направлена на C#.
Здравствуйте, Эдик, Вы писали:
H>>Delphi тоже сама ссылки считает Но дело в том, что взаимозависимость уже есть, по условию задачи. Т.е. два COM-интерфейса ссылаются друг на друга. Кого и главное, когда убивать?
Э>Вся прелесть .NET, что не нужно думать о том кого и когда убивать — все делает GC. Например: Э>
Э>class Parent
Э>{
Э> Child _child;
Э> public Parent()
Э> {
Э> _child = new Child(this);
Э> }
Э>}
Э>class Child
Э>{
Э> Parent _parent;
Э> public Child(Parent parent)
Э> {
Э> _parent = parent;
Э> }
Э>}
Э>class Program
Э>{
Э> static void Main()
Э> {
Э> var x = new Parent();
Э> // Что-то делаем с x
Э> x = null;
Э> // Объект, на который ссылался x, стал недостижим и x._child стал недостижим.
Э> // GC прибьет их обоих, несмотря на то, что они ссылаются друг на друга,
Э> // т.е. GC отслеживает циклические ссылки.
Э> }
Э>}
Э>
Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release).
Здравствуйте, hattab, Вы писали:
H>>>Кому они станут недостижимы? Родитель ссылается на дочерний, дочерний ссылается на родителя. Кого GC должен убить раньше? G>>Ну почитай ты наконец статьи про GC. Там все написано. G>>Родитель ссылается на дочерний, дочерний ссылается на родителя, а на них никто не ссылвается — вот они и недостижимы. GC за один проход уберет всех. Думаешь GC настолько дурной что каждый раз проверяет все объекты в куче?
H>Но они-то друг на друга ссылаются, как их можно убивать???
Еще одно доказательство того, что Delphi отупляет. Как их можно удалять, если на них никто не ссылается — ответ: молча!
Здравствуйте, Эдик, Вы писали:
Э>Это и использование DateTime вместо Stopwatch или QueryPerformanceCounter для замера времени,
Я например использую DateTime вместо Stopwatch или QueryPerformanceCounter.
Знаешь почему?
По тому что QueryPerformanceCounter (на котором работает Stopwatch) на некоторых процессорах (в частности на моем) глючит.
Как вариант еще можно повозиться с timeGetTime.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Эдик, Вы писали:
H>>…для себя полгода назад писал расчетный (примитивный расчет с использование типов Double) бенч на C# и Delphi. Писал объективно, ибо для себя. Разница почти 2 раза в пользу Delphi…
Э>Без исходников говорить что-либо трудно, так что про данный конкретный случай не стану ничего утверждать. Но несколько раз натыкался на тесты производительности .NET, которые были написаны некорректно. Это и использование DateTime вместо Stopwatch или QueryPerformanceCounter для замера времени, и отсутсвие холостого прогона перед запуском тестов (для того, чтобы JIT-компилятор отработал).
Я не буду меряться органами Мой бенчь (а я реально рассматривал перспективу перехода под .Net) был очень прост: в цикле (100.000.000) выполнялись несложные расчеты (основные операции +,-,/,*). Время замерялось именно Stopwatch, под Delphi перф-коунтером. Все лишнее выгружалось. Частота устанавливалась на максимум (у меня бука) без возможности тротлинга. Делалось несколько прогонов, как одного бенча так и другого. Потом откидывались лучшие и худшие результаты и бралось среднее значение. По этому бенчу я не оценивал общую производительность .Net. Померял только то, что померял.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Кому они станут недостижимы? Родитель ссылается на дочерний, дочерний ссылается на родителя. Кого GC должен убить раньше? G>>Ну почитай ты наконец статьи про GC. Там все написано. G>>Родитель ссылается на дочерний, дочерний ссылается на родителя, а на них никто не ссылвается — вот они и недостижимы. GC за один проход уберет всех. Думаешь GC настолько дурной что каждый раз проверяет все объекты в куче?
H>Но они-то друг на друга ссылаются, как их можно убивать??? У родителя они (дочерние) лежат в списке интерфейсов, который он (родитель) должен сам в деструкторе почистить (т.е. сам отказаться от ссылки на дочерний интерфейс). А если пред очисткой он (родитель) еще и дернуть должен дочерний интерфейс для каких-либо целей? А если дочерний при смерти должен дернуть родителя? Что значит, GC за один проход уберет их всех? Он деструкторы вызывать будет?
Если у объектов есть финализаторы, то они еще некоторое время проживут. Сначала выполнятся финализаторы для всех, а только на следующем проходе их GC уберет все объекты.
Ну что ты как дите. Пытаешься доказать что не работет что-то, что другие использут каждый день. Лучше бы изучением вопроса занялся вместо задавания таких вопросов.
Здравствуйте, hattab, Вы писали:
H>Я не буду меряться органами Мой бенчь (а я реально рассматривал перспективу перехода под .Net) был очень прост: в цикле (100.000.000) выполнялись несложные расчеты (основные операции +,-,/,*). Время замерялось именно Stopwatch, под Delphi перф-коунтером. Все лишнее выгружалось. Частота устанавливалась на максимум (у меня бука) без возможности тротлинга. Делалось несколько прогонов, как одного бенча так и другого. Потом откидывались лучшие и худшие результаты и бралось среднее значение. По этому бенчу я не оценивал общую производительность .Net. Померял только то, что померял.
У тебя в пограмме такие серьезные вычисления, что требуется нереальное быстродействие?
Тогда можен написать отдельную библиотеку на асме и для всего остального юзать C# ?
Здравствуйте, hattab, Вы писали:
H>Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release).
Если говорить о COM, то он базируется на подсчете ссылок, это одна из его основ. А у подсчета ссылок есть ограничение — он не может корректно работать с циклическими зависимостями. Так что тут проблема не в технологии, а в дизайне конкретного приложения — в дизайне не учтены ограничения технологии и приходится их нарушать.
Здравствуйте, hattab, Вы писали: H>Хотя в Delphi интерфейсы могут иметь не только COM-объекты.
Так Вы когда говорили
Для интерфейсов существует только один способ GC -- подсчет ссылок.
Вы какие интерфейсы имели в виду? Если COM-интерфейсы (технический аспект) — это одно. Если, скажем так, ООП-интерфейсы (теоретический аспект) — то Вы абсолютно не правы. Рекомендую Вам все же почитать про то, как реализуется сборка мусора в java или .NET (ссылки Вам уже дали).
В Вашем случае с деревом объектов GC сможет выявить, что дерево целиком недоступно — это раз. Далее он в неопределенном порядке выполнит финализаторы объектов, а потом и освободит память. Соответственно, в финализаторах родители и потомки никак не взаимодействуют.
Можете сколько угодно критиковать такую схему, но она реально работает ака успешно применяется (и без всякого Вашего подсчета ссылок).
Здравствуйте, WolfHound, Вы писали:
H>>Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release). WH>А зачем нам COM-интерфейсы?
Здравствуйте, gandjustas, Вы писали:
H>>>>Кому они станут недостижимы? Родитель ссылается на дочерний, дочерний ссылается на родителя. Кого GC должен убить раньше? G>>>Ну почитай ты наконец статьи про GC. Там все написано. G>>>Родитель ссылается на дочерний, дочерний ссылается на родителя, а на них никто не ссылвается — вот они и недостижимы. GC за один проход уберет всех. Думаешь GC настолько дурной что каждый раз проверяет все объекты в куче?
H>>Но они-то друг на друга ссылаются, как их можно убивать??? У родителя они (дочерние) лежат в списке интерфейсов, который он (родитель) должен сам в деструкторе почистить (т.е. сам отказаться от ссылки на дочерний интерфейс). А если пред очисткой он (родитель) еще и дернуть должен дочерний интерфейс для каких-либо целей? А если дочерний при смерти должен дернуть родителя? Что значит, GC за один проход уберет их всех? Он деструкторы вызывать будет?
G>Если у объектов есть финализаторы, то они еще некоторое время проживут. Сначала выполнятся финализаторы для всех, а только на следующем проходе их GC уберет все объекты.
Есть гарантия, что финализатор родителя выполнится последним?
G>Ну что ты как дите. Пытаешься доказать что не работет что-то, что другие использут каждый день. Лучше бы изучением вопроса занялся вместо задавания таких вопросов.
Я не пытаюсь ни кому и ничего доказывать. Я описываю реальную задачу и пытаюсь разобраться, как оно сможет быть решено под .Net.
Здравствуйте, gandjustas, Вы писали:
H>>Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release).
G>Еще раз, запомни простую вещь: в .NET нету разницы между COM и не-COM
Ок. У .Net-интерфейсов есть механизм подсчета ссылок? И почему мне Mr.Cat говорил, что не в курсе, как устроен GC для COM-интерфейсов? Есть какое-то различие? Просвети.
