AutoIt и многоядерные процессоры: предвидися ли поддержка?

[Garrett]

Kalisnik [?]

интересно было бы узнать Ваше мнение

чем более быстрый код будет у ЯП, тем лучше

Если не в ущерб скорости, то лучше ASM или Си

но при этом не в ущер дружелюбности самого ЯП по отношению к пользователю

Тут думаю VB. Как ни как, а это детище дяди Билла, а его концепция как не крути это дружелюбие и удобство по отношению к пользователю. Хотя и по скорости много IMHO не проиграет Си

 

[kaster]

Garrett
скорость имеется в виду скорость арифметических операций. Assembler это конечно круто, но в нем не пишут, как ни странно, большие программы. Так, драйверы всякие. Потому как время на разработку кода не оправдывает отдачи от этого кода. Поэтому все главные расчетные программы в лабораториях CERN'a написано на fortran или Matlab+Fortran.


Добавлено:

Сообщение автоматически объединено: 25 Окт 2010

кстати вот неплохой обзор про преимущества Fortran. COMPARISON OF FORTRAN AND C

 

[Yuri]

Kalisnik
Как вариант, можно еще глянуть в сторону PureBasic.
Только он коммерческий, т.е. платный.

 

[Yashied]

Поэтому все главные расчетные программы в лабораториях CERN'a написано на fortran или Matlab+Fortran.

OffTopic:
Вот они и не могут никак запустить свой коллайдер... Вот установили бы AutoIt, и все было бы OK.

 

[kaster]

OffTopic:
Yashied

 

[Garrett]

Kaster [?]

Так, драйверы всякие.

Не только!

Потому как время на разработку кода не оправдывает отдачи от этого кода.

Тут думаю главный критерий не время, а среда и удобство программирования! Так же немаловажным аспектом, является то, что на Fortran`е написаны тысячи и тысячи готовых решений, которые конвертировать на другие ЯП не имеет смысла! Fortran это один из первых (если не первый) ЯП высокого уровня, который создан и применяется очень давно! Отсюда и:

главные расчетные программы в лабораториях CERN'a

 

[Luke]

Некоторые современные компилируемые BASIC-ки думаю не уступают в скорости С++ (типа FreeBASIC), но выучить их помоему сложнее чем С, т.к. для него куча примеров, книг , и пособий. А синтаксис современных бейсиков уже не так прост как был когда -то, пробовал визуалбайсик - ужас какой то, мне не понравился , тем более он не компилируется (.NET). В результате научился писать простенькие длл-ки на С, и без ООП можно. А по скорости ассемблер полюбому быстрее всех. Да кстати в Python нет настоящей многопоточности - два ядра скорости не добавляют, но было бы очень неплохо если б в АutoIt реализовали многопоточность хотя бы как в Python (с переключением потоков).

 

[kaster]

Garrett [?]

Не только!

Хотелось бы посмотреть на этих мазохистов ;D можно примерчики?
Luke [?]

Да кстати в Python нет настоящей многопоточности - два ядра скорости не добавляют

А кто сказал что многопоточность это скорость? Такой простой пример демонстрирующий недостаток многопоточности в, скажем, AutoIt - попробуй создать GUI c обработкой большого файла по нажатию кнопки. Как думаешь, что произойдет с этим GUI пока файл обрабатывается? ;)

 

[Garrett]

Kaster [?]

Хотелось бы посмотреть на этих мазохистов ;D можно примерчики?

Miraculix


Добавлено:

Сообщение автоматически объединено: 26 Окт 2010

Кстати в будущем разработчики планируют прикрутить к ней компиляторы C/C++, Basic, Pascal.

 

[kaster]

Garrett
При всей ее крутости
а) это сборник разных программ
б) часть из которых - это драйвера
в) небольшой размер (1 дискета ;D)
и соответственно не совсем подходит под "большую" программу, хотя сказал я это конечно более-менее в общей и расплывчатой форме.
Твой ликбез про Fortran я почитал Только не понял, к кому оно было адресовано. И кстати с одним из "тезисов" я не согласен. "Тысячи и тысячи готовых решений" не переводят на другие ЯП не потому что

Fortran это один из первых (если не первый) ЯП высокого уровня, который создан и применяется очень давно!

и в одном из современнейших и мощнейших научных центров мира сидят не закоренелые консерваторы какие, которые не сведущи или не хотят ничего другого кроме Fortran, потому как он им "близок", а потому что он быстрее считает. А переписать любые из фортрановских библиотек под другие ЯП можно и давно уже сделано. Тот же lapack имеет реализации как в С, так и в python, и т.д. Но ценность самого Fortran от этого не уменьшилась. Говорю это в силу специфики своей (уже бывшей) работы приходилось искать наиболее оптимальные и быстрые решения очень тяжеловесных физикохимических расчетов.

и вот еще

Тут думаю главный критерий не время, а среда и удобство программирования!

что за среда? среда разработки? под АСМ есть достаточно удобные IDE, со многими присущими современным, фичами. И если время не главное, то за те десятилетия что существует АСМ, кто нибудь уже написал бы огромный проект потратив несколько лет тупо на кодинг, заимев один из "тех" удобных средств для программирования. Однакож, пока что драйвера да Miraculix :whistle:
потому что, мое мнение - человек должен ценить свое время.

 

[Luke]

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

 

[kaster]

Luke
паралелить, то бишь разбить задачу на подзадачи для разных ядер/процессоров немного отличается от многопоточности. но в любом случае умение грамотно распаралелить код - это на грани искусства. Можно поинтересоваться как ты это сделал? А то пока складывается ощущение, что ты запустил один и тот же (однопоточный) код на разных машинах с одним и двумя процессорами (ядрами) и ждешь ускорения.

 

[Luke]

Скопировал тут http://habrahabr.ru/blogs/python/84629/
Как вариант в AutoIt можно добавить аналог модуля multiprocessing из Python, для некоторых задач подойдет (сложные вычисления), но не для всех.

 

[kaster]

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

 

[Garrett]

Kaster [?]

При всей ее крутости а) это сборник разных программ б) часть из которых - это драйвера в) небольшой размер (1 дискета ) и соответственно не совсем подходит под "большую" программу, хотя сказал я это конечно более-менее в общей и расплывчатой форме.

Перепишете Miraculix на Fortran, и будет "большая" программа.
А Windows:
a) это НЕ сборник разных программ
б) часть из которых - это НЕ драйвера
Только что размер у неё очень "большой"

Твой ликбез про Fortran я почитал Только не понял, к кому оно было адресовано.

Это мысли в слух! Мы здесь общаемся, вот я высказал свои мысли!

и в одном из современнейших и мощнейших научных центров мира сидят не закоренелые консерваторы какие, которые не сведущи или не хотят ничего другого кроме Fortran, потому как он им "близок", а потому что он быстрее считает

Быстрее Assembler`a?

 

[kaster]

Garrett [?]

Перепишете Miraculix на Fortran, и будет "большая" программа.

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

Быстрее Assembler`a?

оставь уже ассемблер в покое ;D быстрее С и любых других ЯП на базе скалярных вычислений.

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

 

[Yashied]

Программы на ассемблере под Windows практически никто не пишет. Только если очень небольшие утилиты. Ассемблер обычно используют внутри ЯП высокого уровня, для написания каких-либо кусков кода, так сказать, для расширения возможностей. Это можно сравнить (грубо), как WinAPI внутри AutoIt. Я раньше довольно часто писал программы на ассемблере, но то были программы для MS-DOS (лучший способ создать резидентную программу). IMHO самое оптимальное для Windows (естественно после AutoIt ) - С/С++.

Конечно же Fortran будет быстее производить математические расчеты по сравнению с тем же ассемблером (если вы только ни гений машинного программирования), ведь он для этого и предназначен. Но с другой стороны можно сказать, что сам Fortran написан на ассемблере... Вообще, ассемблер - ЯП низкого уровня и на нем можно сделать абсолютно все, что и в любом ЯП высокого уровня. Но вот вопрос: оно собственно надо? Каждый ЯП предназначен для своих целей, и нужно их использовать соответственно. Глупо писать DirectX игрушку на ассемблере, или расчитывать полет на Марс в AutoIt или VBS.

P.S

Хотя в AutoIt можно все.

 

[Kalisnik]

Kaster AND Garrett

Поставил PureBasic. За день чуть-чуть ознакомился с синтаксисом (благо что он весьма схож с AutoIt'ом). Вот сравнительные тысты для цикла:

Код AutoIt:

Dim $q, $TimerS, $TimerE

$TimerS = TimerInit()


For $i = 1 To 100000000
	$q += 1
	if $i = 100000000 Then
		$TimerE = TimerDiff($TimerS) / 1000
		$TimerE = Round($TimerE, 2)
		MsgBox(0, "", $TimerE)
	EndIf
Next

Время выполнения этого кода у меня в отладчике (F5): 109.97 с.
Время выполнения исполняемого файла: 106.01 с.

Вот часть кода PureBasic с таймером:

TimerStart = ElapsedMilliseconds()
      For i = 0 To 100000000
        Pi = Pi + 1
        If i = 100000000
          TimerStop = ElapsedMilliseconds() - TimerStart
          Dub = TimerStop / 1000
          SetGadgetText(#String_0, StrF(Dub, 2))
        EndIf
      Next

PureBasic отладка (F5): 19.28 с.
PureBasic исполняемый файл: 0.51 с. !!!

Kaster интересно было бы что-то подобное сравнить и с С/С++ и Fortran

CPU Q8400, Win7 x64

 

[Yashied]

Kalisnik

AutoIt - интерпритатор, а PureBasic - компилятор. Как говорится, две большие разницы.

P.S

А то, что время в исполняемом файле равно 0.51 сек, то это видимо заслуга компилятора, который просто вырезал этот бестолковый цикл.

 

[Kalisnik]

Yashied
Это все понятно... просто я сейчас ужаснулся сколько времени у меня уходило в AutoIt на подобных циклах. Но в плане синтаксиса, да что там говорить - удобности, AutoIt чувствую лидер! Еще в PureBasic мне не понравилась заморочка с определением типа переменной... а чем я совсем не думал в AutoIt. Вывод таков: в автоматизации лучше AutoIt'а не придумать!... а вот считать надо на чем-то другом :whistle:

P\s: :IL_AutoIt_1: - для спокойствия модераторов. )))


Добавлено:

Сообщение автоматически объединено: 26 Окт 2010

Yashied
Можно так...

TimerStart = ElapsedMilliseconds()
      For i = 0 To 100000000
        Pi = Pi + 1
        If Pi = 100000001
          TimerStop = ElapsedMilliseconds() - TimerStart
          Dub = TimerStop / 1000
          SetGadgetText(#String_0, "Время: " + StrF(Dub, 2) + " Счетчик: " + Str(Pi))
        EndIf
      Next

Исполняемый файл: 0.58 с.

Кстати, если к "For To" добавить еще нолик, то время выполнения исполняемого файла: 5.57 с.