Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, artelk, Вы писали:
A>>На сколько реализуемо?
_>Ну т.е. предлагается просто сделать реализацию await из .net на базе C++ сопрограмм... Скучно — они способны на большее, на то, что недоступно в .net await.
Предлагается сделать так, чтоб лапши небыло, при сохранении всех бенефитов асинхронности.
_>Если же говорить про конкретику, то если исключить семафор, реализации подобного и их подробные обсуждения были на этом форуме ещё год назад. Ну и касательно добавления подобного семафора не вижу каких-то принципиальных затруднений, хотя такое уже на практике не проверял.
Помнится там обсуждалось как вернуться в вызывающий поток, т.е. один из юзкесов, реализуемых через await.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>У тебя странное понимание мгновенности. Я подробно не считал, но там явно на пару секунд набегает. Это далеко не мгновенно. Намного более тяжелое твое сообщение с rsdn грузится у меня быстрее.
По ощущениям реально мгновенно, т.к. страница появляется сразу. Причём со всеми нужными картинками.
А как ты там насчитал несколько секунд то? ) Или ты думаешь оно последовательно грузится? )))
виде сообщение грузится безусловно быстрее его сайта:
GET http://rsdn.ru/forum/flame.comp/5795432.1 [HTTP/1.1 200 OK 192мс]
GET http://rsdn.ru/bundles/js/site [HTTP/1.1 200 OK 25мс]
GET http://rsdn.ru/bundles/css/site [HTTP/1.1 200 OK 40мс]
GET http://rsdn.ru/bundles/js/old/messages [HTTP/1.1 200 OK 51мс]
GET http://rsdn.ru/bundles/css/old/messages [HTTP/1.1 200 OK 42мс]
GET http://www.google-analytics.com/analytics.js [HTTP/1.1 200 OK 49мс]
GET http://www.gravatar.com/avatar/5145330fefa221e7027d7d981ee4917c [HTTP/1.1 200 OK 145мс]
GET http://rsdn.ru/account/country/rus/image [HTTP/1.1 200 OK 16мс]
GET http://rsdn.ru/Images/wait.gif [HTTP/1.1 200 OK 11мс]
GET http://rsdn.ru/Content/icons.svg [HTTP/1.1 200 OK 6мс]
GET http://rsdn.ru/images/wait.gif [HTTP/1.1 200 OK 12мс]
GET http://www.google-analytics.com/collect [HTTP/1.1 200 OK 112мс]
Но оно и должно так быть, т.к. страничка как раз намного легче... Я уже молчу про то, что пинг до его сервера 35 мс, а до rsdn 3 мс. Однако если мы возьмём такую http://rsdn.ru/forum/flame.comp/5795432
страничку (которая действительно потяжелее), то она по ощущениям грузится медленнее его сайта и как-то ощутимо кусками... А вот цифры из браузера:
GET http://rsdn.ru/forum/flame.comp/5795432 [HTTP/1.1 200 OK 18мс]
GET http://rsdn.ru/Forum/MsgList.aspx [HTTP/1.1 200 OK 666мс]
GET http://rsdn.ru/forum/flame.comp/5795432.1 [HTTP/1.1 200 OK 32мс]
GET http://rsdn.ru/bundles/js/site [HTTP/1.1 200 OK 26мс]
GET http://rsdn.ru/bundles/css/site [HTTP/1.1 200 OK 32мс]
GET http://rsdn.ru/bundles/js/old/messages [HTTP/1.1 200 OK 52мс]
GET http://rsdn.ru/bundles/css/old/messages [HTTP/1.1 200 OK 33мс]
GET http://www.google-analytics.com/analytics.js [HTTP/1.1 200 OK 51мс]
GET http://www.gravatar.com/avatar/5145330fefa221e7027d7d981ee4917c [HTTP/1.1 200 OK 159мс]
GET http://rsdn.ru/account/country/rus/image [HTTP/1.1 200 OK 16мс]
GET http://rsdn.ru/Images/wait.gif [HTTP/1.1 200 OK 10мс]
GET http://rsdn.ru/Content/icons.svg [HTTP/1.1 200 OK 6мс]
GET http://rsdn.ru/images/wait.gif [HTTP/1.1 200 OK 11мс]
GET http://www.google-analytics.com/collect [HTTP/1.1 200 OK 108мс]
GET http://rsdn.ru/bundles/js/old/msglist [HTTP/1.1 200 OK 19мс]
GET http://rsdn.ru/bundles/css/old/msglist [HTTP/1.1 200 OK 10мс]
GET http://rsdn.ru/script/showmenu.v1.js [HTTP/1.1 200 OK 23мс]
GET http://www.google-analytics.com/analytics.js [HTTP/1.1 200 OK 34мс]
GET http://rsdn.ru/Forum/images/thrs.gif [HTTP/1.1 200 OK 11мс]
GET http://rsdn.ru/Forum/images/flat.gif [HTTP/1.1 200 OK 11мс]
GET http://rsdn.ru/Forum/images/openall.gif [HTTP/1.1 200 OK 11мс]
GET http://rsdn.ru/Forum/images/refresh.gif [HTTP/1.1 200 OK 10мс]
GET http://rsdn.ru/Forum/images/prevg.gif [HTTP/1.1 200 OK 11мс]
GET http://rsdn.ru/Forum/images/next.gif [HTTP/1.1 200 OK 12мс]
GET http://rsdn.ru/Forum/images/new.gif [HTTP/1.1 200 OK 12мс]
GET http://rsdn.ru/Forum/images/sub.gif [HTTP/1.1 200 OK 12мс]
GET http://rsdn.ru/Images/rss.png [HTTP/1.1 200 OK 11мс]
GET http://rsdn.ru/Images/help.gif [HTTP/1.1 200 OK 11мс]
GET http://rsdn.ru/Forum/images/fr1.gif [HTTP/1.1 200 OK 13мс]
GET http://rsdn.ru/Images/search18.png [HTTP/1.1 200 OK 12мс]
GET http://rsdn.ru/Forum/images/fr2.gif [HTTP/1.1 200 OK 12мс]
GET http://rsdn.ru/Forum/LoadRe.aspx [HTTP/1.1 200 OK 123мс]
GET http://www.google-analytics.com/collect [HTTP/1.1 200 OK 50мс]
GET http://www.google-analytics.com/analytics.js [HTTP/1.1 200 OK 26мс]
GET http://www.google-analytics.com/collect [HTTP/1.1 200 OK 106мс]
GET http://rsdn.ru/Forum/images/fr0.gif [HTTP/1.1 200 OK 11мс]
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>При чем тут eval? Это прежде всего механизм, который позволяет компилятору вместо прямой компиляции кода генерировать в исполняемом файле AST. Именно благодаря этому возможны технологии типа LINQ. Если этого в языке нет, то возможна только его слабенькая имитация.
Так а зачем делать такие вещи в рантайме то? Строить конвейеры правильно во время компиляции. Они при этом и надёжнее и быстрее будут. Т.е. ты всё правильно написал, но с точки зрения что вариант linq — это идеал. А на самом деле это сомнительное решение...
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>При чем тут eval? Это прежде всего механизм, который позволяет компилятору вместо прямой компиляции кода генерировать в исполняемом файле AST. Именно благодаря этому возможны технологии типа LINQ. Если этого в языке нет, то возможна только его слабенькая имитация.
_>Так а зачем делать такие вещи в рантайме то? Строить конвейеры правильно во время компиляции. Они при этом и надёжнее и быстрее будут. Т.е. ты всё правильно написал, но с точки зрения что вариант linq — это идеал. А на самом деле это сомнительное решение...
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Какая ещё boost lambda? Откуда это тут вообще возникло? ) НС>Судя по всему ты просто не понимаешь про что речь. Вот смотри, если написать в шарпе так: НС>...
Вижу разницу между лямбдой и выражением в шарпе. Но по прежнему не вижу причём тут boost lambda. )
Здравствуйте, alex_public, Вы писали:
_>По ощущениям реально мгновенно
Ну ты просуммируй по своему же списку.
_>Но оно и должно так быть, т.к. страничка как раз намного легче...
Легче? Оно, насколько я могу судить, сильно тяжелее, как по количеству информации и всяких кнопочек, так и по объему работы по ее генерации на сервере.
Здравствуйте, alex_public, Вы писали:
_>Так а зачем делать такие вещи в рантайме то? Строить конвейеры правильно во время компиляции.
При чем тут конвееры? Ты опять совершенно не слышишь собеседника. Создать цепочку вызовов не проблема на большинстве языков. Проблема с содержимым этой цепочки, с тем что в параметрах where, orderby, groupby и т.д. LINQ на вход получает дерево выражения, а твои C++ аналоги, вместо этого, пытаются хаками это имитировать.
Здравствуйте, alex_public, Вы писали:
_>Вижу разницу между лямбдой и выражением в шарпе. Но по прежнему не вижу причём тут boost lambda. )
boost lambda точно так же пытается через зад имитировать отсутствующие до определенного момента в языке лямбды. Появление нормальных лямбд наглядно продемонстрировало ценность такого подхода. С цитированием, скорее всего, со временем будет то же самое. А пока С++ и качественный интерфейс к БД совместимы плохо.
Здравствуйте, artelk, Вы писали:
A>Предлагается сделать так, чтоб лапши небыло, при сохранении всех бенефитов асинхронности.
Для этого есть много разных вариантов, а не только сопрограммы. Но и они тоже имеются и полноценно работают (в том числе и во многопоточности, как уже продемонстрировал вместо меня Евгений).
А лично мне больше нравятся реализации типа модели акторов — так называемое "выпрямление кода" не нравится с архитектурной точки зрения, т.к. обычно смешивает принципиально разные вещи (типа работы с ui и сетью например).
A>Помнится там обсуждалось как вернуться в вызывающий поток, т.е. один из юзкесов, реализуемых через await.
Да да, точно. Но фокус был в том, что это как раз и было типа сложностью и модной фичей (понятно что подразумевался возврат в UI), а вариант с произвольным потоком наоборот тривиален и скучен.
Более того, если у нас нет обязательного требования возврата в тот же поток, то сам принцип await'a становится не особо интересным — любые реализации просто потоков становятся удобнее этого механизма. Причём речь как о зелёных (в случае потребности очень большого числа одновременных), так и даже о просто системных.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>По ощущениям реально мгновенно НС> Ну ты просуммируй по своему же списку.
Ещё раз повторюсь: ты думаешь оно последовательно грузится? )))
Я уже молчу про то, что значительная часть сразу загружаемого контента с его главной страницы не нужна для начального отображения.
_>>Но оно и должно так быть, т.к. страничка как раз намного легче... НС>Легче? Оно, насколько я могу судить, сильно тяжелее, как по количеству информации и всяких кнопочек, так и по объему работы по ее генерации на сервере.
Ээээ, ты точно прочитал моё сообщение? ) Я же показал подробно всё. Вариант без дерева намного легче (кстати, а сама страничка сообщения при этом всё равно дольше его сайта грузится по цифрам) и соответственно грузится легче. А вариант с деревом тяжелее, но и грузится дольше его сайта. Причём последнее визуально ощутимо.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, artelk, Вы писали:
A>>Для динамических запросов, вестимо.
_>А примерчик подобного из реальной практики можно? ) Ну чтобы требовалась бы обязательная кодогенерация в рантайме, а параметризация не спасала бы.
IQueryable<User> WithRole(this IQueryable<User> users, Role role)
{
return users.Where(u => u.Role = role);
}
//еще куча разных таких методов разной степени сложности
IQueryable<User> users = db.Users;
if(...)
users = users.WithRole(Role.Manager);
//куча всякого такогоvar items = users.Select(u => new {u.ID, UserGroupName = u.UserGroup.Name, u.RegistrationDate});
foreach(var item in items)//сформированный запрос идет к базе, вытягивается только то, что запросили
{
//...
}
Т.е. декомпозизия запроса на части, которые потом динамически собираем в один запрос.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Так а зачем делать такие вещи в рантайме то? Строить конвейеры правильно во время компиляции. НС>При чем тут конвееры? Ты опять совершенно не слышишь собеседника. Создать цепочку вызовов не проблема на большинстве языков. Проблема с содержимым этой цепочки, с тем что в параметрах where, orderby, groupby и т.д. LINQ на вход получает дерево выражения, а твои C++ аналоги, вместо этого, пытаются хаками это имитировать.
Это ты меня не слышишь. ))) Я не спорю с тобой на тему того, какие хаки приходится использовать в C++ для попотки реализации точной копии LINQ. Я говорю о том, что не надо пытаться реализовать именно LINQ, потому как есть более эффективные схемы (правда они не доступны в языках без МП времени компиляции, типа C#).
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Настолько удобно, что ты игрушечный функционал делал месяц чистого времени? S>>Админка посложнее будет, ты видишь только юзерскую часть. НС>Так и на rsdn, думаю, админка не проще твоей. А какая разительная разница в потраченном времени.
Вот смотри какая интересная штука: ты придумал какая у меня админка и придумал какая у рсдн админка.
Здравствуйте, alex_public, Вы писали:
S>>А анимация на главной есть?
_>Речь про автолистание "кусков статей + картинка из статьи"
Нет, оно не просто листается, оно плавно "переворачивается". Открой в хроме...
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>boost lambda точно так же пытается через зад имитировать отсутствующие до определенного момента в языке лямбды. Появление нормальных лямбд наглядно продемонстрировало ценность такого подхода.
Ааа типа такая аналогия к древности... Понятно)
НС>С цитированием, скорее всего, со временем будет то же самое.
Нафиг нафиг эту никчемную фигню. Не надо её подпускать к C++. Так же как и рантайм интроспекцию (а вот интроспекция времени компиляции действительно очень нужна).
Если же говорить об аналогиях этого "цитирования", то я бы наверное хотел получить в C++ функцию mixin из D. Она принимает строковый параметр (который должен быть определён на момент компиляции), воспринимает его как код, компилирует (причём с учётом окружающего контекста) и вставляет вместо себя. И всё это естественно во время компиляции, так что поверх всего этого потом ещё по полной гуляет дикий оптимизатор C++ (который скорее всего заинлайнит всё вокруг на несколько уровней). Вот это действительно мощный инструмент (конечно при условии, что ещё и разрешат полноценно работать со строками в шаблонах, как это сделано в D).
НС>А пока С++ и качественный интерфейс к БД совместимы плохо.
Хыхы, ну давай вернёмся от теории к реальным примерам. Помнится я уже приводил его на этом форуме и Ikemefula так и не нашёл что ответить...
Значит смотри, у нас есть некий библиотечный класс с кучей предков, полей, методов и т.п. Так вот его поля делятся на два типа: динамически инициализируемые (он сам этим занимается в своих конструкторах) и поля с реальными данными. Мы хотим хранить набор объектов этого класса в таблице базы данных. Естественно в нормальном виде (по колонке на не динамическое поле), а не как там какой-нибудь json или xml. Для простоты возьмём только две операции: добавление объекта в базу данных и выгрузка вектора объектов (сразу всех, что есть в табличке). Покажешь как реализуется подобное с помощью "качественно интерфейса к БД"? )
Да, и если что, у меня тут уже есть готовый код в пару строчек на C++, который именно это делает. Причём он работает сразу со всеми известными базами данных.
Здравствуйте, Privalov, Вы писали:
S>>Я слушаю, ты не думай так. Несколько изменений уже запланировал себе
P>Переходишь на правильные инструменты?
Да. Очень сильно подумаю насчет sqlpp11, прикину как разный код в разные браузеры пихать, разделю стили и js на админку и юзерскую часть, объединю svg графику.
A>IQueryable<User> WithRole(this IQueryable<User> users, Role role)
A>{
A> return users.Where(u => u.Role = role);
A>}
A>//еще куча разных таких методов разной степени сложности
A>IQueryable<User> users = db.Users;
A>if(...)
A> users = users.WithRole(Role.Manager);
A>//куча всякого такого
A>var items = users.Select(u => new {u.ID, UserGroupName = u.UserGroup.Name, u.RegistrationDate});
A>foreach(var item in items)//сформированный запрос идет к базе, вытягивается только то, что запросили
A>{
A>//...
A>}
A>
A>Т.е. декомпозизия запроса на части, которые потом динамически собираем в один запрос.
И где здесь что-то обязательное для рантайм кодогенерации? ) Наличие if'a в самом запросе (пока говорим о варианте с просто кодом — в варианте с базой данных вообще всё тривиально, т.к. можно играться с sql строками), статически скомпилированном, никак не повлияет на его производительность. Более того, скорее всего это будет ещё и более быстро, т.к. компилятор может пройтись оптимизатором по такому коду и заинлайнить нужное.
Ну ты просуммируй по своему же списку.
