Связные списки версус динамические массивы - Философия программирования

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

ВВ>А есть ли какое-нибудь преимущество у связных списков перед динамическими массивами, кроме, так сказать, чистоты концепции?

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

Для начала нужно определиться о чем идет речь. Если о списках из ФЯ (т.е. о незименяемых), то один разговор. Если о "классических" реализациях, то другой.

Списки из ФЯ имеют следующие приемущества:
1. O(1) время добавления элементов в начало списка.
2. Неизменяемость, а значит версионность и типобезопасность.
3. Повторное использование хвостов других списков.
5. Они реализуются в виде Алгебраических типов данных, что делает их использование в сопоставлении с образцом очень удобным.

Недостатки тоже очевидны:
1. Медленная вставка, замена и удаление элементов, если эти операции осуществляются не в начале списка.
2. Каждый элемент объекта требует создания отдельного объекта в куче.
3. Несколько ухудшает попадание в кэш процессора, так как занимает больше памяти и иногда приводит к тому что элементы идут не последовательно в памяти.

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

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

Ну, и они не для тех кто использует C# или VB, так как эти языки не имеют встроенной поддержки списков, а без нее кайф от применения списков теряется.

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

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

Ты описал только иммутабельные сценарии, на них массив эффективнее порой на порядок.

ВВ>А есть ли какое-нибудь преимущество у связных списков перед динамическими массивами, кроме, так сказать, чистоты концепции?

Цена изменения содержимого не зависит от кол-ва элементов.
Экономия места для данных, которые по природе близки к "chain of responsibility", там дерево "наоборот" получается.
Для иммутабельного случая эта экономия применима к сценариям любой природы.

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

VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>А есть ли какое-нибудь преимущество у связных списков перед динамическими массивами, кроме, так сказать, чистоты концепции?
ВВ>>Просто, честно говоря, при желании можно легко сымитировать связный список на динамическом массиве + энумератор, при этом мы получим кучу бенефитов, например, нам всегда будет известна длина и сложение списков будет стоить дешевле.
VD>Для начала нужно определиться о чем идет речь. Если о списках из ФЯ (т.е. о незименяемых), то один разговор. Если о "классических" реализациях, то другой.

Вопрос на самом деле о том, насколько успешно можно сымитировать связный список (да, из ФЯ) на основе динамического массива. "O(1) время добавления элементов в начало списка" — это все же техническая особенность связного списка, а вот иммутабельность уже особенность дизайна.
Положим, что в каких-то случаях мы начнем отставать от честного связного списка, но не получится ли так, что в наиболее часто востребованных задачах производительность будет лучше?
К примеру, простейший тест в Немерле — foreach для аррая и списка — показывает, что для в задаче последовательного перебора динамический массив быстрее более чем в 2 раза. Нехорошо как-то.

И длина, длина

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

ВВ>А есть ли какое-нибудь преимущество у связных списков перед динамическими массивами, кроме, так сказать, чистоты концепции?

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

Например, дерево шахматных ходов. Например, если все позиции, которые возникают в результате всех возможных ответов в данной, хранить в виде списка, то размер структуры под одну позицию постоянный, и для нее можно реализовать свой распределитель памяти, где выделение/уничтожение позиции будет O(1). И это все операции, что нам надо.

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

FR>Не надо ничего имитировать все уже украдено до нас http://en.wikipedia.org/wiki/VList

В статье есть фраза

While immutability is a benefit, it is also a drawback, making it inefficient to modify elements in the middle of the array.

Я как-то не так понимаю термин immutability? Речь действительно о том чтобы менять элементы в середине массива?

Но меня смущает еще кое-что:
Единственный вариант, при котором можно говорить о иммутабельности данной структуры — это клонировать весь массив по указателю Base при каждом добавлении элемента чтобы гарантировать неизменность существующих списков, содержащих массив по указателю Base.
Это делает вставку настолько неэффективной, что про иммутабельность можно было просто не упоминать вообще (вне зависимости от середины или краев массива).

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

ВВ>Вопрос на самом деле о том, насколько успешно можно сымитировать связный список (да, из ФЯ) на основе динамического массива.

Сама постановка задачи глупая. Краткий ответ — ни насколько.

ВВ> "O(1) время добавления элементов в начало списка" — это все же техническая особенность связного списка, а вот иммутабельность уже особенность дизайна.

И то и другое особенность дизайна. Точнее особенность самой структуры данных.

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

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

Короче, нужно понимать что делаешь.

ВВ>К примеру, простейший тест в Немерле — foreach для аррая и списка — показывает, что для в задаче последовательного перебора динамический массив быстрее более чем в 2 раза. Нехорошо как-то.

Это бред. Полнейший и махровый. Так вообще нельзя подходить к программированию. Нужно брать задачу и смотреть как ее лучше всего решать. Разница во времени затрачиваемом на перебор списка и массива ничтожна по сравнению со временем которое будет потрачено на вычисления, преобразования данных и т.п. Потом чистое время вообще не имеет смысла. Отдельно взятая задача в 99.999% случаев на современных компьютерах выполняется очень быстро! Смотреть надо на то насколько общая производительность приемлема для конкретной задачи. Может оказаться так, что задача отлично решается даже самым экстенсивными средствами.

Так что выжимать такты процессора из каждого перебора глупо. К тому же списки намного реже перебирают с помощью циклов.
Собственно тогда уж нужно задуматься над тем, что использование ФВП тоже дает оверхэд. Да и дотнет тоже не бесплатен. GC основанный на поколениях вносит оверхэд в любое присвоение указателя на ссылочный объект. Так давай откажемся и от дотнета и будем все писать на С! А там окажется, что и С вносит некоторый оверхэд. Так что здравствуй ассемблер?

ВВ>И длина, длина

Что длинна?

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

S>Я как-то не так понимаю термин immutability? Речь действительно о том чтобы менять элементы в середине массива?

Да невнятно как-то. Может имеется в виду немутабельность VList недостаток при вставке в середину?

S>Но меня смущает еще кое-что:
S>Единственный вариант, при котором можно говорить о иммутабельности данной структуры — это клонировать весь массив по указателю Base при каждом добавлении элемента чтобы гарантировать неизменность существующих списков, содержащих массив по указателю Base.
S>Это делает вставку настолько неэффективной, что про иммутабельность можно было просто не упоминать вообще (вне зависимости от середины или краев массива).

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

Вообще тут http://infoscience.epfl.ch/record/64410/files/techlists.pdf более подробно о VList и некоторых производных от него структур данных.

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

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

S>>Я как-то не так понимаю термин immutability? Речь действительно о том чтобы менять элементы в середине массива?

FR>Да невнятно как-то. Может имеется в виду немутабельность VList недостаток при вставке в середину?
Я не понял о чем речь.

FR>VList это замена обычному односвязному списку который используется в функциональщине, и соответственно оптимизирован под это, то есть предполагается быстрая добавление к голове и легкое переиспользование хвоста. При таком использовании клонирование не нужно.

Переиспользование хвоста без клонирования мне как-то не видится.

Пусть мы имеем список А (2,3,4,5,6), как на картинке в статье. Вставим в него 1-у:
let A1 = A.Add(1)
здесь мы получили реюз ховста. У нас есть:
A (2,3,4,5,6)
A1 (1,2,3,4,5,6)

Теперь делаем
let A2 = A.Add(-1)
и получаем
A (2,3,4,5,6)
A1 (-1,2,3,4,5,6)
A2 (-1,2,3,4,5,6)

т.е. мы добавлением к A нового элемента нарушили список A1.

FR>Вообще тут http://infoscience.epfl.ch/record/64410/files/techlists.pdf более подробно о VList и некоторых производных от него структур данных.
Там ни слова об иммутабельности, хотя я читал невнимательно.

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

FR>>Да невнятно как-то. Может имеется в виду немутабельность VList недостаток при вставке в середину?
S>Я не понял о чем речь.

Я тоже

S>Переиспользование хвоста без клонирования мне как-то не видится.

S>Пусть мы имеем список А (2,3,4,5,6), как на картинке в статье. Вставим в него 1-у:
S>let A1 = A.Add(1)
S>здесь мы получили реюз ховста. У нас есть:
S>A (2,3,4,5,6)
S>A1 (1,2,3,4,5,6)

S>Теперь делаем
S>let A2 = A.Add(-1)
S>и получаем
S>A (2,3,4,5,6)
S>A1 (-1,2,3,4,5,6)
S>A2 (-1,2,3,4,5,6)

S>т.е. мы добавлением к A нового элемента нарушили список A1.

Ты не учитываешь то что "указатель" на VList это база + смещение, поэтому при создании нового списка ничто ни мешает нам создать
голову (блок размером N * 2 от макимального блока родителя) которая укажет точно на нужный нам элемент начала хвоста, это конечно немного
исказит структуру, но ничего страшного. То есть любые добавления в старый список на наш новый (и наоборот) не повлияют, головы у них
получаются разные.

FR>>Вообще тут http://infoscience.epfl.ch/record/64410/files/techlists.pdf более подробно о VList и некоторых производных от него структур данных.
S>Там ни слова об иммутабельности, хотя я читал невнимательно.

Ну там же все пляшет от лисповских списеов которые немутабельны по умолчанию.

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

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

S>>т.е. мы добавлением к A нового элемента нарушили список A1.

FR>Ты не учитываешь то что "указатель" на VList это база + смещение, поэтому при создании нового списка ничто ни мешает нам создать голову (блок размером N * 2 от макимального блока родителя) которая укажет точно на нужный нам элемент начала хвоста, это конечно немного исказит структуру, но ничего страшного. То есть любые добавления в старый список на наш новый (и наоборот) не повлияют, головы у них получаются разные.

Я правильно понимаю, что под головой ты понимаешь то, на что указывает Base, т.е. первый из списка массивов (вместе с дополнительной информацией)?

Если да, то об этом я и говорил, что добавление элемента в иммутабельном случае должно клонировать голову.
Но если речь о клонировании, то зачем нам создавать блок под 2*N элементов, если можно создать только под фактически необходимое кол-во элементов, ведь добавление очередного создаст новую голову.

FR>>>Вообще тут http://infoscience.epfl.ch/record/64410/files/techlists.pdf более подробно о VList и некоторых производных от него структур данных.
S>>Там ни слова об иммутабельности, хотя я читал невнимательно.

FR>Ну там же все пляшет от лисповских списеов которые немутабельны по умолчанию.

Знаком с ними. Их иммутабельность не вызывает никаких сомнений. Более того, добавление (с созданием нового списка) в лисповых списках должно быть намного быстрее VList-а именно в иммутабельной функциональщине. Т.е. cons против клонирования головы...

Либо я все еще чего-то не понимаю с этим VList-ом

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

FR>>Ты не учитываешь то что "указатель" на VList это база + смещение, поэтому при создании нового списка ничто ни мешает нам создать голову (блок размером N * 2 от макимального блока родителя) которая укажет точно на нужный нам элемент начала хвоста, это конечно немного исказит структуру, но ничего страшного. То есть любые добавления в старый список на наш новый (и наоборот) не повлияют, головы у них получаются разные.

S>Я правильно понимаю, что под головой ты понимаешь то, на что указывает Base, т.е. первый из списка массивов (вместе с дополнительной информацией)?

Да.

S>Если да, то об этом я и говорил, что добавление элемента в иммутабельном случае должно клонировать голову.

Нет, достаточно создать пустую голову нужного размера.

В пдфке каждый массив имеет такую структур:

const TailBase
const TailOffset
const Size=N
mutable LastUsed
....

При конструировании нового VList если LastUsed не совпадает с нашим Offset мы создаем новый массив с Size = 1 и добавляем туда новый элемент, смотри картинку 2 в пдфке.

S>Но если речь о клонировании, то зачем нам создавать блок под 2*N элементов, если можно создать только под фактически необходимое кол-во элементов, ведь добавление очередного создаст новую голову.

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

S>Знаком с ними. Их иммутабельность не вызывает никаких сомнений. Более того, добавление (с созданием нового списка) в лисповых списках должно быть намного быстрее VList-а именно в иммутабельной функциональщине. Т.е. cons против клонирования головы...

S>Либо я все еще чего-то не понимаю с этим VList-ом

Угу не понимаешь чуть-чуть

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

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

FR>При конструировании нового VList если LastUsed не совпадает с нашим Offset мы создаем новый массив с Size = 1 и добавляем туда новый элемент, смотри картинку 2 в пдфке.

Спасибо, разобрался. Т.е речь не об полной иммутабельности, а об инкапсулированном изменяемом состоянии с locking-ом.

S>>Но если речь о клонировании, то зачем нам создавать блок под 2*N элементов, если можно создать только под фактически необходимое кол-во элементов, ведь добавление очередного создаст новую голову.

FR>Клонировать вообще не нужно.
FR>Создавать голову в самом деле можно и меньшего размера, но это нарушит структуру. Судя по реализации в пдфке, такое нарушение выгоднее чем создание большой головы.
Тут сложно угадать, что выгоднее, т.к. мы не знаем, к какой голове продолжится добавление элементов и продолжится ли вообще.

S>>Знаком с ними. Их иммутабельность не вызывает никаких сомнений. Более того, добавление (с созданием нового списка) в лисповых списках должно быть намного быстрее VList-а именно в иммутабельной функциональщине. Т.е. cons против клонирования головы...

S>>Либо я все еще чего-то не понимаю с этим VList-ом

FR>Угу не понимаешь чуть-чуть

исправляюсь

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

VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Вопрос на самом деле о том, насколько успешно можно сымитировать связный список (да, из ФЯ) на основе динамического массива.
VD>Сама постановка задачи глупая. Краткий ответ — ни насколько.

Если тебе постановка задачи не нравится, мог бы не отвечать. Делать тебе что ли больше нечего?

ВВ>> "O(1) время добавления элементов в начало списка" — это все же техническая особенность связного списка, а вот иммутабельность уже особенность дизайна.
VD>И то и другое особенность дизайна. Точнее особенность самой структуры данных.

Ага, масло масляное.

ВВ>>К примеру, простейший тест в Немерле — foreach для аррая и списка — показывает, что для в задаче последовательного перебора динамический массив быстрее более чем в 2 раза. Нехорошо как-то.
VD>Это бред. Полнейший и махровый. Так вообще нельзя подходить к программированию. Нужно брать задачу и смотреть как ее лучше всего решать.

Бред? Правда?
Я вот прочитал в твоей статье — связные списки хорошо подходят *по производительности*, когда нужен последовательный перебор данных. А у меня задача такая — важна скорость последовательного перебора. И простейший тест показывает, что это мягко говоря не так.

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

VD>Разница во времени затрачиваемом на перебор списка и массива ничтожна по сравнению со временем которое будет потрачено на вычисления, преобразования данных и т.п. Потом чистое время вообще не имеет смысла. Отдельно взятая задача в 99.999% случаев на современных компьютерах выполняется очень быстро! Смотреть надо на то насколько общая производительность приемлема для конкретной задачи. Может оказаться так, что задача отлично решается даже самым экстенсивными средствами.
VD>Так что выжимать такты процессора из каждого перебора глупо. К тому же списки намного реже перебирают с помощью циклов.
VD>Собственно тогда уж нужно задуматься над тем, что использование ФВП тоже дает оверхэд. Да и дотнет тоже не бесплатен. GC основанный на поколениях вносит оверхэд в любое присвоение указателя на ссылочный объект. Так давай откажемся и от дотнета и будем все писать на С! А там окажется, что и С вносит некоторый оверхэд. Так что здравствуй ассемблер?

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

Вообще, я конечно понимаю, у тебя есть две любимые темы — "это лучше сделать на Немерле" и "преждевременное оптимизация — зло". Это хорошо, что темы есть любимые. У меня тоже есть любимые темы. Правда, они в основном весьма далеки от программирования. Но сколько же можно их повторять-то? Я тебя читаю с 2002 года, и все время, все время одно и то же. С той лишь разницей, что раньше вместо Немерле был C#. Это ж просто офигеть можно.

Форум называется "Философия". Тут "философские" беседы ведутся, понимаешь. Без конкретных как бы задач.

ВВ>>И длина, длина

VD>Что длинна?

Длина списка.

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

ВВ>Если тебе постановка задачи не нравится, мог бы не отвечать. Делать тебе что ли больше нечего?

Ты как нибудь определился бы с тем нужен тебе ответ или нет.
А на неверно поставленный вопрос можно дать только один ответ. Я тебе его и дал.

ВВ>Бред? Правда?

Да, правда.

ВВ>Я вот прочитал в твоей статье — связные списки хорошо подходят *по производительности*, когда нужен последовательный перебор данных. А у меня задача такая — важна скорость последовательного перебора. И простейший тест показывает, что это мягко говоря не так.

Ты всегда читаешь только часть написанных букв вместо того чтобы понять смысл всего сказанного?

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

Ага. Несерьезно.
Кстати, я где-то сравнивал скорость перебора элементов списка и массива? Нет? Так о чем тогда речь?

VD>>Разница во времени затрачиваемом на перебор списка и массива ничтожна по сравнению со временем которое будет потрачено на вычисления, преобразования данных и т.п. Потом чистое время вообще не имеет смысла. Отдельно взятая задача в 99.999% случаев на современных компьютерах выполняется очень быстро! Смотреть надо на то насколько общая производительность приемлема для конкретной задачи. Может оказаться так, что задача отлично решается даже самым экстенсивными средствами.
VD>>Так что выжимать такты процессора из каждого перебора глупо. К тому же списки намного реже перебирают с помощью циклов.
VD>>Собственно тогда уж нужно задуматься над тем, что использование ФВП тоже дает оверхэд. Да и дотнет тоже не бесплатен. GC основанный на поколениях вносит оверхэд в любое присвоение указателя на ссылочный объект. Так давай откажемся и от дотнета и будем все писать на С! А там окажется, что и С вносит некоторый оверхэд. Так что здравствуй ассемблер?

ВВ>К чему все это написано?

Да, действительно не к чему. Тот кто не хочет понять, не поймет ничего сколько ему не объясняй.

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

Очень нужна для тех кто умеет ее использовать и пользуется языками представляющими для нее удобные инструменты, и совсем не нужна для тех кто пользоваться ею не умеет и не хочет учиться, а так же пользуется языками не предоставляющими адекватных инструментов ее использования.

ВВ>Вообще, я конечно понимаю, у тебя есть две любимые темы — "это лучше сделать на Немерле" и "преждевременное оптимизация — зло". Это хорошо, что темы есть любимые. У меня тоже есть любимые темы. Правда, они в основном весьма далеки от программирования. Но сколько же можно их повторять-то? Я тебя читаю с 2002 года, и все время, все время одно и то же. С той лишь разницей, что раньше вместо Немерле был C#. Это ж просто офигеть можно.

Не читай. Я не навязываюсь.

А темы отличные от программирования стоит обсуждать в соответствующих форумах.

ВВ>Форум называется "Философия". Тут "философские" беседы ведутся, понимаешь. Без конкретных как бы задач.

Форум называется "Философия программирования".

Вопрос твой к философии вообще не относится. Если честно, я бы вообще постыдился задавать такой вопрос. Это же равносильно признанию того, что не разбираешься в структурах данных.

ВВ>>>И длина, длина

VD>>Что длинна?

ВВ>Длина списка.

И что с ней?

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

ВВ>>Если тебе постановка задачи не нравится, мог бы не отвечать. Делать тебе что ли больше нечего?
VD>Ты как нибудь определился бы с тем нужен тебе ответ или нет.
VD>А на неверно поставленный вопрос можно дать только один ответ. Я тебе его и дал.

Вопрос с твоей позиции поставлен "идеологически неверно". Хорошо, смирись с этим. Я интересующие меня ответы получил. И не от тебя.

VD>Ага. Несерьезно.
VD>Кстати, я где-то сравнивал скорость перебора элементов списка и массива? Нет? Так о чем тогда речь?

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

По-моему из этого предложения вполне явно следует такой вывод.

ВВ>>К чему все это написано?
VD>Да, действительно не к чему. Тот кто не хочет понять, не поймет ничего сколько ему не объясняй.

Ага, есть альтернативный вариант — эта тема здесь абсолютно не в тему.

VD>Вопрос твой к философии вообще не относится. Если честно, я бы вообще постыдился задавать такой вопрос. Это же равносильно признанию того, что не разбираешься в структурах данных.

Ну видимо создатели VList тоже не разбирались в структурах данных. Это только у тебя все либо черное, либо белое. Либо "правильные" языки, либо "неправильные".
Влад, оле, мне нужна *гибридная* *коллекция*. Массив не устраивает, список не устраивает. А вот VList по ходу вполне.

ВВ>>>>И длина, длина

VD>>>Что длинна?
ВВ>>Длина списка.
VD>И что с ней?

Дык нету ее

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

FR>Не надо ничего имитировать все уже украдено до нас http://en.wikipedia.org/wiki/VList

Прикольно, а почему бы не сделать сцепку этих chunk-ов не на основе односвязанного списка, а на основе сбалансированного дерева? (Баланс должен быть по чанкам, а не элементам). Тогда доступ к хвосту и голове будет примерно равен по эффективности.

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

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

ВВ>Вопрос с твоей позиции поставлен "идеологически неверно". Хорошо, смирись с этим. Я интересующие меня ответы получил. И не от тебя.

Заметано!

VD>>Кстати, я где-то сравнивал скорость перебора элементов списка и массива? Нет? Так о чем тогда речь?

ВВ>

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

ВВ>По-моему из этого предложения вполне явно следует такой вывод.

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

Кстати, ты знаком с О-нотацией?
Не подскажешь какова алгоритмическая сложность перебора списка и массива (в О-нотации)?

ВВ>Ага, есть альтернативный вариант — эта тема здесь абсолютно не в тему.

Как скажешь! Как скажешь...

VD>>Вопрос твой к философии вообще не относится. Если честно, я бы вообще постыдился задавать такой вопрос. Это же равносильно признанию того, что не разбираешься в структурах данных.

ВВ>Ну видимо создатели VList тоже не разбирались в структурах данных.

А он задает такие вопросы как ты? Можно пруфлинк?

ВВ>Это только у тебя все либо черное, либо белое.

Ага. В моем понимании некоторые понятия дуальные. Скажем понимание предмета. Оно или есть, или нет.

ВВ>Либо "правильные" языки, либо "неправильные".

Однако, причем тут Nemerle? (с)

ВВ>Влад, оле, мне нужна *гибридная* *коллекция*. Массив не устраивает, список не устраивает. А вот VList по ходу вполне.

Але, гараж? Не бывает идеальных коллекций. У всего есть свои преимущества и недостатки. VList здесь не исключение.
Ты, кстати, сколько минут о нем знаешь? Видел ли его реализации?

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

Кстати, ты успел прочесть о том, что для ссылки на элемент этого VLiat нужно использовать структуру данных состоящую из двух элементов (ссылки на часть и индекс в ней)?

ВВ>>>>>И длина, длина

VD>>>>Что длинна?
ВВ>>>Длина списка.
VD>>И что с ней?

ВВ>Дык нету ее

Ее украли?

Или ты сокрушаешься о том, что ее приходится вычислять? Ну, дык особенность структуры данных. В VList ее тоже придется вычислять. Но есть радостная весть. Ее можно не использовать или хранить отдельно.

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

ВВ>>

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

ВВ>>По-моему из этого предложения вполне явно следует такой вывод.
VD>У тебя очень богатая фантазия. Из этой цитаты следует только то, что перебор списков (кстати, не любой) довольно эффективен.

Как скажешь, хотя, честно говоря, когда читаешь фразу "Х эффективен, а У медленнее массива", то ее как бы обычно понимаешь, что Х по крайней мере не медленнее.
Впрочем, даже понятно, почему оно медленнее. Код из релиза:

   L_0065: nop 
    L_0066: ldloc.1 
    L_0067: isinst [Nemerle]Nemerle.Core.list`1/Cons<int32>
    L_006c: brfalse L_0094
    L_0071: ldloc.1 
    L_0072: castclass [Nemerle]Nemerle.Core.list`1/Cons<int32>
    L_0077: ldfld !0 [Nemerle]Nemerle.Core.list`1/Cons<int32>::hd
    L_007c: stloc.3 
    L_007d: ldloc.1 
    L_007e: castclass [Nemerle]Nemerle.Core.list`1/Cons<int32>
    L_0083: ldfld class [Nemerle]Nemerle.Core.list`1<!0> [Nemerle]Nemerle.Core.list`1/Cons<int32>::tl
    L_0088: stloc.1 
    L_0089: nop 
    L_008a: nop 
    L_008b: nop 
    L_008c: nop 
    L_008d: ldloc.1 
    L_008e: stloc.1 
    L_008f: br L_0065

Кстати, многовато nop-ов для релиза.

VD>Кстати, ты знаком с О-нотацией?
VD>Не подскажешь какова алгоритмическая сложность перебора списка и массива (в О-нотации)?

Более бредовый вопрос не мог спросить?
Сложность какого перебора? Сложность доступа по индексу и сложность обращения к полю?

VD>>>Вопрос твой к философии вообще не относится. Если честно, я бы вообще постыдился задавать такой вопрос. Это же равносильно признанию того, что не разбираешься в структурах данных.

ВВ>>Ну видимо создатели VList тоже не разбирались в структурах данных.
VD>А он задает такие вопросы как ты? Можно пруфлинк?

Хорошо, я задал неправильный вопрос. Раскаиваюсь. Предлагаю закрыть эту тему, а то я пойду в форум Немерле и задам там кучу еще более неправильных вопросов. У меня даже кое-какие задумки уже есть.

ВВ>>Это только у тебя все либо черное, либо белое.
VD>Ага. В моем понимании некоторые понятия дуальные. Скажем понимание предмета. Оно или есть, или нет.
ВВ>>Либо "правильные" языки, либо "неправильные".
VD>Однако, причем тут Nemerle? (с)

Какой Немерле?

ВВ>>Влад, оле, мне нужна *гибридная* *коллекция*. Массив не устраивает, список не устраивает. А вот VList по ходу вполне.
VD>Але, гараж? Не бывает идеальных коллекций. У всего есть свои преимущества и недостатки. VList здесь не исключение.

Я разве просил идеальную коллекцию?

VD>Ты, кстати, сколько минут о нем знаешь? Видел ли его реализации?

Немного. Не видел. Ты можешь предложить что-то лучше?
Мне нужны:

1. Перебор по модели голова-хвост
2. Добавление в начало и конец
3. Потокобезопасность
4. Знать длину

VD>Я тебя огорчу, но перебор элементов в нем будет ни чем не быстрее нежели в односвязанных списках.
VD>Кстати, ты успел прочесть о том, что для ссылки на элемент этого VLiat нужно использовать структуру данных состоящую из двух элементов (ссылки на часть и индекс в ней)?

Нет, я вообще эту статью не читал.

ВВ>>>>>>И длина, длина

VD>>>>>Что длинна?
ВВ>>>>Длина списка.
VD>>>И что с ней?
ВВ>>Дык нету ее

VD>Ее украли?

Именно.

VD>Или ты сокрушаешься о том, что ее приходится вычислять? Ну, дык особенность структуры данных. В VList ее тоже придется вычислять. Но есть радостная весть. Ее можно не использовать или хранить отдельно.

Ага, и пересчитывать каждый раз.

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

ВВ>Кстати, многовато nop-ов для релиза.

Если не включена поддержка pdb (что может быть и в релизе), nop-ов быть не должно.
В прочем, они выкидываются джитом когда тот работает в оптимизирующем режиме.

VD>>Кстати, ты знаком с О-нотацией?
VD>>Не подскажешь какова алгоритмическая сложность перебора списка и массива (в О-нотации)?

ВВ>Более бредовый вопрос не мог спросить?
ВВ>Сложность какого перебора? Сложность доступа по индексу и сложность обращения к полю?

Последовательного... с начала к концу. Ты же его тестировал.

ВВ>Хорошо, я задал неправильный вопрос. Раскаиваюсь. Предлагаю закрыть эту тему,

ОК

ВВ>а то я пойду в форум Немерле и задам там кучу еще более неправильных вопросов. У меня даже кое-какие задумки уже есть.

Если по делу, а не ради флэйма, то добро пожаловать. Если найдешь что, только спасибо скажем.

ВВ>>>Это только у тебя все либо черное, либо белое.
VD>>Ага. В моем понимании некоторые понятия дуальные. Скажем понимание предмета. Оно или есть, или нет.
ВВ>>>Либо "правильные" языки, либо "неправильные".
VD>>Однако, причем тут Nemerle? (с)

ВВ>Какой Немерле?

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

ВВ>>>Влад, оле, мне нужна *гибридная* *коллекция*. Массив не устраивает, список не устраивает. А вот VList по ходу вполне.
VD>>Але, гараж? Не бывает идеальных коллекций. У всего есть свои преимущества и недостатки. VList здесь не исключение.

ВВ>Я разве просил идеальную коллекцию?

А что ты искал то? Ты начал с какого-то странного заявления о недостатках списков при переборе, а теперь перешел к VList, который тоже список. Ты уж определись о чем ты говоришь и что хочешь.

VD>>Ты, кстати, сколько минут о нем знаешь? Видел ли его реализации?

ВВ>Немного. Не видел. Ты можешь предложить что-то лучше?

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

ВВ>Мне нужны:

ВВ>1. Перебор по модели голова-хвост
ВВ>2. Добавление в начало и конец
ВВ>3. Потокобезопасность
ВВ>4. Знать длину

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

В общем, снова не верная постановка вопроса. Не "мне нужно", а "для задач X выгоднее применять Y нежели Z". И только так!

VD>>Я тебя огорчу, но перебор элементов в нем будет ни чем не быстрее нежели в односвязанных списках.
VD>>Кстати, ты успел прочесть о том, что для ссылки на элемент этого VLiat нужно использовать структуру данных состоящую из двух элементов (ссылки на часть и индекс в ней)?

ВВ>Нет, я вообще эту статью не читал.

Прочти. Там еще обсуждение есть. Очень любопытно.

Пойми. Я не против VList или массивов. И я не рекламирую списки. Я просто уверяю тебя в том, что они все хороши в некоторых ситуациях и плохи в других. Если подходят и массивы и списки, то выбор определяется с одной стороны производительностью которая у массивов зачастую лучше, или удобством, которое зачастую могут быть лучше у списков (если язык умеет с ними работать).

VD>>Или ты сокрушаешься о том, что ее приходится вычислять? Ну, дык особенность структуры данных. В VList ее тоже придется вычислять. Но есть радостная весть. Ее можно не использовать или хранить отдельно.

ВВ>Ага, и пересчитывать каждый раз.

Большая часть алгоритмов работающих со списками не нуждается в знании о длине. Посему и сокрушаться не о чем. Кроме того если длинна нужно не внутри самого вложенного цикла самого критичного алгоритма, то ее вычисление скорее всего не окажет никакого влияния на общую производительность, так как при этом не выделяется ни одного объекта, а сам алгоритм весьма шустр и имеет сложность O(n). Скажем если стоит задача скопировать значение списка в List[T], то намного эффективнее вычислить длину списка и один раз задать длинную List[T] нежели добавлять значения по одному элементу рассчитывая на автоматическое приращение List[T]-а. Происходит это потому, что даже одно выделение памяти и копирование элементов операция более медленная нежели вычисление длинны списка.

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

V>Прикольно, а почему бы не сделать сцепку этих chunk-ов не на основе односвязанного списка, а на основе сбалансированного дерева? (Баланс должен быть по чанкам, а не элементам). Тогда доступ к хвосту и голове будет примерно равен по эффективности.

Потому что VList создавался как замена односвязному списку используемому в большинстве ФЯ и поэтому задача эффективного доступа к концу списка не ставилась.

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

Был изобретен список который обеспечивает в среднем индексирование за O(1) и вычисление длины за O(ln n). Ты же говоришь совсем про другое http://en.wikipedia.org/wiki/Unrolled_linked_list или http://blogs.msdn.com/devdev/archive/2005/08/22/454887.aspx у него характеристики доступа сильно отличаются от VList.

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

VD>Ну, ты приплыл. VList крайне не эффективен при добавлении в конец. Он при этом еще хуже массивов, так как для массива хотя бы один раз память придется перевыделиь.

Тут http://infoscience.epfl.ch/record/64410/files/techlists.pdf описан и VDList, двухстороняя очередь на базе VList.

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

ВВ>А есть ли какое-нибудь преимущество у связных списков перед динамическими массивами, кроме, так сказать, чистоты концепции?

Есть. Дело в том, что связные списки существуют, а динамические массивы — нет.

Я не шучу. Сделать настоящий динамический массив, то есть массив, который без каких-либо переаллокаций увеличивал бы свой размер, в общем случае невозможно. Причина банальна — дальше в адресном пространстве может не быть свободного места. И тогда произойдет новое выделение памяти большего размера с копированием данных , после чего старый массив удаляется. А на это нужно время, во-первых, и память, во-вторых. Например, имея динамический массив на 1 Г, увеличить его размер до 1 Г + 64 К, в 32-битной среде не удастся вообще.

Правда, есть VirtualAlloc с резервированием и коммитированием по частям. В этом случае можно зарезервировать большой кусок адресного пространства, но не выделять память на весь этот размер. Адресное пространство не жалко (до поры до времени). Потом можно коммитировать от начала и далее маленькими кусочками. Так что массив сможет действительно расти без переаллокаций. Это уже ближе к истине, но все же в пределах зарезервированного размера.

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

PD>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>А есть ли какое-нибудь преимущество у связных списков перед динамическими массивами, кроме, так сказать, чистоты концепции?

PD>Есть. Дело в том, что связные списки существуют, а динамические массивы — нет.

PD>Я не шучу.

http://en.wikipedia.org/wiki/Dynamic_array
В двух словах — динамический массив это не тот массив, который меняет свои размеры динамически, а структура данных (std::vector — это реализация динамического массива и она существует).

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

S>В двух словах — динамический массив это не тот массив, который меняет свои размеры динамически, а структура данных (std::vector — это реализация динамического массива и она существует).

Ну не надо же все понимать буквально...
Конечно, std::vector существует, и он есть динамический массив. И про него верно все, что я сказал — увеличение его размера после того, как исчерпан текущий размер, приведет к переаллокации и копированию.

vector::capacity
Returns the number of elements that the vector could contain without allocating more storage.

vector::resize
Specifies a new size for a vector.




    void resize(size_type _Newsize, _Ty _Val)
        {    // determine new length, padding with _Val elements as needed
        if (size() < _Newsize)
            _Insert_n(end(), _Newsize - size(), _Val);
        else if (_Newsize < size())
            erase(begin() + _Newsize, end());
        }


    void _Insert_n(const_iterator _Where,
        size_type _Count, const _Ty& _Val)
        {    // insert _Count * _Val at _Where

//...
        else if (_Capacity < size() + _Count)
            {    // not enough room, reallocate
            _Capacity = max_size() - _Capacity / 2 < _Capacity
                ? 0 : _Capacity + _Capacity / 2;    // try to grow by 50%
            if (_Capacity < size() + _Count)
                _Capacity = size() + _Count;
            pointer _Newvec = this->_Alval.allocate(_Capacity);

#include "vector"

using namespace std;

int _tmain(int argc, _TCHAR* argv[])
{
    vector<char> v(1000000000);
    v.resize(1000000001);
    return 0;
}

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

Павел!
Ты сказал что настоящих динамических массивов не существует, я привел ссылку где написано что именно принято считать динамическим массивом.
PD>

PD>    vector<char> v(1000000000);
PD>    v.resize(1000000001);
PD>

Этот пример не опровергает существование std::vector-а. Он только лишь подтверждает твои слова об специфике перевыделений при нехвататке адресного пространства. Но с этим-то никто не спорил.

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:

S>Павел!
S>Ты сказал что настоящих динамических массивов не существует, я привел ссылку где написано что именно принято считать динамическим массивом.

Мне не хотелось бы заниматься игрой в дефиниции. Массивов (называй их хоть динамическими, хоть как-то иначе), которые могли бы изменять свой размер без переаллокаций, не существует. А термин "динамический массив" вполне существует, но только там всегда будет переаллокация. Со всеми вытекающими.

PD>>

PD>>    vector<char> v(1000000000);
PD>>    v.resize(1000000001);
PD>>

S>Этот пример не опровергает существование std::vector-а.

Еще бы! Вот здорово бы было, если бы я смог опровергнуть его существование, употребляя его

>Он только лишь подтверждает твои слова об специфике перевыделений при нехвататке адресного пространства. Но с этим-то никто не спорил.

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

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

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

PD>Мне не хотелось бы заниматься игрой в дефиниции. Массивов (называй их хоть динамическими, хоть как-то иначе), которые могли бы изменять свой размер без переаллокаций, не существует. А термин "динамический массив" вполне существует, но только там всегда будет переаллокация. Со всеми вытекающими.

PD>А я именно на этом и акцентировал внимание в своем постинге. Ответ-то был на сообщение Василия Воронкова, ну вот я и отметил, что без массовых операций при добавлении нового элемента динамический массив существовать не может. А список может — этого я не писал, но подразумевалось само собой.

Не сомнваюсь, что Василий об этом знает. А для меня было новостью, что динамических массивов не существует.

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

S>Не сомнваюсь, что Василий об этом знает.

VV>Просто, честно говоря, при желании можно легко сымитировать связный список на динамическом массиве

Вот я и решил акцентировать его внимание на том, что в этом моделировании есть подводный камень. Коль скоро он об этом камне сам не упоминает.

S>А для меня было новостью, что динамических массивов не существует.

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

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

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

S>>А для меня было новостью, что динамических массивов не существует.

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

Буду ждать

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

FR>Тут http://infoscience.epfl.ch/record/64410/files/techlists.pdf описан и VDList, двухстороняя очередь на базе VList.

А этот вариант уже не будет неизменяемым и будет иметь другие проблемы.

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

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

PD>Правда, есть VirtualAlloc с резервированием и коммитированием по частям. В этом случае можно зарезервировать большой кусок адресного пространства, но не выделять память на весь этот размер. Адресное пространство не жалко (до поры до времени). Потом можно коммитировать от начала и далее маленькими кусочками. Так что массив сможет действительно расти без переаллокаций. Это уже ближе к истине, но все же в пределах зарезервированного размера.

Термин "динамический массив" придумал не я. Предлагаешь вместо него использовать термин "массив, который при добавлении в конец иногда приходится пересоздавать заново и копировать в него существующие элементы, как правило выбирая длину нового массива так, чтобы резервировать место и избежать лишних аллокаций"? Нет, спасибо.

В реальной ситуации стоимость переаллокаций как правило ничтожна (например, в дотнетовских коллекциях размер обычно просто увеличивается в два раза — при таком подходе зарезервированного места всегдя будет много) и ее можно попросту проигнорировать. Да, адресное пространство надо экономить

Тем не менее по потреблению памяти массив все равно куда экономнее связного списка.

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

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

Не надо спасибо. Я этого не предлагаю. Меня вполне устраивает название "динамический массив". Вообще мне игры в дефиниции не по душе. Еще раз — массивов с изменением размера без переаллокаций быть не может. А с переаллокациями они есть. Называй их хоть динамическими, хоть как-нибудь еще — мне все равно.

ВВ>В реальной ситуации стоимость переаллокаций как правило ничтожна (например, в дотнетовских коллекциях размер обычно просто увеличивается в два раза — при таком подходе зарезервированного места всегдя будет много)

При небольших размерах коллекции — да. При миллионах и сотнях миллионов элементов — вовсе нет.

Но плохо даже не это. Плохо то, что у программы будет очень странная временная зависимость на добавление элемента. В 99.999% — ничтожно. Зато в 0.001% — ого-го!

>и ее можно попросту проигнорировать.

Я там пример привел, на С++ правда, который не работает и никогда в Win32 работать не сможет. Хотя с точки зрения чистой логики он безупречен — было в массиве 1 млрд элементов, а я хочу 1 млрд + 1 элемент. Захоти я сразу 1 млрд + 1 элемент — пожалуйста. А увеличить — не выйдет. Не проигнорируешь. И на C# будет то же самое.

>Да, адресное пространство надо экономить

Совсем не обязательно. Память надо экономить, а вот адресное пространство — только тогда, когда его может не хватить. Его все равно ни меньше, ни больше не станет

Например, мне известно, что у меня в программе не очень много не очень больших объектов, а вот один объект может иметь размер и 16 Кб, и 1 Гб. Своеобразный такой объект, динамический. В этом случае можно спокойно откусить 1 Гб адресного пространства (оставшегося почти 1 Гб на все остальное хватит за глаза) и заполнять его по мере необходимости, понемногу увеличивая и увеличивая. Зачем мне тут экономить, для чего ?

>Тем не менее по потреблению памяти массив все равно куда экономнее связного списка.

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

Одним словом , я не за массив и не за список. я за то, чтобы употреблялось лучшее по условиям задачи.

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

>>Да, адресное пространство надо экономить

PD>Совсем не обязательно. Память надо экономить, а вот адресное пространство — только тогда, когда его может не хватить. Его все равно ни меньше, ни больше не станет

Не понятно. Ведь ресурс-то это как раз адресное пространство, а не память. Мало памяти — почисти диск.

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

PD>>Совсем не обязательно. Память надо экономить, а вот адресное пространство — только тогда, когда его может не хватить. Его все равно ни меньше, ни больше не станет

S>Не понятно. Ведь ресурс-то это как раз адресное пространство, а не память. Мало памяти — почисти диск.

При чем тут диск ? Я говорю об оперативной памяти (+своп). И ресурс — именно память (ОП + своп), ее может и не хватить. А АП у всех 2 Гб, хоть что делай (или 3 на сервере), и оно приватно (если самому не делать часть его публичной), а поэтому от того, как я его использую, никому не холодно и не жарко. И мне его тоже не жалко, пока хватает, конечно.

Например, VirtualAlloc на 1 Гб с MEM_RESERVE. Из примерно 2 Гб АП я зарезервировал 1. И ни одного байта не выделил. Просто пометил адреса как занятые, больше ничего. У меня еще почти 1 Гб осталось, хватит.

А вот если не хватит (например, 2 таких массива нужно), тогда будем и АП экономить.

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

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

PD>>>Совсем не обязательно. Память надо экономить, а вот адресное пространство — только тогда, когда его может не хватить. Его все равно ни меньше, ни больше не станет

S>>Не понятно. Ведь ресурс-то это как раз адресное пространство, а не память. Мало памяти — почисти диск.

PD>При чем тут диск ? Я говорю об оперативной памяти (+своп). И ресурс — именно память (ОП + своп), ее может и не хватить.
Оперативной памяти нехватить не может (ее может быть просто маловато, тогда будет много свопу). От размера ОП зависит разве что объем свопа. Нехватить может либо АП либо места в файла подкачки. И если диск забит под завязку, то не хватает как-правило места в файле подкачки. Мне странно что я объясняю это спецу по WinAPI.

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

VD>Если не включена поддержка pdb (что может быть и в релизе), nop-ов быть не должно.
VD>В прочем, они выкидываются джитом когда тот работает в оптимизирующем режиме.

Да, была включена.

VD>>>Кстати, ты знаком с О-нотацией?
VD>>>Не подскажешь какова алгоритмическая сложность перебора списка и массива (в О-нотации)?
ВВ>>Более бредовый вопрос не мог спросить?
ВВ>>Сложность какого перебора? Сложность доступа по индексу и сложность обращения к полю?
VD>Последовательного... с начала к концу. Ты же его тестировал.

Для массива — O(n). Для списка — не знаю. Есть разные варианты перебора, но судя по сгенерированному коду, который я приводил, там идет простой перебор, без подстраховки от циклических ссылок (возможно, потому что их нельзя создать?). А провисаем на всяких castclass-ах, так что алгоритмическая сложность тут не причем.

А тестировал я обещанную тобой эффективность

Что, нельзя?

VD>Если по делу, а не ради флэйма, то добро пожаловать. Если найдешь что, только спасибо скажем.

У меня вопросы больше философские

Ну ок, спасибо за приглашение

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

PD>>При чем тут диск ? Я говорю об оперативной памяти (+своп). И ресурс — именно память (ОП + своп), ее может и не хватить.
S>Оперативной памяти нехватить не может (ее может быть просто маловато, тогда будет много свопу). От размера ОП зависит разве что объем свопа. Нехватить может либо АП либо места в файла подкачки.

Ты путаешь разные понятия. Не хватить АП может, да, но распоряжаюсь им я сам и это никого не касается. Потому что это не память, а только пространство. Хвати его или не хватит — чисто мои проблемы. Это только адреса, без памяти. Этих адресов 2 млрд. Что хочу с ними — то и делаю, и ни перед кем не отчитываюсь. И если я зарезервирую 1 Гб или же 100 Кб только — от этого ничего не изменится, пока мне хватит второго имеющегося Гб адресов.

Что же касается памяти, то ее не хватить может, так как своп расти не будет неограниченно.

HANDLE WINAPI CreateMemoryResourceNotification(
__in MEMORY_RESOURCE_NOTIFICATION_TYPE NotificationType
);

NotificationType
The memory condition under which the object is to be signaled. This parameter can be one of the following values.

Value Meaning
LowMemoryResourceNotification
0
Available physical memory is running low.

HighMemoryResourceNotification
1
Available physical memory is high.

Applications can use memory resource notification events to scale the memory usage as appropriate. If available memory is low, the application can reduce its working set. If available memory is high, the application can allocate more memory.

А Windows при этом выводит окно "The system is at very low memory state" или что-то в этом роде.

>И если диск забит под завязку, то не хватает как-правило места в файле подкачки.

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

>Мне странно что я объясняю это спецу по WinAPI.

Не обижайся, но ты просто не разобрался с этим вопросом.

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

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

PD>>>При чем тут диск ? Я говорю об оперативной памяти (+своп). И ресурс — именно память (ОП + своп), ее может и не хватить.
S>>Оперативной памяти нехватить не может (ее может быть просто маловато, тогда будет много свопу). От размера ОП зависит разве что объем свопа. Нехватить может либо АП либо места в файла подкачки.

PD>Ты путаешь разные понятия. Не хватить АП может, да, но распоряжаюсь им я сам и это никого не касается. Потому что это не память, а только пространство.
Что с чем?

PD>А Windows при этом выводит окно "The system is at very low memory state" или что-то в этом роде.
Видел в прошлом веке, кажись.

>>И если диск забит под завязку, то не хватает как-правило места в файле подкачки.

PD>Этот случай большого интереса не представляет, хотя, конечно, довести систему до того, чтобы на диске со своп-файлом не было нескольких свободных Гб, можно. Но довести систему до LowMemoryResourceNotification можно, даже если свободного места на диске полно.
Можно.

PD>Не обижайся, но ты просто не разобрался с этим вопросом.
Просто все мои проблемы с памятью были только от фрагментации АП на объемах выделений до гигабайта. LowMemoryResourceNotification давно не видел.

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

PD>>Ты путаешь разные понятия. Не хватить АП может, да, но распоряжаюсь им я сам и это никого не касается. Потому что это не память, а только пространство.
S>Что с чем?

Адресное пространство с физической памятью, понимая под последней ОП + своп. Это — важнейший ресурс всегда (мы в коммунальной квартире, твое приложение не единственное). А АП — это ресурс только когда его не хватает. Здесь мне ни о ком заботиться не надо, кроме как о себе, да и для себя затраты практически нулевые.

PD>>А Windows при этом выводит окно "The system is at very low memory state" или что-то в этом роде.
S>Видел в прошлом веке, кажись.

Оно никуда не делось. Своп не растет бесконечно — бессмысленно, будет просто пробуксовка ОС.

PD>>Не обижайся, но ты просто не разобрался с этим вопросом.
S>Просто все мои проблемы с памятью были только от фрагментации АП на объемах выделений до гигабайта.

Конечно, тогда будут.

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

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

PD>>>Ты путаешь разные понятия. Не хватить АП может, да, но распоряжаюсь им я сам и это никого не касается. Потому что это не память, а только пространство.
S>>Что с чем?

PD>Адресное пространство с физической памятью, понимая под последней ОП + своп.
Я не путаю АП и ФП.

PD>Это — важнейший ресурс всегда (мы в коммунальной квартире, твое приложение не единственное). А АП — это ресурс только когда его не хватает. Здесь мне ни о ком заботиться не надо, кроме как о себе, да и для себя затраты практически нулевые.
Ну да, ОП+ своп — ресурс общий, АП — частный.

PD>>>А Windows при этом выводит окно "The system is at very low memory state" или что-то в этом роде.
S>>Видел в прошлом веке, кажись.

PD>Оно никуда не делось. Своп не растет бесконечно — бессмысленно, будет просто пробуксовка ОС.
Да, знаю. Но у меня своп большой и памяти много. Достичь края не получалось. А вот АП на вес золота.

PD>>>Не обижайся, но ты просто не разобрался с этим вопросом.
S>>Просто все мои проблемы с памятью были только от фрагментации АП на объемах выделений до гигабайта.

PD>Конечно, тогда будут.
Не правильно выразился. При объеме использованной (под актуальные данные) памяти до гигабайта (это могло быть 300 или 600 Мб) было невозможно выделить несчастные 100Кб. Спасибо LOH-у.

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

PD>>Адресное пространство с физической памятью, понимая под последней ОП + своп.
S>Я не путаю АП и ФП.

Тогда,значит. я не прав.

PD>>Это — важнейший ресурс всегда (мы в коммунальной квартире, твое приложение не единственное). А АП — это ресурс только когда его не хватает. Здесь мне ни о ком заботиться не надо, кроме как о себе, да и для себя затраты практически нулевые.
S>Ну да, ОП+ своп — ресурс общий, АП — частный.

Совершенно верно.

PD>>Оно никуда не делось. Своп не растет бесконечно — бессмысленно, будет просто пробуксовка ОС.
S>Да, знаю. Но у меня своп большой и памяти много. Достичь края не получалось. А вот АП на вес золота.

Где как. У меня тоже было, причем обидным образом. Под W2000. C++. Куча фрагментировала почему-то АП, хотя не должна была, по моему мнению. И под XP этого не было. А под W2000 почему-то вместо использования сатрых блоков она отводила новый экстент. А был еще VirtualAlloc, он и проваливался, через несколько часов после начала работы. С трудом поборол.

PD>>Конечно, тогда будут.
S>Не правильно выразился. При объеме использованной (под актуальные данные) памяти до гигабайта (это могло быть 300 или 600 Мб) было невозможно выделить несчастные 100Кб.

Странно, конечно. Но не зная деталей, вполне могу допустить.

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

PD>При чем тут диск ? Я говорю об оперативной памяти (+своп). И ресурс — именно память (ОП + своп)

Это смотря где и как. Для Решарпера, к примеру, память физическая вообще сейчас не проблема, даже на больших солюшенах ему хватит 200-300 мег. А вот с адресным пространством плохо. 10 студия на все плагины оставляет в лучшем случае 500М спейса. С учетом фрагментации попа может наступить очень быстро.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

AVK>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>При чем тут диск ? Я говорю об оперативной памяти (+своп). И ресурс — именно память (ОП + своп)

AVK>Это смотря где и как. Для Решарпера, к примеру, память физическая вообще сейчас не проблема, даже на больших солюшенах ему хватит 200-300 мег. А вот с адресным пространством плохо. 10 студия на все плагины оставляет в лучшем случае 500М спейса.

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

Хотя... ИМХО 500 М достаточно, чтобы разместить все плагины на свете. Если, конечно, их писали не с тем же безобразным отношением к ресурсам.

P.S. Студию в 64-бита не перевели ?

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

PD>Хотя... ИМХО 500 М достаточно, чтобы разместить все плагины на свете.

Это тебе так только кажется за незнанием предмета.

PD>P.S. Студию в 64-бита не перевели ?

Нет, и не собираются.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

PD>>Хотя... ИМХО 500 М достаточно, чтобы разместить все плагины на свете.

AVK>Это тебе так только кажется за незнанием предмета.

Возможно. И все же — что там занимает 1.5 Г АП ?

Я 2010 не ставил, но как-нибудь посмотрю АП в 2008. Интересно, что там есть.

PD>>P.S. Студию в 64-бита не перевели ?

AVK>Нет, и не собираются.

Жаль.

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

PD>>>Хотя... ИМХО 500 М достаточно, чтобы разместить все плагины на свете.
А помнишь, 512 К — это было СТОЛЬКО памяти!!!

Весь институт одновременно сидел...

AVK>>Это тебе так только кажется за незнанием предмета.
PD>Возможно. И все же — что там занимает 1.5 Г АП ?
1.5 Гига — это БЕСКОНЕЧНО МНОГО...

PD>Я 2010 не ставил, но как-нибудь посмотрю АП в 2008. Интересно, что там есть.
PD>>>P.S. Студию в 64-бита не перевели ?
AVK>>Нет, и не собираются.
PD>Жаль.
Скорее всего это произойдет после повсеместного перехода ОС на x64.

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

LVV>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>>Хотя... ИМХО 500 М достаточно, чтобы разместить все плагины на свете.
LVV>А помнишь, 512 К — это было СТОЛЬКО памяти!!!

Весь институт одновременно сидел...

Помню. И компилятор Паскаль ДВК-2 И ТурбоПаскаль Ямахи в 64 Кб тоже помню. Компилировал, как ни странно.

AVK>>>Это тебе так только кажется за незнанием предмета.
PD>>Возможно. И все же — что там занимает 1.5 Г АП ?
LVV>1.5 Гига — это БЕСКОНЕЧНО МНОГО...

Это мы понимаем. Это им не понять.

LVV>Скорее всего это произойдет после повсеместного перехода ОС на x64.

Что-то это добро побеждает, побеждает и никак победить не может (C) Айболит-66

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

AVK>>Это тебе так только кажется за незнанием предмета.

PD>Возможно. И все же — что там занимает 1.5 Г АП ?

Много чего. Например кеш пропарсенных исходников всего солюшена. Или целое море dll'ек. Ну и, конечно, WPF. 1.5Гб, кстати, это после того как они долго чистили на предмет занимаемого спейса. Без чистки 2010 студия без всяких расширений дохла по исчерпанию АП.

PD>Я 2010 не ставил, но как-нибудь посмотрю АП в 2008.

В 2008 ситуация немного полегче. Если решарпер не ставить, то АП хватает. А в 2010 они сами же на свои грабли наступили без всякого решарпера.

AVK>>Нет, и не собираются.

PD>Жаль.

Не то слово. Вот уж кому 64 бита нужно, так это студии.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

AVK>Много чего. Например кеш пропарсенных исходников всего солюшена.

Вообще-то ИМХО размер пропарсенных исходников не должен быть намного больше размера самих исходников. Скорее наоборот — хранить имена полей и переменных в N экземплярах там не надо, а они много (в %) места занимают. Аргумент здесь простой — умели же компилировать на машинах с памятью 64 К программы с намного большим размером исходников.

>Или целое море dll'ек.

Это да. Но их просто надо бы уложить компактно. Не думаю, что их объем так уж велик сам по себе.

>Ну и, конечно, WPF. 1.5Гб, кстати, это после того как они долго чистили на предмет занимаемого спейса. Без чистки 2010 студия без всяких расширений дохла по исчерпанию АП.

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

PD>Вообще-то ИМХО размер пропарсенных исходников не должен быть намного больше размера самих исходников.

Во-первых нет, как минимум связи между нодами в AST в виде указателей отожрут вполне сравнимо с исходым текстом. Во-вторых несколько сотен мег исходников вполне реальая ситуация. В-третьих, помимо пропарсенных исходников нужны еще и индексы, которые тоже немало занимают.

PD> Скорее наоборот — хранить имена полей и переменных в N экземплярах там не надо

Для IDE — надо, иначе ни рефакторинга, ни интеллисенса.

PD>Аргумент здесь простой — умели же компилировать на машинах с памятью 64 К программы с намного большим размером исходников.

То что умели компилировать на машинах с 64К, приходилось сильно урезать. Те же хидеры в C как раз из-за этого пришлось делать.

>>Или целое море dll'ек.

PD>Это да. Но их просто надо бы уложить компактно.

Опять же, ты плохо разбираешься в предмете. Студия это не монолитный код, а сравнительно компактный shell с целой кучей плагинов, разрабатываемых независимыми командами. И все это приправлено нехилым грузом совместимости и стабов для перехода между неуправляемым кодом и .NET.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

AVK>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Вообще-то ИМХО размер пропарсенных исходников не должен быть намного больше размера самих исходников.

AVK>Во-первых нет, как минимум связи между нодами в AST в виде указателей отожрут вполне сравнимо с исходым текстом.

Не думаю. Ноды — они, конечно, ноды и связи — они тоже, но вот под все вхождения имени переменной надо (strlen+1) ее + N*4 байта, не более. А ИМХО эти имена процентов 30-40 как минимум исходного текста занимают. Да и методы те же можно покомпактнее хранить, чем в виде исходного текста.

>Во-вторых несколько сотен мег исходников вполне реальая ситуация.

Реальная, да, но все же не типичная.

PD>> Скорее наоборот — хранить имена полей и переменных в N экземплярах там не надо

AVK>Для IDE — надо, иначе ни рефакторинга, ни интеллисенса.

Почему это ? Кто мешает восстановить текст по внутренней компактной структуре, изоморфной тексту ? В нем же избыточности до черта!

PD>>Аргумент здесь простой — умели же компилировать на машинах с памятью 64 К программы с намного большим размером исходников.

AVK>То что умели компилировать на машинах с 64К, приходилось сильно урезать. Те же хидеры в C как раз из-за этого пришлось делать.

Хедеры тут вообще ни при чем. Они просто, чтобы не писать то, что я писать не обязан. Не буду же я все прототипы из stdio.h сам писать! Кстати, и хедеров, строго говоря, нет. Есть #include, а уж что именно там — можно .h с только декларациями, а можно и .c с дефинициями. Это просто способ организации текста.

>>>Или целое море dll'ек.

PD>>Это да. Но их просто надо бы уложить компактно.

AVK>Опять же, ты плохо разбираешься в предмете. Студия это не монолитный код, а сравнительно компактный shell с целой кучей плагинов, разрабатываемых независимыми командами.

Поверь, я это знаю. Но вот как эти плагины работают — другой вопрос. Загружать их все в ОП совсем не обязательно. Если уж на то пошло, компилятор C++ тоже "плагин", но запускается он как отдельный процесс и АП не ворует у студии.

>И все это приправлено нехилым грузом совместимости и стабов для перехода между неуправляемым кодом и .NET.

За что боролись...

.
Одно непонятно — а нас-то (С++) за что на это монстр посадили ? Продолжили бы развивать VS6.0 для C++, ну а вам свою студию совсеми этими прелестями

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

PD>Не думаю. Ноды — они, конечно, ноды и связи — они тоже, но вот под все вхождения имени переменной надо (strlen+1) ее + N*4 байта, не более. А ИМХО эти имена процентов 30-40 как минимум исходного текста занимают. Да и методы те же можно покомпактнее хранить, чем в виде исходного текста.

Еще раз, ты не в теме. Не все так просто.

PD>Реальная, да, но все же не типичная.

Когда я говорил про то, что Решарперу не хватает АП, речь шла именно про такие проекты.

AVK>>Для IDE — надо, иначе ни рефакторинга, ни интеллисенса.

PD>Почему это ? Кто мешает восстановить текст по внутренней компактной структуре, изоморфной тексту ?

Перформанс.

PD>Хедеры тут вообще ни при чем.

При чем. Без хидеров для ресолва приходится держать в памяти все символьные таблицы.

PD>Поверь, я это знаю. Но вот как эти плагины работают — другой вопрос.

Как бы они не работали — под каждый надо выделять АП для имаджа и рабочих структур.

PD> Загружать их все в ОП совсем не обязательно.

Не обязательно. Но отталкиваться надо от ситуации, когда они все загружены.

PD> Если уж на то пошло, компилятор C++ тоже "плагин", но запускается он как отдельный процесс и АП не ворует у студии.

Когда я писал про плагины, речь шла не о компиляторе, а о том что в студии называется package

PD>Одно непонятно — а нас-то (С++) за что на это монстр посадили ?

Разрабатывать несколько сред дорого и плохо с точки зрения маркетинга.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

PD>>Не думаю. Ноды — они, конечно, ноды и связи — они тоже, но вот под все вхождения имени переменной надо (strlen+1) ее + N*4 байта, не более. А ИМХО эти имена процентов 30-40 как минимум исходного текста занимают. Да и методы те же можно покомпактнее хранить, чем в виде исходного текста.

AVK>Еще раз, ты не в теме. Не все так просто.

Я не в теме, да, и не все так просто, но ведь 20-30 лет назад было не проще, а таки было. А зная, как сейчас умеют транжирить ресурсы, я имею основание предположить, что то, что тебе кажется нормальным, в действительности могло занимать раз так в 5-10 меньше места. Просто потому, что прецедент-то был.

AVK>Когда я говорил про то, что Решарперу не хватает АП, речь шла именно про такие проекты.

Я полагал, мы давно уже не про Решарпер говорим, а обсуждаем, кто и зачем 1.5 Г АП скушал. Про DLL и т.д.

PD>>Почему это ? Кто мешает восстановить текст по внутренней компактной структуре, изоморфной тексту ?

AVK>Перформанс.

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

Кстати, если уж на то пошло — рефлектор же умеет восстановить код по IL. И довольно шустро.
PD>>Хедеры тут вообще ни при чем.

AVK>При чем. Без хидеров для ресолва приходится держать в памяти все символьные таблицы.

И что ? Этим символов в проекте тысячи, десятки тысяч, ну пусть сотня. Ты попробуй напиши со всей своей командой программу, в которой 100000 имен, а потом поговорим

. И библиотеки тут ничего не изменят — там тоже не миллионы имен. Весь нелюбимый тобой Win API — несколько тысяч.

PD>>Поверь, я это знаю. Но вот как эти плагины работают — другой вопрос.

AVK>Как бы они не работали — под каждый надо выделять АП для имаджа и рабочих структур.

AVK>Не обязательно. Но отталкиваться надо от ситуации, когда они все загружены.

Вообще-то отталкиваться нужно от ситуации, когда загружено то, что надо. Вот тебе классический пример. Я с аськой начинал работать, когда на машине было не то 8, не то 16 Мб. Ну и она там сколько-то занимала, и , в общем, не мешала. Сейчас она сама в 16 не уверен, что уложится. А 99% ее использования как тогда было, так и сейчас (строку набрать да отослать, ответ посмотреть). Ну и сидели бы все оставшиеся фичи себе на диски и ждали, когда их в АП призовут. А по минованию надобности выгонят. Нечего им там сидеть.

PD>> Если уж на то пошло, компилятор C++ тоже "плагин", но запускается он как отдельный процесс и АП не ворует у студии.

AVK>Когда я писал про плагины, речь шла не о компиляторе, а о том что в студии называется package

Тут я действительно не очень в курсе. Про package знаю гл. образом то, что они иногда ругаются, что у них что-то не так, но после этого студия все же работает, по крайней мере в части С++.

PD>>Одно непонятно — а нас-то (С++) за что на это монстр посадили ?

AVK>Разрабатывать несколько сред дорого и плохо с точки зрения маркетинга.

Ну вообще-то до поры до времени VB был вполне отдельным от студии продуктом. И FoxPro тоже, да и остается , если его не похоронили (что-то о нем почти и не слыхать). А вот Compaq Fortran вполне неплохо в эту студию встраивался, да и Intel C++, Intel Fortran...

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

PD>Я не в теме, да, и не все так просто, но ведь 20-30 лет назад было не проще

Было. 20 лет назад просто не было аналогичных по функционалу IDE.

PD>Я полагал, мы давно уже не про Решарпер говорим, а обсуждаем, кто и зачем 1.5 Г АП скушал. Про DLL и т.д.

На мелких проектах и студия 1.5 гига не кушает.

PD>Ох, что-то плохо верю.

Это не вопрос веры, это факт.

PD> Да и так — все равно хранят они в этом кеше что-то во внутреннем формате, не сами же исходники. И решарпер — он что, исходники парсит заново ?

Конечно.

PD>Кстати, если уж на то пошло — рефлектор же умеет восстановить код по IL. И довольно шустро.

Шустро, это когда один метод. А когда сотни тысяч?

AVK>>При чем. Без хидеров для ресолва приходится держать в памяти все символьные таблицы.

PD>И что ?

И 64К уже не хватит для программ соотв. размера.

PD>Ты попробуй напиши со всей своей командой программу, в которой 100000 имен

Решарпер вполне такая программа.

PD>Вообще-то отталкиваться нужно от ситуации, когда загружено то, что надо.

А надо может быть все.

AVK>>Разрабатывать несколько сред дорого и плохо с точки зрения маркетинга.

PD>Ну вообще-то до поры до времени VB был вполне отдельным от студии продуктом. И FoxPro тоже

По историческим причинам.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

PD>>Я не в теме, да, и не все так просто, но ведь 20-30 лет назад было не проще

AVK>Было. 20 лет назад просто не было аналогичных по функционалу IDE.

Разумеется. Но переменные (имена) были. Классы были. Компиляция была. И все это в 1 М укладывалось. Что-то я не верю, что понадобилось вдруг в 100 раз больше.

PD>>Я полагал, мы давно уже не про Решарпер говорим, а обсуждаем, кто и зачем 1.5 Г АП скушал. Про DLL и т.д.

AVK>На мелких проектах и студия 1.5 гига не кушает.

АП ? Или памяти ?

PD>>Ох, что-то плохо верю.

AVK>Это не вопрос веры, это факт.

Ну-ну.

PD>>Кстати, если уж на то пошло — рефлектор же умеет восстановить код по IL. И довольно шустро.

AVK>Шустро, это когда один метод. А когда сотни тысяч?

А что, сотни тысяч надо все сразу ? Если да — тут при любой структуре заткнешься. Но я все же думаю (с решарпером не знаком, но с аналогичным работал), все ограничивается не таким уж большим числом файлов и методов.

AVK>>>При чем. Без хидеров для ресолва приходится держать в памяти все символьные таблицы.

PD>>И что ?

AVK>И 64К уже не хватит для программ соотв. размера.

Не понял. Ты что, не понимаешь, что такое #include ? Их в принципе можно все исключить, но тогда придется вручную вставить их текст. Теоретически возможно (и даже практически можно только препроцессировать и вывести результат в файл — в VS). На скорость компиляции не повлияет (если не говорить о precompiled headers, но их тогда и близко не было), на размер таблиц тоже. Вообще ни на что не повлияет, кроме времени чтения файлов с диска.

PD>>Ты попробуй напиши со всей своей командой программу, в которой 100000 имен

AVK>Решарпер вполне такая программа.

Ну-ну...

На набор одного имени кладем 3 секунды. Имя же надо набрать, нет, тут же никто не поможет.

3 * 100000 = 300000 секунд = 83 часа = 3 месяца. Круглосуточно, без перекуров, обеда и сна. А при 8-часовом — почти год. Это только на описание всех имен. Программу будем набирать еще сколько времени ?

PD>>Вообще-то отталкиваться нужно от ситуации, когда загружено то, что надо.

AVK>А надо может быть все.

А вот когда надо будет, тогда и загрузим. И не все, а то, что надо будет когда надо будет . А потом выгрузим, и опять загрузим, когда надо будет. Всем этим методам 100 лет в обед.

AVK>>>Разрабатывать несколько сред дорого и плохо с точки зрения маркетинга.

PD>>Ну вообще-то до поры до времени VB был вполне отдельным от студии продуктом. И FoxPro тоже

AVK>По историческим причинам.

Хорошие были причины

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

PD>Но переменные (имена) были.

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

PD> Что-то я не верю, что понадобилось вдруг в 100 раз больше.

А я нигде и не писал, что в 100 раз больше понадобилось для компиляции.

AVK>>На мелких проектах и студия 1.5 гига не кушает.

PD>АП ? Или памяти ?

И того и другого.

AVK>>Шустро, это когда один метод. А когда сотни тысяч?

PD>А что, сотни тысяч надо все сразу ?

Для рефакторинга, интеллисенса и прочих подобных вещей — да.

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

Твои теории не верны.

AVK>>И 64К уже не хватит для программ соотв. размера.

PD>Не понял. Ты что, не понимаешь, что такое #include ?

А ты понимаешь, что такое количество проходов компилятора, и почему раньше боролись за их минимизацию в том числе и урезанием фич языка, а современные компиляторы делают десятки проходов? Почему раньше во многих языках мейнстрима была такая вещь как forward declaration, а сейчас обычно обходятся без нее? Почему раньше библиотеки у многих языков имели специальный формат файла, а сейчас в качестве библиотек используются исполняемые файлы?

PD>>>Ты попробуй напиши со всей своей командой программу, в которой 100000 имен

AVK>>Решарпер вполне такая программа.

PD>Ну-ну...

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

PD>3 * 100000 = 300000 секунд = 83 часа = 3 месяца. Круглосуточно, без перекуров, обеда и сна.

И что? Решарпер не первый год существует, и команда не из одного человека состоит. Я конечно понимаю, что ты с таким никогда не сталкивался, но существуют проекты, которые намного больше решарпера.

AVK>>А надо может быть все.

PD>А вот когда надо будет, тогда и загрузим.

Видишь ли, разработчикам студии и решарпера надо рассчитывать на такие ситуации. Поэтому от того, что иногда это не надо, легче не становится.

PD>А потом выгрузим, и опять загрузим

Скажи, ты когда нибудь в жизни писал приложения с плагинами, в которых работающие плагины можно выгружать?

AVK>>По историческим причинам.

PD>Хорошие были причины

Нормальные. FoxPro, к примеру, МС купил готовым продуктом уже не первой версии.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

AVK>Здравствуйте, Pavel Dvorkin, Вы писали:

AVK>Да что ты уперся в эти имена? Там и без имен хватает что хранить. Типовой узел AST вполня модет содержать десятки указателей, чтобы навигация по дереву была максимально быстрой.

Что-то мне кажется, что а) десятки — многовато и б) даже для десятка это всего лишь 40 байт.

PD>> Что-то я не верю, что понадобилось вдруг в 100 раз больше.

AVK>А я нигде и не писал, что в 100 раз больше понадобилось для компиляции.

А я и не говорил, что это ты писал. Просто те компиляторы работали в 64 К, а нынешние на 6.4 М работать ни за что не будут, да и на 64 М — не уверен.

PD>>А что, сотни тысяч надо все сразу ?

AVK>Для рефакторинга, интеллисенса и прочих подобных вещей — да.

Не знаю я решарпер, спорить не буду. Но интеллисенс есть был и в VS 5-6, для С++ ничем не хуже он тогда был, его, собственно, и не изменили. А работало все на 32-64 Мб физической ОП.

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

AVK>Твои теории не верны.

Ну это уже не аргумент.

AVK>>>И 64К уже не хватит для программ соотв. размера.

PD>>Не понял. Ты что, не понимаешь, что такое #include ?

AVK>А ты понимаешь, что такое количество проходов компилятора

Понимаю. В VС++ — один + второй от линкера (c2.dll).

>и почему раньше боролись за их минимизацию в том числе и урезанием фич языка

Никто ничего не урезал, насколько я помню, в том же ТурбоПаскале. Наоборот, расширили, а потом еще первый вариант ООП прикрутили , и все в 640 К.

>а современные компиляторы делают десятки проходов?

Откуда такая информация ? Ссылку дай, только не по экзотическим языкам.

>Почему раньше во многих языках мейнстрима была такая вещь как forward declaration а сейчас обычно обходятся без нее?

Отроду в Фортране не было. В C K&R не было (и до сих пор необязательна) — я прототип функции имею в виду. Где были-то ?

>Почему раньше библиотеки у многих языков имели специальный формат файла

Ну ты даешь. Формату COFF уже сто лет в обед.

>а сейчас в качестве библиотек используются исполняемые файлы?

Ты про статические библиотеки слышал ?

PD>>>>Ты попробуй напиши со всей своей командой программу, в которой 100000 имен

AVK>>>Решарпер вполне такая программа.

PD>>Ну-ну...

AVK>Опять ну-ну. Это легко проверяется, благо вся метаинформация в сборках решарпера доступно. Посчитать суммарное количество имен типов, их членов и параметров совсем несложно.

А любопытно бы.

PD>>3 * 100000 = 300000 секунд = 83 часа = 3 месяца. Круглосуточно, без перекуров, обеда и сна.

AVK>И что? Решарпер не первый год существует, и команда не из одного человека состоит. Я конечно понимаю, что ты с таким никогда не сталкивался, но существуют проекты, которые намного больше решарпера.

Я с таким не сталкивался. Слава богу

PD>>А вот когда надо будет, тогда и загрузим.

AVK>Видишь ли, разработчикам студии и решарпера надо рассчитывать на такие ситуации. Поэтому от того, что иногда это не надо, легче не становится.

А все же, почему нельзя загружать и выгружать по мере надобности ?

PD>>А потом выгрузим, и опять загрузим

AVK>Скажи, ты когда нибудь в жизни писал приложения с плагинами, в которых работающие плагины можно выгружать?

Если бы они все одновременно работали, то я бы согласился. Но реально работают только некоторые. Остальным можно послать команду "стоп", потом выгрузить, сохранив состояние, если надо. Все это решаемо. Есть же даже выгрузка драйверов 0 кольца, а это тебе не плагин.

AVK>>>По историческим причинам.

PD>>Хорошие были причины

AVK>Нормальные. FoxPro, к примеру, МС купил готовым продуктом уже не первой версии.

Знаю.

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

PD>Что-то мне кажется, что а) десятки — многовато

Ну, что там тебе кажется, это уж ты сам.

PD> и б) даже для десятка это всего лишь 40 байт.

Только вот узлы для рефакторинга нужно создавать на каждый токен.

PD>А я и не говорил, что это ты писал. Просто те компиляторы работали в 64 К, а нынешние на 6.4 М работать ни за что не будут, да и на 64 М — не уверен.

Зато они работают быстрее и качественнее.

AVK>>Для рефакторинга, интеллисенса и прочих подобных вещей — да.

PD>Не знаю я решарпер, спорить не буду. Но интеллисенс есть был и в VS 5-6, для С++ ничем не хуже он тогда был

Речь не про С++. В С++ нормального интеллисенса и рефакторинга просто не сделать ввиду дизайна языка.

AVK>>Твои теории не верны.

PD>Ну это уже не аргумент.

Для аргумента попробуй сперва свои теории хоть как то обосновать. А то получается очередное требование доказать несуществование Летающего Макаронного Монстра.

AVK>>А ты понимаешь, что такое количество проходов компилятора

PD>Понимаю. В VС++ — один + второй от линкера (c2.dll).

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

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

>>а современные компиляторы делают десятки проходов?

PD>Откуда такая информация ? Ссылку дай, только не по экзотическим языкам.

http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx

PD>Отроду в Фортране не было.

Фортран настолько убог, что ему это не нужно

PD> В C K&R не было (и до сих пор необязательна) — я прототип функции имею в виду. Где были-то ?

Простой вопрос — всегда ли можно обойтись без forward declaration?

>>а сейчас в качестве библиотек используются исполняемые файлы?

PD>Ты про статические библиотеки слышал ?

Т.е. компилятору С достаточно одной только dll, чтобы скомпилировать программу с ее использованием?

AVK>>Опять ну-ну. Это легко проверяется, благо вся метаинформация в сборках решарпера доступно. Посчитать суммарное количество имен типов, их членов и параметров совсем несложно.

PD>А любопытно бы.

Ну вот и займись.

PD>А все же, почему нельзя загружать и выгружать по мере надобности ?

Ты меня вообще читаешь? Неважно, что будет на игрушечных ситуациях, важен максимально плохой случай. Ты там много флагом по поводу качества размахивал: что ты думаешь по поводу качества программы, в которой попытка использовать весь функционал в один момент приводит к ее вылету?
Пакеты в студии, кстати, грузятся по требованию. Но далеко не всегда это можно обеспечить чисто логически. Ряд пакетов обязаны стартовать в момент загрузки солюшена.

AVK>>Скажи, ты когда нибудь в жизни писал приложения с плагинами, в которых работающие плагины можно выгружать?

PD>Если бы они все одновременно работали, то я бы согласился. Но реально работают только некоторые. Остальным можно послать команду "стоп", потом выгрузить, сохранив состояние, если надо. Все это решаемо. Есть же даже выгрузка драйверов 0 кольца, а это тебе не плагин.

Не вижу ответа на заданный вопрос.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

>>а сейчас в качестве библиотек используются исполняемые файлы?
PD>Ты про статические библиотеки слышал ?
AVK>Т.е. компилятору С достаточно одной только dll, чтобы скомпилировать программу с ее использованием?

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

А для того, что "скомпилировать программу с одной только dll" проблем тоже как-то не видно, достаточно, чтобы для этой DLL импорт-директивы были прописаны именно в том виде, в котором их понимает конкретный компилятор.

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

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

Поэтому, кстати, C++\CLI и скуксился.

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

AVK>Не то слово. Вот уж кому 64 бита нужно, так это студии.

А если прилично кода студии теперь на дотнете, то почему бы не перекомпилировать в 64? Самое время.

... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>

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

AVK>>Не то слово. Вот уж кому 64 бита нужно, так это студии.

V>А если прилично кода студии теперь на дотнете, то почему бы не перекомпилировать в 64? Самое время.

Вопрос не ко мне.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

PD>>А я и не говорил, что это ты писал. Просто те компиляторы работали в 64 К, а нынешние на 6.4 М работать ни за что не будут, да и на 64 М — не уверен.

AVK>Зато они работают быстрее и качественнее.

Насчет качественее — не спорю. Насчет быстрее... Давай сравним. ТурбоПаскаль 1.0 на Ямахе с тактовой частотой 2 МГц и памятью в 64К компилировал программу в 1000 строк несколько секунд. Сколько времени надо, чтобы откомпилировать программу размером в 1 млн строк на процессоре в 2 Ггц ? Очевидно, тоже несколько секунд. Давай сюда этот компилятор!

AVK>Речь не про С++. В С++ нормального интеллисенса и рефакторинга просто не сделать ввиду дизайна языка.

+1 насчет рефакторинга. Интеллисенс там есть, хоть и не такой.

PD>>Ну это уже не аргумент.

AVK>Для аргумента попробуй сперва свои теории хоть как то обосновать. А то получается очередное требование доказать несуществование Летающего Макаронного Монстра.

Это еще менее аргумент. А обоснования я приводил не раз в этом нашем треде, путем сравнения с компиляторам прошлых времен. Одно из них выше.

AVK>>>А ты понимаешь, что такое количество проходов компилятора

PD>>Понимаю. В VС++ — один + второй от линкера (c2.dll).

AVK>Все таки не понимаешь. Книжку с драконом читал

Ну не понимаю — и не надо. До сих пор вроде как понимал, и все так же понимали

http://rsdn.ru/forum/tools/386609.1.aspx

И вот тут кое-что сказано

http://ru.wikipedia.org/wiki/%D0%A1%D0%B8_(%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)

"Авторы языка хотели, чтобы программы на нём легко компилировались с помощью однопроходного компилятора"

AVK>Неверно ты помнишь. Грамматика ТурбоПаскаля специальным образом заточена под однопроходную компиляцию, как и формат tpu файлов.

Ну слава богу, хоть ТурбоПаскаль однопроходной. А VC++ — сколько проходов все же ?

>>>а современные компиляторы делают десятки проходов?

PD>>Откуда такая информация ? Ссылку дай, только не по экзотическим языкам.

AVK>http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx

Ну что же, если в C# это нужно — на здоровье. В С++ — нет.

PD>>Отроду в Фортране не было.

AVK>Фортран настолько убог, что ему это не нужно

PD>> В C K&R не было (и до сих пор необязательна) — я прототип функции имею в виду. Где были-то ?

AVK>Простой вопрос — всегда ли можно обойтись без forward declaration?

Прототипы функций в С необязательны. Что же касается

struct A {
struct B* ptr;
};

struct B {...};

то да, предописание необходимо, но в нем нельзя упоминать поля. Вот так можно

struct B;
struct A {
struct B* ptr;
};

struct B {...};

Но из этого, в общем, мало что следует. См. обсуждение http://rsdn.ru/forum/tools/386609.1.aspx.

>>>а сейчас в качестве библиотек используются исполняемые файлы?

PD>>Ты про статические библиотеки слышал ?

AVK>Т.е. компилятору С достаточно одной только dll, чтобы скомпилировать программу с ее использованием?

Ты хоть представление имеешь о том, как компиляция в С/C++ идет ? Компилятору С не надо никаких DLL вообще, поскольку он с ними работать не умеет (за исключением #import, но это OLE). Он компилирует из .c в .obj. Линкеру в С++ тоже никаких DLL не надо, потому что поскольку он с ними работать не умеет. Ему нужны .lib файлы, или статические либы, или библиотеки импорта. В общем, собрать EXE, не имея требуемых для него DLL можно, более того, есть эти DLL или нет — ни на что не влияет при сборке EXE. При запуске, конечно, все DLL вынь да положь.

AVK>>>Опять ну-ну. Это легко проверяется, благо вся метаинформация в сборках решарпера доступно. Посчитать суммарное количество имен типов, их членов и параметров совсем несложно.

PD>>А любопытно бы.

AVK>Ну вот и займись.

PD>>А все же, почему нельзя загружать и выгружать по мере надобности ?

AVK>Ты меня вообще читаешь? Неважно, что будет на игрушечных ситуациях, важен максимально плохой случай. Ты там много флагом по поводу качества размахивал: что ты думаешь по поводу качества программы, в которой попытка использовать весь функционал в один момент приводит к ее вылету?

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

Вот тебе простой пример — виртуальная память. Максимально плохой случай в твоем понимании — это когда все страницы процесса должны быть в ОП. И всех процессов. Но этого никто не допустит просто-напросто, поскольку память не резиновая. Часть страниц в ОП, часть в свопе или mmf. Живем.

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

Да, знаю. Именно они и ругаются, если что не так.

AVK>>>Скажи, ты когда нибудь в жизни писал приложения с плагинами, в которых работающие плагины можно выгружать?

PD>>Если бы они все одновременно работали, то я бы согласился. Но реально работают только некоторые. Остальным можно послать команду "стоп", потом выгрузить, сохранив состояние, если надо. Все это решаемо. Есть же даже выгрузка драйверов 0 кольца, а это тебе не плагин.

AVK>Не вижу ответа на заданный вопрос.

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

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

ВВ>А для того, что "скомпилировать программу с одной только dll" проблем тоже как-то не видно, достаточно, чтобы для этой DLL импорт-директивы были прописаны именно в том виде, в котором их понимает конкретный компилятор.

Маленькое уточнение. Для VC++ — не импорт-директивы, а библиотека импорта, отдельный файл. Обычно прилагается к DLL, но при необходимости может быть сгенерирован по DLL

http://forum.shelek.ru/index.php/topic,3621.0.html

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

AVK>>Зато они работают быстрее и качественнее.
PD>Насчет качественее — не спорю. Насчет быстрее... Давай сравним. ТурбоПаскаль 1.0 на Ямахе с тактовой частотой 2 МГц и памятью в 64К компилировал программу в 1000 строк несколько секунд. Сколько времени надо, чтобы откомпилировать программу размером в 1 млн строк на процессоре в 2 Ггц ? Очевидно, тоже несколько секунд. Давай сюда этот компилятор!
Очевидно, что тот компилятор с памятью в 64К может и не скомпилировать 1 млн. строк вообще хотя бы ввиду отсутствия этой самой памяти.
О какой-то линейной зависимости можно говорить на совершенно простых языках, и то, я даже не знаю языка который не потребовал бы каких-либо внутренних структур.
Да и с оптимизациями в ТурбоПаскале 1.0 было совсем туго.

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

PD>Насчет качественее — не спорю. Насчет быстрее... Давай сравним. ТурбоПаскаль 1.0

Сравнивать надо компиляторы одинаковых языков.

PD>+1 насчет рефакторинга. Интеллисенс там есть, хоть и не такой.

Вот именно что тоже убогий.

AVK>>Неверно ты помнишь. Грамматика ТурбоПаскаля специальным образом заточена под однопроходную компиляцию, как и формат tpu файлов.

PD>Ну слава богу, хоть ТурбоПаскаль однопроходной. А VC++ — сколько проходов все же ?

Не интересовался.

PD>>>Откуда такая информация ? Ссылку дай, только не по экзотическим языкам.

AVK>>http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx

PD>Ну что же, если в C# это нужно — на здоровье. В С++ — нет.

Потому что С++ существенно более старый язык.

PD>то да, предописание необходимо

Вот именно. А в Java и C# такой необходимости нет, там forward declaration отсутствует как класс.

PD>Но из этого, в общем, мало что следует.

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

PD>Ты хоть представление имеешь о том, как компиляция в С/C++ идет ?

Павел, если есть желание заняться пенисометрией, то не советую. У меня все равно длиннее. Ты не у меня пробелы в знаниях ищи, а подумай, как это связано с лимитом потребления памяти.

PD>Думаю, это просто означает, что не очень хорошо продуман функционал.

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

PD> Потому что невозможно его использовать целиком одновременно.

Возможно.

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

PD>Да, знаю.

Ну так вот в основном эти пакеты память и жрут.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

F>Здравствуйте, Pavel Dvorkin, Вы писали:

AVK>>>Зато они работают быстрее и качественнее.
PD>>Насчет качественее — не спорю. Насчет быстрее... Давай сравним. ТурбоПаскаль 1.0 на Ямахе с тактовой частотой 2 МГц и памятью в 64К компилировал программу в 1000 строк несколько секунд. Сколько времени надо, чтобы откомпилировать программу размером в 1 млн строк на процессоре в 2 Ггц ? Очевидно, тоже несколько секунд. Давай сюда этот компилятор!
F> Очевидно, что тот компилятор с памятью в 64К может и не скомпилировать 1 млн. строк вообще хотя бы ввиду отсутствия этой самой памяти.

Я не про память , а про время писал. Ускорили процессор в 1000 раз — давайте в 1000 раз большую скорость.

F> О какой-то линейной зависимости можно говорить на совершенно простых языках, и то, я даже не знаю языка который не потребовал бы каких-либо внутренних структур.
F> Да и с оптимизациями в ТурбоПаскале 1.0 было совсем туго.

И в C# не лучше. Оптимизирует потом JIT

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

AVK>Сравнивать надо компиляторы одинаковых языков.

Одинаковых — это как ? Turbo Pascal и Object Pascal — это одинаковые ? Второй сложнее, да, но не в десять раз. А уж совсем одинаковые — где же взять язык, который за 20 лет совсем не менялся ?

PD>>+1 насчет рефакторинга. Интеллисенс там есть, хоть и не такой.

AVK>Вот именно что тоже убогий.

Ну это кому как. Мне достаточно. А еще есть Visual Assist.

PD>>Ну слава богу, хоть ТурбоПаскаль однопроходной. А VC++ — сколько проходов все же ?

AVK>Не интересовался.

Два.

PD>>>>Откуда такая информация ? Ссылку дай, только не по экзотическим языкам.

AVK>>>http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx

PD>>Ну что же, если в C# это нужно — на здоровье. В С++ — нет.

AVK>Потому что С++ существенно более старый язык.

О да. Вот с этим соглашусь.

А что касается C#, то вряд ли он многопроходной. Слишком уж он быстро компилирует, быстрее, чем С++. Ну да, в нем нет оптимизации, так и для С++/Debug ее тоже нет.

PD>>то да, предописание необходимо

AVK>Вот именно. А в Java и C# такой необходимости нет, там forward declaration отсутствует как класс.

Андрей, не наводи тень на плетень!
Структура данных любой програмы — это граф. С циклами в общем случае, то есть к дереву не сводимый. И компилятору надо эти циклы как-то объяснить. Как именно — не так уж важно, но объяснить надо. В одном случае он их берет из предописаний, в другом — иначе. В конце концов за 2 прохода можно собрать все имена и связи.

В том же С вполне можно было бы допустить

struct A {
struct B* ptr;
};

struct B {...};

и без всякого предописания struct B, но это означало бы, что компилятор на первом проходе должен составить таблицу всех имен, а на втором — проанализировать до конца. Авторы С хотели, чтобы можно было обойтись одним проходом, вот и создали предописание как помощь компилятору. Вот и все.

PD>>Но из этого, в общем, мало что следует.

AVK>Из этого следует то, что язык специально заточен под минимальное количество проходов. А минимальное количество проходов нужно как раз чтобы компилятору хватало малого объема памяти.

Так, хоть с тем, что в С++ проходов мало, ты наконец согласился. Прогресс.

Могу лишь повториться — двух проходов хватит всегда. Малый объем памяти тут ни при чем, так как проход — это просмотр исходного текста. Собственно просмотр можно сделать на буфере любого разумного размера, а вот сколько займут эти структуры во внутреннем формате, зависит от программы, и для сложной функции он малым не будет просто потому, что не может быть. И на 64 К откомпилировать программу в тысячи строк просто не удастся, если не делать промежуточных выводов в файл, а это падение скорости.

PD>>Ты хоть представление имеешь о том, как компиляция в С/C++ идет ?

AVK>Павел, если есть желание заняться пенисометрией, то не советую. У меня все равно длиннее. Ты не у меня пробелы в знаниях ищи,

Глупо. Если ты заявил, что для компиляции в С++ нужна какая-то DLL, то не удивляйся, когда получаешь такие разъяснения. Не хочешь их получать — не делай такие заявления, а сначала разберись.

>а подумай, как это связано с лимитом потребления памяти.

Что связано ? DLL ? Никак не связано — я тебе уже объяснил, что она там не используется никак.

P.S. DLL- вообще-то элемент ОС Windows. И к языку С++ отношения не имеют.

PD>>Думаю, это просто означает, что не очень хорошо продуман функционал.

AVK>Нет, это означает что программа не качественна и не полностью удовлетворяет требованиям.

Именно так.

PD>> Потому что невозможно его использовать целиком одновременно.

AVK>Возможно.

Именно так.

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

PD>>Да, знаю.

AVK>Ну так вот в основном эти пакеты память и жрут.

Так вот и надо выяснить, нужны ли они все одновременно.

P.S. Будет время — посмотрю студию с помощью VMMAP и напишу.

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

ВВ>>А для того, что "скомпилировать программу с одной только dll" проблем тоже как-то не видно, достаточно, чтобы для этой DLL импорт-директивы были прописаны именно в том виде, в котором их понимает конкретный компилятор.
PD>Маленькое уточнение. Для VC++ — не импорт-директивы, а библиотека импорта, отдельный файл. Обычно прилагается к DLL, но при необходимости может быть сгенерирован по DLL
PD>http://forum.shelek.ru/index.php/topic,3621.0.html

Если ты про def-файл, то если маразм мне не изменяет, он используется для декорирования имен и можно в принципе без него. Хотя бы через extern C. В любом случае, это нюансы.
"Скомпилировать программу с DLL" можно без проблем. Другой вопрос, что конкретно для С++ это малоприменимо. Ну так для него и под дотнетом это применимо мало.

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

ВВ>Если ты про def-файл, то если маразм мне не изменяет, он используется для декорирования имен и можно в принципе без него.

Я имею в виду, что если есть только DLL без исходников, то можно восстановить .lib.

>Хотя бы через extern C.

Просто extern C не поможет — будет unresolved external.

>В любом случае, это нюансы.

Конечно.

ВВ>"Скомпилировать программу с DLL" можно без проблем.

Поясни.

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

>>Хотя бы через extern C.
PD>Просто extern C не поможет — будет unresolved external.

Ну __declspec dllimport еще добавь

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

ВВ>>"Скомпилировать программу с DLL" можно без проблем.
PD>Поясни.

Вообще Андрей-то рекламирует модный ныне компонентно-ориентированный, так сказать, подход, когда все библиотеки для того же шарпа распространяются в виде DLL. Причем по принципу compile once run "everywhere". Статическая линковка и "файлы в специальном формате" отсутствуют как класс.

Все, что я хотел сказать — подобный подход возможен и для нейтив кода, без проблем. Точно так же как и для 100% managed кода, написанного на C++\CLI с ключиком /pure возможна статическая линковка, а в некоторых случаях и необходима, если ты, скажем, хочешь написать шаблонную библиотеку.

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

AVK>>Зато они работают быстрее и качественнее.
PD>Насчет качественее — не спорю. Насчет быстрее... Давай сравним. ТурбоПаскаль 1.0 на Ямахе с тактовой частотой 2 МГц и памятью в 64К компилировал программу в 1000 строк несколько секунд. Сколько времени надо, чтобы откомпилировать программу размером в 1 млн строк на процессоре в 2 Ггц ? Очевидно, тоже несколько секунд. Давай сюда этот компилятор!

А ничего, что компиляторы поумнее стали? Много дополнительной работы делают. Вон тот же компилятор C# вывод типов делает.

Потом тот же C# на самом деле очень быстро компилирует. Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.

Да и зачем нам турбопаскель на Ямахе-то? Давай с VC сравним

Это к вопросу о "количестве проходов".

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

PD>А что касается C#, то вряд ли он многопроходной. Слишком уж он быстро компилирует, быстрее, чем С++. Ну да, в нем нет оптимизации, так и для С++/Debug ее тоже нет.

Приводили же тебе ссылку на блог Липперта. Ты не веришь Липперту?

Ты запись-то почитай, там подробно описывается, зачем нужны все эти проходы.

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

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

PD>Одинаковых — это как ?

А вот так. Если хочешь сравнивать, нужно брать одинаковый язык.

PD> Turbo Pascal и Object Pascal — это одинаковые ?

Если речь о современном Object Pascal, то нет.

PD> Второй сложнее, да, но не в десять раз.

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

PD> А уж совсем одинаковые — где же взять язык, который за 20 лет совсем не менялся ?

С++

PD>А что касается C#, то вряд ли он многопроходной.

Т.е. Липперт врет? Или ты его не читал?

PD>Структура данных любой програмы — это граф. С циклами в общем случае, то есть к дереву не сводимый. И компилятору надо эти циклы как-то объяснить. Как именно — не так уж ва жно, но объяснить надо. В одном случае он их берет из предописаний, в другом — иначе. В конце концов за 2 прохода можно собрать все имена и связи.

Без forward declaration — нельзя.

PD>Так, хоть с тем, что в С++ проходов мало, ты наконец согласился.

А я никогда этого и не отрицал.

PD>Могу лишь повториться — двух проходов хватит всегда. Малый объем памяти тут ни при чем, так как проход — это просмотр исходного текста.

Если весь код программы в памяти — количество проходов на производительность сильно не влияет. Если же памяти мало, то держать все исходники или полное AST в памяти не получится, значит надо общаться с диском. И вот тут то проходы и становятся очень дорогими.

PD>Глупо.

Именно

PD> Если ты заявил, что для компиляции в С++ нужна какая-то DLL

Я этого не заявлял.

AVK>>Ну так вот в основном эти пакеты память и жрут.

PD>Так вот и надо выяснить, нужны ли они все одновременно.

Нужны.

PD>P.S. Будет время — посмотрю студию с помощью VMMAP и напишу.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

ВВ>Все, что я хотел сказать — подобный подход возможен и для нейтив кода, без проблем.

А я нигде не писал, что он для нейтив кода невозможен. Я писал, что он невозможен конкретно для современных компиляторов С++.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

F>> Очевидно, что тот компилятор с памятью в 64К может и не скомпилировать 1 млн. строк вообще хотя бы ввиду отсутствия этой самой памяти.
PD>Я не про память , а про время писал. Ускорили процессор в 1000 раз — давайте в 1000 раз большую скорость.
1) Тактовая частота процессора — лишь один из показателей, который влияет на производительность системы в целом. А кол-во памяти ты упорно указываешь.
2) Давай вернём уровень оптимизаций на 20 лет назад — будет быстрее компилировать.

F>> Да и с оптимизациями в ТурбоПаскале 1.0 было совсем туго.
PD>И в C# не лучше. Оптимизирует потом JIT
То, пусть немногое, что он может — он оптимизирует, безусловно что-то перекладывая и на плечи JIT.

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

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

>>>Хотя бы через extern C.
PD>>Просто extern C не поможет — будет unresolved external.

ВВ>Ну __declspec dllimport еще добавь

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

Да не поможет же. Хоть extern, хоть __declspec dllimport . Нужна еще .lib — библиотека импорта. Откуда линкеру эту функцию брать-то ? А вот если ее нет, то можно из DLL слепить, через def-файлы.

ВВ>>>"Скомпилировать программу с DLL" можно без проблем.
PD>>Поясни.

ВВ>Вообще Андрей-то рекламирует модный ныне компонентно-ориентированный, так сказать, подход, когда все библиотеки для того же шарпа распространяются в виде DLL. Причем по принципу compile once run "everywhere". Статическая линковка и "файлы в специальном формате" отсутствуют как класс.

А С++ тут при чем ?

ВВ>Все, что я хотел сказать — подобный подход возможен и для нейтив кода, без проблем.

Нет. Для native кода из DLL еще можно вытянут библиотеку импорта. Хедеры не вытянешь, разве что займешься undecorate, но это не всегда возможно.

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

ВВ>>Все, что я хотел сказать — подобный подход возможен и для нейтив кода, без проблем.
AVK>А я нигде не писал, что он для нейтив кода невозможен. Я писал, что он невозможен конкретно для современных компиляторов С++.

Это-то и непонятно. Почему невозможен-то? Dynamic DLL везде поддерживается.

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

ВВ>А ничего, что компиляторы поумнее стали? Много дополнительной работы делают.

Компиляторы дополнительной работы не делают. Они компилируют из исходного текста в объектный (или IL). Плюс оптимизируют, иногда.

А вот IDE стали умнее намного, да. Плюс отладчики и т.д.

>Вон тот же компилятор C# вывод типов делает.

Вообще-то это делает не компилятор ИМХО. Если это в него и включено, то к собственно компиляции отношения не имеет.

ВВ>Потом тот же C# на самом деле очень быстро компилирует.

Потому что не оптимизирует. С++ тоже быстро в Debug компилирует, а в Release — не очень. Оптимизация.

Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.

А Андрей утверждает, что он многопроходной

ВВ>Да и зачем нам турбопаскель на Ямахе-то? Давай с VC сравним

Это к вопросу о "количестве проходов".

Что с VC сравним и зачем ? Все, что я хотел сказать своим сравнением с TP — это то, что тактовая увеличилась в 1000 раз, память — в десятки тысяч, а вот скорость не то, чтобы очень.

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

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

Может, что-то и делает, но меня тут 100 раз убеждали, что делает все же JIT

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

PD>> А уж совсем одинаковые — где же взять язык, который за 20 лет совсем не менялся ?

AVK>С++

Компиляторы C++ даже 10 летней давности сильно примитивнее современных. А уж 20 лет назад
это был совсем другой язык.

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

ВВ>>Вон тот же компилятор C# вывод типов делает.
PD>Вообще-то это делает не компилятор ИМХО. Если это в него и включено, то к собственно компиляции отношения не имеет.

Боже мой, а кто же это делает? Неужели IDE?

И очень интересно, каким образом это может не иметь отношения к компиляции.

ВВ>>Потом тот же C# на самом деле очень быстро компилирует.
PD>Потому что не оптимизирует. С++ тоже быстро в Debug компилирует, а в Release — не очень. Оптимизация.

А ты возьми да сравни компиляцию в дебуг и там и там.
Как будто блин речь о том, что в режиме full как-то там optimization, когда компиляция сначала вообще идет в промежуточный формат, VC тормозит, а все остальное время летает.

PD>Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.
PD>А Андрей утверждает, что он многопроходной

Это утверждает не Андрей, а Эрик Липперт

И да, действительно многопроходной. Ну значит, видимо, не в проходах проблема.

ВВ>>Да и зачем нам турбопаскель на Ямахе-то? Давай с VC сравним

Это к вопросу о "количестве проходов".
PD>Что с VC сравним и зачем ? Все, что я хотел сказать своим сравнением с TP — это то, что тактовая увеличилась в 1000 раз, память — в десятки тысяч, а вот скорость не то, чтобы очень.

А сложность языков во сколько раз увеличилась?

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

ВВ>>И оптимизацию, какую-никакую, но компилятор Шарпа все же делает. Достаточно сравнить IL в релизе и дебаге.
PD>Может, что-то и делает, но меня тут 100 раз убеждали, что делает все же JIT

Вот если тебе действительно интересно — кто мешает взять и проверить?
Оптимизацию делает и компилятор Шарпа (при компиляции в промежуточный байт-код) *и* Джит. Некоторые вещи, как например инлайнинг, делает только Джит.

Это совсем не мешает компилятору Шарпа генерить для релиза зачастую совершенно другой код, чем для дебага.

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

PD>>> А уж совсем одинаковые — где же взять язык, который за 20 лет совсем не менялся ?
AVK>>С++
FR>Компиляторы C++ даже 10 летней давности сильно примитивнее современных. А уж 20 лет назад
FR>это был совсем другой язык.

Одно дело язык, другое дело — компилятор. Хотя речь-то на самом деле о компиляторах, а не о языках.

У С, кстати, как я понимаю, последний стандарт С99, последняя версия стандарта С++ тоже где-то в этом районе была утверждена. Т.е. ей порядка 10 лет где-то (+/-).

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

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

PD>>>>>Откуда такая информация ? Ссылку дай, только не по экзотическим языкам.

AVK>>>>http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx

PD>>>Ну что же, если в C# это нужно — на здоровье. В С++ — нет.

class Foo
{
public:
    void foo()
    {
        bar();
    }

    void bar()
    {
    }
};

Вопрос на засыпку, как однопроходный компилятор должен компилировать метод Foo::foo? Ну и про 2-х фазный поиск имён, опять же, не забываем. Так, что количество проходов необходимых для компиляции обоих языков одинаковое.

AVK>>Потому что С++ существенно более старый язык.

PD>О да. Вот с этим соглашусь.

PD>А что касается C#, то вряд ли он многопроходной. Слишком уж он быстро компилирует, быстрее, чем С++. Ну да, в нем нет оптимизации, так и для С++/Debug ее тоже нет.

Да, наверно, один из авторов компилятора C#, наглым образом, наврал про то, как работает этот компилятор.

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

AVK>А вот так. Если хочешь сравнивать, нужно брать одинаковый язык.

Ну и пожалуйста. Берем C из VC и C из ТурбоС 198x года. Тактовая IBM PC XT 4.77 MHz, а сейчас в 800 раз больше (это даже не учитывая многоядерности, кэша процессора и т.д.) Язык практически без изменений. Винчестер намного быстрее. А скорость в 1000 раз отнюдь не возросла.

PD>> Второй сложнее, да, но не в десять раз.

AVK>Твоя экспертная оценка сложности компиляции тех или иных изменений, уж извини, не вызывает доверия.

Да мне дела нет, вызывает или нет. Вот тебе пример неизменившегося языка (сам просил), вот тебе и результаты. Моя экспертная оценка тут вообще ни при чем.

PD>> А уж совсем одинаковые — где же взять язык, который за 20 лет совсем не менялся ?

AVK>С++

С++ менялся, и сейчас меняется. Вот С — не менялся.

PD>>Структура данных любой програмы — это граф. С циклами в общем случае, то есть к дереву не сводимый. И компилятору надо эти циклы как-то объяснить. Как именно — не так уж ва жно, но объяснить надо. В одном случае он их берет из предописаний, в другом — иначе. В конце концов за 2 прохода можно собрать все имена и связи.

AVK>Без forward declaration — нельзя.

Да ну ?

struct A {
struct B* ptr;
};
struct B { int i;};

Нет forward declarations ? Нет.

Проходим по тексту. Заносим все имена в контейнер. Обнаружив неописанное имя (B) делаем пометку, что неописано.
Проходим второй раз. Разрешает все неописанные имена по контейнеру.

Вот и все.

PD>>Так, хоть с тем, что в С++ проходов мало, ты наконец согласился.

AVK>А я никогда этого и не отрицал.

Слава богу

PD>>Могу лишь повториться — двух проходов хватит всегда. Малый объем памяти тут ни при чем, так как проход — это просмотр исходного текста.

AVK>Если весь код программы в памяти — количество проходов на производительность сильно не влияет. Если же памяти мало, то держать все исходники или полное AST в памяти не получится, значит надо общаться с диском. И вот тут то проходы и становятся очень дорогими.

Открой для себя memory-mapped файлы. Они и память, они и диск. И ненужные страницы в ОП отсутствуют, а понадобятся — подкаччиваются.

Кстати, то, что ты называешь памятью — это либо ОП, либо своп. Тот же диск, вообще говоря. А резидентную память только в ядре дают, а 3 кольцу — через AWE разве, ну там еще и VirtualLock, но это не пройдет — надо включать привилегию Lock Pages, а ее не включают для компиляции.

PD>> Если ты заявил, что для компиляции в С++ нужна какая-то DLL

AVK>Я этого не заявлял.

А это что ?

AVK>Т.е. компилятору С достаточно одной только dll, чтобы скомпилировать программу с ее использованием?

http://rsdn.ru/forum/philosophy/3753722.1.aspx

С или С++ — никакой разницы в этом плане нет.

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

F>Здравствуйте, Pavel Dvorkin, Вы писали:

F> 1) Тактовая частота процессора — лишь один из показателей, который влияет на производительность системы в целом.

Да. Еще и кэш памяти, еще и скорость винта и т.д. И все это возросло на порядки (а кэш — в бесконечность раз, ибо его не было)

>А кол-во памяти ты упорно указываешь.

Зря указал.

F> 2) Давай вернём уровень оптимизаций на 20 лет назад — будет быстрее компилировать.

А в Debug ? Нет там оптимизации — запрещена опциями.

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

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

ВВ>>>Вон тот же компилятор C# вывод типов делает.
PD>>Вообще-то это делает не компилятор ИМХО. Если это в него и включено, то к собственно компиляции отношения не имеет.

ВВ>Боже мой, а кто же это делает? Неужели IDE?

Откуда мне знать ? Спроси Андрея. Я лишь одно говорю — к собственно компиляции это отношения не имеет.

ВВ>И очень интересно, каким образом это может не иметь отношения к компиляции.

ВВ>>>Потом тот же C# на самом деле очень быстро компилирует.
PD>>Потому что не оптимизирует. С++ тоже быстро в Debug компилирует, а в Release — не очень. Оптимизация.

ВВ>А ты возьми да сравни компиляцию в дебуг и там и там.

C# быстрее.

ВВ>Как будто блин речь о том, что в режиме full как-то там optimization, когда компиляция сначала вообще идет в промежуточный формат, VC тормозит, а все остальное время летает.

Не летает, увы.

PD>>Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.
PD>>А Андрей утверждает, что он многопроходной

ВВ>Это утверждает не Андрей, а Эрик Липперт

ВВ>И да, действительно многопроходной. Ну значит, видимо, не в проходах проблема.

Или в определении того, что такое проход

ВВ>>>Да и зачем нам турбопаскель на Ямахе-то? Давай с VC сравним

Это к вопросу о "количестве проходов".
PD>>Что с VC сравним и зачем ? Все, что я хотел сказать своим сравнением с TP — это то, что тактовая увеличилась в 1000 раз, память — в десятки тысяч, а вот скорость не то, чтобы очень.

ВВ>А сложность языков во сколько раз увеличилась?

Языка С — в 1.0000 раз. А компилятор C VC по сравнению с ТурбоС 199? года быстрее в 1000 раз не стал.

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

C>Здравствуйте, Pavel Dvorkin, Вы писали:

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

PD>>>>>>Откуда такая информация ? Ссылку дай, только не по экзотическим языкам.

AVK>>>>>http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx

PD>>>>Ну что же, если в C# это нужно — на здоровье. В С++ — нет.

C>

C>class Foo
C>{
C>public:
C>    void foo()
C>    {
C>        bar();
C>    }

C>    void bar()
C>    {
C>    }
C>};
C>

C>Вопрос на засыпку, как однопроходный компилятор должен компилировать метод Foo::foo? Ну и про 2-х фазный поиск имён, опять же, не забываем. Так, что количество проходов необходимых для компиляции обоих языков одинаковое.

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

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

ВВ>Одно дело язык, другое дело — компилятор. Хотя речь-то на самом деле о компиляторах, а не о языках.

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

ВВ>У С, кстати, как я понимаю, последний стандарт С99, последняя версия стандарта С++ тоже где-то в этом районе была утверждена. Т.е. ей порядка 10 лет где-то (+/-).

У C++ — 98 плюс косметические улучшения в 2003.
Но проблема в том что более — менее нормально стандарт начал поддерживаться как раз наверно с 2003 — 2004 года, плюс тогда же появился и начал массово использоваться современный стиль программирования.

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

Pzz>"Сложение" массивов требует аллокации памяти и копирования. И та и другая операции при большом объеме достаточно дорогие. "Сложение" списков требует лишь перенастройки пары указателей.

Ну вот, хоть кто-то напомнил о чем топик

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

PD>>>>>>>Откуда такая информация ? Ссылку дай, только не по экзотическим языкам.

AVK>>>>>>http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx

PD>>>>>Ну что же, если в C# это нужно — на здоровье. В С++ — нет.

PD>Почитай внимательно мои постинги, я же ясно говорю, что компилятор должен быть двухпроходным для решения этих проблем. Но для их решения больше 2 проходов не требуется.

Видимо, я как-то не так понял выделенную фразу.

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

ВВ>>Просто, честно говоря, при желании можно легко сымитировать связный список на динамическом массиве + энумератор, при этом мы получим кучу бенефитов, например, нам всегда будет известна длина и сложение списков будет стоить дешевле.
Pzz>"Сложение" массивов требует аллокации памяти и копирования. И та и другая операции при большом объеме достаточно дорогие. "Сложение" списков требует лишь перенастройки пары указателей.

В теории — да. А на практике ведь нужно как-то бороться с циклическими зависимостями?

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

Pzz>>"Сложение" массивов требует аллокации памяти и копирования. И та и другая операции при большом объеме достаточно дорогие. "Сложение" списков требует лишь перенастройки пары указателей.

ВВ>В теории — да. А на практике ведь нужно как-то бороться с циклическими зависимостями?

Э-эээ. Ну вы можете иметь быстрые списки, и сами следить за отсутствием циклических зависимостей~~, я так и делаю и до сих пор не умер~~. А можете иметь безопасные списки, которые будут это делать за вас, за что придется заплатить определенную цену. А можете иметь быстрые списки в релизе и безопасные в дебаге~~, что я лично считаю полным идиотизмом, но никому не скажу~~

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

PD>Ну и пожалуйста. Берем C из VC и C из ТурбоС 198x года. Тактовая IBM PC XT 4.77 MHz, а сейчас в 800 раз больше (это даже не учитывая многоядерности, кэша процессора и т.д.) Язык практически без изменений. Винчестер намного быстрее. А скорость в 1000 раз отнюдь не возросла.

Цифры в студию. На слово я тебе не верю.

AVK>>Без forward declaration — нельзя.

PD>Да ну ?

Возвращаемся к старому вопросу — всегда ли в С++ можно обойтись без forward declaration?

PD>Открой для себя memory-mapped файлы. Они и память, они и диск. И ненужные страницы в ОП отсутствуют, а понадобятся — подкаччиваются.

При чем тут я? Я тебе объясняю, зачем в свое время боролись за количество проходов.

AVK>>Я этого не заявлял.
PD>А это что ?
AVK>>Т.е. компилятору С достаточно одной только dll, чтобы скомпилировать программу с ее использованием?
PD>http://rsdn.ru/forum/philosophy/3753722.1.aspx

Знаки препинания видишь? Это был вопрос.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

ВВ>>Потом тот же C# на самом деле очень быстро компилирует.

PD>Потому что не оптимизирует. С++ тоже быстро в Debug компилирует, а в Release — не очень. Оптимизация.

PD>Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.

PD>А Андрей утверждает, что он многопроходной

Это не я утверждаю, это Липперт утверждает. Прочти наконец статью, ссылку на которую ты сам просил.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

PD>Откуда мне знать ? Спроси Андрея. Я лишь одно говорю — к собственно компиляции это отношения не имеет.

Давай начнем сначала. Что такое, по твоему, вывод типов?

ВВ>>И да, действительно многопроходной. Ну значит, видимо, не в проходах проблема.

PD>Или в определении того, что такое проход

А что, у тебя есть какое то непонимание того, что такое проход?
http://en.wikipedia.org/wiki/Multi-pass_compiler

A multi-pass compiler is a type of compiler that processes the source code or abstract syntax tree of a program several times. This is in contrast to a one-pass compiler, which traverses the program only once. Each pass takes the result of the previous pass as the input, and creates an intermediate output. In this way, the (intermediate) code is improved pass by pass, until the final pass emits the final code.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

ВВ>Это-то и непонятно. Почему невозможен-то?

Возьми любой компилятор С++ на выбор и попробуй использовать dll без дополнительных хидеров и либ, причем контроль типов, естественно, должен остаться.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

AVK>Возьми любой компилятор С++ на выбор и попробуй использовать dll без дополнительных хидеров и либ, причем контроль типов, естественно, должен остаться.

Т.е. вся проблема в том, что в случае .NET Assembly манифест встроен в эту самую assembly, а тут он предоставляется отдельно?
Как-то я тут не вижу кардинальной разницы.

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

PD>Потому что не оптимизирует. С++ тоже быстро в Debug компилирует, а в Release — не очень. Оптимизация.

PD>Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.

Наверняка мелочевка. Один рабочий проект у меня собирается где то почти за час на 2гц.

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

PD>>Потому что не оптимизирует. С++ тоже быстро в Debug компилирует, а в Release — не очень. Оптимизация.
PD>>Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.
I>Наверняка мелочевка. Один рабочий проект у меня собирается где то почти за час на 2гц.

Самый большой домашний проект — 3 тыс. файлов где-то, собирается за несколько секунд. У вас видимо (если речь действительно про шарп) во время сборки происходит много чего еще помимо собственно компиляции.

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

ВВ>Т.е. вся проблема в том, что в случае .NET Assembly манифест встроен в эту самую assembly, а тут он предоставляется отдельно?

Проблемы никакой нет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>

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

ВВ>>Боже мой, а кто же это делает? Неужели IDE?

PD>Откуда мне знать ? Спроси Андрея. Я лишь одно говорю — к собственно компиляции это отношения не имеет.
ВВ>>И очень интересно, каким образом это может не иметь отношения к компиляции.
PD>Откуда мне знать ? Спроси Андрея. Я лишь одно говорю — к собственно компиляции это отношения не имеет.

У меня есть серьезное подозрение, что ты не до конца понимаешь, о чем речь. Погугли на type inference.

ВВ>>Это утверждает не Андрей, а Эрик Липперт

ВВ>>И да, действительно многопроходной. Ну значит, видимо, не в проходах проблема.
PD>Или в определении того, что такое проход

Дай свое определение, вот и посмотрим об одном мы говорим или о разном.

ВВ>>А сложность языков во сколько раз увеличилась?
PD>Языка С — в 1.0000 раз. А компилятор C VC по сравнению с ТурбоС 199? года быстрее в 1000 раз не стал.

ОК, "сложность языков" некорректная формулировка. Переформулируем.
А сложность компиляторов во сколько раз увеличилась?

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

PD>>>Потому что не оптимизирует. С++ тоже быстро в Debug компилирует, а в Release — не очень. Оптимизация.
PD>>>Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.
I>>Наверняка мелочевка. Один рабочий проект у меня собирается где то почти за час на 2гц.

ВВ>Самый большой домашний проект — 3 тыс. файлов где-то, собирается за несколько секунд. У вас видимо (если речь действительно про шарп) во время сборки происходит много чего еще помимо собственно компиляции.

Так речь про С++ или где ? Не пойму, как можно быстро компилить проект с шаблонами.

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

I>Так речь про С++ или где ? Не пойму, как можно быстро компилить проект с шаблонами.

Смотри D, там шаблоны еще наваристей чем в C++ а компилируется на порядок шустрее.

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

F>> 1) Тактовая частота процессора — лишь один из показателей, который влияет на производительность системы в целом.
PD>Да. Еще и кэш памяти, еще и скорость винта и т.д. И все это возросло на порядки (а кэш — в бесконечность раз, ибо его не было)
Именно. Но ты при этом считаешь, что мы должны получить 1000x, тогда как в таких задачах на верхнюю планку будет влиять скорость доступа к памяти, а она у нас пока всё ещё значительно ниже. Кеш безусловно помогает, но чем больше размер исходных файлов -> размер внутренних структур -> тем мы больше будем иметь промахов.

F>> 2) Давай вернём уровень оптимизаций на 20 лет назад — будет быстрее компилировать.

PD>А в Debug ? Нет там оптимизации — запрещена опциями.
Опции дело такое — constant folding, например, афаик — совсем не отключается.
Диагностика ошибок всё таки стала лучше (применительно к C++), а значит и анализа — больше.
TP/Delphi и прочие — и сейчас быстро компилируются, что в релизе, что в дебаге. На мелких проектах я лично успеваю у коллег только моргнуть. TP5.5 вот ощутимее дольше компилировал, по сравнению с 1.0 — но откомпиленные им программы просто летали, опять же по сравнению с 1.0...
C/C++ — никогда быстро не компилировался и врядли будет, пока есть километры хидеров.
Собственно о чем спорим?

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

ВВ>>Самый большой домашний проект — 3 тыс. файлов где-то, собирается за несколько секунд. У вас видимо (если речь действительно про шарп) во время сборки происходит много чего еще помимо собственно компиляции.
I>Так речь про С++ или где ? Не пойму, как можно быстро компилить проект с шаблонами.

Я писал про скорость компиляции кода Шарпом. А то, что плюсы час проект компилируют — это в порядке вещей. Ну так есть pch однако. В шарпах никакой инкрементальной компиляции в принципе. Поэтому, извините, но час компиляции на Шарпе — это просто трагедия вселенского масштаба.

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

ВВ>Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.
PD>А Андрей утверждает, что он многопроходной

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

А ты зачем-то упираешься, что раньше компилятору хватало 64К памяти и отказываешься верить, что большие расходы памяти чем-то оправданы.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

PD>>>Я не в теме, да, и не все так просто, но ведь 20-30 лет назад было не проще
AVK>>Было. 20 лет назад просто не было аналогичных по функционалу IDE.

PD>Разумеется. Но переменные (имена) были. Классы были. Компиляция была. И все это в 1 М укладывалось. Что-то я не верю, что понадобилось вдруг в 100 раз больше.

Странный подход. Для того, чтобы понять, зачем потребовалось больше ресурсов надо сравнить, что изменилось, а не что осталось прежним.

Иначе можно сравнить, например телегу с автомобилем. Вот телеги, 1000 лет назад — колеса были? Были! Сиденья были? Были! Грузы возили? Возили! Так почему у современных автомобилей так жутко цена выросла, да еще стали бензин зачем-то тратить...

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

ВВ>>>Самый большой домашний проект — 3 тыс. файлов где-то, собирается за несколько секунд. У вас видимо (если речь действительно про шарп) во время сборки происходит много чего еще помимо собственно компиляции.
I>>Так речь про С++ или где ? Не пойму, как можно быстро компилить проект с шаблонами.

ВВ>Я писал про скорость компиляции кода Шарпом. А то, что плюсы час проект компилируют — это в порядке вещей. Ну так есть pch однако. В шарпах никакой инкрементальной компиляции в принципе. Поэтому, извините, но час компиляции на Шарпе — это просто трагедия вселенского масштаба.

C C# все в порядке, час это С++

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

I>Так речь про С++ или где ? Не пойму, как можно быстро компилить проект с шаблонами.

Да тут опять фиг поймешь про что речь.

Скорее про то, что Павел утвержадет, что С++ с выключенной оптимизацией компилирует так же быстро как шарп. Типа все тормоза компиляции С++ чисто в том, что он сильно оптимизирует, а дизайн языка и организации исходных файлов в нем значения не имеет — все эти имена из всех хидеров же можно за несколько секунд извлечь при парсинге каждого файла, причем на 4хмегагерцовой машине с 512К памяти...

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

AVK>>Возьми любой компилятор С++ на выбор и попробуй использовать dll без дополнительных хидеров и либ, причем контроль типов, естественно, должен остаться.
ВВ>Т.е. вся проблема в том, что в случае .NET Assembly манифест встроен в эту самую assembly, а тут он предоставляется отдельно?
ВВ>Как-то я тут не вижу кардинальной разницы.

Поиграем в Капитана Глубокая Память.

Напоминаю, что весь сыр бор разгорелся из-за того, что Павел отказывается поверить, что больший расход ресорсов современными IDE оправдан. Типа и на 64К и 1.2Mhz процессоре ведь как-то компилировали.

В частности, про длл разговор зашел в контексте фразы, что на 64К и 1.2Mhz процессоре приходилось очень жестко экономить ресурсы и ценой этого уменьшать возможности языка. Сокращать число проходов, уменьшать выполняемые проверки и прочее. И только в частности пример — что dll получались такие, что их нельзя сразу взять и подключить к другому проекту.
Тут действительно нет принципиальной проблемы, но разработчику удобнее, когда манифест встроен в сборку. Раньше же это было неоправданным расходом ресурсов, теперь — оправданным. И это только один мелкий камушек из горы различий между средствами разработки сейчас и 30 лет назад. Нет смысла его так пристально разглядывать.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

	От:	Воронков Василий
	Дата:	24.03.10 12:47
	Оценка:

	От:	ankorol
	Дата:	24.03.10 13:03
	Оценка:

	От:	Mr.Cat
	Дата:	24.03.10 13:06
	Оценка:

От:	nikov	http://www.linkedin.com/in/nikov
Дата:	24.03.10 13:06
Оценка:	+3

	От:	Воронков Василий
	Дата:	24.03.10 13:10
	Оценка:

	От:	Anton V. Kolotaev
	Дата:	24.03.10 13:16
	Оценка:

	От:	Кэр
	Дата:	24.03.10 14:02
	Оценка:	60 (9) +9

От:	VladD2	www.nemerle.org
Дата:	24.03.10 21:18
Оценка:

От:	Mystic	http://mystic2000.newmail.ru
Дата:	25.03.10 12:28
Оценка:	8 (1)

От:	samius	http://sams-tricks.blogspot.com
Дата:	25.03.10 13:39
Оценка:

	От:	Pavel Dvorkin
	Дата:	26.03.10 04:29
	Оценка:	+1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	26.03.10 16:08
Оценка:

От:	Pzz	https://github.com/alexpevzner
Дата:	30.03.10 12:46
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	30.03.10 13:20
Оценка: