Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Сперва нужно убедиться, что проблема именно в копировании между процессами. Кроме того, локально сиквел умеет через shared mem общаться, да и namep pipes локально через него же работают.
Файловые базы всегда были быстрее ибо все происходит в одном процессе. И 1С это интерпретатор!
На компилируемых языках используя индексы вообще все летает. Обработка для формирования классов для прямого доступа к файлам 1С через курсоры BDE. И многого другого
и солнце б утром не вставало, когда бы не было меня
Re[63]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Serginio1, Вы писали:
НС>>Сперва нужно убедиться, что проблема именно в копировании между процессами. Кроме того, локально сиквел умеет через shared mem общаться, да и namep pipes локально через него же работают. S>Файловые базы всегда были быстрее ибо все происходит в одном процессе.
Или не потому.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[82]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Сперва нужно убедиться, что проблема именно в копировании между процессами. Кроме того, локально сиквел умеет через shared mem общаться, да и namep pipes локально через него же работают. S>>Файловые базы всегда были быстрее ибо все происходит в одном процессе.
НС>Или не потому.
А за счет чего? Интерпретатор выигрывает! Если на компилируемом языке то вообще все летает на закэшированных файлах системой. SQL в монопольном режиме запускали, shared mem использовали. Сейчас уже точно не скажу. Но факт остается фактом. Как бы не вылизовали запросы и алгоритмы. Если на двух машинах понятно что тормоза еще заметнее http://rsdn.org/forum/prj.rfd/8090779.1
Здравствуйте, Ночной Смотрящий, Вы писали: НС>Скорее всего умеет, но не для Expression<T>, а для dynamic. Именно поэтому в Expression даже стейтмент блок есть.
Да, в комментариях Барта к его проекту есть упоминания о том, что собственно все нововведения в System.Linq.Expressions после C# 3.0 были связаны ровно с dynamic.
Но в фичу "парсинг лямбды в Expression Tree" ничего из этого не попало, а это именно то, что я имею в виду под "порождением компилятором".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[64]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали: V>Наличие многопоточной очереди лишь одной дисциплины. V>И применение очереди этой дисциплины не по месту.
То есть к самой ConcurrentQueue вопросов нету. Ну, ок.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[75]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Мы пришли к тому, что все твои утверждения про наследование применимы к интерфейсам.
НС>Нет.
То есть, кроме голословных утверждений у тебя ничего нет.
I>>>>Возьми любое другое свойство, например тот самый метод add. НС>>>Нет, надо взять то, что таки ОО контракты гарантируют. Только смысл сего действа непонятен. I>>Так ты возьми да покажи
НС>И опять полетели чайники.
Какие еще чайники? Ты чтото утверждаешь. Я прошу это продемонстрировать. У тебя в ответ голословные утверждения, ссылки где предлагается ровно то о чем я говорю и какие то "чайники". Аргументы от тебя когда последуют?
I>>Ты утверждаешь что для интерфейсов наследование работает нормально.
НС>Ссылку на подобное утверждение мое не затруднит?
Забыл о чем речь? Бывает.
Ты утверждал, что для полиморфизма интерфейсов более чем достаточно. Далее от меня последовал пример про удаление элементов в методе add(который ты старательно "забываешь").
Подробнее:
Например, нам нужен один и тот же алгоритм для объектов разных типов, что есть самый настоящий полиморфизм. Этот алгоритм использует метод add и написан в соответствии со свойствами этого метода.
Отсюда ясно, этот алгоритм не сработает в том слуаче, если add ведет себя как то иначе, т.к. семантически эта конкретная операция с ожидаемыми свойствами неприменима к конкретному типу, а раз так, то нельзя позволять такое использование.
Итого — не совсем понятно, где тут "более чем достаточно".
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Кстате, сам Memoize тоже выполнен похожим образом, через CAS. НС>К сожалению, одним CAS не обойдешься и полность lock free алгоритмов для хеш-таблицы нет. При коллизии все равно приходится использовать локи.
Со вложенными хеш-таблицами достаточно просто.
Т.е. при коллизии хеша создаётся вложенная хеш-таблица с другим кол-вом индексов.
При межпоточных конфликтах обновления пересоздаётся Bucket или отбрасывается вновь-созданная дочерняя хеш-таблица, если конкурирующий поток уже создал дочернюю хеш-таблицу по данному индексу.
Re[83]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
I>>>Мы пришли к тому, что все твои утверждения про наследование применимы к интерфейсам. НС>>Нет. I>То есть, кроме голословных утверждений у тебя ничего нет.
Чайники, однако, они такие.
НС>>И опять полетели чайники. I>Какие еще чайники?
Рассела.
I>Ты чтото утверждаешь. Я прошу это продемонстрировать. У тебя в ответ голословные утверждения
Вон то что выше — это не утверждение, это намек на то что твое утверждение бездоказательно абсолютно.
I>>>Ты утверждаешь что для интерфейсов наследование работает нормально. НС>>Ссылку на подобное утверждение мое не затруднит? I>Забыл о чем речь? Бывает. I>Ты утверждал, что для полиморфизма интерфейсов более чем достаточно.
Это совсем другое утверждение.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[84]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Или не потому. S>>А за счет чего?
НС>Чайник Рассела?
Твоё мнение интересно
и солнце б утром не вставало, когда бы не было меня
Re[85]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Serginio1, Вы писали:
НС>>Чайник Рассела? S>Твоё мнение интересно
Я не эксперт в этом вопросе. Но по опыту — очень врядли на операциях, связанных с активным и объемным IO маршалинг между процессами играет заметную роль. Тем более в случае сиквела, который умеет в shared mem.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[64]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Serginio1, Вы писали:
S>Выводы S>В ходе нашего маленького исследования были получены следующие выводы: S>TypeHandle является указателем либо на MethodTable, либо на TypeDesc (зависит от типа объекта)
И в любом случае первое поле объекта указывает на typeinfo, который представлен объектом RuntimeType.
Т.е., оно выглядит так:
class Object {
private RuntimeType _type;
public Type GetType() => _type;
public virtual void ToString() = _type.ToString();
...
}
unsafe class RuntimeType {
...
// по смещению 0x40 в AMDx64 ссылка на VMT (или TypeDesc)private IntPtr* _vmt;
...
}
Соответственно, адрес, скажем, 4-й виртуальной ф-ии:
IntPtr funcAddr = obj->_type->_vmt[4];
В плюсах путь короче:
IntPtr funcAddr = obj->_vmt[4];
Еще что забавно, что для пущей эффективности в том лейауте было бы неплохо сделать указатель на VMT первым полем RuntimeType, но RuntimeType — это такой же Object, первое поле уже занято. ))
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Ты чтото утверждаешь. Я прошу это продемонстрировать. У тебя в ответ голословные утверждения
НС>Вон то что выше — это не утверждение, это намек на то что твое утверждение бездоказательно абсолютно.
Снова пустые слова. Если ты не заметил, то в данном разговоре аргументы только с моей стороны. От тебя только намёки, что я де гдето чтото упустил
I>>>>Ты утверждаешь что для интерфейсов наследование работает нормально. НС>>>Ссылку на подобное утверждение мое не затруднит? I>>Забыл о чем речь? Бывает. I>>Ты утверждал, что для полиморфизма интерфейсов более чем достаточно.
НС>Это совсем другое утверждение.
Это ровно то, о чем шла речь — в данном случае я просто повторил себя же. От тебя никаких встречных аргументов не поступило. Итого 0- с чем то ты не согласен, но пояснить свою позицию или не можешь, или не хочешь.
Не ясно, зачем ты продолжаешь сюда чего то писать при полном отсутствии аргументов?
Re[78]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
НС>>Вон то что выше — это не утверждение, это намек на то что твое утверждение бездоказательно абсолютно. I>Снова пустые слова.
Какой вопрос, такой и ответ.
I> Если ты не заметил, то в данном разговоре аргументы только с моей стороны.
Таке и должно быть. Иначе чайник Рассела.
I>>>>>Ты утверждаешь что для интерфейсов наследование работает нормально. НС>>>>Ссылку на подобное утверждение мое не затруднит? I>>>Забыл о чем речь? Бывает. I>>>Ты утверждал, что для полиморфизма интерфейсов более чем достаточно.
НС>>Это совсем другое утверждение. I>Это ровно то, о чем шла речь
Тебе показалось. То что я написал означало, что интерфейсы вполне достаточны для стандартного ОО полиморфизма. С чего ты решил что это утверждение относится и ко всяким интересным вещам типа иммутабельности — я без понятия. Поэтому мне совершенно не интересно доказывать тебе, что интерфейсов достаточно для гарантии иммутабельности и чего ты там еще со своимм методом add мне приписать пытаешься.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[65]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>>Выводы S>>В ходе нашего маленького исследования были получены следующие выводы: S>>TypeHandle является указателем либо на MethodTable, либо на TypeDesc (зависит от типа объекта)
V>И в любом случае первое поле объекта указывает на typeinfo, который представлен объектом RuntimeType.
V>Т.е., оно выглядит так: V>
V>class Object {
V> private RuntimeType _type;
V> public Type GetType() => _type;
V> public virtual void ToString() = _type.ToString();
V> ...
V>}
V>unsafe class RuntimeType {
V> ...
V> // по смещению 0x40 в AMDx64 ссылка на VMT (или TypeDesc)
V> private IntPtr* _vmt;
V> ...
V>}
V>
V>Соответственно, адрес, скажем, 4-й виртуальной ф-ии: V>
V>IntPtr * funcAddr = obj->_type->_vmt[4];
V>
V>В плюсах путь короче: V>
V>IntPtr * funcAddr = obj->_vmt[4];
V>
V>Еще что забавно, что для пущей эффективности в том лейауте было бы неплохо сделать указатель на VMT первым полем RuntimeType, но RuntimeType — это такой же Object, первое поле уже занято. ))
// A TypeHandle is the FUNDAMENTAL concept of type identity in the CLR.
// That is two types are equal if and only if their type handles
// are equal. A TypeHandle, is a pointer sized struture that encodes
// everything you need to know to figure out what kind of type you are
// actually dealing with.
// At the present time a TypeHandle can point at two possible things
//
// 1) A MethodTable (Intrinsics, Classes, Value Types and their instantiations)
// 2) A TypeDesc (all other cases: arrays, byrefs, pointer types, function pointers, generic type variables)
//
// or with IL stubs, a third thing:
//
// 3) A MethodTable for a native value type.
//
// MTs that satisfy IsSharedByReferenceArrayTypes are not
// valid TypeHandles: for example no allocated object will
// ever return such a type handle from Object::GetTypeHandle(), and
// these type handles should not be passed across the JIT Interface
// as CORINFO_CLASS_HANDLEs. However some code in the EE does create
// temporary TypeHandles out of these MTs, so we can't yet assert
// !IsSharedByReferenceArrayTypes() in the TypeHandle constructor.
Ага, значит TypeHandle может быть как указателем на MethodTable, так и указателем на TypeDesc, в зависимости от типа объекта. Для массивов он указывает на TypeDesc. Тип object[][] — это массив, элементами которого являются object[], для которых TypeHandle=TypeDesc. Эта информация объясняет наш пример, но всё ещё остаются некоторые вопросы. Например: а как же отличить, на что именно указывает TypeHandle? Поможет нам в этом дальнейшее изучение исходников CLI:
Всё зависит от второго бита в адресе: нулевое значение определяет MethodTable, а единичное — TypeDesc. Если мы работаем с шестнадцатеричными адресами, то можно легко определить вид TypeHandle по последней цифре:
и солнце б утром не вставало, когда бы не было меня
Re[79]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>> Если ты не заметил, то в данном разговоре аргументы только с моей стороны.
НС>Таке и должно быть. Иначе чайник Рассела.
На мой взгляд диалог гораздо эффективнее, т.к. обе стороны предлагают варианты, задают вопросы, уточняют, поясняют и тд.
А ты раз за разом выбираешь чайники, отказываешься пояснять, уточнять, приводить примеры и тд.
I>>>>Ты утверждал, что для полиморфизма интерфейсов более чем достаточно.
НС>>>Это совсем другое утверждение. I>>Это ровно то, о чем шла речь
НС>Тебе показалось. То что я написал означало, что интерфейсы вполне достаточны для стандартного ОО полиморфизма. С чего ты решил что это утверждение относится и ко всяким интересным вещам типа иммутабельности — я без понятия.
Как забавно — ты снова переключился на другой пример, с иммутабельностью. Цитирую себя "пример про удаление элементов в методе add(который ты старательно "забываешь").
Ты в очередной раз "забыл" о чем шла речь.
> Поэтому мне совершенно не интересно доказывать тебе,
Ты бы вместо доказательства попробовал внятно изложить свои мысли, слова пояснять примерами. Глядишь, стало бы понятнее.
> что интерфейсов достаточно для гарантии иммутабельности и чего ты там еще со своимм методом add
Не надо сочинять — пример с add никакого отношения к иммутабельности не имеет. Предполагаю, тебе просто хочется куда то спрыгнуть.
> мне приписать пытаешься.
Видишь? Был задан вопрос, что бы понять, чего же ты имел ввиду.
А дальше пошло непонятное: I> А как же ты будешь имплементить связь "A is B" ? НС> Интерфейсами. Если вообще буду, так как использование is для логики — та еще кака. I> Обычно проблемы возникают не с самой связью is, а с реализацией композиции через наследование НС> Именно.
Итого — сначала ты утверждаешь про проблемы is "is для логики — кака" и тут же соглашаешься "проблемы не с is, а с композицией"
Вот после такого, что ты имел ввиду — вообще ни разу не ясно. Тогда было самое время сказать, что же ты имел ввиду.
И я тебе прямо сообщил, что ты поменял показания: I> Ты меняешь показания: "использование is для логики — та еще кака".
И ты проигнорировал, пояснять не стал, что же ты имел ввиду. Тут же не допрос и не собеседование. Что тебе мешало пояснить — не ясно
Теперь выясняется, что это я тебе чего то приписываю, хотя телепатия поступает почему то с твоей стороны
Re[80]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
НС>>Таке и должно быть. Иначе чайник Рассела. I>На мой взгляд диалог гораздо эффективнее, т.к. обе стороны предлагают варианты, задают вопросы, уточняют, поясняют и тд.
Не, диалог гораздо эффективнее, когда не придумываешь себе удобного собеседника, и не выдаешь бездоказательные заявления в надежде, что собеседник кинется их опровергать.
НС>>Тебе показалось. То что я написал означало, что интерфейсы вполне достаточны для стандартного ОО полиморфизма. С чего ты решил что это утверждение относится и ко всяким интересным вещам типа иммутабельности — я без понятия. I>Как забавно — ты снова переключился на другой пример, с иммутабельностью.
Да пофик. Ты опять не понял что я написал.
I>Цитирую себя "пример про удаление элементов в методе add(который ты старательно "забываешь").
Ты даже не дочитал сообщение до конца
и чего ты там еще со своимм методом add
>> Поэтому мне совершенно не интересно доказывать тебе, I>Ты бы вместо доказательства попробовал внятно изложить свои мысли, слова пояснять примерами. Глядишь, стало бы понятнее.
Мысль была изложена в самом начале. Не стоит пихать в структуры наследование, когда даже в классах с этим наследованием проблемы. Что тебе в этой простой мысли непонятно?
>> что интерфейсов достаточно для гарантии иммутабельности и чего ты там еще со своимм методом add I>Не надо сочинять — пример с add никакого отношения к иммутабельности не имеет.
А я где то утверждал что имеет? Ты опять споришь с воображаемым собеседником.
>> мне приписать пытаешься. I>Снова полезла телепатия.