XProfan

- Seite 17 -

« Dieser Beitrag wurde als Lösung gekennzeichnet. »

- Seite 15 -

Jens-Arne
Reumschüssel

Es gibt eine neue Version, die anders mit dem internen Messagehandling umgeht. Bitte probier die mal aus. Vielleicht ist das Problem damit behoben.

XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de

24.09.2022 ▲

RudiB.

Übrigens, Freebasic ist selbst beim verarbeiten von String-Funktion ca. 35x schneller als XProfan. Das hätte ich nicht gedacht, dafür ist aber Freebasic lange nicht so komfortabel bei der Programmierung.

Gruß aus München

XProfan X4
Xprofan X4
Rudolf Beske / München

Hardware: NB Intel I9 - 16GByte RAM

29.09.2022 ▲

RudiB.

Ja, Dein Beispiel funktioniert....

XProfan X4
Xprofan X4
Rudolf Beske / München

Hardware: NB Intel I9 - 16GByte RAM

29.09.2022 ▲

Jens-Arne
Reumschüssel

Ich kann nicht bestätigen, dass FreeBasic-Stringfunktionen schneller wären als XProfan-Stringfunktionen, jedenfalls nicht für @upper$:


declare i%,tc&,s$

fbPROC fbupper(ByRef s As ZString) As Integer Export
  s=ucase(s)
  return 0
ENDPROC

cls

tc&=&GetTickCount
for i%,1,10000
  s$="asdjhaskdjhaskjdhkajshdkjhaksjdhkjahö+12"
  s$=@upper$(s$)
endfor
print "@upper$: "+@str$(&GetTickCount-tc&)

tc&=&GetTickCount
for i%,1,10000
  s$="asdjhaskdjhaskjdhkajshdkjhaksjdhkjahö+12"
  @fbupper(@addr(s$))
endfor
print "@fbupper: "+@str$(&GetTickCount-tc&)

waitinput
end

FreeBasic ist deutlich langsamer, und zwar obwohl der Funktionsaufruf von JRPC3 über call realisiert wird und nicht über external, und obwohl für die FreeBasic-Routine nicht einmal neuer Speicherplatz reserviert werden muss, wie es für @upper$ der Fall ist (weil dort s$ neu zugewiesen wird).

XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de

30.09.2022 ▲

RudiB.

dann teste mal so.....

declare i%,tc&,s$
fbPROC fbupper(ByRef s As ZString) As Integer Export
DIM i as Integer
For i = 1 to 10000
s=ucase(s)
s=lcase(s)
Next i
return 0

ENDPROC

cls
tc&=&GetTickCount
for i%,1,10000
s$="asdjhaskdjhaskjdhkajshdkjhaksjdhkjahö+12"
s$=@upper$(s$)
endfor
print "@upper$: "+@str$(&GetTickCount-tc&)
tc&=&GetTickCount
s$="asdjhaskdjhaskjdhkajshdkjhaksjdhkjahö+12"
@fbupper(@addr(s$))
print "@fbupper: "+@str$(&GetTickCount-tc&)
waitinput
end

sogar schneller mit Upper-Case und Lower-Case....

XProfan X4
Xprofan X4
Rudolf Beske / München

Hardware: NB Intel I9 - 16GByte RAM

RudiB.

oder so, mit gleichen Voraussetzungen (jeweils eine Procedure aufrufen)

declare i%,tc&,s$
'----- FreeBasic - Procedure ---------------
fbPROC fbupper(ByRef s As ZString) As Integer Export
s=ucase(s)
return 0

ENDPROC

' ----- XProfan - Procedure -----------------

Proc Upper

s$=@upper$(s$)

EndProc

cls
tc&=&GetTickCount
for i%,1,10000
s$="asdjhaskdjhaskjdhkajshdkjhaksjdhkjahö+12"
upper(@addr(s$))
endfor
print "@upper$: "+@str$(&GetTickCount-tc&)
tc&=&GetTickCount
for i%,1,10000
s$="asdjhaskdjhaskjdhkajshdkjhaksjdhkjahö+12"
@fbupper(@addr(s$))
endfor
print "@fbupper: "+@str$(&GetTickCount-tc&)
waitinput
end

hier ist der Vorteil zwar nicht mehr ganz so groß, aber trotzdem schneller

Xprofan X4
Rudolf Beske / München

Hardware: NB Intel I9 - 16GByte RAM

Jens-Arne
Reumschüssel

Hallo Rudi,

darüber hatte ich auch schon nachgedacht. Offenbar ist der Aufruf einer Prozedur mit so viel Registergeschiebe u.ä. verbunden, dass das ganz schön lange dauert. In der Praxis lohnt es daher nicht, eine FB-Funktion für die Stringfunktionen zu schreiben, die man dann im Profan-Programm nutzen würde. Aber innerhalb einer fbProc kann man den Geschwindigkeitsvorteil, der offenbar doch existiert, natürlich ausspielen.

Gruß, Jens-Arne

XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de

RudiB.

Du sprichst gerade die FB-Funktionen an. Warum wird die eigentlich nicht von JRPC3 erkannt, hast Du das nicht implementiert ?

XProfan X4
Xprofan X4
Rudolf Beske / München

Hardware: NB Intel I9 - 16GByte RAM

Jens-Arne
Reumschüssel

Ich meinte damit FreeBasic-Procs (fbProcs). Die werden doch hoffentlich von JRPC3 erkannt. Ich habe darauf angespielt, dass offenbar jedweder Funktionsaufruf mit sehr viel Overhead geschieht, der Zeit kostet. Ansonsten verstehe ich die Frage nicht ganz, erläutere mir sie bitte noch einmal (hast Du mit "FB-Funktion" etwas anderes gemeint als ich?).

Und unser kleines Beispiel habe ich noch einmal etwas verfeinert. Denn um wirklich Gerechtigkeit herzustellen, muss auch die Profan-Funktion mit call aufgerufen werden und außerdem einen Parameter haben (auch wenn der vorliegend nichts tut):


declare i%,tc&,s$,funcaddr%

fbPROC fbupper(ByRef s As ZString) As Integer Export
  s=ucase(s)
  return 0
ENDPROC

PROC upper
  parameters dummy%
  s$=@upper$(s$)
ENDPROC

cls
funcaddr%=@procaddr("upper",1)

tc&:=&GetTickCount
for i%,1,10000
  s$:="asdjhaskdjhaskjdhkajshdkjhaksjdhkjahö+12"
  call(funcaddr%,@addr(s$))
endfor
print "@upper$: "+@str$(&GetTickCount-tc&)

tc&:=&GetTickCount
for i%,1,10000
  s$:="asdjhaskdjhaskjdhkajshdkjhaksjdhkjahö+12"
  @fbupper(@addr(s$))
endfor
print "@fbupper: "+@str$(&GetTickCount-tc&)

waitinput
end

Jetzt sind beide Varianten fast gleich schnell (kompiliert) mit immer noch einem kleinen Vorteil bei FreeBasic.

XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de

RudiB.

Hallo Jens-Arne,

....alles gut. Die fbProcs werden natürlich sauber erkannt und verarbeitet. Ich meinte Freebasic-Funktionen. Habe doch dazu die Datei "datei_fb_test.prf" hochgeladen. Diese hast Du dann auch umgeschrieben zu einer fbProc.
Wie gesagt unter Freebasic gibst ja Sub´s und Funktionen....

XProfan X4
Xprofan X4
Rudolf Beske / München

Hardware: NB Intel I9 - 16GByte RAM

Jens-Arne
Reumschüssel

Man kann schlicht nicht direkt in FreeBasic programmieren, also auch nicht direkt Funktionen von dort aufrufen, weil der Profan-Compiler diese Funktionen nicht direkt in sein Programm einbauen kann. Um sie zu nutzen, muss immer eine DLL erzeugt werden, in der naturgemäß Funktionen (Procs) stehen, die man dann von außen aufrufen kann, um den darin enthaltenen nativen FreeBasic-Code zu nutzen. Das geht nicht ohne den Umweg über eine DLL-Funktion. Das macht auch der XProfan-Inline-Assembler so, der XPSE-Inline-Assembler und XPSE-nPROCs ebenfalls.

EDIT: Vielleicht noch einmal anders herum erklärt: Um FreeBasic-Code zu erzeugen, muss der FreeBasic-Compiler verwendet werden. Das geht natürlich nicht "plötzlich" innerhalb eines Profan-Programms. Durch die Nutzung von DLL-Funktionen ist der FreeBasic-Code hingegen derart abgegrenzt, dass der FreeBasic-Compiler das vorgesetzt bekommt, was für ihn gedacht ist, und der Profan-Compiler seinen Anteil.

XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de

RudiB.

Hallo Jens-Arne,

Danke für Deine Antwort......verstehe....man kann das ganze ja auch mit Sub´s lösen. Aber gut zu wissen.
Ich möchte mein Programm jetzt mit fbProcs optimieren, da es mir einfach zu langsam ist.....

Gruß Rudi

XProfan X4
Xprofan X4
Rudolf Beske / München

Hardware: NB Intel I9 - 16GByte RAM

Jens-Arne
Reumschüssel

Genau dafür sind fbProcs da. Das lohnt sich aber nur bei Programmpassagen, die viel rechnen oder ganz oft aufgerufen werden, etwa in einer großen Schleife. Z.B. ist es eine extrem gute Idee, die Subclassproc nach FreeBasic zu verlagern, wenn die länger als ein paar Zeilen ist. Wenn man darin bspw. OwnerDraw-Elemente versorgt, dann ist das in Profan oft zu langsam. Ein Beispiel dafür wären farbige Elemente in Gridboxen.

XProfan X4
XProfan X4 * Prf2Cpp * XPSE * JRPC3 * Win11 Pro 64bit * PC i7-7700K@4,2GHz, 32 GB RAM
PM: jreumsc@web.de