Latest Beta

[jaberwacky]

Here a test script I wrote where you can see the FPS counter. Best performance I get is when running it with x64 and Beta!

EDIT: Nevermind, I'm a big doofus. Ok, no improvements were made. I forgot to remove the i+= 1 from the function. When I do that then the FPS goes back down.

If I run your script on x64 and beta then I get around 18 fps. However if I modify the Draw_Stars function to use a for loop then it jumps up to 32 fps!

expandcollapse popup

Func Draw_Stars()
    $fps_timer = TimerInit()

    $idle_n = _Timer_GetIdleTime()

    If $idle_n < $idle_o Then _exit()

    $idle_o = $idle_n

    Local $newx, $newy, $i, $c

    GUISetCursor(16, 1, $hGUI)

    _GDIPlus_GraphicsFillRect($hGraphic, 0, 0, $iW, $iH, $hBrush)

    For $i = 0 To $maxStars - 1
        $aStars[$i][0] += $aStars[$i][0] / $speed
        $aStars[$i][1] += $aStars[$i][1] / $speed
        $aStars[$i][2] += $r
        $newx = $aStars[$i][0] + $iW2
        $newy = $aStars[$i][1] + $iH2
        $c = Hex(Min($aStars[$i][2], 0xFF), 2)
        _GDIPlus_PenSetColor($hPen, "0xFF" & $c & $c & $c)
        _GDIPlus_GraphicsDrawEllipse($hGraphic, $newx, $newy, 1, 1, $hPen)
        If $newx < 0 Or $newx > $iW Or $newy < 0 Or $newy > $iH Then NewStars($i, $iW2 * _Random(0.75, 1.25, 0.95, 1.05), $iH2 * _Random(0.75, 1.25, 0.95, 1.05), $iW2 * _Random(0.75, 1.25, 0.95, 1.05), $iH2 * _Random(0.75, 1.25, 0.95, 1.05))
        $i += 1
    Next

    $fps_diff = TimerDiff($fps_timer)

    If TimerDiff($fps_maintimer) > 499 Then ;calculate FPS
        $fps = Int(1000 / $fps_diff)
        $fps_maintimer = TimerInit()
    EndIf

    _GDIPlus_GraphicsDrawStringEx($hGraphic, $fps, $hFont, $tLayout, $hFormat, $hBrush_Text)

    _WinAPI_BitBlt($hDC, $main_screen_x, 0, $iW, $iH, $hDC_backbuffer, 0, 0, $SRCCOPY)
EndFunc   ;==>Draw_Stars

Edited June 8, 2011 by LaCastiglione

[Ascend4nt]

LaCastiglione, your function does indeed work faster. (*or so it seemed lol)

However, I'm not seeing any of the performance gains other people are claiming to see with the latest betas - the fps on both of those versions remains consistent.

Also, one odd thing about the 64-bit version of AutoIt is that it consistently runs slower for all programs I test. I'm starting to wonder if this has to do with the processor itself. It's an older model (Q6600), so perhaps the CPU itself was optimized more for 32-bit code. Intel may have needed one or two more generations to get 64-bit optimizations perfected..

Edited June 8, 2011 by Ascend4nt

[jchd]

As an unrelated to AutoIt sidenote, we see 6 .. 7% speed improvement by compiling the C source of SQLite as a single huge preprocessed source (called the amalgamation) versus compiling the same headers/code source files using the same version and options of a compiler. Executable size is also reduced. This is of course due to recent compilers being able to devise much more clever optimizations when they "see" the whole picture at once, instead of being forced to generate conservative code in separate compilation units. AFAIK the best performer in this area is gcc but I'd love to try Intel compiler.

Edited June 9, 2011 by jchd

[jaberwacky]

LaCastiglione, your function does indeed work faster. (*or so it seemed lol)

Well, when I leave in the i += 1 doesn't skip half of the stars?

However, I'm not seeing any of the performance gains other people are claiming to see with the latest betas - the fps on both of those versions remains consistent.

I didn't either. I have an AMD Athlon 64 X2 5000+ BE.

Also, one odd thing about the 64-bit version of AutoIt is that it consistently runs slower for all programs I test. I'm starting to wonder if this has to do with the processor itself. It's an older model (Q6600), so perhaps the CPU itself was optimized more for 32-bit code. Intel may have needed one or two more generations to get 64-bit optimizations perfected..

I'm lost in that techno jungle.

[UEZ]

Well, my fps calculation was probably not good and I changed the code a little bit.

Sorry,

UEZ

Edited June 9, 2011 by UEZ

[jaberwacky]

Oh, no, don't get me wrong. I thought I was making an optimization but it turns out that I wasn't -- at all.

[Jon]

3.3.7.10 (14th June, 2011) (Beta)

- Fixed #1565: Arrays as object properties; memory leak. (trancexx)

- Fixed: ObjCreate() memory leak when using a remote computer. (trancexx)

- Fixed #865: winhttp.winhttprequest.5.1 ObjEvent unhandled exception. (trancexx)

- Fixed: Remote COM bug caused by incorrect CoCreateInstanceEx() parameter. (trancexx)

[wraithdu]

I haven't hit 3.3.7.10 yet, but on .9 InetGet/Read seems to be broken when using proxies. I've tried HttpSetProxy(0) for IE settings and explicitly setting the proxy HttpSetProxy(2, "<my_proxy:port>"), but neither will let me get anything while at work behind our HTTP proxy. I don't have anywhere else to test, so can anyone confirm a problem?

Edited June 18, 2011 by wraithdu

[wraithdu]

^^^ Above still seems broken in beta .10.

[Valik]

Could this be related to an IE update as opposed to an AutoIt update? I don't know that the proxy or InetGet/Read code has been touched.

[wraithdu]

Dammit, sorry. No problem. Turns out my work proxy blocks requests based on User Agent as well, so I needed to set a valid browser user agent.

Edit:

Ok, odd. I first used Chrome's agent string and it worked. Then I tried "some user agent" and it still worked. So maybe our proxy has a blacklist instead of a whilelist and AutoIt's user agent string is blocked. Shitty.

Maybe changing the default to a valid browser string would be a good idea?

Edited June 20, 2011 by wraithdu

[wraithdu]

Also, is the change away from inlining the SQLite3 DLLs permanent? I see it is now trying to pull directly from AutoIt's servers (which is how I ran into this dumb proxy issue in the first place). I would have to vote against this, as AutoIt can't guarantee a user has an active network connection.

Oh, and the DLL version in the UDF is outdated compared to what is available on AutoIt's server.

[Valik]

No. If the user wishes to spoof a different browser that is their business. AutoIt is going to report what it is otherwise.

[Valik]

SQLite should have never been distributed with AutoIt in the first place.

[GEOSoft]

wraithdu;

I just download the actual dll from the SQLite site and then either put it in @SystemDir and register it OR put it in @ScriptDir.

[MvGulik]

I'm kinda mystified about #forceref and #forcedef intended use and/or differences.

Doc(beta) is only saying "can be used ... (Function/Assign)" with a example that on its own is also only showing the how, but not the why.

... to me of course.

As such the following is probably a correct error message. But I have no clue about why a Const is triggering this error.

Local Enum $_Default_, $_1_, $_2_, $_3_
#forcedef $_Default_, $_1_, $_2_, $_3_
D:\_CODE_\...\___MAIN___.au3(85,14) : ERROR: $_Default_ previously declared as a 'Const'.
            #forcedef $_Default_
            ~~~~~~~~~~^

(switched back to #forceref)

---

Think the dime is slowly dropping. Still ... a little more info on those two options is probably not a bad idea.

Edited June 22, 2011 by iEvKI3gv9Wrkd41u

[PsaltyDS]

@iEvKI3gv9Wrkd41u: Post a short demo. If I run just this through AU3Check, I get no errors:

Local Enum $_Default_, $_1_, $_2_, $_3_

#forcedef $_Default_, $_1_, $_2_, $_3_

But the intended use is more like this:

Main()

Func Main()
    #forcedef $MyVar_1
    Assign("MyVar_1", "one")
    ConsoleWrite("$MyVar_1 = " & $MyVar_1 & @LF)
EndFunc

Run that with Production 3.3.6.1 and you get the error report, run it with Beta 3.3.7.10 and it runs clean.

[MvGulik]

Yep, Was using #forcedef wrongly. ... fixed

Edited June 28, 2011 by iEvKI3gv9Wrkd41u

[Jon]

3.3.7.11 (4th July, 2011) (Beta)

AutoIt:

- Changed: PCRE updated to 8.12.

- Added: COM support for pure "OUT" parameters. (trancexx)

- Fixed: Potential memory leak in COM error event code. (trancexx)

[GEOSoft]

Good to have that PCRE update. Thanks Jon.

Was that compiled using UCP?

I'll probably know soon enough but I have not had a chance to get it installed yet.