Есть ли будущее у DELPHI?

Цитата korvin @ 10.05.12, 09:25

Я уже предложил выше. А IL_Agent добавил, что на выход можно посылать битмап, который уже должен отображаться в контроле.

ОКей, я согласен

Добавлено 10.05.12, 09:27

Цитата korvin @ 10.05.12, 09:25

А, ты про другое. Ну не знаю. Я сразу написал какие языки могу потестить. Делфи среди них не было =)

Ладно, как-нить разберемся. Найдем кого-нить с двумя системами, думаю, или с сопоставимыми машинами

Цитата --Ins-- @ 10.05.12, 09:19

А, ну да, печалька, хотя если задаться целью и взять лазарус... Так как тогда тестить?

Файрманки!

Цитата --Ins-- @ 09.05.12, 18:19

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

Как то зловеще звучит про контрол. Много возни. Давай вот то же самое, но с генератором ландшафтов. Я так понимаю у тебя уже есть просмотрщик. Вот выдай народу формат файла, там разберёмся. Хотя тут много математики, но разобраться можно.

Цитата [S]mike @ 10.05.12, 09:37

Файрманки!

Да ну его в печь

Цитата Повстанець @ 10.05.12, 11:04

Как то зловеще звучит про контрол. Много возни.

Да ладно! 10% от всей задачи. Если нет, то другие инструменты дельфям сливают конкретно по части разработки гуи

Цитата Повстанець @ 10.05.12, 11:04

Давай вот то же самое, но с генератором ландшафтов.

Давай!

Цитата Повстанець @ 10.05.12, 11:04

Я так понимаю у тебя уже есть просмотрщик

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

Цитата Повстанець @ 10.05.12, 11:04

Вот выдай народу формат файла, там разберёмся. Хотя тут много математики, но разобраться можно.

Формата файла у меня никакого готового нет. Массивы можно генерить случайно, а можно как-нибудь реалистично, в принципе алгоритм генерации ландшафтов примитивный - это холмовой алгоритм, реализуется в пару десятков строк кода: http://www.ixbt.com/video/3dterrains-generation.shtml
Но мы измерять алгоритм генерации не будем, тут кто на что горазд. Измерять будем обработку уже готового массива

Сообщение отредактировано: --Ins-- - 10.05.12, 11:40

Цитата --Ins-- @ 10.05.12, 11:39

Измерять будем обработку уже готового массива

Ну ок. А как обрабатывать то будем?

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

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

Поэтому уже сам подход неверный. Тут нужна аппаратная поддержка.

Цитата Повстанець @ 10.05.12, 11:42

А как обрабатывать то будем?

Можно примерно как предложил IL_Agent:
1. На входе - размер массива, на выходе - массив
2. На входе задаем область просмотра и размер битмапа - на выходе разукрашенный битмап. Замеряем скорость генерации битмапа
3. Вернуться к п.2. и повторить некоторое количество раз для разных областей
Палитра - можно условиться, 256 цветов в Grayscale или взять какую-нибудь красивую цветную - горы коричневые, равнины - зеленые, впадины - голубые

Сообщение отредактировано: --Ins-- - 10.05.12, 11:49

Цитата --Ins-- @ 10.05.12, 11:46

2. На входе задаем область просмотра - на выходе разукрашенный битмап. Замеряем скорость генерации битмапа
3. Вернуться к п.2. и повторить некоторое количество раз для разных областей

Ну опять же, если работать с GDI+ через C# наиболее быстрый способ, сформировать Bitmap это использование методов LockBits и дальнейшее шаманство, и не дай бог кому-нибудь использовать методы GetPixel/SetPixel. Т.е. производительность опять упрется в библиотечные функции.

Поэтому если уж хотите использовать этот порочный подход, то замеряйте только время генерации исходного массива.
Т.е. на входе у нас float[] (квадратная карта высот) и на выходе float[].

Цитата Red @ 10.05.12, 11:50

Т.е. производительность опять упрется в библиотечные функции.

Один вызов LockBits/UnlockBits на производительность не повлияет при достаточно большом размере массива. К тому же, его или нечто подобное придется делать на любом ЯП, я так думаю

Сообщение отредактировано: --Ins-- - 10.05.12, 11:54

Цитата --Ins-- @ 10.05.12, 11:52

К тому же, его или нечто подобное придется делать на любом ЯП, я так думаю

Вот именно, что "нечто подобное" может здорово отличаться по производительности. Например та же пара Get/Set Pixel.

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

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

Добавлено 10.05.12, 11:59
--Ins--, ну и опять же, сделает кто-то внешне безобидный каст к Color на каждой итерации и прощай первенство.

Цитата Red @ 10.05.12, 11:57

Например та же пара Get/Set Pixel.

Ну, если тебе инструмент кроме Get/SetPixel никакой альтернативы работы с пикселами битмапа не предоставляет, то это уже по определению чистейший слив по производительности для ряда практических задач, можно даже не тестить. Но я все же думаю, что должно что-то быть. В шарпе точно есть названные тобой методы GDI+. Самы эти вызовы проецирования битмапа в память работают быстро и вызываются единожды, а дальше - работа с массивом в памяти и никаких тебе системных вызовов

Цитата Red @ 10.05.12, 11:57

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

Да нет проблем. Но все же лучше его визуализировать для наглядности. Ну, если так хочется, вызовы LockBits/UnlockBits можно исключить из замера, хотя я убежден, что их вклад в скорость выполнения едва ли превысит 1%, и будет тем меньше, чем больше битмап/массив

Добавлено 10.05.12, 12:05

Цитата Red @ 10.05.12, 11:57

--Ins--, ну и опять же, сделает кто-то внешне безобидный каст к Color на каждой итерации и прощай первенство.

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

--Ins--, в общем если кратко, то для такой задачи сразу нужно смотреть в сторону GPU/DirectX/OpenGL.
В случае .NET можно посмотреть на WPF там есть поддержка 3D и шейдеров.

Цитата Red @ 10.05.12, 12:12

-Ins--, в общем если кратко, то для такой задачи сразу нужно смотреть в сторону GPU/DirectX/OpenGL.

Я сразу говорю, что я их использовать не собираюсь. Или же ты заранее заявляешь что без них шарп сольет?

Цитата

Smike Says: Your comment is awaiting moderation.
May 10th, 2012 at 5:22 am

>> "Microsoft и Embarcadero - братья навек"
Помнится, в прошлом году в это же время уже можно было пощупать бету Pulsar (то есть Delphi XE2). Какие новости в этом году? Какова и будет ли поддержка Android, WinRT, Windows Phone? Будет ли родной компилятор под MacOS & iOS? Ведь Embarcadero традиционно делает релиз новой версии в августе-сентябре, то есть уже фактически через 3,5 месяца.

http://blogs.embarcadero.com/vsevolodleono...g/#comment-3240

Добавлено 10.05.12, 12:26

Цитата --Ins-- @ 10.05.12, 12:22

Или же ты заранее заявляешь что без них шарп сольет?

Сольет или нет - глупо не использовать аппаратное ускорение, если сейчас даже самые бюджетные ноутбуки работают с Windows Aero.

Цитата [S]mike @ 10.05.12, 12:23

глупо не использовать аппаратное ускорение

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