Re[27]: MS забило на дотнет. Питону - да, сишарпу - нет? - Компьютерные священные войны

Здравствуйте, vdimas, Вы писали:
S>>Вы перепутали два совершенно разных коннектора.
V>Не, это ты перепутал и аки утопающий за соломинку хватаешься.
Вот это уже феерия пошла.

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

V>Сейчас достоверно работает официальный.
Ещё месяц назад "достоверно" для MySQL работал ODBC драйвер.

V>По твоей ссылке пока мест неизвестно что.
Как там говорил крокодил Гена? "Хотел бы я быть таким неизвестно кто!"

V>Ты бы выплюнул, прежде чем говорить.
Ну, то есть продолжается натягивание сов на глобус. Предсказуемо, предсказуемо.
Вместо того, чтобы признать "ну да, я невнимательно посмотрел на ссылку, перепутал репозитории", начинают придумываться фантастические причины не рассматривать приведённую мной ссылку.
Давайте вы просто перестанете вот это всё лить на форум перед изумлённой публикой, а?

V>Во-первых, вот они:
V>https://github.com/mysql-net/MySqlConnector/tree/master/tests/MySqlConnector.Tests
Во-первых, нет. Ну блин научитесь уже открывать ссылки, которые вам присылают. Видим, что помимо собственно Unit тестов, в проекте есть ещё несколько видов тестов.
Включая тесты на совместимость с тем коннектором, который вы считаете "правильным".

V>Во-вторых, в тесты ты не заглядывал.
V>Сравни с тестами linq2db, включая предыдущие две инкарнации, начиная с RDF.
Не, давайте лучше сравним с тестами того коннектора, который вы готовы выбрать, отвечая за это банкротством. Мы же выбираем не между MySqlConnector и Linq2db, а между MySqlConnector и Connector/NET.

V>Их нет.
Ну, то есть то, что ребята прошли все тесты на ADO.Net Conformance tests, это как бы ерунда. Кстати, сколько из них завалил Connector/NET?

V>А в поделии по твоей ссылке до продакшена дойдёт любая бага.

V>В деле доступа к БД трясутся над тем, чтобы данные правильно выдавались, бо страшно.
Короче, вы уже начинаете фантазировать вслух. Неинтересно.
V>Ответил выше.
Не, не ответили. Вы пишете про то, как вы хотите, чтобы всё было. А по факту официальный драйвер запросто умеет возвращать бред при определённых сочетаниях фактического и запрошенного типов. Как раз тот тип багов, который вы тут на строчку выше приводили как самый страшный.
Или вот https://bugs.mysql.com/bug.php?id=91754 — нормас, да? Можно до седых волос дойти, пытаясь найти, кто попортил данные в базе.

Но вас же это не смущает — миллионы мух не могут ошибаться.
V>Я находил баги и в майкрософтном ADO.Net драйвере к MS SQL.
V>В дотнет Core тоже найдено и зарепорчено несколько багов.
Ну, вот видите! Внезапно оказалось, что баги в драйвере — отнюдь не катастрофа, не разорение компании. Нашли, заворкэраундили, зарепортили в гитхаб.
V>А ты в этом плане никто и звать тебя никак.
Ну, как же тут на личности-то не перейти.
V>Болтун-фантазёр, который вообразил себе будто дотнет бабочками какает, просто потому что это дотнет, а как дела обстоят на самом деле — ни сном ни духом.

V>Да, я помню, как ты чуть ли не громче всех орал примерно в 2005-м, что дотнет позволяет делать меньше ошибок.
V>Но на деле вышло наоборот — такого чудовищного кол-ва ошибок как в дотнетном коде еще поискать.

V>Чего далеко ходить, по твоей ссылке код каких-то конченных двух олигофренов, посмотри сам:
V>Ничего тебя не смущает?

V>Приведение sealed this к интерфейсу.
V>В голове у авторов мусор вместо человеческих мозгов.

Может быть. А может быть — просто артефакты процесса разработки. В какой-то итерации этого sealed класса такое приведение было необходимым; потом оно перестало быть нужным, а код вызова — остался.

V>А лично у меня лёгкий ступор.
V>И от того, как много в дотнете профнепригодных дэбилов, прям гнездо.

V>И особенно когда этих дэбилов представляют в духе "полюбуйтесь на наших передовиков!".
V>Если передовики такие, какие ж остальные?

Код остальных можно посмотреть в оракловом коннекторе.

V>Хинт: чем очевидней спекуляция, тем больше тянет на зевоту.
А то.

Здравствуйте, vdimas, Вы писали:
V>Первый раз на моей памяти в техническом споре человек с пеной у рта доказывает не то, что видел или хотя бы что ему случайно привиделось, а то, что из пальца только что насосал.
А всё отчего? Оттого, что кто-то не умеет читать.
Давайте вспомним, откуда всё началось:
https://rsdn.org/forum/flame.comp/8082525.1

При этом "копировать", собственно, ничего не надо. В реализации IDataRow можно делать конвертацию на лету при помощи MemoryMarshal.

Я что, обещал, что 100% провайдеров под дот нет делают именно так? Нет.
Это было в ответ на "В дотнете же это всё "даётся сверху" без малейшей возможности настроить под себя" и "в отличие от дотнетных дров, нет надобности копировать эти данные".
Внезапно, простейшая мысль о том, что "сверху" в дотнете даётся только IDataRecord/IDataReader, а всё остальное — оно идёт "снизу", оказалась для вас неподъёмно сложной.
Далее, я открытым текстом с самого начала писал:

Воображаем примерно такую штуку:
public struct DataRecord: IDataRecord
{
private Span<byte> _rawData;
public int GetInt32(int i) =>
GetFieldType(i) == typeof(int)
? MemoryMarshal.GetReference(MemoryMarshal.Cast<byte, int>(_rawData.Slice(GetFieldOffset(i)));
: Convert.ToInt32(GetValue(i));

...
}

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

V>Уровень днище, ценность "экспертного мнения" отрицательная.
Ну да. В топике, правда, есть только один участник, претендующий на экспертность своего мнения. Но ценность этого мнения определена верно.

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

V>>Первый раз на моей памяти в техническом споре человек с пеной у рта доказывает не то, что видел или хотя бы что ему случайно привиделось, а то, что из пальца только что насосал.
I>Как я вижу, это именно твой подход почти что в каждой теме.

Сделай так, чтобы и другие увидели — давай цитаты.

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

V>>Тонкий клиент кушает данные малыми порциями, но сервер может ворочать большими порциями.
V>>Причём, ворочать не на SQL-языке, бо он тормозной аки первый в мире калькулятор, а на каком-нить хотя бы на пару порядков более эффективном.
S>Ну, вот пока что, по мере погружения в тему, не видно перспектив сделать эффективнее на пару порядков

.

Компиллируемые языки эффективнее скриптовых примерно на порядок.
А два порядка — это эффект уже от СМО, на этом и строился рассчёт.

S>Даже если мы рассматриваем только pure и deterministic запросы, обеспечение ACID накладывает свои ограничения.

А что тут нового?
Там как в любом другом наборе ресурсов и очередей к ним.

S>Т.е. при самом неоптимальном query plan, основные тормоза будут даже не на интерпретации выражений вроде GetIntFieldByOffset()*GetDecimalFieldByOffset(), а на захвате блокировок.

Эээ, тормоза на блокировках зависят от частоты конфликтов квадратично.
В этом прелесть механизмов СМО и засада одновременно.
Т.е. слишком большой штраф при увеличении конфликтов, но и уменьшение конфликтов происходит в квадратичной зависимости от улучшения эффективности.

В общем, есть такая дисциплина — теория массового обслуживания, я одно время плотно по ней упражнялся.

Она простая и одновременно мощная — там 3-4 основные формулы всего (три основных вида распределения плотности потока заявок, но можно взять нормальное распределение для простоты), с помощью этого аппарата можно расписать вообще всё происходящее в IT в плане обсуждаемого, т.е. работу любых сервисов, локального пула потоков IO и задач, общение многих независимых программ и/или многих независимых сетевых соединений одной программы (а так же в произвольном сочетании) через одну сетевую карту и т.д..

К каждому ресурсу приписывается трафик заявок и среднее время обработки заявки в отсутствии ожидания.
Можно найти среднюю длину очереди, можно найти среднее время ожидания в очереди и т.д., так как основной закон прост аки закон Ома.

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

Т.е., при уменьшении времени обработки каждой заявки на порядок, время ожидания в очереди изменится на два порядка при том же трафике.

Прикинь, уменьшение времени исполнения заявки в системе из одной машины вдвое равно масштабированию этой машины в кластер на 4 узла.
(это если считать, что сам кластер ничего не стоит с т.з эффективности, т.е. кластер сферический в вакууме)

Если в 10 — то в 100.
Т.е. заменили скриптовую машинку на компиллируемый код — получили из одной машины аналог развёрнутого кластера на 100 узлов (при этом сам механизм организации кластера всё еще сферический и ничего не стоит).

И это, сцуко, такая аппетитная морковка перед носом, что не возвращаться к этой идее невозможно.
И я регулярно напоминаю в спорах, что улучшение эффективности только за счёт смены технологий серверного приложения способно насовсем отбить надобность разворачивания сколь угодно большого кластера, который разворачивается с целью повышения эффективности (кластера бывают разных типов, речь о нагрузочном кластере), озаботившись только резервированием с целью fault tolerance.

Походу сам с собой разговаривал. ))
До меня только сейчас дошло, что ты был не в курсе этих зависимостей про частоты конфликтов в СМО, т.е. банально не понимал зачем я вообще эти темы обсуждал, про компиллируемые серваки.

Ну... зато теперь ты должен лучше понимать мотивы, двигавшие меня начать обсуждения насчёт слияния бизнес-кода и функциональности сервера данных в компилябельном нейтивном оргазме. ))

Кстате, принципиальное отделение текущих/оперативных данных от т.н. "исторических" тоже даёт сравнимый чудовищный эффект.
На своей заднице испробовал когда-то, да еще на тормознутой технике конца 90-х — начала нулевых, когда любые эффекты были ну уж слишком хорошо заметны.

S>И если мы его скомпилируем в бинарь, устранив интерпретатор, то захват/отпускание блокировок никуда не денутся.
S>Ну, впрочем, это всё ещё такие, прикидки на пальцах.

И одновременно с этим еще больше начинаю тебя не понимать уже я...

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

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

S>Здравствуйте, Serginio1, Вы писали:
S>>Почему нельзя ввести такие структуры непонятно.
S>Потому, что очень многое в дотнете и в существующих программах для него завязано на нынешнее устройство строк.

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

На сегодняшний день целиком и полностью доступна аналогичная функциональность поверх строк Span<> как узких UTF8, так и последовательности широких 16 битных char.
Эта функциональность раскидана по АПИ дотнета:
https://docs.microsoft.com/en-us/dotnet/api/system.memoryextensions?view=net-5.0
https://docs.microsoft.com/ru-ru/dotnet/api/system.buffers.text.utf8parser?view=net-5.0
https://docs.microsoft.com/ru-ru/dotnet/api/system.buffers.text.utf8formatter?view=net-5.0
https://docs.microsoft.com/en-us/dotnet/api/system.int32.tryparse?view=net-5.0#System_Int32_TryParse_System_ReadOnlySpan_System_Char__System_Int32__

Но у себя, например, собираю требуемую функциональность "в одну точку" через "инлайные" статические классы-хелперы.

Причём, до 3-го .Net Core самописные хелперы рвали по эффективности имеющиеся аналоги из АПИ как тузик грелку.
Уже к 5-му дотнету надобность в своих самописных хелперах вокруг последовательностей символов отпала.

Остались только кое-какие вопросы к парсингу и форматированию чисел с плавающей точкой — в дотнете используется промежуточный буфер, а можно использовать подставляемый, экономя на одном лишнем копировании результата. Если/когда дадут соотв. сигнатуры, то вопрос можно будет считать окончательно закрытым.

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

V>Ну... там завязка не столько на устройство, сколько на имеющуюся функциональность вокруг такого устройства, включая парсинг и сериализацию банальных чисел и дат.

V>На сегодняшний день целиком и полностью доступна аналогичная функциональность поверх строк Span<> как узких UTF8, так и последовательности широких 16 битных char.
V>Эта функциональность раскидана по АПИ дотнета:
V>Но у себя, например, собираю требуемую функциональность "в одну точку" через "инлайные" статические классы-хелперы.
В этом толку нет, т.к. все эти Span<char> и Span<byte> всё ещё требуют непрерывный блок памяти.
Для того, чтобы внедрять "альтернативные строки", нужно переписывать алгоритмы не на Span, а на IReadOnlySequence.
То есть то, что пилится сейчас, помогает для того, чтобы выпарсить, к примеру, HTTP-дату, которая лежит где-то в середине byte[], без копирования этого кусочка и трансформации его в отдельный массив char[].
А вот если наши данные представлены в памяти как цепочка или дерево массивов byte[], и дата попала на границу фрагментов, то мы не сможем сконструировать из этих сырых байтов необходимый для Span блок.

С точки зрения перспективы замены штатного класса string на "свои аналоги" это и есть тупик.

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

V>>На сегодняшний день целиком и полностью доступна аналогичная функциональность поверх строк Span<> как узких UTF8, так и последовательности широких 16 битных char.
V>>Эта функциональность раскидана по АПИ дотнета:
V>>Но у себя, например, собираю требуемую функциональность "в одну точку" через "инлайные" статические классы-хелперы.
S>В этом толку нет, т.к. все эти Span<char> и Span<byte> всё ещё требуют непрерывный блок памяти.

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

S>Для того, чтобы внедрять "альтернативные строки", нужно переписывать алгоритмы не на Span, а на IReadOnlySequence.

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

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

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

И?
Обсуждается драйвер к MySQL.
Беру доку, беру официальный драйвер, смотрю, комментирую увиденное.

S>Когда вы по делу пишете — прямо интересно почитать. А вот эти вот кривляния — они зачем?

Мда, с рефлексией у кое-кого баальшие проблемы. ))
Я вполне по-делу (да, всё на месте) критиковал имеющийся драйвер (для MySQL, один из критикуемых) , но теперь должен чувствовать свою вину, что он такой какой есть?
Потому что не обратил внимания, что ты решил пообсуждать некую ноунейм реализацию в топике, где речь шла о том, каким кодом фактически пользуются сегодняшние разработчики? ))

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

Мне точно требуется объяснять, почему в таких сценариях принято сходу посылать?

V>>Сейчас достоверно работает официальный.
S>Ещё месяц назад "достоверно" для MySQL работал ODBC драйвер.

Так и работает достоверно, я его когда-то замечательно использовал для MySQL.
Мне сказали об "официальном" драйвере к MySQL — ОК, посмотрел и на него.

V>>Ты бы выплюнул, прежде чем говорить.
S>Ну, то есть продолжается натягивание сов на глобус. Предсказуемо, предсказуемо.

А тут бы уже накрылся ветошью и не отсвечивал.
Какой ты, оказывается...
А всё "вы", да "вы".
Пипец днище. ))

Я так думаю, что ты специально скатился на трешовые пошлости, чтобы тебя не ткнули носом, что с одной стороны обсуждается драйвер доступа к БД, а с другой твой пример про ORM и linq маппер, да еще который насквозь прозрачен, т.е. в любой своей строчке поддаётся тривиальнейшему хотя бы code review, независимому от остального проекта, бо с декомпозицией там полный порядок... в отличие от задачи верификации парсеров или многошаговых хелперов над нетривиальными АПИ. Тут только тысячи тестов решают или широкое использование многими тысячами независимых разработчиков.

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

I>>и всяким плюшкам вокруг него построеным, type narrowing, control flow analysis и тд.
V>Не имеет отношения к языку.
I>>2 перформанс компилятора — улучшился в разы
V>Не имеет отношения к языку.
I>>3 слабоватая поддержка редакторами — compiles services теперь адекватные, навигация, рефакторинг, интеллисенс теперь заруливают любой жээс редактор.
V>Не имеет отношения к языку.

Это в С++ оно не имеет отношения к языку. Поэтому и получили тот инструментарий для него, что получили.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

V>И всё же, это не имеет отношения к языку.
V>Это как пытаться называть улучшения Решарпера улучшением/развитием C#.

Решарпер вторичен. А вот улучшение VS таки да, напрямую связано с улучшением C#. partial methods тому хороший пример.
Совместный дизайн языка, компилятора и тулов, как это происходит в случае C# — очень хорошая практика.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

I>>Cуть изменений, о которых я сказал, — препятствия для перехода устранены.

V>Но в статье речь о другом.
V>О том, что обратный переход на JS даёт больше плюшек.

В статье утверждается, что в 18м году на Реакте не было особых бенефитов от тайпскрипта. И это действительно так и было на тот момент.
Если раньше Реакт разработчики шарахались от Тайпскрипта, то сейчас Тайпскрипт уже вариант нормы.

I>>Наоборот — изменили язык, добавив конкретные фичи.

V>Улучшение вывода типа — это не изменение языка, это его улучшение.

И с каких пор улучшение перестало быть изменением?

V>Но фишка TS в том, что код без проблем можно писать и при недостаточном выводе типов, страдает только intellisense.

При недостаточном выводе типа страдает качество приложения, т.е. вместо number спокойно приходит object и компилер это проглатывает.

I>>>>и всяким плюшкам вокруг него построеным, type narrowing, control flow analysis и тд.
V>>>Не имеет отношения к языку.
I>>Наоборот. Язык это не только синтаксис.

V>И всё же, это не имеет отношения к языку.

Тайпскрипт это целиком про типы. Он вообще никак не исправляет JS, только навешивает типизацию ради компайл-тайм бенефитов.

V>Это как пытаться называть улучшения Решарпера улучшением/развитием C#.
V>Т.е. бред сивой кобылы.

Похоже, ты про тайпскрипт прочитал одну ту самую статью

V>Это была лишь одна из претензий.
V>И большие проекты по-прежнему запускаются далеко не мгновенно.

Запуск большого проекта никак не зависит от того, чем его компилировали, typescript, babel, flow и тд.
А вот компиляция большого проекта сократилась в разы и перестала быть препятствием.

I>>Еще одна причина — малое количество тайпингов для готовых либ. Она тоже решена. Часть проектов перешли на TypeScript, часть запилили руками и предлагают тайпинги искаропки, часть имеют 3d-party поддержку, которая стала проще.

V>"Проблема" была решена еще раньше тулзинами, дающими скелет такой типизации.

Пример такой "тулзины" ? Надеюсь это не Google Closure Compiler ?

I>>А это фича как раз JavaScript, а не ТайпСкрипт

Основные фичи тайпскрипта находятся в тех самых типах — интерфейсы, дженерики, вывод типа и тд и тд и тд.

V>Это всё давно было на 2018-й.

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

V>>>Я прошу показать — в каком из своих утверждений?
I>>Читай сам:
I>>"However, this comes at a cost. TypeScript, requires much more time to compile."

V>Ты отвечаешь в этом абзаце невпопад.
V>Что касается туплов-генериков, то это опять более для интеллисенса, до этого можно было точно так же работать с обычными туплами.

Именно — TypeScript добавляет исключительно типы. Всё остальное берется из EcmaScript.
Туплы без типов мало чем интересны, т.к. в этом случае типизация нарушается на раз и компилер даже варнинг не покажет.

V>Ну вот на неудобства и надо было пытаться отвечать.
V>Но отвечать там нечего.
V>Практически ничего из изменений языка на перечисленные неудобства не влияют.

Какое избирательное зрение. Смотрим вместе
— автор упоминает медленную компиляцию. Проблема решена.
— автору не хватает тайпингов, а имеющиеся добавляют проблем. Проблема решена.
— типы добавляют проблем. Проблема решена.

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

V>>>Первый раз на моей памяти в техническом споре человек с пеной у рта доказывает не то, что видел или хотя бы что ему случайно привиделось, а то, что из пальца только что насосал.
I>>Как я вижу, это именно твой подход почти что в каждой теме.

V>Сделай так, чтобы и другие увидели — давай цитаты.

Самое простое, из последнего — твои рассуждения про ТайпСкрипт, про кофе, всё прямо в этом треде.

http://rsdn.org/forum/flame.comp/8102709.1
Вот отсюда ясно, что ты настаиваешь непойми на чем. Похоже, ты так и не понял, что Тайпскрипт только тем и занят, что добавляет типы. Но тебя почитать, окажется что это все и за фичи считать нельзя

Теперь про кофе, ржом вместе в голос:

Вот твой опыт с туркой:

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

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

Вот снова подробности про турку:

1. Одна турка способна выдать одну порцию кофе примерно раз в 15-20 минут, а их редко бывает больше одной в таких заведениях.

Черепаха-бариста?

А вот твоя реакция на "свежеобжареный кофе":

В кафе при тебе зерна не "обжаривают" — слегка разогревают.
Это, скорее, часть антуража.
Обжаренным по технологии зёрнам не требуется повторная обжарка или разогрев.
Более того, при повторном "разогреве" зёрна теряют часть аромата.
Это что-то типа размена аромата из чашки на аромат в заведении. ))

Похоже, что ты фантазировал прямо по ходу.

Далее, уникальный рецепт заваривания в турке от Vdimas

По технологии, кофе в турке доводится до кипения 7-8 раз, т.е. бармен 7-8 раз приподнимает турку над песком,

Вот еще:

Де-факто, характерную горечь кофе в турке приобретает уже после первого закипания, но по классическому восточному рецепту уровень горечи доводят в таком кофе до абсурда.

Где же ты пил такой шмурдяк? Я вот ни разу не нарывался на горький кофе в турке. Ну вот ни разу.

Далее, сеанс телепатии:

Во всех перечисленных тобой заведениях будет ассортимент кофе из автоматов.

Здесь, похоже, не помогли ни ссылки, ни фото — vdimas знает лучше

Продолжаем про кофе, феерия

Порция 150 гр только закипает в первый раз примерно за 7 минут.

Видео с Мариной Хюппёнен не помогли, vdimas знает лучше

Ты кофе на спиртовке варишь чтоли или на примусе?

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

V>Компиллируемые языки эффективнее скриптовых примерно на порядок.
V>А два порядка — это эффект уже от СМО, на этом и строился рассчёт.

S>>Даже если мы рассматриваем только pure и deterministic запросы, обеспечение ACID накладывает свои ограничения.

V>А что тут нового?
V>Там как в любом другом наборе ресурсов и очередей к ним.
А что мы считаем ресурсом? Если мы делаем классический блокировочник, то у него минимальная гранулярность блокировки — 1 строка.
То есть мы на select — запрос, который сканирует 50% таблицы с миллионом записей, последовательно захватываем и отпускаем 500000 блокировок.
На пальцах — цикл сканирования выглядит так:

foreach(var candidateRow in table.Index1.IndexSeek(predicate.IndexPart))
{
   lock(GetRowLock(candidateRow))
   {
     if(predicate.ResidualPart(candidateRow))
       yield return selector(candidateRow);
   }
}

S>>Т.е. при самом неоптимальном query plan, основные тормоза будут даже не на интерпретации выражений вроде GetIntFieldByOffset()*GetDecimalFieldByOffset(), а на захвате блокировок.

V>Эээ, тормоза на блокировках зависят от частоты конфликтов квадратично.
Даже в отсутствие конфликтов блокировки отжирают время. Вместо быстрого цикла с телом типа table[rowNumber].Slice(fieldOffset, fieldLength), которое при удаче вообще сворачивается в пару ассемблерных инструкций, у нас на каждой итерации начинается беготня по таблицам блокировок.
Интуитивно кажется, что эта беготня имеет примерно тот же порядок стоимости, что и интерпретация выражений вроде GetFieldValue(rowPointer, fieldId).
То есть мы ускорим работу не на порядок, а всего в пару раз.

V>Прикинь, уменьшение времени исполнения заявки в системе из одной машины вдвое равно масштабированию этой машины в кластер на 4 узла.
V>(это если считать, что сам кластер ничего не стоит с т.з эффективности, т.е. кластер сферический в вакууме)
Ну, вот у меня пока такое понимание, что основные задержки обработки "заявки" в современных трёхзвенках — это трипы между апп-сервером и СУБД. Если внести весь код в СУБД, то как раз получим те самые два порядка.
Компиляция — штука хорошая, но её эффект заранее трудно оценить именно потому, что не получается сделать из плана запроса код, сравнимыый с каноническим while(p*++=q*++);.

V>Походу сам с собой разговаривал. ))
Нет, почему. Я эту идею целиком поддерживаю.
V>До меня только сейчас дошло, что ты был не в курсе этих зависимостей про частоты конфликтов в СМО, т.е. банально не понимал зачем я вообще эти темы обсуждал, про компиллируемые серваки.
Ну, вот мне сначала казалось, что компиляция даст офигенный буст к производительности DBMS. А сейчас я вижу некоторые ограничения, которые на первый взгляд будут замедлять исполнение кода примерно на десятичный порядок по сравнению с компилируемым кодом, который шарашит по "голым" данным, без оглядки на isolation и durability.

В частности, от идеи работать с memory-mapped file, похоже, придётся отказаться. Потому, что write-ahead log для него потребует flush на каждое изменение, вместо одного flush на коммит.
Это сильно ухудшает производительность сканирования — вместо тупого обращения по смещению pageNo*pageSize, нужно лезть в bufferManager.getPage(pageNo), который даже на happy path добавляет лишнюю косвенность.
Поэтому MMF будут уместны только для mostly-read key-value storage, где как правило 1 транзакция == 1 изменение, а чтения доминируют над записями.

V>Ну... зато теперь ты должен лучше понимать мотивы, двигавшие меня начать обсуждения насчёт слияния бизнес-кода и функциональности сервера данных в компилябельном нейтивном оргазме. ))
Да, возможно.

V>На своей заднице испробовал когда-то, да еще на тормознутой технике конца 90-х — начала нулевых, когда любые эффекты были ну уж слишком хорошо заметны.
Вот это как раз странно. Потому что при наличии уместных индексов, уменьшение рабочего объёма в N раз сокращает время операции на константу ~ log(N).

V>Обрати внимание на мою тактику: я первым делом выясняю мотивы — что, куда, зачем, сколько это даст? Какой ценой?
V>Если дебет с кредитом даёт неплохой расклад — можно и углубиться.
Тут сложность в том же, что и в живописи: не получится сначала уловить сходство, а потом написать портрет.
И так понятно, что переход от подхода А к подходу Б даст выигрыш G с затратами L.
А вот оценить величины G и L, хотя бы с точностью до порядка — большая проблема. Ну, вот можно посмотреть в ветку с обсуждением immutable коллекций — там мелкие изменения в коде ведут в резким скачкам в производительности.
И эти изменения нифига не интуитивны — почему простой безусловный вызов по известному адресу стоит на порядок дороже, чем условный переход?
То есть "сколько это даст" можно измерить только тогда, когда уже значительная часть системы готова.
Причём рассуждать "по аналогии" нельзя. То есть, к примеру, мы можем взять какой-то кусочек кода, типа вычисления пи до 1000 знака. Запилим его на Expression<Func<int>>, прикрутим интерпретатор, и замерим скорость вычисления через интерпретатор против вычисления через сгенерированный Compile. метод. Заодно замерим скорость выполнения Compile.

Можно ли из полученных результатов делать какие-то выводы про производительность выполнения SQL кода в режиме интерпретации vs в режиме компиляции?
Нет, нельзя. Ну, то есть понятно, что медленнее от компиляции код уже не станет. А вот насколько он станет быстрее — это вопрос. Сколько будет стоить компиляция — тоже вопрос, от которого зависит ответ на более интересный вопрос "при каких условиях динамическая компиляция выиграет у интерпретации". Похожий вопрос — "при каких условиях статическая компиляция выиграет у динамической".
Вот умозрительно на эти вопросы отвечать — дохлый номер. В конце всегда рулят бенчмарки, а не рассуждения уровня "палец к носу".
А чтобы провести бенчмарки, надо что-то написать.

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

S>В частности, от идеи работать с memory-mapped file, похоже, придётся отказаться. Потому, что write-ahead log для него потребует flush на каждое изменение, вместо одного flush на коммит.

Так а зачем лог и данные в одном файле держать? Сиквел держит в разных, и для лога MMF в одно место не уперся, там все операции последовательные. А для файла страниц MMF — то что дохтур прописал.

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>В частности, от идеи работать с memory-mapped file, похоже, придётся отказаться. Потому, что write-ahead log для него потребует flush на каждое изменение, вместо одного flush на коммит.
НС>Так а зачем лог и данные в одном файле держать? Сиквел держит в разных, и для лога MMF в одно место не уперся, там все операции последовательные. А для файла страниц MMF — то что дохтур прописал.
Даже если держим в разных, WAL требует, чтобы страницы лога были записаныдо того, как на диск уедут изменённые страницы данных.
В MMF мы не можем этого гарантировать.
Поэтому возможна такая ситуация:
1. мы хотим внести изменение x = x + 1.
2. Мы добавляем к логу запись (@x, oldX, newX); (без flush)
3. Вносим изменение x = x + 1 в станицу данных;
4. Внезапно ОС решает, что пора скинуть страницу данных на диск
5. Происходит сбой (до коммита транзакции).
Всё — у нас на диске есть новое значение x, но нет лог-записей для того, чтобы откатить x обратно.
Чтобы предотвратить это, мы будем вынуждены делать flush лога между 2 и 3.
Альтернатива — иметь свой менеджер буферов, который в момент вытеснения буфера на диск делает flushLog(minLSN), гарантируя фиксацию нужной нам части лога.
Насколько я знаю, MS SQL идёт именно по этому пути.

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

НС>>Так а зачем лог и данные в одном файле держать? Сиквел держит в разных, и для лога MMF в одно место не уперся, там все операции последовательные. А для файла страниц MMF — то что дохтур прописал.
S>Даже если держим в разных, WAL требует, чтобы страницы лога были записаныдо того, как на диск уедут изменённые страницы данных.

Поэтому кеширование для таких файлов отключается.

S>В MMF мы не можем этого гарантировать.

Так не надо лог в MMF писать, о чем и речь.

S>2. Мы добавляем к логу запись (@x, oldX, newX); (без flush)

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Поэтому кеширование для таких файлов отключается.
Нет. Так никто не делает.

S>>В MMF мы не можем этого гарантировать.

НС>Так не надо лог в MMF писать, о чем и речь.
Это как раз понятно. Лог пишется в режиме stream: добавляем всегда в конец. Но отсутствие кэширования (== flush на каждый write) гарантированно убъёт производительность при модификациях.
Представьте себе выполнение операции update employee set salary = salary * 1.05 where region = @region.
То, что вы предлагаете, означает выполнение flush лога N раз для N записей, попавших под предикат.
Это — очень плохое решение, т.к.
— на HDD мы получим ограничение быстродействия в ~100 изменений в секунду, т.е. транзакция, трогающая всего лишь 1000 записей, будет выполняться не меньше 10 секунд.
— на SSD мы получим многократные перезаписи одной и той же страницы, очень быстро изнашивая диск.

S>>2. Мы добавляем к логу запись (@x, oldX, newX); (без flush)

НС>Так что тут если какое то буферизирование при записи в лог и делать, то только чисто программное, на уровне прикладного кода.
По большому счёту, нам всё равно, как устроена буферизация при записи в лог. Там главное — возможность сделать честный flush() в нужный приложению момент.
Отключение буферизации делается в первую очередь для того, чтобы избежать бессмысленного перекладывания данных из одного буфера в другой, т.к. нам всё равно известны точные моменты, когда надо всё же сделать flush.
То есть в дотнете / windows можно реализовать два способа:
1. FileStream.Flush + FlushFileBuffers (неэффективно)
2. Открыть файл c флагами FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH. Тогда можно делать просто FileStream.Flush().
Подчеркну: в обоих случаях мы делаем Flush лога на на каждое изменение, а только на каждый commit transaction. То есть транзакция, которая трогает 1000 записей, будет выполняться ~10ms (если выбранный размер буфера достаточен для того, чтобы избежать промежуточных сбросов в процессе исполнения).

НС>И, в любом случае, MMF для файла лога бессмысленен и бесполезен, там все равно запись и чтение строго последовательные.
Речь идёт про MMF для файла данных.

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	30.09.21 09:27
Оценка:	+3

От:	Sinclair	https://github.com/evilguest/
Дата:	30.09.21 09:32
Оценка:	+3

От:	Sinclair	https://github.com/evilguest/
Дата:	30.09.21 10:28
Оценка:	+1

	От:	vdimas
	Дата:	01.10.21 02:03
	Оценка:

	От:	vdimas
	Дата:	01.10.21 02:58
	Оценка:

	От:	Ночной Смотрящий
	Дата:	01.10.21 08:21
	Оценка: