| Вопрос: Стоит ли переходить на .NET? | Добавлено: 29.07.07 05:02 |
Автор вопроса:  программист
|
| Ответы | Всего ответов: 95 |
|
Номер ответа: 76 Автор ответа:  shuffle Администратор ICQ: 201502381 Вопросов: 15 Ответов: 737 |
Профиль | | #76 | Добавлено: 06.08.07 22:43 |
| А вы не забыли о том, что компилятор оптимизирует код, что ставит их в неравное положение? | ||
|
Номер ответа: 77 Автор ответа:  Sharp Лидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #77 | Добавлено: 06.08.07 23:12 |
|
Bugor: ну них**се
Bugor: компилятор нарушает логику работы программы Bugor: я в шоке Bugor: a = GetTickCount(); i = fibo(40); cout << (GetTickCount() - a); cout << i; Bugor: 00401B78 |. 57 PUSH EDI 00401B79 |. FFD6 CALL ESI ; [GetTickCount 00401B7B |. 8BF8 MOV EDI,EAX 00401B7D |. FFD6 CALL ESI ; [GetTickCount 00401B7F |. 2BC7 SUB EAX,EDI 00401B81 |. 50 PUSH EAX 00401B82 |. B9 F0624100 MOV ECX,OFFSET 111111.std::cout 00401B87 |. E8 54FEFFFF CALL 111111.std::basic_ostream<char,std:> Sharp: Читерствует с бенчмарками? Bugor: это с***о нормально? Sharp: второй геттиккоунт выше располагает, чем фибо? Sharp: маза, надо будет написать такой компилятор Bugor: да**я Sharp: Benchmark C++  )
Sharp: КОторый вообще будет х***ый код генерить, зато четко просекать, где его пытаются забенчмаркить и выдавать п***атые результаты Bugor: жжошь |
||
|
Номер ответа: 78 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #78 | Добавлено: 07.08.07 00:11 |
|
shuffle
А вы не забыли о том, что компилятор оптимизирует код, что ставит их в неравное положение?
Я не забыл. Компилятор оптимизирует код, но и виртуалка тоже этим занимается. Подходы разные. Просто мне запомнлись слова Рихтера, который пропагандировал С# - новая платформа оптимизирует код лучше, чем С++, потому как окончательно компилит код с учетом специфики среды (я потом долго тестил - и на консоли они шли практически равнозначно.). Под руку попалось, вот и захотелось это проверить, в новом качестве.
Извечный спор, который стал сейчас еще острее: что лучше компилятор, или интерпритатор (нового поколения). У каждого свои сильные стороны. Да и потом, так я снова сел за Java, захотелось посмотреть, кто чего добился.
Так что в принципе, даже при таких некорректных тестах, можно сделать определенные выводы. Тесты конечно, мягко говоря, очень слабые, если интересно (а мне интересно) можно создать новую тему и провести их гораздо грамотнее. Так что никакой некорректности в сравнении компилятора и "интерпритатора" я не вижу. |
||
|
Номер ответа: 79 Автор ответа: shuffleАдминистратор ICQ: 201502381 Вопросов: 15 Ответов: 737 |
Профиль | | #79 | Добавлено: 07.08.07 02:37 |
|
Я не забыл. Компилятор оптимизирует код, но и виртуалка тоже этим занимается. Подходы разные. Надо было не только не забыть, но и учесть это. Ведь по сути вы сравнивали разные программы. К тому же очевидно, что интерпретатор будет работать медленнее компилятора (не самого компилятора, конечно, а нативного кода), а если это оказывается не так, значит они исполняют разный код. Выходит, вы проводили бенчмарки на качество оптимизации? Тогда следует учитывать, что два почти одинаковых исходных кода, которые в равной степени можно оптимизировать одинаково хорошо ручками, не будут так же одинаково оптимизированны компилятором (интерпретатором). Из этого следует, что проводить один-два теста и из этого заключать, что оптимизирует лучше, по меньшей мере странно.
|
||
|
Номер ответа: 80 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #80 | Добавлено: 07.08.07 14:22 |
|
К тому же очевидно, что интерпретатор будет работать медленнее компилятора (не самого компилятора, конечно, а нативного кода), а если это оказывается не так, значит они исполняют разный код.
Медленне интерпритатор (соаременный) априори должен работать только при первом проходе. Делее он оперирует (по крайней мере такова идеология ) c родным кодом. Дополнительный постоянный тормоз - это среда выполнения(виртуальная машина). Дополнительный плюс, то что виртуалка должна выжать максимум из железа.
Поэтому вывод, что код разный, очень проблематичен. Даже если и так, то что с того? У каждого свои подходы. Выходит, вы проводили бенчмарки на качество оптимизации?
Во многом да. Тогда следует учитывать, что два почти одинаковых исходных кода, которые в равной степени можно оптимизировать одинаково хорошо ручками, не будут так же одинаково оптимизированны компилятором (интерпретатором). Из этого следует, что проводить один-два теста и из этого заключать, что оптимизирует лучше, по меньшей мере странно.
Согласен. И не на основании только этих тестов я делал выводы. Посмотрел немало сторонних тестов, сам немало потестил. Просто результаты +/- попали "норму". Еще раз повторюсь, можно провести значительно более интересные тесты. |
||
|
Номер ответа: 81 Автор ответа: W[4Fh]LFВопросов: 0 Ответов: 187 |
Web-сайт: Профиль | | #81 | Добавлено: 07.08.07 23:11 |
|
Дайте мне оптимизированный код получения числа разрядов в числе. Проще говоря кол-ва цифр. На .NET
Ещё можете подкинуть код подсчёта числа строк в файле. |
||
|
Номер ответа: 82 Автор ответа: -АлександР-Вопросов: 55 Ответов: 1008 |
Web-сайт: Профиль | | #82 | Добавлено: 07.08.07 23:56 |
|
А вы не забыли о том, что компилятор оптимизирует код, что ставит их в неравное положение? Не-а, не забыли, на это и расчет, мы ж не интерпретаторы сравниваем, но почему же в неравное положение... Это и есть сравнение на то, какой компилятор лучше оптимизирует код, по-моему, это было ясно с самого начала, другого и не было замысла 0-:
Надо было не только не забыть, но и учесть это. Ведь по сути вы сравнивали разные программы. К тому же очевидно, что интерпретатор будет работать медленнее компилятора (не самого компилятора, конечно, а нативного кода), а если это оказывается не так, значит они исполняют разный код. Выходит, вы проводили бенчмарки на качество оптимизации? Тогда следует учитывать, что два почти одинаковых исходных кода, которые в равной степени можно оптимизировать одинаково хорошо ручками, не будут так же одинаково оптимизированны компилятором (интерпретатором). Из этого следует, что проводить один-два теста и из этого заключать, что оптимизирует лучше, по меньшей мере странно. в этом я вижу долю истины, правда исходные коды были взяты настолько тривиальными и наивными, что на мой взгляд там и оптимизировать было нечего... в последних, математических тестах фактически соревновались меж собой циклы, а не то, что лежало внутри них )DD, не думаю, что циклы могут быть оптимизированы по разному при разном содержимом..., впрочем это догадка, давайте сделаем больше тестов. Но про механизм оптимизации мало кто знает - будем тыкать пальцем в небо, а потом брать среднее значение?
Предлагаю просто сделать основные тесты на скорость в ситуациях, которые чаще всего приходится применять в программах, и всякие там тормозящие моменты сравнить - это то, что действительно актуально и по нашим силам. И это на мой взгляд будет наиболее точная оценка Тесты конечно, мягко говоря, очень слабые, если интересно (а мне интересно) можно создать новую тему и провести их гораздо грамотнее. да, можно
|
||
|
Номер ответа: 83 Автор ответа: shuffleАдминистратор ICQ: 201502381 Вопросов: 15 Ответов: 737 |
Профиль | | #83 | Добавлено: 08.08.07 00:57 |
|
не думаю, что циклы могут быть оптимизированы по разному при разном содержимом Могут быть.
Предлагаю просто сделать основные тесты на скорость в ситуациях, которые чаще всего приходится применять в программах Именно про это я и говорил. Но вы ведь этого не сделали, а претендовали на абсолютную истину и непротиворечивость результатов
|
||
|
Номер ответа: 84 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #84 | Добавлено: 08.08.07 01:17 |
|
W[4Fh]LF
Дайте мне оптимизированный код получения числа разрядов в числе. Проще говоря кол-ва цифр. На .NET
Чудно. Давай еще сравним скорость работы драйвера написанного на NET?
Ладно, если есть что сказать дельного, предложи конкретные и адекватные тестовые задания. shuffle Но вы ведь этого не сделали, а претендовали на абсолютную истину и непротиворечивость результатов
Ну вот зачем передергивать? Скажи кто претендовал на абсолютную истину?
Ну раз что W[4Fh]LF.
|
||
|
Номер ответа: 85 Автор ответа: shuffleАдминистратор ICQ: 201502381 Вопросов: 15 Ответов: 737 |
Профиль | | #85 | Добавлено: 08.08.07 03:58 |
|
Чудно. Да, сначала только напишем.
Давай еще сравним скорость работы драйвера написанного на NET?Ну вот зачем передергивать? Топик 16: Скажи кто претендовал на абсолютную истину?но и здесь .НЕТ впереди, такова справедливость... надеюсь после этого топика, никто его больше не назовет тормазнутым И аналогично, после очередного абсурдного бенчмарка в посте 37:вот как!
на этой счасливой ноте можно закрыть топик))) |
||
|
Номер ответа: 86 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #86 | Добавлено: 08.08.07 04:49 |
|
shuffle
Хоть что -то из этого я написал? По моему я наооборот пытался внести объективность????
|
||
|
Номер ответа: 87 Автор ответа: shuffleАдминистратор ICQ: 201502381 Вопросов: 15 Ответов: 737 |
Профиль | | #87 | Добавлено: 08.08.07 05:05 |
|
Хоть что -то из этого я написал? Да, к тебе у меня нет претензий.
По моему я наооборот пытался внести объективность???? |
||
|
Номер ответа: 88 Автор ответа: W[4Fh]LFВопросов: 0 Ответов: 187 |
Web-сайт: Профиль | | #88 | Добавлено: 08.08.07 09:04 |
|
Чудно.
Давай еще сравним скорость работы драйвера написанного на NET?Если ты его хотя бы напишешь, я без всяких тестов сдамся
Ладно, если есть что сказать дельного, предложи конкретные и адекватные тестовые задания.
Типа 2+2 в цикле, которые вы уже проделали?
Подсчёт числа строк задание интересное и тут нужно уже подключить мозги, чтобы добиться нормальных результатов. Задача на подсчёт разрядов решается минимум 7ью, изместными мне, способами и самый очевидный из них - самый медленный. И с этими задачами, лично я, сталкивался в реальной практике не раз, а придумывать что-то новое у меня просто нет времени, через день я уезжаю на месяц, так что звиняйте
Могу ещё посоветовать откопать топик, где Sharp тестировал md5 и посоветовать что-нибудь на рекурсию. Но если в целом, вот, что я Вам скажу по теме, это моё ИМХО. Помимо всего прочего, выводы Ваши не верны, потому что вы развиваете цепочку в другом направлении. Во всех основных задачах на скорость компилятор лишь инструмент, быстрый алгоритм должен быть заложен изначально и взяться ему, кроме как из головы, неоткуда. В задачах, что я предложил, главный оптимизатор не компилятор, а ты. В компиляторе тут ценится совсем другое, я бы назвал это степенью свободы. И степень свободы обратнопропорциональна уровню языка(абстракции). Вдумайтесь в эти слова. Если на С/С++ задача решается десятью способами, выбирай только наиболее подходящий по скорости и размеру, то на .NET выбора такого не будет! Я всё прекрасно понимаю, я понимаю, что удобство и скорость разработки и, что за всё надо платить, НО если мы говорим про скорость, то .NET плох прежде всего этим. Ну и в конце-концов даже ваша самая простая конструкция, как в случае с вашим циклом, превращается в 12 команд ВМ и добросовестно исполняется 100000000 раз. Почему нельзя было использовать приёмы из компилятора С++ идушего в том же пакете? Не знаю. PS Медленне интерпритатор (соаременный) априори должен работать только при первом проходе. Делее он оперирует (по крайней мере такова идеология
) c родным кодом.Это называется Just-In-Time (JIT). Это не идеология, а технология
|
||
|
Номер ответа: 89 Автор ответа: SharpЛидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #89 | Добавлено: 08.08.07 12:33 |
|
W[4Fh]LF, аккуратнее, драйвер Windows не обязательно должен работать в ring0
|
||
|
Номер ответа: 90 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #90 | Добавлено: 08.08.07 16:31 |
|
W[4Fh]LF
Вот это другое дело. В задачах, что я предложил, главный оптимизатор не компилятор, а ты.
Хорошо зная слабые и сильные стороны... Тогда это будет больше состязанием программистов, имхо. Но и тест этот будет более объективным с определенной точки зрения. Подобное было на RSDN. Когда, например, Delphi опустили, но пришли гуру (из королевства) и заоптимизили код. Конечно, С++ не знает себе равных по различным подходам к реализации проблемы... Что касается поставленных задач, я с таким уже долгое время не сталкиваюсь. Но впрочем у каждого своя специфика (считать количество разрядов в числе и строк в файле - специфика wasmа. Если я угадал, с тебя пиво, если нет -с меня. )
На самом деле лучше поработать с md5, лично мне интереснее и юность вспомню.
Я готов написать тесты на Java. Потому как давно с ним не работал и сечас активно вспоминаю. Кто еще готов поучаствовать? |
||