Здравствуйте, Serginio1, Вы писали:
_>>Где это "тут" договорились? ) На Qt я создают один и тот же интерфейс (код) и он работает на всех платформах сразу. Причём на каждой из них выглядит родным. S> Там нехило по твоему QT прошлись. Сказав, что это убожество по сравнению с родными инструментами.
Где это "там"? ) Ну и сказать можно что угодно. Какое-то значение это будет иметь только в том случае, если это подтверждено аргументами. )
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>>>> Я давно не интересовался. Меня GC давно не беспокоит. Только вызываю его при работе с ком. EP>>>Я тебя поздравляю, действительно есть задачи где от него нет проблем. Я в первом же сообщении этой ветки тебе сказал что сам частенько использую Python. S>> Ну и? Тогда о чем разговор?
EP>Так я тебе этот вопрос практически в каждом сообщении задаю — к чему ты подводишь? Если к тому что на практике применимы разные языки, с разными технологиями (GC/etc), даже тормозные — так я об этом тебе в первом же ответе сказал.
Что такое тормозные. Я тебе задал вопрос каковы тормоза в реальных приложениях, а не выдранных тормозные тесты. Какова их доля в реальных приложениях?
EP>Конечно тебе всё равно. Всё что не восхваляет твой блаб язык и всё что показывает что в других языках есть аналоги на запрошенные тобой фичи, причём местами более мощные — тебе не интересно. S>>А многие подумают, чего это чувак побитовые операции за операции с массивами применяет.
EP>Только первый раз, с непривычки. EP>LINQ кстати говоря тоже структурно далёк от SQL — от SQL там только ключевые слова. А по сути это монадическая DO-нотация.
Потому, что SQL далек от совершенства для интеллисенсе
S>>А насчет быстроты то все зависит от компилятора которые могут в теже итераторы и преобразовываться.
EP>Теоретически может, а на практике это намного тяжелее. EP>Теоретически, да, сферически компилятор может взять программу на любом языке и выдать супер оптимальный код.
В чем тяжелее? Вся информация есть. Просто не нужно.
S>>>>>> Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста. EP>>>>>В результате генерируется текст запроса, так понятнее S>> В результате генерируется машинный код на сервере. Есть абстракции. Контекс можно подменить и тогда итогом будет совсем другое.
EP>Так в описываемой мной схеме тоже можно заменить контекст, и тоже итог может быть совсем другими
S>>>> В итоге мне наплевать, вто что трансформирутся Linq запрос. EP>>>Да тут в принципе тоже, я про текст запрос сказал, для того чтобы подчеркнуть что трансформация происходит на этапе компиляции. S>> Так я от тебя ссылки и не дождался.
EP>Я приводил — sqlpp11, первая ссылка в Google, или например на YouTube. Там очень близко к тому что я описал, в том числе есть возможность работать по контейнерам, правда это особо не зачем.
Что то совсем совсем мало гугл выдает. Задай про Linq и тебе куча статей и примеров.
и солнце б утром не вставало, когда бы не было меня
На C++ для подобных целей уже более двадцати лет используются Expression Templates. Причём порождаемые деревья выражений можно обрабатывать на этапе компиляции.
Используется в разных областях — и в математических/инженерных задачах (например Eigen), и при парсинге(легендарный Spirit), и при генерации запросов(упомянутый sqlpp11), и т.д. и т.п.
А начиная с C++11 — теперь во время компиляции можно обрабатывать и обычные строки, то есть теперь EDSL могут быть и строковыми, при этом проверяемыми/типизируемыми на этапе компиляции.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>>>>
S>>>> .NET 4.5 мы внесли некоторые изменения для более эффективного использования фрагментов памяти в LOH, особенно в плане того, как мы управляем списком свободной памяти. Изменения относятся к сбору мусора (garbage collection, GC) как на рабочей станции, так и сервере. Но обратите внимание на то, что это не отменяет лимит в 85 000 байтов на размер объекта в LOH.
Ну есть и непотокобезопасные
EP>Это по сути random-access последовательность состоящая из chunk'ов фиксированного размера — это позволило бы обходить проблемы с фрагментацией даже на старой LOH стратегии.
S>>Сейчас говоря дефрагментирует и LOH
EP>Видимо не по-умолчанию, это к вопросу о настройках EP>
EP>https://msdn.microsoft.com/en-us/library/system.runtime.gcsettings.largeobjectheapcompactionmode%28v=vs.110%29.aspx
EP>The default value of the LargeObjectHeapCompactionMode property is GCLargeObjectHeapCompactionMode.Default, which indicates that the LOH is not compacted during garbage collections.
EP>If you assign the property a value of GCLargeObjectHeapCompactionMode.CompactOnce, the LOH is compacted during the next full blocking garbage collection, and the property value is reset to GCLargeObjectHeapCompactionMode.Default.
EP>И походу нужно каждый раз взводить.
Такие ситуации возникают ооочень редко. Зная о них можно и взводить. У меня никогда таких проблем не было. Но я пишу то в основном на 1С.
EP>>>А зачем ты привёл это? Оно как-то опровергает мои тезисы? S>> Про блокировки
EP>Что именно? Вот это? "Точно — конкурентная гадость, которая скорей всего не lock-free." EP>Там сказано что она lock/wait-free?
В фоновом режиме для прохода по графу нет никаких блокировок.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Где это "тут" договорились? ) На Qt я создают один и тот же интерфейс (код) и он работает на всех платформах сразу. Причём на каждой из них выглядит родным. S>> Там нехило по твоему QT прошлись. Сказав, что это убожество по сравнению с родными инструментами.
_>Где это "там"? ) Ну и сказать можно что угодно. Какое-то значение это будет иметь только в том случае, если это подтверждено аргументами. )
Ветка была про кроссплатформенность. Я не специалист. Поэтому говорю, то что видел. Ты в той вктке вроде тоже был
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели. EP>Это по сути random-access последовательность состоящая из chunk'ов фиксированного размера — это позволило бы обходить проблемы с фрагментацией даже на старой LOH стратегии.
Здравствуйте, Serginio1, Вы писали:
S>>> Ну и? Тогда о чем разговор? EP>>Так я тебе этот вопрос практически в каждом сообщении задаю — к чему ты подводишь? Если к тому что на практике применимы разные языки, с разными технологиями (GC/etc), даже тормозные — так я об этом тебе в первом же ответе сказал. S> Что такое тормозные.
Например работающие сильно медленнее чем возможно, потребляющих намного больше энергии чем необходимо, требующих большее количество железок чем достаточно.
S>Я тебе задал вопрос каковы тормоза в реальных приложениях
Зачем ты его задал? Я же не утверждал что эти тормоза в каждом приложении критичны. Очевидно что разницу между одной наносекундой, и одной микросекундой никто не заметит.
S>>>А многие подумают, чего это чувак побитовые операции за операции с массивами применяет. EP>>Только первый раз, с непривычки. EP>>LINQ кстати говоря тоже структурно далёк от SQL — от SQL там только ключевые слова. А по сути это монадическая DO-нотация. S> Потому, что SQL далек от совершенства для интеллисенсе
Так зачем говорить что он понятен тем кто знаком с SQL? Там структура совершенно другая.
S>>>А насчет быстроты то все зависит от компилятора которые могут в теже итераторы и преобразовываться. EP>>Теоретически может, а на практике это намного тяжелее. EP>>Теоретически, да, сферически компилятор может взять программу на любом языке и выдать супер оптимальный код. S> В чем тяжелее? Вся информация есть. Просто не нужно.
Ещё раз "вся информация" может быть сильно разной. Вся информация есть и в динамически типизированных языках, и теоретически компилятор может применить максимально возможную оптимизацию.
В данном случае C++ легко оптимизировать потому что легко всё заинлайнить, а легко заинлайнить потому что нет ни одного виртуального/косвенного вызова, и нет ни одной аллокации.
При этом да, инлайнить виртуальные/косвенные вызовы тоже возможно на этапе компиляции, но это очевидно труднее — так как требуется более серьёзный анализ.
S>>>>>>> Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста. EP>>>>>>В результате генерируется текст запроса, так понятнее S>>> В результате генерируется машинный код на сервере. Есть абстракции. Контекс можно подменить и тогда итогом будет совсем другое. EP>>Так в описываемой мной схеме тоже можно заменить контекст, и тоже итог может быть совсем другими S> Где я её не видел Если ты про это https://github.com/rbock/sqlpp11 то там нет твоих |
Так | это другая библиотека, ты за контекстом следишь? | это Boost.Range, а тут sqlpp11.
S>и соединений не увидел,
Выше уже привели ссылку.
S>ленивости итд.
Ленивость важна в контексте контейнеров, приведённый пример Boost.Range — ленивый. Если не веришь — могу доказать тестом.
Касательно sqlp11 — там есть пример использования с контейнерами — он может быть реализован как лениво, так и энергично, как именно — мне лень смотреть, так как я использую более удобный для этой цели Boost.Range.
Или ты о какой ленивости?
EP>>Я приводил — sqlpp11, первая ссылка в Google, или например на YouTube. Там очень близко к тому что я описал, в том числе есть возможность работать по контейнерам, правда это особо не зачем. S> Что то совсем совсем мало гугл выдает.
Ну не знаю, может у тебя google другой — http://lmgtfy.com/?q=sqlpp11 . У меня в выдаче первая ссылка на этот проект.
S>Задай про Linq и тебе куча статей и примеров.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>>А внутри Linq деревья выражений. S>>https://msdn.microsoft.com/ru-ru/library/bb397951.aspx
EP>На C++ для подобных целей уже более двадцати лет используются Expression Templates. Причём порождаемые деревья выражений можно обрабатывать на этапе компиляции. EP>Используется в разных областях — и в математических/инженерных задачах (например Eigen), и при парсинге(легендарный Spirit), и при генерации запросов(упомянутый sqlpp11), и т.д. и т.п. EP>А начиная с C++11 — теперь во время компиляции можно обрабатывать и обычные строки, то есть теперь EDSL могут быть и строковыми, при этом проверяемыми/типизируемыми на этапе компиляции.
Вот интересная статья http://habrahabr.ru/post/256821/
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
EP>>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели. S>Если потокобезопасная то S>http://professorweb.ru/my/csharp/charp_theory/level12/12_15.php
Какая из них конкретно?
S>Ну есть и непотокобезопасные
В той теме так и не привели.
EP>>>>А зачем ты привёл это? Оно как-то опровергает мои тезисы? S>>> Про блокировки EP>>Что именно? Вот это? "Точно — конкурентная гадость, которая скорей всего не lock-free." EP>>Там сказано что она lock/wait-free? S> В фоновом режиме для прохода по графу нет никаких блокировок.
А что ты понимаешь под блокировкой? Stop-the-world?
Так речь же не об этом, а о гонках возникающих при обходе графа из одного потока, и изменениях этого же графа из других, и им подобных.
Есть статьи описывающие lock-free реализации, но как я понял нигде в mainstream это не реализовано.
Здравствуйте, Serginio1, Вы писали:
S>>> Там нехило по твоему QT прошлись. Сказав, что это убожество по сравнению с родными инструментами. _>>Где это "там"? ) Ну и сказать можно что угодно. Какое-то значение это будет иметь только в том случае, если это подтверждено аргументами. ) S> Ветка была про кроссплатформенность. Я не специалист. Поэтому говорю, то что видел. Ты в той вктке вроде тоже был
Тут часто обсуждают такие вещи, но я что-то не помню чтобы кто-то говорил про убогость Qt — всё же это один из лидирующих в мире инструментов. ))) У него конечно же есть куча своих недостатков (типа надстройки над C++ и т.п.), про которые я сам всегда упоминаю. Но на фоне остальных (где проблемы не во внутренней архитектуре, а в вообще отсутствие необходимой функциональности) всё очень даже не плохо.
S>> Потому, что SQL далек от совершенства для интеллисенсе
EP>Так зачем говорить что он понятен тем кто знаком с SQL? Там структура совершенно другая.
Я этого не говорил. Я говорил только про битовые операции
S>> В чем тяжелее? Вся информация есть. Просто не нужно.
EP>Ещё раз "вся информация" может быть сильно разной. Вся информация есть и в динамически типизированных языках, и теоретически компилятор может применить максимально возможную оптимизацию.
Где то и проводит.
EP>В данном случае C++ легко оптимизировать потому что легко всё заинлайнить, а легко заинлайнить потому что нет ни одного виртуального/косвенного вызова, и нет ни одной аллокации. EP>При этом да, инлайнить виртуальные/косвенные вызовы тоже возможно на этапе компиляции, но это очевидно труднее — так как требуется более серьёзный анализ.
В большинстве это и не нужно. А виртуальные помогают конструировать иерархию и доступ к неопределенным типам через интерфейсы http://infostart.ru/public/402038/
EP>Так | это другая библиотека, ты за контекстом следишь? | это Boost.Range, а тут sqlpp11.
А в Net это встроено в платформу. S>>и соединений не увидел,
EP>Выше уже привели ссылку.
EP>Или ты о какой ленивости?
Я ссылку уже видел. Давно от вас ждал. Но все равно мало примеров. Хотя верю, что можно.
EP>>>Я приводил — sqlpp11, первая ссылка в Google, или например на YouTube. Там очень близко к тому что я описал, в том числе есть возможность работать по контейнерам, правда это особо не зачем. S>> Что то совсем совсем мало гугл выдает.
EP>Ну не знаю, может у тебя google другой — http://lmgtfy.com/?q=sqlpp11 . У меня в выдаче первая ссылка на этот проект.
S>>Задай про Linq и тебе куча статей и примеров.
EP>И что?
Казалось бы
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Klikujiskaaan, Вы писали:
EP>>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели. EP>>Это по сути random-access последовательность состоящая из chunk'ов фиксированного размера — это позволило бы обходить проблемы с фрагментацией даже на старой LOH стратегии. K>https://www.nuget.org/packages/Nito.Deque
Судя по "amortized O(1) access to both front and back" — там реализация не на chunk'ах, а на одном массиве. Для того чтобы обходить проблемы с фрагментацией требуется именно на chunk'ах.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели. S>>Если потокобезопасная то S>>http://professorweb.ru/my/csharp/charp_theory/level12/12_15.php
EP>Какая из них конкретно?
Бери какой хочешь. Для этого нужно знать, что ты под std::deque S>>Ну есть и непотокобезопасные
EP>В той теме так и не привели.
Ты на год посмотри 30.06.04
Тогда мало чего было. Еще Net 1.1 был без дженериков итд.
EP>>>>>А зачем ты привёл это? Оно как-то опровергает мои тезисы? S>>>> Про блокировки EP>>>Что именно? Вот это? "Точно — конкурентная гадость, которая скорей всего не lock-free." EP>>>Там сказано что она lock/wait-free? S>> В фоновом режиме для прохода по графу нет никаких блокировок.
EP>А что ты понимаешь под блокировкой? Stop-the-world? EP>Так речь же не об этом, а о гонках возникающих при обходе графа из одного потока, и изменениях этого же графа из других, и им подобных. EP>Есть статьи описывающие lock-free реализации, но как я понял нигде в mainstream это не реализовано.
Там может быть куча стратегий. Суть в том, что с каждой новой версией GC работает все быстрее. Если раньше были видны тормоза, то сейчас об этом все забыли
и солнце б утром не вставало, когда бы не было меня
Ну так все необходимые элементы же имеются. Так что никаких проблем в создание точной копии данных примеров не вижу. Разве что есть только один вариант записи (только через точку), а не два, как в C#.
Ну и кстати, это ещё и работает намного быстрее, чем EF. В данном случае не за счёт крутых оптимизаторов C++ или чего-то подобного, а за счёт метапрограммирования — запросы формируются во время компиляции, а не во время исполнения. Да, для какого-нибудь решения из области 1C подобное ускорение конечно же не принципиально. А вот в случае высоконагруженных веб-серверов это становится уже очень принципиально...
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Примеров достаточно, целая папка examples в наличие. Вот один файл оттуда, в котором сразу всё видно: https://github.com/rbock/sqlpp11/blob/master/examples/sample.cpp. S>> Во спасибо интересно. А такие как здесь http://infostart.ru/public/402433/
_>Ну так все необходимые элементы же имеются. Так что никаких проблем в создание точной копии данных примеров не вижу. Разве что есть только один вариант записи (только через точку), а не два, как в C#.
_>Ну и кстати, это ещё и работает намного быстрее, чем EF. В данном случае не за счёт крутых оптимизаторов C++ или чего-то подобного, а за счёт метапрограммирования — запросы формируются во время компиляции, а не во время исполнения. Да, для какого-нибудь решения из области 1C подобное ускорение конечно же не принципиально. А вот в случае высоконагруженных веб-серверов это становится уже очень принципиально...
Ну ка расскажи, как ты динамические запросы формируешь на этапе компиляции?
_
_>Ну так все необходимые элементы же имеются. Так что никаких проблем в создание точной копии данных примеров не вижу. Разве что есть только один вариант записи (только через точку), а не два, как в C#.
_>Ну и кстати, это ещё и работает намного быстрее, чем EF. В данном случае не за счёт крутых оптимизаторов C++ или чего-то подобного, а за счёт метапрограммирования — запросы формируются во время компиляции, а не во время исполнения. Да, для какого-нибудь решения из области 1C подобное ускорение конечно же не принципиально. А вот в случае высоконагруженных веб-серверов это становится уже очень принципиально...
Ну часто используемы запросы можно компилировать да и затраты на трансляцию мизерные http://www.codeproject.com/Articles/38174/How-to-improve-your-LINQ-query-performance-by-X дольше сам запрос выполняется
вот поновее http://blogs.msdn.com/b/ricom/archive/2008/01/14/performance-quiz-13-linq-to-sql-compiled-query-cost-solution.aspx
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> Потому, что SQL далек от совершенства для интеллисенсе EP>>Так зачем говорить что он понятен тем кто знаком с SQL? Там структура совершенно другая. S> Я этого не говорил. Я говорил только про битовые операции
ОК, видимо перепутал.
Тем не менее, с битовой операцией всё просто: "Что это? Битовая операция? А, пайп — всё понятно".
А с LINQ'ом же получается: "Что это? SQL запрос? А, монадическая нотация" — это при том что с монадами мало кто знаком, либо считают их чем-то трудно понимаемым. В любом случае разница кардинальная, как бы её не ретушировали ключевыми словами.
EP>>При этом да, инлайнить виртуальные/косвенные вызовы тоже возможно на этапе компиляции, но это очевидно труднее — так как требуется более серьёзный анализ. S> В большинстве это и не нужно.
В любом случае, это намного тяжелее, несмотря на то что "вся информация есть".
S>А виртуальные помогают конструировать иерархию и доступ к неопределенным типам через интерфейсы
Да понятное дело что виртуальные/косвенные вызовы имеют область применения. Но при этом использование их там, где они не нужны — приводит к вполне справедливым тормозам.
EP>>Так | это другая библиотека, ты за контекстом следишь? | это Boost.Range, а тут sqlpp11. S>А в Net это встроено в платформу.
Так это известная тема — вместо предоставления какой-то универсальной возможности, на C# решают какой-то сиюминутный use-case. Это приводит например к зоопарку с вариантами замыканий, которые даже ещё планируют расширять локальными методами. Также это приводит к меньшей гибкости самого языка — шаг влево/вправо — и упираешься в забор: 1
