Does anyone know, what priority property means?
I created two threads (both incremented/decremented the same Int64, it's not
recommended behavior, is it the cause?), the first had "highest" priority, the
second "lowest" (I didn't try "realtime" or "idle"). The results didn't differ
from both "no
How much is and should be speed difference between static and dynamic arrays?
I wrote simple program (source at the end of the message), which compared speed
of the same operations (I know there are many more operations, this was just a
little sample test). Under WinXPsp2 with enough memory and
On 4 apr 2006, at 11:21, Пётр Косаревский wrote:
I didn't dig sources, but is it really hard to make them equally
fast? (By the way, the speed difference was less, than I expected.)
They are equally fast if you turn on register variables and if enough
free registers are available (e.g. on
> > I didn't dig sources, but is it really hard to make them equally
> > fast? (By the way, the speed difference was less, than I expected.)
>
> They are equally fast if you turn on register variables and if enough
> free registers are available (e.g. on a PPC; possibly also on an x86
> if y
On 4 apr 2006, at 11:41, Пётр Косаревский wrote:
They are equally fast if you turn on register variables and if enough
free registers are available (e.g. on a PPC; possibly also on an x86
if you have a very simple loop and little or no variables used both
before and after the loop).
It's wron
IIRC thread priority is not implemented on Darwin, and possibly other FPC platforms
On Apr 4, 2006, at 4:53, Пётр Косаревский wrote:
Does anyone know, what priority property means?
I created two threads (both incremented/decremented the same Int64, it's not recommended behavior, is it the cause?)
The Windows Kernel works in a priority level of program execution
(main process) and sub processes (child process).
Each priority tells Windows what queue to place the processes.
If your parent process is "Norma" then the child process does not have
effect except that it's priority on executing wil
Something new at the end of message.
> >> They are equally fast if you turn on register variables and if enough
> >> free registers are available (e.g. on a PPC; possibly also on an x86
> >> if you have a very simple loop and little or no variables used both
> >> before and after the loop).
> > It
On 4 apr 2006, at 13:12, Пётр Косаревский wrote:
In real program registers should be used more efficiently,
especially when dealing with SEVERAL arrays, than for support of
ONE dynamical array.
We don't do anything special to use register not as efficiently as
possible, and on the other
> The Windows Kernel works in a priority level of program execution
> (main process) and sub processes (child process).
> Each priority tells Windows what queue to place the processes.
> If your parent process is "Norma" then the child process does not have
> effect except that it's priority on exe
> Something new at the end of message.
>
>> >> They are equally fast if you turn on register variables and if enough
>> >> free registers are available (e.g. on a PPC; possibly also on an x86
>> >> if you have a very simple loop and little or no variables used both
>> >> before and after the loop).
> No, it's a very common cases on all cpus which have a reasonable
> amount of available registers.
With 3-4 dynamical arrays and several parameters?
> > What can I do to speed up dynamical arrays?
> >
> > What can I do to speed up static arrays?
I mean: what is the shortest way to estimate spee
It's been a while since I developed for Windows, so I do not know if
the following function is deprecated or not, or even will work on all
Windows versions:
SetPriorityClass
You can set the process priority at runtime as far as I remember
(please take a look at MSDN for better information :)).
Id
>> No, it's a very common cases on all cpus which have a reasonable
>> amount of available registers.
> With 3-4 dynamical arrays and several parameters?
>
>> > What can I do to speed up dynamical arrays?
>> >
>> > What can I do to speed up static arrays?
> I mean: what is the shortest way to estim
On 4 apr 2006, at 13:46, Пётр Косаревский wrote:
No, it's a very common cases on all cpus which have a reasonable
amount of available registers.
With 3-4 dynamical arrays and several parameters?
It all depends on how many parameters, how many other variables and
how they are used. But a PP
> If you really want to speed up both cases you need to use pointers and
> increase the pointer value in each iteration. This saves the indexing in
> every iteration.
Thank you, that was informative. Here are the results (one program at the end
for completeness):
ap^:=app^; inc(ap); d
> It's been a while since I developed for Windows, so I do not know if
> the following function is deprecated or not, or even will work on all
> Windows versions:
> SetPriorityClass
>
> You can set the process priority at runtime as far as I remember
> (please take a look at MSDN for better inform
On Tue, 4 Apr 2006, ??? wrote:
If you really want to speed up both cases you need to use pointers and
increase the pointer value in each iteration. This saves the indexing in
every iteration.
Thank you, that was informative. Here are the results (one program at the end
for comp
Hello,
I'm newbie under Linux.
I'm trying to test my application which is working with sqlite 3.3.4
database fine under Windows, but it generates error about 'incorect
library' or something.So I started to test examples from FPC 2.0.2
official release and fillds example from db/sqlite give me
> Because of the copy-on-write mechanism. The reference count must be
> checked each time you do a write. This is normal. It's the same in
> Delphi, and a good reason for avoiding dynamic arrays.
>
> You can use pointer arithmetics in FPC, it works as a dynamic array, but
> without the overhead.
On Tue, 4 Apr 2006, ??? wrote:
Because of the copy-on-write mechanism. The reference count must be
checked each time you do a write. This is normal. It's the same in
Delphi, and a good reason for avoiding dynamic arrays.
You can use pointer arithmetics in FPC, it works as a dynam
On 4 apr 2006, at 15:01, Michael Van Canneyt wrote:
Thank you, that was informative. Here are the results (one program
at the end for completeness):
ap^:=app^; inc(ap); dec(bp);
47804845
ap^:=1; inc(ap);
37033703
ap^:=a[0] xor ap^; inc(ap);
3813420
On 4 apr 2006, at 16:28, Jonas Maebe wrote:
No, that is not true. He's now using plain pointers. The compiler
does not keep track of the fact that a particular pointer points to
a reference-counted type. Both loops are now equally fast in
principle (and they are in practice on e.g. ppc).
On Tue, 4 Apr 2006, Jonas Maebe wrote:
On 4 apr 2006, at 15:01, Michael Van Canneyt wrote:
Thank you, that was informative. Here are the results (one program at the
end for completeness):
ap^:=app^; inc(ap); dec(bp);
47804845
ap^:=1; inc(ap);
37033703
> > Because of the copy-on-write mechanism.
>
> No, that is not true. He's now using plain pointers. The compiler
> does not keep track of the fact that a particular pointer points to a
> reference-counted type. Both loops are now equally fast in principle
> (and they are in practice on e.g.
On 4 apr 2006, at 17:12, Пётр Косаревский wrote:
If he understands right: if he reverted the order of the
"loops" (big loops, each between time measurings) or separated
"loops", splitting program, he'd get different results.
However, splitting tests or reverting order doesn't seem to change
> Original order:
> Total:8199ms
> Total:12038ms
>
> Reversed order:
> Total:9526ms
> Total:13332ms
And on my machine it doesn't matter, whether I reverse them or even split.
When it will be more urgent (it will) I will:
1. Create pseudo dynamical arrays with GetMem() or something
2. Compare
On 4 apr 2006, at 17:36, Пётр Косаревский wrote:
Original order:
Total:8199ms
Total:12038ms
Reversed order:
Total:9526ms
Total:13332ms
And on my machine it doesn't matter, whether I reverse them or even
split.
Probably you are not using the latest 2.1.1 compiler.
Jonas
___
Hello,I am trying to compile a Firebird UDF library with fpc 2.0.0 under on the amd64 architecture (precisely: ubuntu dapper preview release),but unfortunately I hit bug 4733...That is: The code compiles fine, but fails to link, here below the complete error:
[EMAIL PROTECTED]:~/subversion/linux/Ud
29 matches
Mail list logo
