Здравствуйте, Хвост, Вы писали:
Х>Здравствуйте, samius, Вы писали:
S>>Да не, можно найти тысячу ситуаций (искувственных и натуральных), где разница в способе размещения замыкания будет заметна. Взять хотя бы тот же расчет координат в GIS-ах. Да, точно! В таких нагруженных случаях пользоваться лямбдой вообще неуместно, потому говорить о разнице между размещением замыкания лямбды на стеке и хипе как-бы неуместно. Боюсь что больше будет заметна разница лямбд на делегатах (в C#) и лямбд на виртуальных функциях (Nemerle и F#). Х>кстати вот лично у меня для трансформации используется функтор, который создаётся на стеке, но компиляторы С++ сейчас настолько умные что инлайнят всё и вся и оверхедов ноль, поетому в С++ я думаю лямбды в моём случае никак не повлияют на производительность.
Про инлайнить все и вся — заявление слишком сильное. Все равно там куча условий. Сомневаюсь, что инлайнится метод трансформации координат из геодезии в экранные. Но если скажешь, что точно инлайнится — поверю наслово.
Будет ли лямбда C++ так же эффективна как вручную заинлайненный код — тоже не уверен.
X>, а вот с C# вопрос не однозначен.
Но необходимость лямбды в таких узких местах контроллируется программистом как и выбор аллокатора в C++.
Здравствуйте, Хвост, Вы писали:
Х>ну что значит досчитывать? вот я смотрю на екран, вижу объекты, нажал на другое место на обзорной вьюхе — у меня совсем другие объекты на екране, их прийдётся пересчитывать в псевдо-екранные, а ведь можно сразу в екранные. Если активно скроллить — зумить, то объекты на екране сменяют друг друга почти так же быстро как и при клике на обзорной вьюхе, тут "досчитывать" придётся по пол-екрана на скролл-зум.
Одно дело считать каждый раз из геодезии в экранные. Другое — считать каждый раз из геодезии в недоэкранные (это меньше, чем в полностью экранные) а остальное сделает железо. Если активно зуммить, то большой шанс, что можно сделать реюз предрассчитанных псевдоэкранных координат просто изменением матрицы преобразования.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Хвост, Вы писали:
Х>>Здравствуйте, samius, Вы писали:
S>>>Да не, можно найти тысячу ситуаций (искувственных и натуральных), где разница в способе размещения замыкания будет заметна. Взять хотя бы тот же расчет координат в GIS-ах. Да, точно! В таких нагруженных случаях пользоваться лямбдой вообще неуместно, потому говорить о разнице между размещением замыкания лямбды на стеке и хипе как-бы неуместно. Боюсь что больше будет заметна разница лямбд на делегатах (в C#) и лямбд на виртуальных функциях (Nemerle и F#). Х>>кстати вот лично у меня для трансформации используется функтор, который создаётся на стеке, но компиляторы С++ сейчас настолько умные что инлайнят всё и вся и оверхедов ноль, поетому в С++ я думаю лямбды в моём случае никак не повлияют на производительность. S>Про инлайнить все и вся — заявление слишком сильное. Все равно там куча условий. Сомневаюсь, что инлайнится метод трансформации координат из геодезии в экранные. Но если скажешь, что точно инлайнится — поверю наслово.
не, не из геодезии, в памяти лежат данные в виде, похожем на твои "псевдо-екранные", точнее что-то вроде промежуточных между екранными и геодезией, которые быстро конвертятся как в екранные так и в геодезию, поетому функтор на самом деле маленький, строк 10-15, из них половина — собственно вычисления.
Здравствуйте, VladD2, Вы писали:
ГВ>>>>Расскажи это лисперам. В лиспе исторически замыкания создавались копированием используемых переменных. ГВ>>Ну, поскольку я знаю твою манеру ведения дискуссии, то обращаю внимание на слово "исторически". А если точно, то я отсылал к common lisp чёрт-те какой давности. В современных диалектах, AFAIK, это уже не так. VD>Демагог, есть демагог. Нет никакого исторического наследния CL.
Дык. Наследия нет, а наблюдения очевидцев — есть (см. Э. Ховёнен, Й. Сеппянен, "Мир Лиспа", М.: 1986 — почему-то к этим славным финнам у меня доверия поболе, чем к даже к Грэхему). Это лишний раз доказывает, что интерпретация "единственно правильного поведения" замыкания сильно зависит от.
VD>CL — это стандарт вышедший таким каким он есть.
Диалект под названием "Common Lisp" существовал задолго до принятия стандарта ANSI.
VD>И вообще, твои слова банальная демонстрация некомпетентности. Лисп изначально имел сборщик мусора и стало быть делать урезанные в нем не имело никакого смысла.
ИМХО, очень даже имело смысл делать такие специфические замыкания. Напоминаю об "иммутабельной природе" функционального программирования.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>Приведи парочку компиляторов С++ промышленного качества, в которых аллокация по кардинально другом алгоритму делается.
При чём тут компиляторы? Управление памятью — это библиотеки.
CC>>Там Per-thread pool с lock-free deferred алгоритмом на случай освобождения памяти из не-родного-потока. G>Значит уже забыл. Пулы интересуют еще меньше, так как они требуют подгонки размеров блоков и пулов. G>Как аллокатор общего назначения использовать смысла нету.
Что за вздор?!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Дык. Наследия нет, а наблюдения очевидцев — есть (см. Э. Ховёнен, Й. Сеппянен, c, М.: 1986 — почему-то к этим славным финнам у меня доверия поболе, чем к даже к Грэхему). Это лишний раз доказывает, что интерпретация "единственно правильного поведения" замыкания сильно зависит от.
Ты в очередной раз сморозил глупость и пытаешься выйти сухим из воды. Не выйдет.
Пойми, когда ты ошибившись начинаешь изворачиваться и молоть черти что пытаясь сделать серьезную мину при плохой игре, ты только больше себя дескридитируешь.
Common Lisp, которому ты кого-то тут отсылал, во-первых, не может иметь черти какой давности, так как появился относительно недавно, а во-вторых он изначально был весьма строгой спецификацией с самого начала содержащей определение замыканий в том виде который есть и сейчас.
VD>>CL — это стандарт вышедший таким каким он есть.
ГВ>Диалект под названием "Common Lisp" существовал задолго до принятия стандарта ANSI.
Ты очередной раз бредишь. CL был создан с единственной целью — стандартизовать Лисп.
ГВ>ИМХО, очень даже имело смысл делать такие специфические замыкания. Напоминаю об "иммутабельной природе" функционального программирования.
Твое ИМХО мало кого волнует. Попробуй подтвердить его ссылками.
И кончай изворачиваться. Все твои попытки сделать вид, что ты не говорил глупость делают эту глупость только более четко видной.
CL язык настолько же функциональный, как и императивный. Но замыкания в нем полноценные, в отличии от недоязыков авторы которых думают исключительно о производительности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ГВ>>Дык. Наследия нет, а наблюдения очевидцев — есть (см. Э. Ховёнен, Й. Сеппянен, c, М.: 1986 — почему-то к этим славным финнам у меня доверия поболе, чем к даже к Грэхему). Это лишний раз доказывает, что интерпретация "единственно правильного поведения" замыкания сильно зависит от.
VD>Ты в очередной раз сморозил глупость и пытаешься выйти сухим из воды. Не выйдет.
Узнаю старого доброго VladD2!
VD>Пойми, когда ты ошибившись начинаешь изворачиваться и молоть черти что пытаясь сделать серьезную мину при плохой игре, ты только больше себя дескридитируешь.
Изволь. Вот цитата из вышеупомянутой книги (т. 1, с. 261-262):
_(setq y 10)
10
_(setq s (function (lambda (x) (+ x y)))
(LEXICAL-CLOSURE ...)
Здесь переменной S присваивается в качестве значения замыкание, в котором переменная y свободна. Значение переменной y сохраняется в замыкании, и поэтому возможны более поздние присваивания на это значение не повлияют. Теперь замыкание можно использовать как функциональный аргумент вместо имени функции или лямбда-выражения. Его можно, например, вызвать с помощью формы FUNCALL:
_(funcall s 2) ; в замыкании y = 10
12
_(setq y 100)
100
_(funcall s 2) ; значения связей в
12 ; замыкании сохраняются
Обращаю твоё внимание, что этот пример не повторяется один-в-один на Allegro CL 8.1 — второй вызов даст 102.
Ещё одна цитата из того же, первого тома, но с.15-16:
Основой изложения нами выбран диалект Коммон Лисп, ставший "де-факто" промышленным стандартом языка Лисп. В книге представлены все важнейшие языковые формы и свойства конструкций Коммон Лиспа, а также типы функций и данных.
Лексика и транслитерации — как в оригинале.
VD>Common Lisp, которому ты кого-то тут отсылал, во-первых, не может иметь черти какой давности, так как появился относительно недавно, а во-вторых он изначально был весьма строгой спецификацией с самого начала содержащей определение замыканий в том виде который есть и сейчас.
Может быть. Языков без спецификаций не бывает. Факт остаётся фактом — стандарт ANSI Common Lisp принят в 1994, тогда как диалект под названием Common Lisp уже существовал на момент выхода в свет финского оригинала "Мира Лиспа" — где-то 85-86 гг. Как видишь, в случае Lisp комитет тоже не особо торопился.
VD>>>CL — это стандарт вышедший таким каким он есть. ГВ>>Диалект под названием "Common Lisp" существовал задолго до принятия стандарта ANSI. VD>Ты очередной раз бредишь. CL был создан с единственной целью — стандартизовать Лисп.
Разве это отменяет факт существования диалекта до того, как был принят стандарт?
ГВ>>ИМХО, очень даже имело смысл делать такие специфические замыкания. Напоминаю об "иммутабельной природе" функционального программирования. VD>Твое ИМХО мало кого волнует. Попробуй подтвердить его ссылками. VD>И кончай изворачиваться. Все твои попытки сделать вид, что ты не говорил глупость делают эту глупость только более четко видной.
VD>CL язык настолько же функциональный, как и императивный. Но замыкания в нем полноценные, в отличии от недоязыков авторы которых думают исключительно о производительности.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
В СССР книга вышла в 1990 г. 1986-й — это финское издание.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не совсем так. Дело в том, что GC для C++ не должен решать задачи управления абсолютно всеми объектами и никто ничего такого и не предлагает. Но для каких-то отдельных моментов он вполне может оказаться приемлемым решением, лучшим, чем reference counting. Ключевое слово: "какие-то отдельные моменты".
Пока в С++ не будет введено понятие "управляемого GC указателя/ссылки" ничего путного в С++ сделать не удастся. Только не строгий GC который крайне не практичен.
Проблема проста до банальности. С++ спроектирован в расчете на то, что адреса в указателях неизменны. А качественный GC предполагает, что как раз таки объекты можно перемещать, а значит их адреса изменятся. В этих условиях GC должен иметь возможность определить в каких ячейках памяти лежат адреса управляемых GC объектов, а в каких просто данные (возможно совпадающие по значению с адресами). GC Явы и дотнета спроектированы в расчете на использование метаданных генерируемых компиляторами и определенные ограничения в языках. Таких ограничений в С++ нет. Посему реализация эффективного GC для него невозможна.
Пример доработки С++ — это C++/CLI и Menaged C++. Там были введены специальные типы указателей которые описываются в метаданных и контролируются рантаймом. По другому никак.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Тут надо подумать, быстро не отвечу. Преимущества, по идее, должны быть в меньшем количестве lock (неизбежен при подсчёте ссылок) и соответственно — в меньшем количестве сбросов кэша процессора. Ну и конечно — в решении проблемы с циклическими ссылками.
На практике GC в С++ оказываются куда менее эффективными чем даже подсчет ссылок. Преимущество только одно. Нет проблем с зацикливанием.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Хвост, Вы писали:
Х>Здравствуйте, gandjustas, Вы писали:
Х>>>Ну как, "мы наш, мы новый мир построим", HeapAlloc + ручное управление памятью, указатели, MyMemMgr.alloc() етц, только пользовать ето будет сложнее, смартпоинтеров то нет G>>Ты прикалываешься или реально тупость говоришь? G>>1)HeapAlloc работает медленнее, чем GC G>>2)Даже если выделишь память с помощью unmanaged, то ты не сможешь создать .NET объект в ней. G>>3)Ты не сможешь хранить ссылки на managed объекты в таком блоке памяти. Х>я разве где-то утверждал обратное? а то что будет нелегко (пункты 2, 3) так етож C#, он такой)
G>>В итого это не будет ни быстрее, ни надежнее. Если ты серьезно считаешь что таким вообще стоит заниматься в каком либо случае, то тебе надо срочно обратиться к доктору. Х>менежмент руками будет быстрее, надёжнее или нет
Сначала докажи это. В общем случае быстрее у тебя точно не выйдет. Можно в локальных случаях сделать пулы, но абсолютно тоже самое достуно и с GC.
Х>ето больше радиус кривизны рук решает.
Радиус кривизны рук определяет склонность к изобретению велосипедов.
Х>я считаю что таким действительно не стоит заниматься, C# для етого не предназначен, он высокоуровненвый и медленный, хочешь высокоуровневый и быстрый — бери С++.
Можешь конкретно показать чем он медленный?
Только ссылки на говнокод не надо.
Я показал что аллокатор в С++ медленно работает, покажи что-нить такое для C#
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>>см. Э. Ховёнен, Й. Сеппянен, c, М.: 1986
ГВ>В СССР книга вышла в 1990 г. 1986-й — это финское издание.
Ты бы еще на китайцев сослася бы. Вытянул какую-то бредятину и на ее основании с умным видом вывел целую теорию.
Лексические замыкания в CL появились из Схемы. И было это в 70-е.
Эти фины описывали черти-что сбоку бантик.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
G>>Приведи парочку компиляторов С++ промышленного качества, в которых аллокация по кардинально другом алгоритму делается. ГВ>При чём тут компиляторы? Управление памятью — это библиотеки.
new и delete — часть языка. Неважно через что они реализуются.
CC>>>Там Per-thread pool с lock-free deferred алгоритмом на случай освобождения памяти из не-родного-потока. G>>Значит уже забыл. Пулы интересуют еще меньше, так как они требуют подгонки размеров блоков и пулов. G>>Как аллокатор общего назначения использовать смысла нету. ГВ>Что за вздор?! Чацкий прямо:
"Вон из Москвы, сюда я больше не ездун... не ездец... не ездюк..., тьфу сюда я я больше ни приеду".
А по сущству есть что сказать? Или ты честно считаешь что в своем проекте будешь вмеесто стандартных new, delete и всего что с ними связано применять тот код, который привел CreatorCray?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>>см. Э. Ховёнен, Й. Сеппянен, c, М.: 1986
ГВ>В СССР книга вышла в 1990 г. 1986-й — это финское издание.
Короче, вот реальная история CL.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Лексические замыкания в CL появились из Схемы. И было это в 70-е.
Источник?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>>>>см. Э. Ховёнен, Й. Сеппянен, c, М.: 1986 ГВ>>В СССР книга вышла в 1990 г. 1986-й — это финское издание.
VD>Короче, вот реальная история CL.
In 1986 X3J13 was formed as a technical working group to produce a draft for an ANSI Common Lisp standard. Because of the acceptance of Common Lisp, the goals of this group differed from those of the original designers. These new goals included stricter standardization for portability, an object-oriented programming system, a condition system, iteration facilities, and a way to handle large character sets. To accommodate those goals, a new language specification, this document, was developed.
То есть в 86-ом была только только сформирована группа по работе над CL. Учитывая, что на книгу нужно было потратить хотя бы пол года, я никак не могут понять что же описывали эти горячие финские парни, если в MIT и CMU только сели за составление стандарта.
А уж фраза:
Основой изложения нами выбран диалект Коммон Лисп, ставший "де-факто" промышленным стандартом языка Лисп. В книге представлены все важнейшие языковые формы и свойства конструкций Коммон Лиспа, а также типы функций и данных.
вообще выглядит как издевка. Может это текст из предисловия на русском языке написанный в 1990-м?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Пока в С++ не будет введено понятие "управляемого GC указателя/ссылки" ничего путного в С++ сделать не удастся. Только не строгий GC который крайне не практичен.
Мне пока видится, что возможный GC для C++ должен быть сопряжён с каким-то особым указателем, вроде gc_ptr<T>. В любом случае использование обычных указателей C++ будет отличаться от использования GC-указателей.
VD>Проблема проста до банальности. С++ спроектирован в расчете на то, что адреса в указателях неизменны. А качественный GC предполагает, что как раз таки объекты можно перемещать, а значит их адреса изменятся. [...]
VD>Пример доработки С++ — это C++/CLI и Menaged C++. Там были введены специальные типы указателей которые описываются в метаданных и контролируются рантаймом. По другому никак.
Согласен, что это подходит в качестве примера подключения GC к C++.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Эти фины описывали черти-что сбоку бантик.
Вот более полная цитата из приведённой тобой ссылки:
In April 1981, after a DARPA-sponsored meeting concerning the splintered Lisp community, Symbolics, the SPICE project, the NIL project, and the S-1 Lisp project joined together to define Common Lisp. Initially spearheaded by White and Gabriel, the driving force behind this grassroots effort was provided by Fahlman, Daniel Weinreb, David Moon, Steele, and Gabriel. Common Lisp was designed as a description of a family of languages. The primary influences on Common Lisp were Lisp Machine Lisp, MacLisp, NIL, S-1 Lisp, Spice Lisp, and Scheme. Common Lisp: The Language is a description of that design. Its semantics were intentionally underspecified in places where it was felt that a tight specification would overly constrain Common Lisp research and use.
In 1986 X3J13 was formed as a technical working group to produce a draft for an ANSI Common Lisp standard. Because of the acceptance of Common Lisp, the goals of this group differed from those of the original designers. These new goals included stricter standardization for portability, an object-oriented programming system, a condition system, iteration facilities, and a way to handle large character sets. To accommodate those goals, a new language specification, this document, was developed.
Как видишь, горячим финским парням было что описывать в 1986-м.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>То есть в 86-ом была только только сформирована группа по работе над CL. Учитывая, что на книгу нужно было потратить хотя бы пол года, я никак не могут понять что же описывали эти горячие финские парни, если в MIT и CMU только сели за составление стандарта.
Судя по всему, было уже какое-то устоявшееся соглашение. См. цитату, которую я привёл в сообщении рядом.
VD>А уж фраза: VD>
VD> Основой изложения нами выбран диалект Коммон Лисп, ставший "де-факто" промышленным стандартом языка Лисп. В книге представлены все важнейшие языковые формы и свойства конструкций Коммон Лиспа, а также типы функций и данных.
VD>вообще выглядит как издевка. Может это текст из предисловия на русском языке написанный в 1990-м?
Нет, это цитата из авторского введения.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
