Здравствуйте, samius, Вы писали:
C>>http://www.codeproject.com/KB/msil/MsilParser.aspx вполне себе пример. Пусть хотя бы такое простенькое на С++ сделают. S>На счет этого, я как раз не переживаю. Умельцы такое и на Delphi слабают и даже на том же C# без MSIL-а.
Слабать-то слабают — вопрос в производительности решения.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, samius, Вы писали:
S>>Компилятор можно и на Руби написать. S>>* Будет ли это только сравнение C++ и Руби? S>>* Сколько займет ресурсов написание простенького компилятора, который бы опередил JIT (хотя бы в рамках задачи)? A>неделю, не меньше
Добаляю этот пост в избранное, через неделю ждем первых результатов.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, samius, Вы писали:
S>>Компилятор можно и на Руби написать. S>>* Будет ли это только сравнение C++ и Руби? S>>* Сколько займет ресурсов написание простенького компилятора, который бы опередил JIT (хотя бы в рамках задачи)? A>неделю, не меньше
не меньше — однозначно.
А вообще, идея с собственным компилятором не так и плоха в контексте данной задачи. Например, имея собственный компилятор можно сделать решение на чистом SSE и прогонять через него сразу пачки векторов при отсутствии логики ветвления в описании геометрии. А то даже и GPU прикрутить.
Однако, ресурсы!!!
Здравствуйте, gandjustas, Вы писали:
S>>>* Сколько займет ресурсов написание простенького компилятора, который бы опередил JIT (хотя бы в рамках задачи)? A>>неделю, не меньше G>Добаляю этот пост в избранное, через неделю ждем первых результатов.
у нас очевидно сильно разные понятия о "простеньком". я говорю о компиляции математического задания поверхностей, это так, для уточнения.
ps. и еще я сразу сказал, что примеры посмотреть нельзя так что не ждите
Здравствуйте, samius, Вы писали:
A>>неделю, не меньше S>не меньше — однозначно.
а то
S>А вообще, идея с собственным компилятором не так и плоха в контексте данной задачи. Например, имея собственный компилятор можно сделать решение на чистом SSE и прогонять через него сразу пачки векторов при отсутствии логики ветвления в описании геометрии. А то даже и GPU прикрутить. S>Однако, ресурсы!!!
а вот это уже зависит от того, насколько критична производительность. полагаю, векторный обсчет на gpu может сильно перекрыть трудозатраты на разработку.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, samius, Вы писали:
S>>А вообще, идея с собственным компилятором не так и плоха в контексте данной задачи. Например, имея собственный компилятор можно сделать решение на чистом SSE и прогонять через него сразу пачки векторов при отсутствии логики ветвления в описании геометрии. А то даже и GPU прикрутить. S>>Однако, ресурсы!!! A>а вот это уже зависит от того, насколько критична производительность. полагаю, векторный обсчет на gpu может сильно перекрыть трудозатраты на разработку.
Не критична. Это я теоретизирую. В НИИ, где я работал несколько лет назад (откуда собственно задача), такому решению бы безусловно обрадовались, но их вполне устраивает интерпретатор, написанный на фортране кучу лет назад. Может и не устраивает, но что-то предпринимать по этому поводу они вряд ли будут.
Здравствуйте, Antikrot, Вы писали:
A>отлично, все как надо. абсолютно масштабируемая программа (итерации внешнего цикла-то независимые) A>у меня было 18 с чем-то секунд на 2х ядрах по 2.4GHz, у тебя 9 на четырех таких же
IID>>Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества. A>видел бы это Шеридан
[offtop]
Чтоб дойти до этой ветки Шеридану надо знать, что в результате полемики C# vs C++ в конкретной задаче получится нужный для его дальнейших войн вывод. А так, как для этого надо еще все ветки прочитать и даже заинтересоваться реализацией алгоритмов... ИМХО этого он не выдержит...
[/offtop]
and1 wrote: > IID>>Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества. > A>видел бы это Шеридан
> [offtop] > Чтоб дойти до этой ветки Шеридану надо знать, что в результате полемики C# vs C++ в конкретной > задаче получится нужный для его дальнейших войн вывод. А так, как для этого надо еще все > ветки прочитать и даже заинтересоваться реализацией алгоритмов... ИМХО этого он не выдержит... > [/offtop]
Я КСВ если и не читаю полностью, то хотябы пробегаю взглядом практически каждое сообщение.
По сабжу: я и так __вижу__, что дотнет приложения заметно тормозят на __любой__ технике. Лично мне кажется что надо быть самому
тормозом, чтобы этого не видеть. Либо надо быть программистом и писать при помощи дотнета. В последнем случае лишь самолюбие не
дает согласиться что таки да, софт тормозной выходит.
Здравствуйте, Sheridan, Вы писали:
S>and1 wrote: >> IID>>Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества. >> A>видел бы это Шеридан
>> [offtop] >> Чтоб дойти до этой ветки Шеридану надо знать, что в результате полемики C# vs C++ в конкретной >> задаче получится нужный для его дальнейших войн вывод. А так, как для этого надо еще все >> ветки прочитать и даже заинтересоваться реализацией алгоритмов... ИМХО этого он не выдержит... >> [/offtop] S>Я КСВ если и не читаю полностью, то хотябы пробегаю взглядом практически каждое сообщение.
S>По сабжу: я и так __вижу__, что дотнет приложения заметно тормозят на __любой__ технике. Лично мне кажется что надо быть самому S>тормозом, чтобы этого не видеть. Либо надо быть программистом и писать при помощи дотнета. В последнем случае лишь самолюбие не S>дает согласиться что таки да, софт тормозной выходит.
Не будь голословным. Сразу приводи название софта, который "заметно тормозит".
И сразу придумай определение заметности тормозов.
И желательно показазывай нетормозящие аналоги, а то пока сравнить не с чем тормоза условны.
Здравствуйте, minorlogic, Вы писали:
M>Ты не видишь очевидных вещей.
M>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок.
Очень спорное утверждение. Возможно средне-типовые задачи, типа сделать выборку и БД или простенькую формочку соединить со стандартным контролом делается пару кликов мыши, почти без кода.
Когда же наступает пора сделать что-то не поддерживаемое фреймворком, к примеру интегрировать Win32 DLL и кучей callback, то тогда идут мучения и сплошной маршалинг.
M>Поэтому высвободившееся время можно использовать для оптимизации на более эффективных алгоритмов.
Да?! Или на чашку кофе.
M>Именно поэтому когда доходит до реальных примеров, использования шарпа дает преимущество, а С++ прошлый век.
Большинство софта С++ и пока что переход на C# не намечается.
gandjustas wrote:
> Сразу приводи название софта, который "заметно тормозит".
rsdn@home vs. knode например
> И сразу придумай определение заметности тормозов.
Да тупо отрисовка и реакция на пользователя.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, minorlogic, Вы писали:
M>>Ты не видишь очевидных вещей.
M>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок. S>Очень спорное утверждение.
Не придуривайся, это уже давно факт.
S>Возможно средне-типовые задачи, типа сделать выборку и БД или простенькую формочку соединить со стандартным контролом делается пару кликов мыши, почти без кода.
Ты только таким занимаешься?
Под быстрым написанием кода имеется ввиду именно написание кода.
S>Когда же наступает пора сделать что-то не поддерживаемое фреймворком, к примеру интегрировать Win32 DLL и кучей callback, то тогда идут мучения и сплошной маршалинг.
И какой процет таких задач? В какого типа приложениях возникает? Какие мучения имеются ввиду?
Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?
M>>Именно поэтому когда доходит до реальных примеров, использования шарпа дает преимущество, а С++ прошлый век. S>Большинство софта С++ и пока что переход на C# не намечается.
Какого софта? Ты еще не усвоил по каким причинам некоторый софт пока на неуправляемых языках делается?
Здравствуйте, Sheridan, Вы писали:
S>gandjustas wrote:
>> Сразу приводи название софта, который "заметно тормозит". S>rsdn@home vs. knode например
Там тормозит нативная БД вроде как.
>> И сразу придумай определение заметности тормозов. S>Да тупо отрисовка и реакция на пользователя.
Тупо отрисовка — это сплошной нэтив. Считй что ты сравниваешь один нэтив фреймворк с другим.
Кстати, покажи в каком WPF приложении тормозит "тупо отрисовка".
Здравствуйте, gandjustas, Вы писали:
M>>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок. S>>Очень спорное утверждение. G>Не придуривайся, это уже давно факт.
Факт — в парочке компаний, а везде С++
S>>Когда же наступает пора сделать что-то не поддерживаемое фреймворком, к примеру интегрировать Win32 DLL и кучей callback, то тогда идут мучения и сплошной маршалинг.
G>И какой процет таких задач?
Очень большой, т.к количество производимого софта на C++ очень большое. Поэтому если надо что-то итегирирвать, то C++ в большинстве случаев предпочтительней.
G>Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?
Интерефейсы нужно делать на C, а внутри C++, тогда потрабельней.
S>>Большинство софта С++ и пока что переход на C# не намечается. G>Какого софта? Ты еще не усвоил по каким причинам некоторый софт пока на неуправляемых языках делается?
Практически весь софт, включая MS Office, Adobe, Skype, и пр. пишется на C++. Перехода на C# даже на горизонте нет
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
M>>>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок. S>>>Очень спорное утверждение. G>>Не придуривайся, это уже давно факт. S>Факт — в парочке компаний, а везде С++
Это вообще во всех компаниях. Отсуствие ручного управления памятью в разы увеличивает скорость разработки.
S>>>Когда же наступает пора сделать что-то не поддерживаемое фреймворком, к примеру интегрировать Win32 DLL и кучей callback, то тогда идут мучения и сплошной маршалинг.
G>>И какой процет таких задач? S>Очень большой, т.к количество производимого софта на C++ очень большое. Поэтому если надо что-то итегирирвать, то C++ в большинстве случаев предпочтительней.
Ну я несколько лет пишу на .NET, всего пару раз пришлось столкнутся с интеропом, проблем вообще никаких.
Сам то ты на .NET пишешь и интероп делаешь?
G>>Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi? S>Интерефейсы нужно делать на C, а внутри C++, тогда потрабельней.
Когда же наступает пора C++ интегрировать Win32 DLL и кучей callback, то тогда идут мучения и сплошной C.
S>>>Большинство софта С++ и пока что переход на C# не намечается. G>>Какого софта? Ты еще не усвоил по каким причинам некоторый софт пока на неуправляемых языках делается? S>Практически весь софт, включая MS Office, Adobe, Skype, и пр. пишется на C++. Перехода на C# даже на горизонте нет
Значит не усвоил.
S>>>>Большинство софта С++ и пока что переход на C# не намечается. G>>>Какого софта? Ты еще не усвоил по каким причинам некоторый софт пока на неуправляемых языках делается? S>>Практически весь софт, включая MS Office, Adobe, Skype, и пр. пишется на C++. Перехода на C# даже на горизонте нет G>Значит не усвоил.
Я понимаю ваше волнение и пережвание из-за неверно выбранной специализации. Тут вомногом виноват MS со своей промывкой мозгов.
Ну ничего, можно еще бросить этот убогий C#. Переходите хоть на Питон.
gandjustas wrote:
>>> Сразу приводи название софта, который "заметно тормозит". > S>rsdn@home vs. knode например > Там тормозит нативная БД вроде как.
И изза этого окно при перетаскивании не отрисовывалось?
> Тупо отрисовка — это сплошной нэтив. Считй что ты сравниваешь один нэтив фреймворк с другим.
И что? Это както лишает приложение тормозов?
> Кстати, покажи в каком WPF приложении тормозит "тупо отрисовка".
В любом. ___Любое___ дотнет приложение, которое я когда-либо видел — так или иначе тормозило.
Здравствуйте, Sheridan, Вы писали:
S>gandjustas wrote:
>>>> Сразу приводи название софта, который "заметно тормозит". >> S>rsdn@home vs. knode например >> Там тормозит нативная БД вроде как. S>И изза этого окно при перетаскивании не отрисовывалось?
???
Это надо как-то особенно писать, .NET по-умолчанию так не умеет.
>> Тупо отрисовка — это сплошной нэтив. Считй что ты сравниваешь один нэтив фреймворк с другим. S>И что? Это както лишает приложение тормозов?
Это как-то связано с .NET?
>> Кстати, покажи в каком WPF приложении тормозит "тупо отрисовка". S>В любом. ___Любое___ дотнет приложение, которое я когда-либо видел — так или иначе тормозило.
Это вообще философский вопрос. Любое приложение так или иначе тормозит, потому что его скорость работы конечна.
Более того, все компьютеры тормозят и тормозить будут всегда, потому что конечна скорость света.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>>>Большинство софта С++ и пока что переход на C# не намечается. G>>>>Какого софта? Ты еще не усвоил по каким причинам некоторый софт пока на неуправляемых языках делается? S>>>Практически весь софт, включая MS Office, Adobe, Skype, и пр. пишется на C++. Перехода на C# даже на горизонте нет G>>Значит не усвоил.
S>Я понимаю ваше волнение и пережвание из-за неверно выбранной специализации. Тут вомногом виноват MS со своей промывкой мозгов.
Не завидуй.
S>Ну ничего, можно еще бросить этот убогий C#. Переходите хоть на Питон.
Да я и так питон пользую.
Здравствуйте, gandjustas, Вы писали:
M>>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок. S>>Очень спорное утверждение. G>Не придуривайся, это уже давно факт.
Расскажи это индусам. А то они не знают и говнокодят на шарпе так, что только брызги летят.
G>И какой процет таких задач? В какого типа приложениях возникает? Какие мучения имеются ввиду? G>Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?
Пример с CreateThread в который передается метод в качестве функции потока тебя устроит?
