Что быстрее? VB6 или VB.NET?

[GPP]

Какая программа работает быстрее? Написанная на VB.NET или VB 6? Конечно при условии что они "одинаковые"

[Viper]

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

[Хакер]

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

[Nord777]

VB6-код выполняется быстрее,

И у тебя есть весомые аргументы?

[SLIM]

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

[offtopic]Толи я не понял толи ты сам себе противоречишь...[/offtopic]

[Viper]

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

[offtopic]Толи я не понял толи ты сам себе противоречишь...[/offtopic]

Все нормально. Ибо нет однозначного ответа. Кстати, можно поискать предыдущие темы аналогичные. Там тоже не нашлось однозначного ответа про скорость выполнения кода в VB и в VB.NET.

[Хакер]

VB6-код выполняется быстрее,

И у тебя есть весомые аргументы?

Угу.
VB6-код выполняется центральным процессором.
MSIL-код выполняется нэтовским ядром, а не центральным процессором.

Нэтовское ядро не может выполнять MSIL-код, быстрее, чем процессор выполнит Native-код, потому что оно само (нэтовское ядро) выполняется процессором.

Можно предположить, что .net работает иначе, что он сначала компилирует MSIL-код в Native, а потом заставляет центральный процессор выполнить полученный Native-код. Тогда такой Native-код будлет работать столько же времени, что и аналогичный VB-шный. Но тогда затраты времени появляются засчёт компиляции MSIL-кода в Native.

[offtopic]Толи я не понял толи ты сам себе противоречишь...[/offtopic]

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

Всё зависит от многих обстоятельств.

З.Ы. .net — must die.

[ANDLL]

MSIL-код выполняется нэтовским ядром, а не центральным процессором.

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

[Хакер]

1) В чем тогда фишка MSIL-ности? Почему бы тогда не делать ngen на стороне программиста?
2) Но vb.net-ный код скомпилируется в итоге в более сложный Native-код, чем аналогичный vb-код.

[ANDLL]

1) В чем тогда фишка MSIL-ности? Почему бы тогда не делать ngen на стороне программиста?

Ну из одного MSIL получается разный код для разных аппаратных и софтварных платформ.
Ты же не сможешь на стороне программиста сделать код который будет работать одновременно на итаниуме и x64?
Или код который одновременно работает на linux и на windows, используя именно родные вызовы(то есть не wine\MS SFU)
Кроме того, ngen и jit помимо компиляции еще и проверяют код на целостность

2) Но vb.net-ный код скомпилируется в итоге в более сложный Native-код, чем аналогичный vb-код.

Да. За малым исключением - сгенерированный .net-овский машинный код использует fastcall, который вероятно быстрее чем stdcall, который использует VB. Так что по крайней мере в одном .net код точно быстрее VB-шного(правда вероятно медленнее в других вещах)

[Хакер]

Ну из одного MSIL получается разный код для разных аппаратных и софтварных платформ.
Ты же не сможешь на стороне программиста сделать код который будет работать одновременно на итаниуме и x64?
Или код который одновременно работает на linux и на windows, используя именно родные вызовы(то есть не wine\MS SFU)

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

Да. За малым исключением - сгенерированный .net-овский машинный код использует fastcall, который вероятно быстрее чем stdcall, который использует VB. Так что по крайней мере в одном .net код точно быстрее VB-шного(правда вероятно медленнее в других вещах)

Я давно усомнился в fast-ости fastcall-а. Во-первых, оно ограничивает нас в использовании регистров. А если нам нужно будет поюзать те два регистра, которые заняты аргументами, нам то, что в них хранится придётся куда-то прятать (очевидно в стек). А уж fastcall-ная рекурсивная функция однозначно проиграет в производительности stdcall-ной.

[ANDLL]

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

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

Я давно усомнился в fast-ости fastcall-а. Во-первых, оно ограничивает нас в использовании регистров. А если нам нужно будет поюзать те два регистра, которые заняты аргументами, нам то, что в них хранится придётся куда-то прятать (очевидно в стек). А уж fastcall-ная рекурсивная функция однозначно проиграет в производительности stdcall-ной.

В других(не x86) платформах "свободных" регистров больше чем два.
Ну а быстрее fastcall или нет - вопрос спорный. Для примера, функция, которая скажем складывает два числа и возвращает результат(или вообще функция которая не вызывает другие функции) в реализации fastcall будет работать быстрее, так как может вообще избегать использования физической памяти. С другой стороны(и это плюс в сторону stdcall), push и pop то же не работают с памятью на прямую - ведь в случае со стэком кэш работает весьма эффективно.
Но все равно, я думаю есть тесты на которых Vb.NET даст прирост скорости по сравнению с VB6.

P.S. Ну и разумеется, не стоит думать, что описанная в п1 причина - единственная, из за которой используется промежуточный код

[Денис]

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

[Proxy]

Ага. Бенчмаркам я верюбольше, чем трёпу. Хотя результат мне заранее представляется на стороне шестого.

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

А в чём прелесть .net в таком случае?

[tyomitch]

Ага. Бенчмаркам я верюбольше, чем трёпу. Хотя результат мне заранее представляется на стороне шестого.

Предлагаю для начала сформулировать, что конкретно считать "скоростью языка".

[Proxy]

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

[tyomitch]

Ещё конкретнее. Какая именно работа с графикой?

[Proxy]

Не могу придумать(

[tyomitch]

Тогда какая тебе разница, какой получится цифра в результате?
Или единственное, что важно -- чтобы была Авторитетная Цифра, не важно что конкретно она отображает?

[Хакер]

Предлагаю сравнивать по скорости вычисления CRC32.

[Proxy]

tyomitch, мне-то всёравно.

[Williams]

Неплохое сравнение нашел:

My experience has been poorly written VB.NET applications perform worse then
well written VB6 applications. On the same token well written VB.NET
applications perform better then poorly written VB6 applications. Further I
find that well written VB.NET applications perform about the same as well
written VB6 applications...

Oh! I find its easier & faster to write well written VB.NET applications,
then it is to write well written VB6 applications. As the framework handles
& offers a lot of things for you, such as global exception handlers and full
OOP.

I have seen reports, but have not really noticed it myself, that the start
up time may be slower for a VB.NET app.

[Nord777]

Предлагаю сравнивать по скорости вычисления CRC32.

Неужели ты созрел?

Предлагаю создать новый топик, в котором не будет ничего лишнего, только тесты.
1) Название теста.
2) код VB6 (в виде форматированного тегом [Code] текста)
3) Экзешник VB6

И тоже самое VB.Net
Каждый сможет протестировать на своей машине и отписаться о результатах, указав параматры компа.(наверно достаточно указать только проц)

[Williams]

Предлагаю сравнивать по скорости вычисления CRC32.

Неужели ты созрел?

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

Я за

[SLIM]

Мяса мяса!!! Народ хочет мяса!!! Бойня будет супер!!! Давайте. Я хочу на это посмотреть....Хакер не уж то останешься не у дел?

[GPP]

И так, где же этот топик с исходниками и тестами?

[SLIM]

Nord777
Может всетки начнешь раз никто не решается

[Nord777]

Nord777
Может всетки начнешь раз никто не решается

Бесполезная затея без виновника торжества. Когда человек говорит "А" все ждут, когда он скажет "Б". Вот и нам надо подождать. Я думаю, что дождемся. Ведь Хакер хозяин своего слова?...
Он как публичный и авторитетный человек, для многих на этом форуме, должен уметь отстаивать свою точку зрения.
Не только пустыми словами.
И потом, новую тему неплохо было бы прилепить, а это только модераторы.

[SLIM]

Nord777
Я не думаю что удастся скомпрометировать такой речью. Это раз.
Во вторых - всеже я считаю что будет состязаться не общество .NET с обществом VB6, а наоборот, общество VB6 с обществом .NET. Так что вам и начинать (судя по товим постам и подписи). Я бы уже давно начал топик если бы чуть больше знал .NET.
Так что думаю всеже первый шаг за тобой раз уж такой активный.

[Хакер]

Бесполезная затея без виновника торжества. Когда человек говорит "А" все ждут, когда он скажет "Б". Вот и нам надо подождать. Я думаю, что дождемся. Ведь Хакер хозяин своего слова?...

Я где-то разве пообещал сказал, что я намереваюсь провести какие-то сравнительные тесты?

Если ты о:

Предлагаю сравнивать по скорости вычисления CRC32.

То это был мой ответ на:

Предлагаю для начала сформулировать, что конкретно считать "скоростью языка".

Потому что судить о "скорости языка" по быстроте работы с графикой (как хотел Proxy) как-то очень тупо. А вот расчёт CRC32 — первое, что пришло мне в голову, где нет ничего платформо-специфичного. Вот я и предложил tyomitch'у и Proxy сравнивать по скорости вычисления CRC32.

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

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

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

Но свободного времени сейчас нет: у меня лежат три недописанные статьи в МануAll, корые надо дописать, почекать и выложить, мне нужно сделать на этом форуме форму быстрого ответа, сделать кликабельный логотип и т.д.

Первым делом, я бы занялся чем-то из вышеперечисленного.

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

И потом, новую тему неплохо было бы прилепить, а это только модераторы.

В этом нет никаких проблем.