Discussion:
bpl70v20.zip Borland-Pascal 7.01 RT-Libary Update
(too old to reply)
Robert AH Prins
2004-10-18 11:05:37 UTC
Permalink
Mon 18-Oct-2004: Got from the update author

459244 Oct 10 2004 ftp://garbo.uwasa.fi/pc/turbopa7/bpl70v20.zip
bpl70v20.zip Borland-Pascal 7.01 RT-Libary Update Rel2.0, R.Prins

All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:***@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Timo's FAQ materials at http://www.uwasa.fi/~ts/http/tsfaq.html
Robert AH Prins
2004-10-27 16:20:25 UTC
Permalink
Post by Robert AH Prins
Mon 18-Oct-2004: Got from the update author
459244 Oct 10 2004 ftp://garbo.uwasa.fi/pc/turbopa7/bpl70v20.zip
bpl70v20.zip Borland-Pascal 7.01 RT-Libary Update Rel2.0, R.Prins
FWIW, this was the original message that accompanied the Garbo upload:

Subject: BPL70V20.ZIP Partial 32-bit replacement libraries for BP7

File name: BPL70V20.ZIP
One line description: Optimized BP7 runtime libraries
Replaces: NONE - THIS IS AN ALTERNATIVE TO BPL70N16.ZIP!
Suggested Garbo directory: TURBOPA7
Uploader name & email: Robert AH Prins <prino at onetel dot com>
Author or company: Robert AH Prins
Email address: <prino at onetel dot com>
Surface address: 52 Lummis Vale, Kesgrave, IPSWICH, SUFFOLK, IP5 2FJ, UK
Special requirements: 80386+ required
Shareware payment required from private users: N
Shareware payment required from corporates: N
Distribution limitations: None
Garbo CD-ROM distribution allowed without preconditions: Yes
Demo: No
Nagware: No
Self-documenting: Yes
External documentation included: Yes
Source included: Yes
Size: 449 K / 1415 K
10 lines description:
BPL70V20.ZIP contains optimized Run Time Libraries for Borland Pascal 7.
The code is based on Norbert Juffa's BPL70N16, but incorporates changes
Borland made in BP 7.01. Unlike the libraries in Norbert's BPL70N16, the
ones include here only run on 386+ CPU's due to the extensive use of
32-bit instructions. Many of the original RTL routines have also been
split up further to increase the smart-link granularity.

In addtion to the System unit, the RTLs also include optimized Dos, CRT
(removal of RTE 200) and Overlay units.
Long description:
The most notable "flaws" in the replacement libraries written by Norbert
Juffa in BPL70N16.ZIP are:

1) they are based on the original BP 7.00 RTL code
2) they do not use any 32-bit code

To quote Norbert:

"Those users already familiar with my previous project, the fast
replacement library for Turbo Pascal 6.0 (distributed as TPL60N19.ZIP),
may be disappointed that not all the features of that program have been
included in BPL70N16.ZIP yet. I don't have much time at the moment but
still wanted to provide a BP 7.0 version of my library as soon as
possible. So I decided to port the performance relevant stuff first and
work on the other aspects later."

Now, better (10 years...) late than never, BPL70V20.ZIP contains some of
these "other aspects" Norbert never got around to.

The most significant differences between BPL70N16 & BPL70V20 are

1) the new RTLs are based on the BP 7.01 RTL
2) they _require_ a 32-bit CPU
3) much of the code is Pentium+ friendly by replacing most slow CISC
instructions with their RISC equivalents, which can be executed
in parallel on Pentium/PII/PIII/P4/Atlon CPUs
4) they are more smartlink-friendly
5) in the default configuration, they no longer support the software
FPU emulator (but two additional System units incorporating the
SW emulator) are provided
6) they include a copy of my non-RTE200 smartlink friendly CRT unit
7) they include more smartlink-friendly DOS & Overlay units

As far as performance is concerned, the greatest gains, compared to
Norbert's libs, can be found in the Longint arithmetic. Norbert removed
all traces of it, I removed all traces of 16-bit code, essentially
reverting back to the original Borland unit, but without the Test8087
tests. The output from LONGTEST indicates that my code is about 35%
faster than that of Norbert and some 5% faster than the original BP 7
RTL.

Another noticable improvement is in the Set handling code. My code is
about 10% faster than the code in BPL70N16, which is due to the fact
that I use 32-bit code RISCified code that.

The results of WHETST87, where my code is some 10 to 14% faster than
Norbert's should be taken with a pinch of salt. Yes, it IS faster, but
this might mostly be due to the much faster conversion INT 34-3D to
real FPU instructions.

The two most notable other improvements that are not shown in the
results of any of the supplied testing programs are:

1) the Move() routine auto-aligns the destination of the move and moves
4 bytes at a time, making it, for longer moves, close to four times
as fast as the original Borland RTL and up to twice as fast as
Norbert's code.

2) The 'internal' move also moves 4 bytes at a time, but doesn't perform
auto-alignment of the destination. This move is, among others, used
during assignments of records and arrays.

Other routines also use some 32-bit instructions, but the quality of
Norbert's original code was so high to start with, that improvements
are marginal. On my AMD64 all benchmarks execute faster, on the old
Cyrix some are slower. At this moment (October 2004) I do not have
access to any Intel hardware to generate more performance data.

As for the sources included in the various archives in the main file,
ARISOURC.ZIP & STRSOURC.ZIP contain Norbert's arithmetic and string
handing sources, with my tweaks. RAHPSRCE.ZIP contains all source that
no longer contains any Borland copyrightable code and the full sources
for the hardware and software emulators used in the libraries. Be aware
that this code has been significantly changed from the code extracted
from the original EM86/7 .OBJ files supplied by Borland.

RAHPSRCE.ZIP also contains, in \RTL\BIN\TPU & \RTL\BIN\TPP versions of
all units compiled with full debugging information and versions of
System.TPU/TPP that support the software emulator.

The units included are:

- nnnnD.TPU/TPP : Unit nnnn compiled with full debugging support
- SystemE.TPU/TPP : System units compiled with SW emulator support
- SystemED.TPU/TPP: System units compiled with SW emulator and full
debugging support

To use any of these alternative units, rename them and use TPUMOVER to
add them to the appropriate TPL.

Last but not least, RAHPSRCE also contains the two makefiles I use
to generate the whole mess...

Robert AH Prins
October 2004
Joachim Merkel
2004-10-29 02:55:00 UTC
Permalink
Post by Robert AH Prins
Post by Robert AH Prins
Mon 18-Oct-2004: Got from the update author
459244 Oct 10 2004 ftp://garbo.uwasa.fi/pc/turbopa7/bpl70v20.zip
bpl70v20.zip Borland-Pascal 7.01 RT-Libary Update Rel2.0, R.Prins
FWIW, this was the original message that accompanied the Garbo
Subject: BPL70V20.ZIP Partial 32-bit replacement libraries for BP7
[...]

Thank you very much.

I've tested (just) Turbo.tpl and found something irritating me.
I take a programm with two units (here is a working example):

program tst;

uses tst1;
begin
writeln(om)
end.

unit tst1;
interface
uses overxms;
var om:word;
implementation
begin
om:=ovrmemsize
end.

unit overxms;
interface
var ovrmemsize:word;
implementation
begin
ovrmemsize:=2
end.


I can't compile that program with the Turbo.tpl from bpl70v20.zip

TST1.PAS(7): Error 3: Unknown identifier.
om:=ovrmemsize
F:\>d:\bp\bin\bpc /B tst.pas
Borland Pascal Version 7.0 Copyright (c) 1983,92 Borland Inter[...]
TST1.PAS(7): Error 3: Unknown identifier.
om:=ovrmemsize
^

I can compile it under the following circumstances:

1) I take other Turbo.tpl (the original one from BP 7.0,
bpl70n16.zip):

F:\>d:\bp\bin\bpc /B tst.pas
Borland Pascal Version 7.0 Copyright (c) 1983,92 Borland Inter[...]
OVERXMS.PAS(7)
TST1.PAS(8)
TST.PAS(6)
21 lines, 2352 bytes code, 674 bytes data.

2) I take your Turbo.tpl and change the name of the unit
OVERXMS.PAS (I took the name ovelxms.pas):

F:\>d:\bp\bin\bpc /B tst.pas
Borland Pascal Version 7.0 Copyright (c) 1983,92 Borland Inter[...]
OVERXMS.PAS(7)
TST1.PAS(8)
TST.PAS(6)
21 lines, 2352 bytes code, 674 bytes data.

3) or took your Turbo.tpl and change the name of the variable
ovrmemsize and can led the name of the unit Overxms.pas
unchanged.


------------
FYI in the "real" program (CrossPoint/FreeXP) I found that thing I
described above. We use a slightly modified OVERXMS.PAS/.OBJ from
Wilbert van Leijen from SWAGs. It works nice.

BTW the most important thing we have corrected was an "error" in
OVERXMS.ASM writing the overlay to the XMS-memory, where
Novell Dos 7.0 changes the register BX to zero. Probably it's a
typical misbehaviour from Novell DOS to change the values in a
not used register. I can't decide that, but it took much time
to find this little bug.

Look at the two ">"-marked positions.
--------------------------------zip-----------------------------------
CopyUnitToXms PROC

; XMS requires that an even number of bytes is moved

MOV DX, ES:[OvrHeader.CodeSize]
TEST DX, 1
JZ @@1
INC DX
INC ES:[OvrHeader.CodeSize]

; Get the fields of the XMS block move structure

@@1: MOV Word Ptr [XmsMove.BlkSize], DX
XOR AX, AX
MOV Word Ptr [XmsMove.BlkSize+2], AX
MOV [XmsMove.SrcHandle], AX
MOV Word Ptr [XmsMove.SrcOffset], AX
MOV AX, [OvrHeapOrg]
MOV Word Ptr [XmsMove.SrcOffset+2], AX
MOV AX, [OvrXmsHandle]
MOV [XmsMove.DestHandle], AX
MOV Word Ptr [XmsMove.DestOffset], DI
MOV Word Ptr [XmsMove.DestOffset+2], BX
MOV AH, 11
LEA SI, XmsMove
Post by Robert AH Prins
PUSH BX
CALL [XmsDriver]
Post by Robert AH Prins
POP BX
; Bump code size

ADD DI, DX
ADC BX, 0

; Check return code from XMS driver

OR AX, AX
JZ @@2
CLC
RETN
--------------------------------zap-----------------------------------

(To email me remove "-xxx" from my adress above.)
--
Salut
_)oachim
Robert AH Prins
2004-10-29 10:42:15 UTC
Permalink
Post by Joachim Merkel
Post by Robert AH Prins
Post by Robert AH Prins
Mon 18-Oct-2004: Got from the update author
459244 Oct 10 2004 ftp://garbo.uwasa.fi/pc/turbopa7/bpl70v20.zip
bpl70v20.zip Borland-Pascal 7.01 RT-Libary Update Rel2.0, R.Prins
Subject: BPL70V20.ZIP Partial 32-bit replacement libraries for BP7
[...]
Thank you very much.
I've tested (just) Turbo.tpl and found something irritating me.
program tst;
uses tst1;
begin
writeln(om)
end.
unit tst1;
interface
uses overxms;
var om:word;
implementation
begin
om:=ovrmemsize
end.
unit overxms;
interface
var ovrmemsize:word;
implementation
begin
ovrmemsize:=2
end.
I can't compile that program with the Turbo.tpl from bpl70v20.zip
TST1.PAS(7): Error 3: Unknown identifier.
om:=ovrmemsize
F:\>d:\bp\bin\bpc /B tst.pas
Borland Pascal Version 7.0 Copyright (c) 1983,92 Borland Inter[...]
TST1.PAS(7): Error 3: Unknown identifier.
om:=ovrmemsize
^
1) I take other Turbo.tpl (the original one from BP 7.0,
F:\>d:\bp\bin\bpc /B tst.pas
Borland Pascal Version 7.0 Copyright (c) 1983,92 Borland Inter[...]
OVERXMS.PAS(7)
TST1.PAS(8)
TST.PAS(6)
21 lines, 2352 bytes code, 674 bytes data.
2) I take your Turbo.tpl and change the name of the unit
F:\>d:\bp\bin\bpc /B tst.pas
Borland Pascal Version 7.0 Copyright (c) 1983,92 Borland Inter[...]
OVERXMS.PAS(7)
TST1.PAS(8)
TST.PAS(6)
21 lines, 2352 bytes code, 674 bytes data.
3) or took your Turbo.tpl and change the name of the variable
ovrmemsize and can led the name of the unit Overxms.pas
unchanged.
------------
FYI in the "real" program (CrossPoint/FreeXP) I found that thing I
described above. We use a slightly modified OVERXMS.PAS/.OBJ from
Wilbert van Leijen from SWAGs. It works nice.
BTW the most important thing we have corrected was an "error" in
OVERXMS.ASM writing the overlay to the XMS-memory, where
Novell Dos 7.0 changes the register BX to zero. Probably it's a
typical misbehaviour from Novell DOS to change the values in a
not used register. I can't decide that, but it took much time
to find this little bug.
Look at the two ">"-marked positions.
--------------------------------zip-----------------------------------
CopyUnitToXms PROC
; XMS requires that an even number of bytes is moved
MOV DX, ES:[OvrHeader.CodeSize]
TEST DX, 1
INC DX
INC ES:[OvrHeader.CodeSize]
; Get the fields of the XMS block move structure
@@1: MOV Word Ptr [XmsMove.BlkSize], DX
XOR AX, AX
MOV Word Ptr [XmsMove.BlkSize+2], AX
MOV [XmsMove.SrcHandle], AX
MOV Word Ptr [XmsMove.SrcOffset], AX
MOV AX, [OvrHeapOrg]
MOV Word Ptr [XmsMove.SrcOffset+2], AX
MOV AX, [OvrXmsHandle]
MOV [XmsMove.DestHandle], AX
MOV Word Ptr [XmsMove.DestOffset], DI
MOV Word Ptr [XmsMove.DestOffset+2], BX
MOV AH, 11
LEA SI, XmsMove
Post by Robert AH Prins
PUSH BX
CALL [XmsDriver]
Post by Robert AH Prins
POP BX
; Bump code size
ADD DI, DX
ADC BX, 0
; Check return code from XMS driver
OR AX, AX
CLC
RETN
--------------------------------zap-----------------------------------
Eeks...

I've added a modified version of WvL's OVERXMS to TURBO.TPL (from my
OVER-110.ZIP on Garbo) I should have removed it from the final build. To
solve your problem, remove it using TPUMOVER and all will be OK.

I'll add your change to OVER-110 and upload a new version (OVER-120)
later (today?), FWIW my 386'ified source of WvL's code and the full
source of the Overlay unit can both be found in that archive, you might
want to look at them.

Finally, what's your opinion about the product - feel free to email me
privately if you want.

Regards,

Robert
--
Robert AH Prins
prino at onetel dot com
Joachim Merkel
2004-10-30 00:11:00 UTC
Permalink
Post by Robert AH Prins
I've added a modified version of WvL's OVERXMS to TURBO.TPL (from my
OVER-110.ZIP on Garbo) I should have removed it from the final
build. To solve your problem, remove it using TPUMOVER and all will
be OK.
Yes, TPUMOVER TURBO.TPL -OVERXMS did it.
Post by Robert AH Prins
I'll add your change to OVER-110 and upload a new version (OVER-120)
later (today?), FWIW my 386'ified source of WvL's code and the full
source of the Overlay unit can both be found in that archive, you
might want to look at them.
Thanks for adding it. I knew of OVER-110, but hadn't tested it and
forgot that you're the author. Our main problem is to put all that
XMS-stuff together in CrossPoint/FreeXP because we've just added
OVERXMS to other parts using XMS memory. It's not so much work
to rearrange it, but I plan some extensions too.

BTW we build an xmsavail (shows the biggest free XMS memory block)
that works on plain DOS and all Windows. The routine tests the value
not only asks the XMS-driver.
More than that, if you ask Windows NT or W2K to give you as much as
it can deliver with an entry of 16384 KB XMS in the PIF-file it will
do 16293KB (I hope the value is correct) but after freeing the memory
the NTVDM collapses because it needs one MB itself. This is not the
problem with Windows XP, but we will always ask for >16384 KB, exactly
16384KB or 15215 KB and less (finest granulation 1 KB), so mostly
we'll get just 15215KB from Windows XP too (under FreeXP, not my
xmsavail as a standalone program, don't know why exactly) but that's
enough for us and is better than always have to check the Windows
version.
The results under Win98 were really desastrous, the system routines
were never be able to find more than 2 (two!) MB of XMS and so couldn't
deliver more. No we get max. 64 MB XMS memory under Win9x.
Post by Robert AH Prins
Finally, what's your opinion about the product - feel free to email
me privately if you want.
In my opinion you've offered long missed solutions but it's not
easy to see the details (without source) or the whole picture
and how far it will be useful for an existing program like CrossPoint/
FreeXP after many years of development.
So we have to check the possible consequences how (doubled) amounts
are no longer useful or the complexity of some parts of our program
could be minimized or something could be done that results in a better
factorizing. I hope I can give you a more precise feedback sometimes.

--
Salut
_)oachim
Joachim Merkel
2004-10-30 04:58:00 UTC
Permalink
Post by Robert AH Prins
Finally, what's your opinion about the product - feel free to email
me privately if you want.
[...] I hope I can give you a more precise feedback
sometimes.
I forgot to mention that it nicely works with my personal version of
CrossPoint/FreeXP. I didn't notice any difference in speed, but the
program is highly optimized with 386 assembler inline code.

(To email me remove "-xxx" from my adress above.)
--
Salut
_)oachim
Joachim Merkel
2004-10-30 11:20:00 UTC
Permalink
[...] better factorizing.
oops. factoring
--
Salut
_)oachim
Robert AH Prins
2004-10-30 19:17:15 UTC
Permalink
Post by Joachim Merkel
Post by Robert AH Prins
I've added a modified version of WvL's OVERXMS to TURBO.TPL (from my
OVER-110.ZIP on Garbo) I should have removed it from the final
build. To solve your problem, remove it using TPUMOVER and all will
be OK.
Yes, TPUMOVER TURBO.TPL -OVERXMS did it.
Post by Robert AH Prins
I'll add your change to OVER-110 and upload a new version (OVER-120)
later (today?), FWIW my 386'ified source of WvL's code and the full
source of the Overlay unit can both be found in that archive, you
might want to look at them.
Thanks for adding it. I knew of OVER-110, but hadn't tested it and
forgot that you're the author. Our main problem is to put all that
XMS-stuff together in CrossPoint/FreeXP because we've just added
OVERXMS to other parts using XMS memory. It's not so much work
to rearrange it, but I plan some extensions too.
I've uploaded OVER-120.ZIP to Garbo. Don't know when Timo will put it in
the proper directory, probably on Monday.

<snip>
Post by Joachim Merkel
Post by Robert AH Prins
Finally, what's your opinion about the product - feel free to email
me privately if you want.
In my opinion you've offered long missed solutions but it's not
easy to see the details (without source) or the whole picture
and how far it will be useful for an existing program like CrossPoint/
FreeXP after many years of development.
So we have to check the possible consequences how (doubled) amounts
are no longer useful or the complexity of some parts of our program
could be minimized or something could be done that results in a better
factoring. I hope I can give you a more precise feedback sometimes.
As the initial post already mentioned, the greatest gains can be seen in
the handling of longint arithmetic (compared to Norbert's code), in set
operations and in (larger) moves. The rest of Norbert's code didn't
offer a lot of of other opportunities to optimize it any further. The
other major change concerns the emulators, the SW emulator is gone,
unless you use one of the extra units, and the HW emulator requires at
least a 387.

There is scope for further improvements, look at the Fastcode project in
borland.public.delphi.language.basm, but I'm not sure if I want to do
more, as it would require the insertion of profiling code (as a minimum
'inc [longintcounter]') into every RTL routine and some exit code to
print the stats _AND_ a fair amount of people willing to run some
real-life programs to actually produce the stats in order to find out
which RTL code is used most often and, eg for the Move() (and internal
move), the amount of data moved and if it's an overlapping move or not.
Given the somewhat limited amount of people that actually gave me any
feedback when I asked for beta-testers, I'm not very optimistic...
However, if Femme V, Jason B, Rimvydas P, you and whoever else are
prepared to provide this feedback, I might be persuaded to do something
over the Christmas period.

Regards,

Robert
--
Robert AH Prins
prino at onetel dot com
Joachim Merkel
2004-10-31 04:44:00 UTC
Permalink
Post by Robert AH Prins
As the initial post already mentioned, the greatest gains can be
seen in the handling of longint arithmetic (compared to Norbert's
code), in set operations and in (larger) moves.
I suppose we'll discuss it in the CrossPoint/FreeXP developer
newsgroup next time.
BTW one of our tools works faster (6 sec faster to test 11 MB news on
an i486DX2-66 here) with your Turbo.tpl, another tool slows down but
not significant. The complete source of the last one can be found at:
ftp://ftp.freexp.de/freexp/snapshot/euuz_src.zip
(It's a long used and and now far enhanced converting tool
for mail/news RFC<->ZConnect, a sort of a gate software with a
lot of parsing and string operations. There's all the source to
get it compiled and it's stable. It's not fully integrated in our
CVS but this will happen as soon as possible.)
For other actual source of CrossPoint/FreeXP or our developer
newsgroup look for informations at
http://freexp.co.uk or http://www.bitzbox.plus.com .
Post by Robert AH Prins
There is scope for further improvements, look at the Fastcode
project in borland.public.delphi.language.basm [...]
Thank you, I'll visite that newsgroup.
Post by Robert AH Prins
I want to do more, as it would require the insertion of profiling
code (as a minimum 'inc [longintcounter]') into every RTL routine
and some exit code to print the stats _AND_ a fair amount of people
willing to run some real-life programs to actually produce the stats
in order to find out which RTL code is used most often [...]
I'm always looking for possibilities to optimize my/our code and try
to get a deeper understanding of my tools and testing of all parts of
the software.
OTH what you'll probably win here you can easily loose with some CPUs
today but I'll reflect your works and ideas. If you want to test me
something or give you informations feel free to ask me or post it
to the Crosspoint/FreeXP developer newsgroup.

(To email me remove "-xxx" from my adress above.)
--
Salut
_)oachim
Robert AH Prins
2004-10-31 10:43:44 UTC
Permalink
Post by Joachim Merkel
Post by Robert AH Prins
As the initial post already mentioned, the greatest gains can be
seen in the handling of longint arithmetic (compared to Norbert's
code), in set operations and in (larger) moves.
I suppose we'll discuss it in the CrossPoint/FreeXP developer
newsgroup next time.
BTW one of our tools works faster (6 sec faster to test 11 MB news on
6 seconds on? Please, give me a percentage, 6 seconds on 60 seconds is
good, 6 seconds on 30 minutes isn't very interesting, and some
indication as to what to calling code is doing.
Post by Joachim Merkel
an i486DX2-66 here) with your Turbo.tpl, another tool slows down but
not significant.
Again, percentages and functions please.
Post by Joachim Merkel
ftp://ftp.freexp.de/freexp/snapshot/euuz_src.zip
I'll download it and have a look, but at the moment, my wife is away for
a week, I'm very busy copying several 100 floppies to CD-R and trying to
get rid of many older versions of files. I'll probably have to get some
software that can handle images (any suggestions?) as playing
floppy-disk jockey is getting on my nerves...

FWIW, one of my problems is that I just missed TurboPower going out of
business last year. I was unemployed for well over a year and my
financial priorities precluded me from buying TurboAnalyst. When I
finally got a job again, they had left the business. I'm not sure, but I
think TA allowed you to see which RTL routines are included in the final
EXE although I don't know it it would work on my modified RTL code.
Post by Joachim Merkel
(It's a long used and and now far enhanced converting tool
for mail/news RFC<->ZConnect, a sort of a gate software with a
lot of parsing and string operations. There's all the source to
get it compiled and it's stable. It's not fully integrated in our
CVS but this will happen as soon as possible.)
For other actual source of CrossPoint/FreeXP or our developer
newsgroup look for informations at
http://freexp.co.uk or http://www.bitzbox.plus.com .
Post by Robert AH Prins
There is scope for further improvements, look at the Fastcode
project in borland.public.delphi.language.basm [...]
Thank you, I'll visite that newsgroup.
Keep in mind that all code there is 32-bit and some of the routines,
although fast in the extreme, are very, very, very, very long...
Post by Joachim Merkel
Post by Robert AH Prins
I want to do more, as it would require the insertion of profiling
code (as a minimum 'inc [longintcounter]') into every RTL routine
and some exit code to print the stats _AND_ a fair amount of people
willing to run some real-life programs to actually produce the stats
in order to find out which RTL code is used most often [...]
I'm always looking for possibilities to optimize my/our code and try
to get a deeper understanding of my tools and testing of all parts of
the software.
OK, you're number one. Half a dozen more and I'll create a special RTL
with profiling code in it. (Don't hold your breath...)
Post by Joachim Merkel
OTH what you'll probably win here you can easily loose with some CPUs
today but I'll reflect your works and ideas. If you want to test me
something or give you informations feel free to ask me or post it
to the Crosspoint/FreeXP developer newsgroup.
OK, will do.

Regards,

Robert
--
Robert AH Prins
prino at onetel dot com
Joachim Merkel
2004-10-31 22:12:00 UTC
Permalink
Post by Robert AH Prins
6 seconds on? Please, give me a percentage, 6 seconds on 60 seconds
is good, 6 seconds on 30 minutes isn't very interesting, and some
indication as to what to calling code is doing.
Surely.

The tool named ZPR.EXE repairs broken news- or mailbatches in
ZConnect-format and it's running a test here. There seems to
happen many jumps in the memory buffered header(s).

--------------------------------zip-----------------------------------
ZPR - ZConnect(R)-Pufferreparierer (Freeware)
(c) 1993-1999 Peter Mandrella
FreeXP-Version v3.40 RC3 (c) 2002-2004 by FreeXP <***@freexp.de>

Eingabedatei: 'MPUFFER.11
Ausgabedatei: -keine-

Nachrichten gesamt: 4003
[messages totally]

davon fehlerhaft: 0
[errors]

Prins BP 7.1 Turbo.Tpl
Elapsed time = 00:00:18.01

Juffa BP 7.0 Turbo.tpl
Elapsed time = 00:00:18.13

BP 7.0 Turbo.tpl
Elapsed time = 00:00:24.28
--------------------------------zap-----------------------------------
Post by Robert AH Prins
Post by Joachim Merkel
an i486DX2-66 here) with your Turbo.tpl, another tool slows down
but not significant.
Again, percentages and functions please.
--------------------------------zip-----------------------------------
ZConnect <-> RFC/UUCP/SMTP Converter with MIME
(c) 1993-1999 Peter Mandrella
FreeXP-Version v3.40 RC3 (c) 2002-2003 by FreeXP <***@freexp.de>
"Enhanced UUZ" - improved RFC1036/2047/2822 compliance and long header
support

Mails: 0
News : 1016

Prins BP 7.1 Turbo.Tpl
1747.28 KB processed in 0:00:22'51 at 77.59 KB/sec and 45.12 msgs./sec

Juffa BP 7.0 Turbo.tpl
1747.28 KB processed in 0:00:22'39 at 78.00 KB/sec and 45.12 msgs./sec

BP 7.0 Turbo.tpl
1747.28 KB processed in 0:00:23'29 at 75.02 KB/sec and 43.33 msgs./sec
--------------------------------zap-----------------------------------
Post by Robert AH Prins
Post by Joachim Merkel
ftp://ftp.freexp.de/freexp/snapshot/euuz_src.zip
I'll download it and have a look [...]
Thanks, it' just an example, where we'd have to look carefully for
the best efficency, but it's a project developed in our sparetime and
after a little profiling with TPROF it was fast enough for us.
--
Salut
_)oachim
Joachim Merkel
2004-11-01 01:02:00 UTC
Permalink
Joachim Merkel (J.Merkel-***@TBX-xxx.berlinet.de) wrote:

[...]
Post by Joachim Merkel
--------------------------------zip-------------------------------
-- ZPR - ZConnect(R)-Pufferreparierer (Freeware)
[...]
Post by Joachim Merkel
Nachrichten gesamt: 4003
[messages totally]
davon fehlerhaft: 0
[errors]
Prins BP 7.1 Turbo.Tpl
Elapsed time = 00:00:18.01
Juffa BP 7.0 Turbo.tpl
Elapsed time = 00:00:18.13
^^^^^
sorry 22.13
Post by Joachim Merkel
BP 7.0 Turbo.tpl
Elapsed time = 00:00:24.28
--------------------------------zap---------------------------------
[...]
--
Salut
_)oachim
Joachim Merkel
2004-11-04 01:41:00 UTC
Permalink
Post by Joachim Merkel
The tool named ZPR.EXE repairs broken news- or mailbatches in
ZConnect-format and it's running a test here. There seems to
happen many jumps in the memory buffered header(s).
"Running a test" with ZPR meant just testing the correctness of
ZConnect-headers and the higher speed with Prins' Turbo.tpl
was mainly the result from a faster "system.readblock"-routine
as TPROF shows.

(To email me remove "-xxx" from my adress above.)
--
Salut
_)oachim

Loading...