Конференция VBStreets

**Ramzes** » 01.06.2006 (Чт) 16:47

Хакер
при специальной оптимизации и .Net будет летать.

Sebas
Надо будет сравнить :roll:

**Vinechka** » 01.06.2006 (Чт) 17:09

Кстати, насчет летать не летать. Проскакивал какой-то класс по вычислению MD5 хэша. На вб6 он мегабайтный файл долго очень вычислял. строенными же средствами дотнета хэш с гигабайтного файла у меня лично вычисляется секунд за 10-15. Основным сдерживающим фактором при этом является скорость считывания с IDE хардов.

**Ramzes** » 01.06.2006 (Чт) 17:15

Vinechka
Смотря опять таки что делать, например UI писать с помощью GDI+ на .Net очень медленно получается, а на 6 я таких задач не делал :roll:

**Wild VB Code for Food** » 01.06.2006 (Чт) 18:51

Хакер писал(а):Ramzes, вот!!! и я о том. Так что мы, гамемакеры , будем пока сидеть на VB6 / VC6

Нет, все серьёзные гейм -мейкеры пишу на VC2003/Delphi2005(DelphiX)/FASM

**RUSYA** » 02.06.2006 (Пт) 17:47

нее

) .NET по скорости сжигает 6-ую студию... это интуитивно понятно, достаточно вспомнить, что всё же .NET, и для 64 битной платформы... + логично, что новая технология должны быть более быстрой...

К игрушкам .NET можно отнести к "так сяк", т.к. морду по барабану на чём рисовать, а вот саму игру DirectX or OpenGL... и в какой студии приминять 3д движёк по большому счёту нет разницы...

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

**tyomitch** » 02.06.2006 (Пт) 18:14

RUSYA писал(а):нее ) .NET по скорости сжигает 6-ую студию... это интуитивно понятно, достаточно вспомнить, что всё же .NET, и для 64 битной платформы... + логично, что новая технология должны быть более быстрой...

Какой-то бред. Кто 64-битная платформа? .net 64-битная платформа?

**MeMBus** » 03.06.2006 (Сб) 11:07

скорость работы программ написанных в VS6 и VS.Net - отдельная тема

**Viper** » 03.06.2006 (Сб) 11:28

RUSYA писал(а):нее ) .NET по скорости сжигает 6-ую студию... это интуитивно понятно, достаточно вспомнить, что всё же .NET, и для 64 битной платформы... + логично, что новая технология должны быть более быстрой...

Интуитивно это отнюдь не понятно. Тем более непонятно почему если .NET, то скорость должна быть выше? а уж 64-битная платформа тут совсем не при чем.

Тестирования времени выполнения одинаковых задач показывают, что с быстродействием VB6 и VB.NET все очень неоднозначно. Тестирование несколько лет назад проводил для двух программ без пользовательского интерфейса решаюших уравнения равновесия для много опорных балок (если проще, то решалась куча систем уравнений с большим числом неизвестных). Алгоритмы были одинаковые совершенно.

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

**hCORe** » 03.06.2006 (Сб) 11:32

Ну так, естественно! Если бы .NET был медленным в операциях с файлами, кто бы в бизнесе его использовал?

**GSerg** » 03.06.2006 (Сб) 11:51

Гы гы.
http://bbs.vbstreets.ru/viewtopic.php?p=6594809#6594809

**RUSYA** » 05.06.2006 (Пн) 17:33

2 tyomitch, я немного не так выразился, я не говорю что если .NET так обязательно 64 битная платформа, я говорю, что если .NET + Framework 2.0 то возможна поддержка 64-битный платформ...

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

**tyomitch** » 05.06.2006 (Пн) 17:48

Интересно, какой такой магией .net может обеспечить более быстрый доступ к файлам и памяти, чем простой WinAPI?

**Viper** » 06.06.2006 (Вт) 8:03

tyomitch писал(а):Интересно, какой такой магией .net может обеспечить более быстрый доступ к файлам и памяти, чем простой WinAPI?

сие действительно загадка, но что называется против факта не попрешь...

**tyomitch** » 06.06.2006 (Вт) 8:05

больше похоже на кривизну рук тестировщика :roll:

**keks-n** » 06.06.2006 (Вт) 12:28

Учитывая, что CLR ломится к тому же самому WinAPI...

**alibek** » 06.06.2006 (Вт) 12:30

keks-n писал(а):Учитывая, что CLR ломится к тому же самому WinAPI...

Откуда информация?
Я слышал, что это временно, в будущих версиях Windows WinAPI уже не будет.

**Sebas** » 06.06.2006 (Вт) 12:49

alibek писал(а):
keks-n писал(а):Учитывая, что CLR ломится к тому же самому WinAPI...

Откуда информация?
Я слышал, что это временно, в будущих версиях Windows WinAPI уже не будет.

ВынАпи32 не будет в Сингулярити. А её ещё скоро не будет)))

**keks-n** » 06.06.2006 (Вт) 13:37

И что, она будет ломиться напрямую к ядру, или всё-таки через ntdll?

**tyomitch** » 06.06.2006 (Вт) 13:51

keks-n, они и ядро на .нет-е напишут!
из неуправляемого кода останется только mscorlib.dll!

слушай больше этих маркетроидов

**Sebas** » 06.06.2006 (Вт) 14:20

tyomitch писал(а):keks-n, они и ядро на .нет-е напишут!
из неуправляемого кода останется только mscorlib.dll!

слушай больше этих маркетроидов

Ядро будет на C# но, неуправляемое. ОЧ непонятно, что будет со сборкой мусора.

**Ramzes** » 06.06.2006 (Вт) 14:30

Sebas
Будем надеятся, что ничего плохого и нового (совершенно нового) они не придумают

**Денис Победря** » 06.06.2006 (Вт) 14:34

ВинАпи исжил себя. Погоня за совместимостью - радость и беда Виндовс

Конференция VBStreets

VS6 vs VS .NET

Кто сейчас на конференции