Высокий/низкий уровень, ручное/автоматическое управление

← →
DiamondShark © (2010-11-09 21:08) [0]

Чтоб не холиварить в тематической, перенесу из
http://delphimaster.net/view/2-1289307984/

DiamondShark © (09.11.10 19:47) [12]

В третьем тысячелетии не имеют права на существование языки без автоматического управления памятью.
----------------------------------------------------------------------
И. Павел © (09.11.10 20:22) [13]

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

Даже assembler?
Или все же только на очень высоком уровне, и если не требуется быстрых вычислений?
----------------------------------------------------------------------
DiamondShark © (09.11.10 20:58) [15]
> И. Павел © (09.11.10 20:22) [13]
> Даже assembler?

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

> Или все же только на очень высоком уровне

Человек всегда мыслит только на высоком уровне.

Низкоуровневые языки не для крутости, а от бедности. Когда в 50-х годах прошлого века машинное время было дороже зарплаты программиста, а 100К слов было объёмом памяти суперкомпьютера -- низкий уровень был оправдан.

> и если не требуется быстрых вычислений?

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

← →
Dimka Maslov © (2010-11-09 21:20) [1]

> Эффективные алгоритмы человеку легче придумывать на высоком
> уровне

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

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

Берём MSVS и пишем динамическую библиотеку, которую компилируем в режиме сверхглубокой оптимизации. Потом дизассеблируем. И видим что? Офигенный по размеру код инициализации при входе в каждую функцию. При большом количестве вызовов функции избавление от этих лишних операций даёт существеннейшую выгоду в скорости работы.

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

← →
TUser © (2010-11-09 21:42) [2]

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

переход на асм, наверное, может ускорить работу на 2% или на 10%, но смена алгоритма или покупка нового железа легко дадут больше

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

конечно, это мир, каким он выглядит с моей маленькой колокольни

← →
Mystic © (2010-11-09 22:08) [3]

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

PostMessage(hSomeWnd, WM_DO_SOMETHING, Integer(TObject.Create()), 0);

← →
_Юрий (2010-11-09 22:08) [4]

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

← →
crux (2010-11-09 22:32) [5]

Сразу видно, что люди не знакомы с мощью и мультипарадигменностью C++. Тут вам и смартпоинтеры разнообразные, и Boehm-Demers-Weiser коллектор и ручное управление памятью, что конечно же говорит о том, что С++ и третье тысячелетие переживет.

← →
jack128_ (2010-11-09 22:38) [6]

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

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

← →
TUser © (2010-11-09 22:51) [7]

> алгоритм в 5 строчек на одном языке, на другом может занять тысячу строк

Я о скорости работы говорил.

← →
Kerk © (2010-11-09 22:58) [8]

> crux (09.11.10 22:32) [5]

Все-таки сишники часто крайне ограниченные люди. Удивительно даже.

← →
Игорь Шевченко © (2010-11-09 23:03) [9]

Между алгоритмом и конкретной его реализацией обычно находится пропасть. Разного размера.
Например, реализация алгоритма анализа текстового файла начинается с загрузки файла в невидимый компонент TMemo, ну а дальше Memo.Lines[I]...

← →
Дмитрий Белькевич (2010-11-09 23:03) [10]

Когда машина научится автоматом превращать вот это:

for i := 0 to BuffHigh do Img.FBuff8[i] := MinMax(0, 255, TempInt - (ShiftMask.FBuff8[i] - ImageSlice.FBuff8[i]) * TempDbl2);

Во что-то такое:

asm pushad mov eax, TempInt movd mm0, eax punpcklwd mm0, mm0 punpcklwd mm0, mm0 mov eax, TempDbl2 movd mm1, eax punpcklwd mm1, mm1 punpcklwd mm1, mm1 mov ecx, BuffHigh and ecx, $fffffffC mov esi, p1 mov esi, [esi] mov edi, p2 mov edi, [edi] mov ebp, p3 mov ebp, [ebp] pxor mm4, mm4 @@cycle: movd mm3, [ebp + ecx] movd mm2, [esi + ecx] punpcklbw mm2, mm4 punpcklbw mm3, mm4 psubw mm2, mm3 pmullw mm2, mm1 movq mm3, mm0 psubw mm3, mm2 packuswb mm3, mm3 movd [edi + ecx], mm3 sub ecx, 4 jnz @@cycle emms popad end;

Тогда я скажу, что ассемблер не нужен. А раньше - увы...

p.s. оно там чуть-чуть (на BuffHigh mod 4) недосчитывается, знаю.

← →
Юрий Зотов © (2010-11-09 23:07) [11]

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

И это высказывание априори ошибочно в силу своей категоричности.

← →
crux (2010-11-09 23:17) [12]

Kerk © (09.11.10 22:58) [8]

Таково обыкновенно мнение паскалистов, всей силы C++ не ведающих, ибо коли ведали бы славу Его и благодать, поклонялся бы оракулам Дельфийским да Оберонам эльфийским? [Ст. АРМ 54:12]

Юрий Зотов © (09.11.10 23:07) [11]

Вот же воистину просветленный человек.

← →
Kerk © (2010-11-09 23:36) [13]

> crux (09.11.10 23:17) [12]

Начни с осознания того, что эта ветка вообще не про какой-то конкретный язык программирования.

← →
crux (2010-11-09 23:50) [14]

Kerk © (09.11.10 23:36) [13]

Ну так еще не вечер, всегда можем сделать.

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

А что до третьего тысячелетия, то откуда мы знаем, что тогда будет? Соханится ли гонка Потребности ПО/Возможности аппаратного обеспечения? Потребности программного обеспечения бесконечно велики, а возможности аппаратного обеспечения априори конечны, поэтому потребность в оптимизации никогда не исчезнет? Выглядит довольно правдоподобным утверждением, если заходить издалека. Доказательство? Опровержение конкретным примером? Кто возьмется?

← →
Kerk © (2010-11-09 23:54) [15]

Вообще, я не знаю, как там будет в третьем тысячелетии, но в ближайшие 10-15 лет назревает ренессанс функциональных языков. Мне так кажется, по крайней мере. А их без сборщика мусора сложно себе представить.

← →
Германн © (2010-11-09 23:57) [16]

> А их без сборщика мусора сложно себе представить.

Равно как и без "дворников". :)

← →
crux (2010-11-10 00:00) [17]

Kerk © (09.11.10 23:54) [15]

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

← →
Игорь Шевченко © (2010-11-10 00:22) [18]

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

почему "будет" ?

← →
Kerk © (2010-11-10 00:24) [19]

Ну оно только началось и будет довольно длинным :)

← →
Германн © (2010-11-10 01:10) [20]

> Ну оно только началось и будет довольно длинным

А нам постоянно медиа твердит о скором конце света по множеству предсказаний.

← →
RWolf © (2010-11-10 02:06) [21]

> Дмитрий Белькевич (09.11.10 23:03) [10]

а так ли уж сильно эта вставка ускоряет алгоритм? всё равно узким местом остаётся чтение/запись в память.

← →
И. Павел © (2010-11-10 08:21) [22]

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

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

Да и автоматическая сборка мусора - не такая уж и сверхполезная штука, чтобы считать ее основным достижением 3 тысячелетия. Опять же, ИМХО, она сделана от бедности. Например, в распоряжении JAVA программы на машине клиента не много ресурсов, и за ними нужно очень тщательно следить.

← →
oxffff © (2010-11-10 08:33) [23]

Ничего не понял.

← →
И. Павел © (2010-11-10 08:37) [24]

> Ничего не понял.

Я про то, что последнее время очень много посетителей форума пытаются убедить других посетителей в том, что Delphi не имеет права на существование (теперь заявляют об этом в открытую). И заявления такие делают не гуру Delphi. Вот если Анатолий Подгорецкий скажет, что с дельфи пора завязывать, я обеспокоюсь :)

← →
oxffff © (2010-11-10 08:43) [25]

Было бы здорово, если бы управление памятью осуществлялось гибридным способом. То есть как я себе это представляю?
Например такая реализация.

Есть два 2 кучи управляемая и не управляемая.
Текущий деструктор или финализатор управляемой сущности так проходит по корням приложения и далее рекурсивно и смотрит какие объекты достижимы по корням. Деструктор/Финализатор смотрит что финализируется по ссылке и делает финализация+деаллокация либо финализация.

Можно оптимизировать разрешив на уровне языка префиксы к корням.
То есть

a:Tobject (принимает только неуправляемые потомки Tobject)
b:managed Tobject
c:uni Tobject ()

Если
a:=a;
a:=b; ошибка. managed and unmanaged ref"s are incompatible
с:=a;

Run time проверки в случае

a:=c;
b:=c;

IMHO.

← →
oxffff © (2010-11-10 08:44) [26]

> И. Павел © (10.11.10 08:37) [24]

Я не понял о чем это ветка. Обо всем и не о чем. :)

← →
oxffff © (2010-11-10 08:46) [27]

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

← →
Думкин © (2010-11-10 08:47) [28]

> про то, что последнее время

мерзко хихикает.

В будующем 99%% программистов не будет волновать реализация вообще.
Язык будет описательным.
А как это будет реализовано конкретно - всем будет плевать.
И только 1% Гуру будут знать как и что и поддерживать все это дело.

недавно слушал передачу про наиболее перспективные профессии будующего.
Не услышал "программист"
Какие-то, менеджеры виртуальных пространств - есть. А программиста - нет!
Придурки, кто ж вам будет эти пространства делать и инструменты для менеджерения этих пространств.
А если кто захочет немного другого пространства? Менеджер его сделает, что -ли..
А мобилки умные, стиралки и проч. и проч.
(умный дом, кстати, опять рекламировали по спаму. Это типа с шифоньером Шопенгауэра обсудить, с холодильником в шахматы сыграть?! (знаю-знаю. шучу))

← →
Дмитрий Белькевич (2010-11-10 09:03) [30]

> а так ли уж сильно эта вставка ускоряет алгоритм? всё равно
> узким местом остаётся чтение/запись в память.

Сильно.

← →
Дмитрий Белькевич (2010-11-10 09:05) [31]

> В будующем 99%% программистов не будет волновать реализация
> вообще.

Не будет. Как только будет создан ИИ, он сразу же захватит весь мир. Мы все умрём - нас уже ничего не будет волновать.

> Не будет. Как только будет создан ИИ,

не стоит утрировать.
Когда ты пишешь from T1 join T2
тебя ж не волнует как там конкретно находится соответствие.
Или применяются ли хеши и какой именно метод сортировки order by
а далее более

надо только абстрагироваться :)
Первым пароходам тоже поначалу парус ставили. Ибо как же так, корабль и без паруса?!

> В будующем 99%% программистов не будет волновать реализация вообще

Она и сейчас 99% не волнует. В скриптовых языках и в некоторых компилируемых реализация сокрыта (как устроены хэши в перле или ArrayList в джаве?). Там где не сокрыта - тоже не всякий программист ("программист"?) Делфи ответиит на воросы типа - почему надо вызывать Free, а не Destroy. Хотя исходники открыты и книжки есть.

← →
Дмитрий Белькевич (2010-11-10 09:25) [34]

> надо только абстрагироваться :)

Угу, только потом начинаются такие запросы, что база данных рушится, а у программеров круглые глаза: "оно же компилится"...
И выполняется потом по полчаса на запрос.

← →
Дмитрий Белькевич (2010-11-10 09:29) [35]

> Низкоуровневые языки не для крутости, а от бедности. Когда
> в 50-х годах прошлого века машинное время было дороже зарплаты
> программиста, а 100К слов было объёмом памяти суперкомпьютера
> -- низкий уровень был оправдан.

Если что-то не получается, не трать зря силы, возьми кувалду побольше. (с) Мерфи.

← →
Дмитрий Белькевич (2010-11-10 09:32) [36]

> тебя ж не волнует

Меня - волнует, если что.

TUser © (10.11.10 09:21) [33]
Дмитрий Белькевич (10.11.10 09:25) [34]

значит, уголь кончился, на парусе идем и машина теперь только мешает :)
А сделают так, что угля будет достаточно всегда - парус будет не нужен.

> только потом начинаются такие запросы

вот. А если оптимизатор (подпиленный Гуру, на мегагигатерагерцном/байтном железе ) поймет, что надо от него,
сам, (стандарт Sql 2135года:) ) правильно построит запрос и в течении всего время эксплуатации на основе статистики наиболее правильно сам индексы наставит - база данных будет жива

> Меня - волнует, если что.

и это хорошо! И необходимо.
Но пока.. и в ближайшие лет 100 тоже, имхо

> Kerk (10.11.2010 00:24:19) [19]

Апологеты говорят будет коротким.

> И. Павел (10.11.2010 08:37:24) [24]

А ты взятку дай, что бы я не говорил.

> TUser (10.11.2010 09:21:33) [33]

Это потому что он на delphimaster.ru не ходит, тут бы ему быстро мозги
прочистили, что на весь остаток жизни будет бояться Destroy

Высокий/низкий уровень, ручное/автоматическое управление Найти похожие ветки