» Вопросы по Embarcadero RAD Studio XE3

sergionn

Цитата:

1) у тебя никто даже в буд.версиях xe3-xe4 ассемблер пока не отбирают, завсегда и dos с турбопаскалем поставить можно.....

Если они переведут компилятор Delphi на LLVM, никто такие низкоуровневые фичи как ассемблер в новый компилятор не потянет.

Вы переписку по ссылкам читали? Когда у Бауэра спросили, стоит ли ожидать оптимизации математики с плавающей точкой, он прямо ответил, что выжимать такты из кода никто не будет. У инженеров, занимающихся компилятором, и так много работы. Когда спросили насчет старого RTTI (TypeInfo.pas), зачем в нем в XE3 появились зависимости от нового RTTI.pas - он ответил, что в старом нет поддержки атрибутов свойств объектов. Поэтому новый RTTI и дальше будет наращиваться, и проникать всюду в RTL и VCL. Потому что оно "мощное", даром что медленное и объемное по занимаемой памяти. Если еще в XE и XE2 можно было частично перекомпилить VCL и получить выигрыш по размеру EXE-шника в 2 раза (ищите по слову NoRTTI), то в XE3 такой фокус не прокатывает уже.


Цитата:

смысл смотреть в сторону RO, если там вся та-же песня что и родная платформа, только переложенная на паскаль,
т.е. кросплатформенности как таковой нет! На каждую платформу: андроид, osx, ios нужно ЗАНОВО писать свой код,
- проще сразу писать на object-c, джаве............. Зачем нужен костыль в виде oxygen - если весь код паскалевский под него придется перелопачивать?????

Смысл в том, что компиляторы RO реально работают. И они доводят дело до конца. И, на самый крайний случай, с них всегда можно спрыгнуть, быстро конвертировав код в C#. Также как быстро можно конвертировать любой C# код в Oxygene. А большинство последних разработок Em-ro в области компиляторостроения оказываются пшиком: либо их забрасывают, либо они глючные. Из свежего - поддержка iOS в XE2 (сколько человекочасов выброшено в мусор?), 1-я глючная и тормозная версия FMX, недоделанные и глючные Generics, тормозной LiveBindings (как они туда умудрились транслятор выражений всунуть?).


Цитата:

FM2 + Mobile studio именно предлагает кросплатформенный подход - один код на все платформы,
а где нужно использовать нативный КОНТРОЛ, то это делается переключение типа контрола на нативный!!!!
см. выше последнее видео, 50-я минута.........

Да, это будет круто... Когда-нибудь... Лет через 5, возможно, даже глючить не будет... Наверное.

GlavBuh

Низкоуровневые фичи? Ну-ну) Для прикладного софта не вижу в них смысла. Модель управления памятью на базе ARC - это довольно ок, такой разумный компромис между Garbage Collector и "ручным управлением". А если указателям на объекты добавят новый уровень проверки - что в том плохого? Вы часто патчите VMT в своих проектах?) Ну и если говорить об ассемблерных вставках - так это верный способ поиметь проблем на разных типах процессоров! ARM v6, ARM v7/7s, AMD, x86, x64 - вы для всех будете на своем ассемблере писать?) В общем не вижу смысла для прикладных решений!) К тому же, думаю, там где ассемблер есть, его не отключат. Просто не будут делать для новых платформ.

sergionn

Согласен, что рост количества "сервиса" в языке увеличивает производительность труда)

Не согласен про Oxygene - там можно писать общий код для всех платформ. Он даже может заюзать кросс-платформенную Sugar, которая благодаря mapped types будет довольно шустрой и нативной на каждой платформе. Беда в другом - общих frameworks на платформах по-определению мало! Например, сетевые библиотеки существуют на каждой платформе, но они разные. Да тот же xUnit на каждой платформе свой - OCUnit, NUnit, ... Но у RemObjects есть RO SDK/DataAbstract - а это уже позволяет делать софт с доступом к данным, то есть решает много проблем с деловым софтом!)

Зато появление Oxygene может вызвать создание таких кросс-платформенных библиотек!)

deks
Цитата:

Низкоуровневые фичи? Ну-ну)

В этом есть/была фишка Delphi. Что можно легко писать прикладные решения (как в VB, C#), и в то же время при необходимости иньектировать свои DLL в чужие процессы, патчить RTL на лету (например так делают библиотеки-локализаторы), оптимизировать критические участки кода ассемблерными вставками. Да какую навороченную библиотеку для Delphi не взять - там везде есть что-то "эдакое".

Или взять DDevExtensions, IDEFixPack Андреаса Хаусладена, которые стоят наверное у всех. Создание таких патчеров будет в принципе невозможно. А уйдут такие как Андреас, кто останется? Молодое поколение, то которое без понятия о системе распределения памяти, на которое Em-ro делает ставку. Ну, тогда в путь и с песней. А я останусь пожалуй.

Насчет Oxygene. Вот и Боб Сварт сделался его реселером _http://www.bobswart.nl/Weblog/Blog.aspx?RootId=5:5668
И указывает на преимущества покупки Oxygene for .NET вместо Embarcadero Prism.

deks
Цитата:

Не согласен про Oxygene - там можно писать общий код для всех платформ.

Более того, как указывает Боб Сварт, там общий компилятор (!) для всех платформ:

Цитата:

Note that Oxygene for .NET, Oxygene for Java and "Nougat" all share the same Oxygene language and compiler.

А Эмбракадарцы до сих пор не смогли реализовать проверку кода в редакторе основным компилятором, используют специальный на писанный на J#. Для справки: J# - это такой выкидыш Microsoft, который даже его создатели уже забыли.

Опять же, цены... Delphi в США стоит одних денег, в Европе других, а в Китае вообще заоблачных. Oxygene можно купить онлайн за $499 из любой страны мира, либо в Европе у ретейлера за тех же 399 евро.

А компилятор сам по себе вообще бесплатный. Для любителей ручного кодирования. _http://www.remobjects.com/downloads.aspx
Кстати тут выяснилось, что для компилятора Oxygene есть бесплатная же мини-IDE _http://www.andreas-flucke.homepage.t-online.de/AFDLite/download.html

sergionn

Цитата:

ты где был........,
мы про moble studio уже "трем" с 7-й страницы

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

Цитата:

Зато появление Oxygene может вызвать создание таких кросс-платформенных библиотек!)  

Не больше, чем IKVM, Scala.Net и прочие нишевые извращения.

Ибо идея виртуальных машин типа JVM и CLR не в кроссплатформности с привязкой к языку типа C/C++, а наоборот в кросс-языковости с привязкой к общему рантайму.

Соотв. и рекламируется Oxygen тем, что может прозрачно использовать уже готовые мощные родные для платформы библиотеки. А тогда зачем делать библиотеки для Oxygene ? Это получается шаг назад, только через еще один косвенный уровень - замедляющий и жрущий память. Железо -> OS -> библиотеки для ЯВУ типа STL -> JVM/CLR -> снова библиотеки для ЯВУ

В конце концов, если кому хочется - то всё это уже есть: PyPy, CPython Jython, IronPython
Пожалуйста, давно уже можно делать еще один уровень абстракции поверх других уровней, как и предлагается для RO. Много наделали ?

Добавлено:

Цитата:

Насчет Oxygene. Вот и Боб Сварт сделался его реселером

И тут мне тоже непонятно. Они опоздали везде, кроме Win32, в который вцепились, и куда никто кроме них не пролез по большому счёту. Ну и возделывайте свою нишу, как Кобольды.

Расширяться, конечно, хорошо - вот только сил уже даже на родную нишу не хватает. Да и куда расширяться-то ? Пустых ниш нету, везде уже кто-то сидит.

Linux ? поздно, после Kylix вам уже никто не поверит, тем более Lazarus окреп.

.NET ? заманчиво, но RemObjects уже застолбили делянку - и если раньше Оксиджен был вторичным wannabe-Delphi для моднявого .Net'a, то теперь всё получится наоборот и Delphi Mk.2 будет вторичным wannabe-Oxygene.

Мобильники... мммм... Упс - и туда RemObjects уже щупальца пустили... Хотя там ещё какие-то шансы есть, может быть. Вот только навыки десктопного программирования на мобильниках зачем ? А если менят ьвсе библиотеки и привычки - то можно и язык сменить до кучи, тут уже не так важно.

Добавлено:

Цитата:

используют специальный на писанный на J#.

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

Arioch1

Цитата:

Ибо идея виртуальных машин типа JVM и CLR не в кроссплатформности с привязкой к языку типа C/C++, а наоборот в кросс-языковости с привязкой к общему рантайму.

Что, действительно? JVM это уже кросс-языковость с привязкой к общему рантайму?
Вот это новость.

en.wikipedia.org/wiki/List_of_JVM_languages

Arioch1
Интересно.
Но как-то большая часть из представленного смахивает на "академические поделки".
Опять же, основная масса работает как ретранслятор.
Не думаю, что из представленного реально использутся процентов 5.
Хотя, все равно - забавно.

у так и под CLR пишут на шарпе, немного на Васике, остальные тоже - в пределах погрешности

Arioch1
Ну не совсем, но хотя и близко к этому.
Знаю конторы (в т.ч. и буржуйские) где управляемые плюсы это что-то типа "spirit of development". Да и железный питон все еще кое-где используется.
Хотя все равно это мелочи.
Вон у нас в конторе, молодой один увидел шарповский sdk для андроида под msvs, накупил книг, накачал андроидного апи. Прокричал, что в маркете отстой один, а он отныне будет мир удивлять и бабло зарабатывать. Пыхтел месяца 3, а потом забросил. "Чего забросил? Да какой-то этот шарпный сдк убогий".

на телефоне, где вечно не хватает памяти, а раодная среду - побочное дитя Жабы - писать на шарпе ? Да, мир он удивил.

Но ведь есть же проект переписать на Mono весь андроид. Раз уж человек хочет войти в историю - пусть подбирает и заканчивает.

GlavBuh

Да, компилятор у них общий для всех трех платформ, причем в IDE встроены вполне интересные фишки, типа авто-исправления кода, или считать ошибки, которые можно исправить, предупреждениями. Отмечу только, что для OSX/iOS используется LLVM backend, а для .NEt и Java - свои бэкэнды.

Бесплатный только компилятор командной строки. Но VS в целом хорошая IDE и там есть примеры / шаблоны и тп. В общем, можно и заплатить, благо что не так дорого как Delphi.

Arioch1

Вы про кросс-платформенность не совсем понимаете суть Sugar. почитайте - это библиотека, которая делает общий API для платформенных классов. Типа, общий API для строк, контейнеров, работы с файлами и тп. Также есть часть Legacy, которая дает некоторую совместимость с Delphi RTL. Так что Sugar - это не "слой", скорее это "карта соответствия" frameworks разных платформ. Вполне себе забавно)

Я ж не говорю, что многоплатформенный язык - это первый на рынке! Но для Pascal - один из первых. Другой - FPC, тоже кстати ничего себе. Delphi пока "начинает")

Ну и про C# для Андроида - есть вполне годный проект MonoDroid. На нем довольно много софта уже писано. Аналогичен и MonoTouch. Подход - в целом аналогичен тому, что делает RemObjects, но на C#.

Поглядел http://docs.xamarin.com/Android/Guides/Advanced_Topics/Application_Package_Sizes и http://docs.xamarin.com/Android/Guides/Advanced_Topics/Architecture

Каждая программа тянет с собой полтора десятка МБ .Net'a. Неплохо для мобильника.

А теперь представим, что у нас запущен пяток дотнетовских программ, каждая в своей песочнице, у каждой своя версия CLR, свой распухший GC... И это в системе, которая изначально планировалась как "немножко ядру, остальное Единому Господину Дальвику"

Возьми для примера IKVM - они не написали java-машину как CLR-процесс, они перекодируют .jar'ы в родные CLR-сборки. А Xamarin не так делает, он отдельные неродные виртуалки запускает, чтобы посоревновались с Дальвиком за ресурсы.

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

Добавлено:

Цитата:

Так что Sugar - это не "слой", скорее это "карта соответствия"

Примерно так же уже много лет должна в теории делать Scala.Net
И что-то пока грустно с нею. То ли не нужны варяги. То ли на бумаге гладко, а потом мелкие несоответствия контрактов и поведения вылезают.

И вы в общем из контекста вырываете. Возможно в Шугаре тщательно минимизировали издержки, свели всё к наименьшему общему и вообещ это произведение искусства. Пусть. Но ведь отечал-то я на тезис
Цитата:

появление Oxygene может вызвать создание таких кросс-платформенных библиотек!)

- т.е. речь шла не о Шугаре, а о новых, ещё не написанных библиотеках. Причём - массово писаных, а не - пусть,предположим, - гениями. Чeму-то типа SWT.

Тот же Data Abstract - это же не mapped types на ADO.NET и JDBC, а *замена* штатным библиотекам.

sergionn

Цитата:

3) вот видос оборный по всех технологиям oxygen был _http://tv.remobjects.com/oxygene/oxygene-20-oxygene-overview.mp4, но что то видео потерли с сайта, я посмотрел, и сделал один вывод: проще писать под конкретную платформу, чем пытаться подтянуть оксиджен, но я могу ошибаться........  

Вот это видео? _http://www.remobjects.com/tv/oxygene.aspx?video=oxygene-20-oxygene-overview

Вы наверное уже слышали, что буквально недавно в Плюсах появилась новая штуковина - Communities называется. Вот ссылочка на только что созданную Delphi Community: https://plus.google.com/communities/103113685381486591754

Цитата:

Вот это видео?

ну да..........

Посмотрел, вроде прикольно все выглядит.
Только приложения под винду и линукс не нативные и требуют установки рантаймов?
С версиями оксигена вообще муть какая-то. Даже у Эмбо понятнее что куда входит и сколько стоит.

SolidSnakeRU

Под винду приложение Oxygene - это под .net - со всеми вытекающими. То есть требуется .net. Нативными их можно назвать для win8.

Под Linux приложение Oxygene может быть под Mono.

С версиями Oxygene - не понимаю что там сложного! Есть 3 версии: под .net, java и cocoa. Соответственно, называются Echoes, Cooper и Nougat. Эмро продавала Echoes как Delphi Prism.

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

Я смотрел цены тут: http://www.remobjects.com/shop/
Не показалось наглядным

В любом случае, коли это .нет - то не подходит...

SolidSnakeRU
Да, нативные программы быстрее. Поэтому я по-прежнему на D2007 - XE2 (с вырезанным RTTI).

Но, учитывая как в Em-ro расставляют приоритеты, скоро программы на .NET WPF будут лагать меньше, чем Дельфовские, с вздувшимся RTL и тормозным кросплатформным FireMonkey. По математическим операциям это уже так - даже скрипты на JavaScript благодаря движку V8 влегкую уделывают Delphi-программы.

Что касается программирования под OSX/iOS, так обе команды - Em-ro и RemObjects, избрали один и тот же backend для своих компиляторов под эти ОС - LLVM. И обе обещают релизы в 1 пол. 2013г. Конечно, мы посмотрим, у кого лучше получится. Но я ставлю на RemObjects. У них уже вторая бетка вышла.

SolidSnakeRU

Там про Oxygene одна строка- все три платформы за $499. Ну и еще он входит в Suite для платформы. И да, для Windows - под .NET.

Copper - это под Java.

Nougat - тут просто iOS/OSX.

Добавлено:
GlavBuh

У RemObjects выходит weekly beta.

Проблема с RemObjects - в RTL, не допилено именно кросс-платформенная часть (Sugar). Но ее обещают сделать OpenSource, так что можно поспособствовать. Но особенных проблем задействовать RTL платформы нет. Ну и нет проблем с GUI - оно платформенное.

У EMRO проблемы с GUI - очень любопытно что сделали для FM2 под iOS: предыдущие поделки были близки к неработоспособным (типа, запуск простой программы под 20 секунд на самом крутом HW).

Цитата:

даже скрипты на JavaScript благодаря движку V8 влегкую уделывают Delphi-программы.  

ладно чесать то, ты сам проверял????????

Я собрал из ранее публиковавшихся на форумах 2 теста, с которыми, как писали, delphi оч.плохо справлялся:
1) вычисление интеграла
2) и синуса с квадратным корнем,
собрал все под 3 компилятора, 32 бита + js, оптимизации по умолчанию, все расчетные переменные double:
все запускал на windows 8 x64, Intel® Core™ i5-2410M Processor

1) Microsoft Visual Studio Ultimate 2012, Version 11.0.50727.1 RTMREL
1 тест: 7 секунд / 4 секунды - x64
2 тест: 5 секунд / 6 секунд - x64

2) Lazarus (freepascal), сборка Lazarus + fpc 2.6.1 от 9 декабря 2012:
1 тест: 9 секунд
2 тест: 10 секунд

3) Embarcadero® Delphi® XE3 Version 17.0.4625.53395
1 тест: 9 секунд / 8 секунд (64бита)
2 тест: 12 секунд
причем если вычисления оформить в виде отдельной функции, сделав переменные локальными, и скомпилировать под x64,
то время тестов будет 7 и 9 секунд соответственно

4) Embarcadero® C++® XE3 Update1, 64bit, LLVM
1 тест: 3 секунды
2 тест: 1 секунда

5) Google Chrome Версия 23.0.1271.95 m - движок V8
1 тест: 28 секунд
2 тест: 13 секунд

6) Microsoft IE10 Версия 10.0.9200.16384
1 тест: 42 секунды
2 тест: 16 секунд

Все подсчитанные суммы на всех тестах совпали до значимых позиций.

Вот сам тест на js:

<!DOCTYPE HTML>
<html>
<head> </head>
<body>
<script>
var vp = 200000;
var np = 0;
var snp = np;
var step = 0.0001;
var sum = 0;
var x = 128;
var y, z;

var start = new Date().getTime();
while (np + step < vp) {
sum = sum + ((np*np + (np + step)*(np + step))) / 2 * step;
np = np + step; }
var elapsed = new Date().getTime() - start;
var start1 = new Date().getTime();
for (i=1; i<200000000; i++){
y = i + (x / 2);
z = Math.sin(Math.sqrt(y * 3)); }
var elapsed1 = new Date().getTime() - start1;
alert("Time Integral: " + elapsed / 1000 + " sec summ:" + sum +
" Time Sin&Sqrt: " + elapsed1 / 1000 + " z: " + z + " y: " + y);
</script>
</body>
</html>

sergionn
Я это взял вот отсюда: https://forums.embarcadero.com/thread.jspa?threadID=74930&start=0&tstart=0
Здесь сравнивали Delphi с C++ (Qt / msvc / mingw) и Java 1.7. Тест запускали куча людей. Дизассемблировали код, исследовали. Выводы все равно неутешительные для Delphi.

А вот здесь Eric Grange, создатель движка DWScript (http://delphitools.info/dwscript/) гонял тесты для своего движка на разных браузерах, и сравнивал с Delphi:
http://delphitools.info/2011/03/24/kudos-to-the-firefox-4-tracemonkey-team/
http://delphitools.info/2011/05/10/delphi-for-javascript/

У меня нет оснований не доверять его выводам.

Цитата:

Вот сам тест на js:

М.б. оформил бы как ссылку, чтобы открыть из разных браузеров - и готово? На сайте или на jslint каком-нибудь

GlavBuh

Цитата:

Я это взял вот отсюда: https://forums.embarcadero.com/thread.jspa?threadID=74930&start=0&tstart=0

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

Вот поэтому я постоянно и говорю, что нахрен не нужны все эти кросс-платформы и С++B. Пусть, сначала, Делфю доведут до ума, всё остальное на потом .. и, кстати, уже бы довели, если бы не их бредовые "разработки" для платформы Apple.

Цитата:

Здесь сравнивали Delphi с C++ (Qt / msvc / mingw)

Qt - это не компилятор, а фреймворк, и компилится он как под msvs так и под mingw,
так что можно сравнивать только с msvc, mingw, freepascal, java, javascript...........

Цитата:

У меня нет оснований не доверять его выводам.

ты вообще понял о чем речь то в этих статьях шла,
я собрал в один файл все ОБСУЖДАЕМЫЕ там, и на форуме этого Эрика тесты,
доработал до идентичности их на с++, pascal, js, и запустил на ОДНОЙ машине.
Результат ОПУБЛИКОВАН.
И вообще зачем кивать на кого-то, возьми да сравни сам - максимум час работы!!!!!!!!!!
Легко просто огульно сидеть тут на форуме и охаивать, основываясь
на каких то там обсуждениях! Проверь сам!!!!!!!!

p.s. Эрику очень сильно ОБИДЕЛСЯ, что emb купил и взял за основу для своего нового кросплатформенного
фреймвока KsDev Евгения Крюкова, а не поддерживаемую им и более продвинутую и подходящую
(как он считает) GLSCENE - это отчетливо сквозит во многих критических его постах.
И да, кстати этот Эрик является еще лицом заинтересованным, в продвижении
SmartMobileStudio, т.к. она в КОРНЕ ОСНОВАНА на его РАБОТЕ , поэтому если глянуть на
эмбаркадеровский форум, в топики, где хаят firemonkey (по большей части заслуженно),
то Эрик всегда ВСТАВЛЯЕТ свои НЕГАТИВНЫЕ 5 копеек!
Т.к. ОН КРОВНО ЗАИНТЕРЕСОВАН в смерти FM, и скорейшей замены delphi на ЕГО SmartMobileStudio,
Как говорят американцы - "It's Just Business, Nothing Personal" - Просто бизнес, ничего личного

Добавлено:

Цитата:

М.б. оформил бы как ссылку, чтобы открыть из разных браузеров - и готово? На сайте или на jslint каком-нибудь

если надо, могу тебе на почту кинуть все тесты, оформлять и выкладывать к сож. времени нет., а javascript подправлю сейчас - просто копируй и сохраняй в файл html.

Добавлено:

Цитата:

Кстати, там всё разжёвывается: где и почему медленно. Всем известно, что оптимизация кода в Делфях оставляет желать лучшего, но имеем то, что имеем.

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

Да, по поводу теста Mandelbrot, постараюсь как будет время вывести его через fm2..........
И как руки дойдут до Update 1, запущу тест на новом С++ x64 LLVM компиляторе............

sergionn
Возможно в XE3 64-bit что-то изменилось к лучшему. Все равно компилятор проигрывает другим игрокам - Microsoft, Intel. Но это как бы не новость. Вот то что он проигрывал JavaScript V8 для меня реально был шок.

Цитата:

Вот то что он проигрывал JavaScript V8 для меня реально был шок.

а он и не проигрывает, я надеюсь ты не из тех людей которые "смотрят в книгу и видят фигу",
или тебя Эрик зазомбировал?
вот тебе код на delphi, компилирую сравнивай с приведенным выше на js
program Project2;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils;
var
cnt1, cnt2, cnt3 : TDateTime; vp, np, snp, step, sum, x, y, z: Double;
i: Integer;
begin
vp := 200000;
np := 0;
snp := np;
step := 0.0001;
sum := 0;
x := 128;
y := 0; z := 0;
Writeln('Integral calculations...');
cnt1 := Now();
while (np + step < vp) do begin
sum := sum + ((np*np + (np + step)*(np + step))) / 2 * step;
np := np + step;
end;
cnt2 := Now();
cnt3 := cnt2 - cnt1;
Writeln('Time Integral: ' + FormatDateTime('ss', cnt3) + ' seconds '+ 'Summ: ' + FloatToStr(sum));
Writeln('Sin and Sqrt calculations...');
cnt1 := Now();
for i := 1 to 200000000 do begin
y := i + (x / 2);
z := Sin(Sqrt(y * 3));
end;
cnt2 := Now();
cnt3 := cnt2 - cnt1;
Writeln('Time Sin&Sqrt: ' + FormatDateTime('ss', cnt3) + ' seconds '+ ' Z: ' + FloatToStr(z) + ' Y: ' + FloatToStr(y));
ReadLn;
end.

Добавлено:
А вот что меня реально разочаровывает в emb/delphi
- это ОТКРОВЕННО, НАПЛЕВАТЕЛЬСКОЕ отношение к пользователям и устранению багов,
для меня было актуальным, как минимум устранение около 6 багов, которые были и в квалити централи, и висели там уже пару-тройку месяцев, так вот
НЕ ОДИН, НЕ ОДИН из этих БАГОВ НЕ БЫЛ УСТРАНЕН в xe3 update1,
это просто СВИНСТВО!
И вот именно поэтому, конкретно я,
с большой вероятностью возможно перейду на RO + Smart Mobile studio!

sergionn
Я попробовал у себя.
Delphi 2007 1 тест - 14 sec 2 тест - 12 sec
Delphi XE2 32-bit 16.0.4504.48759 1 тест - 14 sec 2 тест - 15 sec
Delphi XE2 64-bit 16.0.4504.48759 1 тест - 13 sec 2 тест - 15 sec
Chrome 23.0.1271.95 1 тест - 40 sec 2 тест - 16 sec
Opera 12.10 - n/a (умаялся ждать)

Delphi XE3 у меня в данный момент нету, поэтому не тестировал.


Цитата:

а он и не проигрывает, я надеюсь ты не из тех людей которые "смотрят в книгу и видят фигу", или тебя Эрик зазомбировал?

Я не думаю, что он подделывал результаты расчета Мандельброта. Даже если посмотреть приведенный тобой 2-й тест, результат Chrome сопоставим с XE2. Поэтому вполне возможно, что но его тесте Chrome лидировал.


Цитата:

Да, по поводу теста Mandelbrot, постараюсь как будет время вывести его через fm2.......... И как руки дойдут до Update 1, запущу тест на новом С++ x64 LLVM компиляторе............  

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

Да, кстати, а в XE3 вот такое компилируется ?
http://pastebin.ca/2291074

Хотя бы один из 4-х вызовов.

А то у меня в XE2 аж однажды ICE выпал, вот только не могу минимизировать

Добавлено:

Цитата:

Opera 12.10 - n/a (умаялся ждать)

Пичалька. Я вчера по мотивам, запустил в 12.11 тест Канваса с фракталом, упомянутый в форуме.
Chrome: ~ 0,06 sec, а Opera ~ 0,4 sec, "тормозит как Дельфи" :-D