 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
Zippo()
Guest
|
 Posted: Wed Apr 30, 2008 5:24 am Post subject: |
 |
|
| holomind wrote: | | have you done some speed-tests to see if it actually got slower ? |
Thought it would be pretty obvious. Any time you do 2 things when you could be doing one, it takes longer. But to help satisfy your curiosity:
| Code: | F1::
StartTime := A_TickCount
Loop 100000
DllCall("GetTickCount", UInt, 0)
MsgBox % A_TickCount - StartTime
Return
F2::
StartTime := A_TickCount
Loop 100000
GetTickCount()
MsgBox % A_TickCount - StartTime
Return
GetTickCount() {
Return DllCall("GetTickCount", UInt, 0)
} |
The braces that are needed for the GetTickCount() function are probably adding to the difference also. I've done other tests that show the mere presence of braces can effect the speed of functions that do the exact same thing. Not that it makes a difference in that little test as the braces in the function are not optional. |
|
| Back to top |
|
 |
holomind
Joined: 11 Mar 2006
Posts: 299
Location: Munich, Germany
|
| Posted: Wed Apr 30, 2008 9:24 am Post subject: |
|
|
@zippo: thanks for your speed-test and explanaition. on my pc i get a difference of about 40% which is not too small. but perhaps its not too realisitic, as gettick is very fast compared to the time the function call needs for its overhead (stack manipulation etc.).
my theory still is, that time spent inside the dll (eg. redrawing the scene) ist longer than the overhead by the indirection through the functioncall.
maybe one could have some "just-in-time" compiler, which expands the "eyecandy"-functions to real dll-calls. by copying the script and replacing all functions which are defined by dllcalls into their full expression. then the "optimized" script would be runned. the way this function-calls and dllcalls work is very strict and systematic and it should be easy to write such a "pre-compiler", to even save more time, it could test the last-modified-time of the original and the optimized script and only re-compile it on demand.
like adding one include-file at the beginning, "include "optimize-dllcalls". which expands the script into a "native" dllcall version and then runs this script and terminates the first one.
then you would get the benefit of eyecandy copy-paste opengl (c-syntax) and full speed without bloat and function-call overhead.
(perhaps this replacing can be done with some smart regex-replaces ?)
this little just-in-time function-extraction is interesting (not useless, no nonsens) as it would work with all scripts which use dll-call-wrappers and therefore can speed them up a bit. (but i guess the improvement will be in a range of 5% -50% increase in speed).
there will be a little overhead for recompiling (some stringreplaces) the script, but only if you modify your source-script.
if this idea works good it could be rewritten in c and be added as feature into ahk-core. |
|
| Back to top |
|
|
SomeGuy
Joined: 21 Apr 2008
Posts: 94
Location: somewhere
|
| Posted: Wed Apr 30, 2008 10:49 pm Post subject: |
|
|
putting
inside the main loop reduces the idle cpu usage on my machine to about 3%....without it it consumes about 25% all the time...It does not cause any noticeable side effects such as lag. (at least here) |
|
| Back to top |
|
|
Zippo()
Guest
|
| Posted: Wed Apr 30, 2008 11:20 pm Post subject: |
|
|
I think tinkering with the source code just to parse wrappers in scripts is taking it to the extreme a little 
99.9% of the scripts posted on this forum would see absolutely no benefit in having any wrappers removed. As a matter of fact, it would probably introduce more problems than it would fix.
That is because most scripts don't wrap 100+ DllCalls. And for the very few that might wrap a large number of them, they usually call the wrapper one time and then stop and wait for something (button click, mouse movement, message box... see where it is going?).
Wrapping all those calls in OpenGL is a performance hit in a section of the code that is most likely to be the bottleneck of the entire script. It doesn't matter if you are spending more time in the OpenGL library than you are in the section of the script that calls the library. You are calling the draw sections many times a second. The time it takes to call the dummy wrapper, which then calls the original DllCall, is still added to the overall performance hit.
Rather than rewriting the AHK source to take out wrappers, it would be better if the person writing the script knew when to tweak it. There is a point that it makes no sense to bother with it. Take this for example:
| Code: | x_m := sector1_triangle%A_Index%_vect3_x
y_m := sector1_triangle%A_Index%_vect3_y
z_m := sector1_triangle%A_Index%_vect3_z
u_m := sector1_triangle%A_Index%_vect3_u
v_m := sector1_triangle%A_Index%_vect3_v
glTexCoord2f(u_m, v_m)
glVertex3f(x_m, y_m, z_m) |
We could maybe get a little better performance with:
| Code: | glTexCoord2f(sector1_triangle%A_Index%_vect3_u, sector1_triangle%A_Index%_vect3_v)
glVertex3f(sector1_triangle%A_Index%_vect3_x, sector1_triangle%A_Index%_vect3_y, sector1_triangle%A_Index%_vect3_z) |
Are you going to parse all of those instances for people also? And why even bother to change one part but leave the wrappers or vice versa?
Throwing out a bunch of wrappers without any oposition just seems wrong to me, considering that you can see excatly what is going on in the DllCalls anyhow. Not to mention that wrapping all of them to start with is about as fun as watching paint dry.
Again, that's just my 2 pennies. |
|
| Back to top |
|
|
Zippo()
Guest
|
| Posted: Wed Apr 30, 2008 11:38 pm Post subject: |
|
|
| SomeGuy wrote: | putting
inside the main loop reduces the idle cpu usage on my machine to about 3%....without it it consumes about 25% all the time...It does not cause any noticeable side effects such as lag. (at least here) |
And so far the most advanced example draws 36 triangles per DrawGLScene() call, with no transparencies or filtering at 16 bits in 640x480 mode with a texture size of 256x256. You could run that on an Atari 2600 
Even with Sleep, 1 with an OS granularity of ~10ms, that is still around 100 fps. |
|
| Back to top |
|
|
holomind
Joined: 11 Mar 2006
Posts: 299
Location: Munich, Germany
|
| Posted: Thu May 01, 2008 8:34 am Post subject: |
|
|
| Zippo() wrote: | | I think tinkering with the source code just to parse wrappers in scripts is taking it to the extreme a little |
i like to think in extremes and scratch the edge of the possible. now we have opengl in AHK, one year ago it was hard, as the knowledge was not in the forum.
The discussion is interesting, because it may help to improve the performance of AHK in general. if also removing temporaray variables will improve speed, this should be done one the core-level and auto-optimize.
but here is a catch. i choose AHK over c/c++/c#, because of its simplicity and not because of its speed. if i want really speedy apps i would write in assembler and tweak with registers, or use c and use a good compiler and optimizer. But then i never would finish even one script. there is a reason for high-level languages and AHK is in a sense more highlevel than basic. as you can write a whole application in one line. (press key , do something) and that is the real strength of it. doing opengl in AHK is really fun, but not the strength of the language. but seeing that the script runs 30-triangles (with texture) in 100Frames proves that even the not so optimized AHK-interpreter lanuage is fast enough. Also many windows-applications were written in Visual-Basic and not c or c++ because of the faster speed in development (easyness) because most of the time you call api-functions and therefore most of the time you spend in optimized c-code (inside the dll). (in theory  . I have written programs in GFA-Basic earlier on my Amiga, and it had the feature to interpret the program or to compile it. (similar to create an .exe out of ahk) and some scripts got speedier by a factor of 10 or 100 because of optimization. the ideal solution would be to optimize the parser which generates .exe out of .ahk and there remove all unneeded indirections with a automatic code-optimizer. (but this is not an easy job i guess). |
|
| Back to top |
|
|
Zippo()
Guest
|
| Posted: Thu May 01, 2008 10:38 am Post subject: |
|
|
| holomind wrote: | | ...but here is a catch. i choose AHK over c/c++/c#, because of its simplicity and not because of its speed... |
Here is my take on the language wars:
| A Lost Scripture wrote: | And God said unto them, "Let it be fast."
And the ASM programmer said, "It is fast."
And the Basic programmer said, "It is slower than assembly, but it gets done faster and is easier to maintain."
And the C programmer said, "It is slower than Basic, but it gets done faster with a few less errors."
And the C++ programmer said, "It is slower than C, but it gets done faster, with less errors and is easier to reuse."
And the C# programmer said, "It is slower than C++, but it is multi-platform and gets done faster."
And the VB programmer said, "It runs like @&#$. But I can get it to you for 1/2 off the regular price." |
As for this:
| holomind wrote: | | but seeing that the script runs 30-triangles (with texture) in 100Frames proves that even the not so optimized AHK-interpreter lanuage is fast enough. |
You forgot:
| Quote: | | with no transparencies or filtering at 16 bits in 640x480 mode with a texture size of 256x256. You could run that on an Atari 2600 |
But if you don't care about speed, there is no point in continuing this discussion. Happy coding |
|
| Back to top |
|
|
tic
Joined: 22 Apr 2007
Posts: 1318
|
| Posted: Thu Jun 05, 2008 5:39 pm Post subject: |
|
|
It runs quite slow on this 2GHz P4 and uses 80% cpu even when idle.
I dont think you should completely try and emulate the c code. i think its quite nasty calling a function and having it loop continually calling another function within that function. and having all global functions is also nasty. i know it allows the enumeration to not have to be sent, but its not very nice. Is there any reason why CreateWindowEx is used rather than just creating a standard gui? As that function hasnt currently allowed WS_EX_LAYERED to be set, but all of that stuff can just be set with standard ahk code...?
So, would we be able to try and get it to update a layered window so that we create non-standard guis. I would like that. Ill give it a try later when I'm on a better PC 
I did like the "doomed" example though |
|
| Back to top |
|
|
Zippo
Joined: 21 Apr 2006
Posts: 56
Location: East Coast, USA
|
| Posted: Thu Jun 05, 2008 11:50 pm Post subject: |
|
|
I tried (for all of about 5 minutes) to get it working with a standard GUI. I meant to go back and try again but I keep forgetting. Maybe someone else has that working though. One thing you'll probably have to do is change the class attributes of the GUI to include CS_OWNDC.
I've kind of put it on the backburner until OpenGL 3.0 is released. That might happen before 2010 :/
_________________
____________________ |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
