Скорость вызова DLL

[DarkInside]

Зависит ли от количества функций в DLL и насколько зависит?

[Randomize]

Зависит на сто процентнов.

А если серьёзно, то попробуй описать возникшую проблему, вместо таких абстрактных вопросов.

[DarkInside]

Ну, дело обстоит таким образом. Мне нужно быстрое вычисление площади многоугольников. Начал копать в сторону вычислений на шейдерах. Нашел на PureBasic отличную библиотеку GPUCalc, да и на CUDA там есть примеры. Всё понятно, всё по полочкам (в отличие от того же PyOpenCL на питоне, в котором еще разбираться надо пол года). Хочу собрать это всё в DLL и подцепить к блицу. Ну и заодно вычисления на double запихать в эту либу. (Потестил double в х64 PureBasic на возведениях в степени и извлечение корней - в 10 раз быстрее, чем в блице, это еще я один поток задействовал, сейчас разбираюсь с остальными 7-ю). Так вот собственно не хотелось бы терять производительность на обмене с DLL.
- Получается, чем меньше функций в одной DLL, тем лучше? То есть лучше их разбить на несколько или всё в одну DLL запихать?
- Что быстрее decls или CallDll? Или без разницы?
- Если я DLL из ОЗУ буду считывать, будет сокращение задержек на чтение? или SSD в принципе не является узким местом?

[mr.DIMAS]

дллка загружается в адресное пространство приложения и следовательно скорость загрузки зависит от количества функций

upd. скорость вызова функций не зависит от их количества в длл

[DarkInside]

дллка загружается в адресное пространство приложения

То есть она польностью загружается при первом вызове любой функции? Это через decls? А через CallDLL что меняется? То есть нет смысла её сначала грузить в ОЗУ и потом оттуда считывать функции? Я просто думал при каждом вызове функции прога обращается к файлу DLL.

[mr.DIMAS]

Не при первом вызове, а при вызове LoadLibrary WinAPI. Либо при загрузке виндой экзешника с прилинкованной дллкой. Деклсы блица это и есть неявный вызов LoadLibrary c кучей GetProcAddress. CallDLL скорее всего позволяет делать все ручками.

[impersonalis]

Загрузка DLL может быть статической, а может - динамической.
Статическая (она же "неявное подключение"): загрузка dll происходит при загрузке exe; для сборки приложения компоновщику необходима библиотека импорта. (Аналог в блитце - decls-файл.) (например, так реализуется работа с MAT-файлами.)
Динамическая: для загрузки нужна только dll; используются API-функции ОС (типа, LoadLibrary, GetProcAddress, FreeLibrary); загрузка происходит с использованием имён функций. (Аналог в блитце - CallDLL.)

В зависимости от ситуации, удобно то одно, то другое.

Ну, в общем, это mr.DIMAS и сказал.

[DarkInside]

Удобно то понятно. Потери скорости где меньше?

Тут оказывается даже если вынести код в функцию (в блице), уже теряется 4% производительности на вызов этой функции. А если функция обращается к другой функции, то уже 8% ... и тд. Сколько будет теряться на DLL?

Вот это: d# = Exp(0.37*Log(d#)) на 4% быстрее, чем вот это:

d# = sqrt#(d#, 0.37)

Function sqrt#(a#, n#)
	Return Exp(n#*Log(a#))
End Function

Кстати, такое извлечение корня у меня на 10% быстрее, чем d# = d# ^ 0.37

А в PB извлечение корня по модулю: Pow(d.d, 0.37) наоборот в 1.5 - 2 раза быстрее, чем Exp(0.37*Log(d.d)). Ну и в 10 раз быстрее, чем в блице. Ну и точность double.

Боюсь предположить, насколько быстр Intel® Fortran Composer XE. Поговаривают, он обходит GCC (С/C++) процентов на 40. И в Cern ПО для обработки данных с коллайдера на фортране.

[mr.DIMAS]

Вот поэтому критические по скорости приложения и пишут на C\C++

[DarkInside]

Да, но пока я выучу и напишу программу на С\C++, программа на PB уже всё посчитает. Да и не думаю, что PB сильно отстает от C, ну может раза в 2. Тут тоже компилятор х64 хорошо оптимизирован.

Например, вот такие вещи он не будет обрабатывать:

For i = 1 to 10000000
v.d = Pow(v.d, 2)
v.d = Pow(v.d, 0.5)
Next

Тк понимает, что это обратная операция и ни к чему она не приведет.

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

Мда... FreeBasic быстрее, чем PureBasic в 4 раза, то есть в 40 раз быстрее, чем блиц. В папке с FreeBasic лежит gcc.exe, но в википедии написано, что у него свой компилятор.

Скоро до Фортрана доберусь...

Вот чем мне нравятся бейсики: открыл, написал, даже не заглядывая в хелп и запустилось, минут 15 у меня ушло на освоение нового бейсика - тупо чтоб найти функцию системного времени. На питон 2 дня только пытался установить модуль. Кстати, надо на нем тоже потестировать, но имхо он медленный.

Dim TimerStart As Single = Timer()

Dim d As Double = 3324325235.534534

For i As Integer = 0 To 100000000
d = d ^ 0.37
Next

Print Timer() - TimerStart
Sleep

[Nex]

Сообщение от DarkInside

Вот чем мне нравятся бейсики: открыл, написал, даже не заглядывая в хелп и запустилось

Открой уже VS с C#. Тот же бейсик если не использовать всякие ооп штуки. Можно даже в дань традициям написать всё в одном главном файле на массивах. И скорость работы будет больше, меньше вопросов по уже не актуальным ЯП и в интернете будут ответы на все вопросы.

[DarkInside]

C# медленный, .net же, не могу представить, для чего он мне. Кстати, PB на хабре называют "си-подобным бейсиком". Зная PB, можно перейти на С. Но опять же на PB я уже почти разобрался с вычислениями на GLSL и мне всего лишь надо всё оформить. А вычисления на CPU в PB, конечно, чуть медленнее, чем на C, но FreeBasic в 4 раза быстрее PB, а значит где-то на уровне GCC С++. И потоки на FB тоже из коробки и удобно реализованы. Вставки Си, вставки Asm, строки Си, библиотеки Си - всё это есть на FB. То есть смысл сейчас заморачиваться и разбираться в Сях, для того, чтобы написать библиотеку на 100 строчек, когда всё уже готово и разжевано? Когда-нибудь в другой раз, когда задача будет посерьезнее.

И да, сообщество FB реально озабочено производительностью, поэтому он не может быть медленным. У них подход следующий: многие быстрые функции стырены из библиотеки Си (например, возведение в степень поэтому такое быстрое), потом сообщество пилят на ASM'e свои функции в попытках обогнать Си, получается, конечно, редко, но всё же. Я его и отрыл то, когда гуглил быстрые строковые алгоритмы.

Sub ONE(param As Any Ptr)
Dim a As Integer
Do
a+=1
View Print 1 To 2
Print "thread One, a=";a
Sleep(70)
If a=100 Then Exit Do
Loop
Print "Thread ONE ended "
End Sub
Sub TWO(param As Any Ptr)
Dim a As Integer
Do
a+=1
View Print 3 To 4
Print "thread TWO, a=";a
Sleep(50)
If a=100 Then Exit Do
Loop
View Print 3 To 4
Print "Thread TWO ended "
End Sub

Threadcreate(@ONE())
Threadcreate(@TWO())
Sleep

[h1dd3n]

Ocaml такой крутой что в 1 рейтинге занял 1 и 3 позицию одновременно? Вот это он молодец!

[DarkInside]

Ocaml из коробки предлагает на выбор, что делать с кодом:
a) интерпретировать
b) компилировать в машинный код
c) компилировать в байт-код
d) выкинуть нахер и забыть как страшный сон

Очевидно, что на первом месте компилятор, на третьем - интерпретатор. http://www.ibm.com/developerworks/ru...8_2/index.html

[h1dd3n]

Это был намек на то что данный рейтинг херня полная.
Java и Scala оба компилируются в байткод jvm, и оптимизации к ним потом применяются абсолютно одинаковые. JIT компилятор jvm (java/scala) надо "прогреть", только тогда будут применены оптимизации. Сравнивать скорость языков/платформ по сраному рекурсивному фибоначи может только конченный рукожоп.