[fpc-devel] strange code in TThread in classesh.inc
What is the point of these ifdef's, they are identical in the sense of
variable names and types...?
--Line 1208 in classesh.inc
snip
property Terminated: Boolean read FTerminated;
{$ifdef Unix}
private
// see tthread.inc, ThreadFunc and TThread.Resume
FSem: Pointer;
FInitialSuspended: boolean;
FSuspendedExternal: boolean;
{$ifdef linux}
FPid: LongInt;
{$endif}
{$endif}
{$ifdef netwlibc}
private
// see tthread.inc, ThreadFunc and TThread.Resume
FSem: Pointer;
FInitialSuspended: boolean;
FSuspendedExternal: boolean;
FPid: LongInt;
{$endif}
public
snip
--
Regards,
- Graeme -
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strange code in TThread in classesh.inc
Graeme Geldenhuys wrote:
What is the point of these ifdef's, they are identical in the sense of
variable names and types...?
--Line 1208 in classesh.inc
snip
property Terminated: Boolean read FTerminated;
{$ifdef Unix}
private
// see tthread.inc, ThreadFunc and TThread.Resume
FSem: Pointer;
FInitialSuspended: boolean;
FSuspendedExternal: boolean;
{$ifdef linux}
FPid: LongInt;
{$endif}
{$endif}
{$ifdef netwlibc}
private
// see tthread.inc, ThreadFunc and TThread.Resume
FSem: Pointer;
FInitialSuspended: boolean;
FSuspendedExternal: boolean;
FPid: LongInt;
{$endif}
public
snip
--
What would be your suggestion - change it to {$IF defined(UNIX) or
defined(NETWLIBC)}? I'd say that it would be better to make the interface
completely common, i.e. to get rid of these IFDEFs completely (e.g. by
including a record defined in platform specific part of the unit).
Tomas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strange code in TThread in classesh.inc
On 29/09/06, Tomas Hajny [EMAIL PROTECTED] wrote:
What would be your suggestion - change it to {$IF defined(UNIX) or
defined(NETWLIBC)}? I'd say that it would be better to make the interface
completely common, i.e. to get rid of these IFDEFs completely (e.g. by
including a record defined in platform specific part of the unit).
Tomas
Yeah, I just thought it is unnecessary code duplication and extra work
if it has to be maintained. The record idea sounds like a good plan
and will get rid of the IFDEF's completely. Sound make the code much
easier to read as well.
Regards,
- Graeme -
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strange code in TThread in classesh.inc
Graeme Geldenhuys schreef:
On 29/09/06, Tomas Hajny [EMAIL PROTECTED] wrote:
What would be your suggestion - change it to {$IF defined(UNIX) or
defined(NETWLIBC)}? I'd say that it would be better to make the interface
completely common, i.e. to get rid of these IFDEFs completely (e.g. by
including a record defined in platform specific part of the unit).
Tomas
Yeah, I just thought it is unnecessary code duplication and extra work
if it has to be maintained. The record idea sounds like a good plan
and will get rid of the IFDEF's completely. Sound make the code much
easier to read as well.
I won't argue the maintenance aspect, but I doubt your case for readability.
If you make this change, these fields are not in the same file as the class
definition anymore, so I would have to look at two places. And the implementation
becomes more unreadible.
Instead of
FSem := 0;
It will be (assuming a record field name FPrivateData)
FPrivateData.Sem := 0;
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TLCLMemanager
Hi, The LCL contains the non-visual unit LCLMemManager: http://svn.freepascal.org/svn/lazarus/trunk/lcl/lclmemmanager.pas I would like to propose that you rename it and add it to the FCL. It contains some simple (base) clasess for pooling records and objects. For the binary trees benchmark at http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytreeslang=all I wrote an alternative using the TLCLNonFreeMemManager. The alternative runs in 40% of the time of the original and uses less memory. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TLCLMemanager
On Fri, 29 Sep 2006, Vincent Snijders wrote: Hi, The LCL contains the non-visual unit LCLMemManager: http://svn.freepascal.org/svn/lazarus/trunk/lcl/lclmemmanager.pas I would like to propose that you rename it and add it to the FCL. It contains some simple (base) clasess for pooling records and objects. For the binary trees benchmark at http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytreeslang=all I wrote an alternative using the TLCLNonFreeMemManager. The alternative runs in 40% of the time of the original and uses less memory. If the lazarus people agree with this, I see no problem in doing so. What name would you suggest ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TLCLMemanager
Michael Van Canneyt schreef: On Fri, 29 Sep 2006, Vincent Snijders wrote: Hi, The LCL contains the non-visual unit LCLMemManager: http://svn.freepascal.org/svn/lazarus/trunk/lcl/lclmemmanager.pas I would like to propose that you rename it and add it to the FCL. It contains some simple (base) clasess for pooling records and objects. For the binary trees benchmark at http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytreeslang=all I wrote an alternative using the TLCLNonFreeMemManager. The alternative runs in 40% of the time of the original and uses less memory. If the lazarus people agree with this, I see no problem in doing so. I think they will agree, but I will ask to make sure. What name would you suggest ? A name change because of the LCL in the name. But just TMemManager is too generic, IMHO. What about TMemoryPool and TNonFreeMemoryPool? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TLCLMemanager
Vincent Snijders schreef: Michael Van Canneyt schreef: If the lazarus people agree with this, I see no problem in doing so. I think they will agree, but I will ask to make sure. Mattias, who wrote the unit, agrees. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TLCLMemanager
On Fri, 29 Sep 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Fri, 29 Sep 2006, Vincent Snijders wrote: Hi, The LCL contains the non-visual unit LCLMemManager: http://svn.freepascal.org/svn/lazarus/trunk/lcl/lclmemmanager.pas I would like to propose that you rename it and add it to the FCL. It contains some simple (base) clasess for pooling records and objects. For the binary trees benchmark at http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytreeslang=all I wrote an alternative using the TLCLNonFreeMemManager. The alternative runs in 40% of the time of the original and uses less memory. If the lazarus people agree with this, I see no problem in doing so. I think they will agree, but I will ask to make sure. What name would you suggest ? A name change because of the LCL in the name. But just TMemManager is too generic, IMHO. What about TMemoryPool and TNonFreeMemoryPool? Don't you think the word MemoryManager (MM) should be in it ? like pooledmm ? (and class TPooledMemoryManager) ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TLCLMemanager
On Fri, 29 Sep 2006 16:32:23 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Fri, 29 Sep 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Fri, 29 Sep 2006, Vincent Snijders wrote: Hi, The LCL contains the non-visual unit LCLMemManager: http://svn.freepascal.org/svn/lazarus/trunk/lcl/lclmemmanager.pas I would like to propose that you rename it and add it to the FCL. It contains some simple (base) clasess for pooling records and objects. For the binary trees benchmark at http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytreeslang=all I wrote an alternative using the TLCLNonFreeMemManager. The alternative runs in 40% of the time of the original and uses less memory. If the lazarus people agree with this, I see no problem in doing so. I think they will agree, but I will ask to make sure. What name would you suggest ? A name change because of the LCL in the name. But just TMemManager is too generic, IMHO. What about TMemoryPool and TNonFreeMemoryPool? Don't you think the word MemoryManager (MM) should be in it ? This could cause confusion with TMemoryManager. like pooledmm ? (and class TPooledMemoryManager) ? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] sse2 registers
I am trying out the sse2 support in fpc 2.1.1 and compile my code with -Cfsse2. The program is the mandelbrot benchmark: http://shootout.alioth.debian.org/gp4/benchmark.php?test=mandelbrotlang=fpascal The innerloop is like this: Zr := 0; Zi := 0; Tr := 0; Ti := 0; i := 0; while (i50) and (Tr + Ti limit) do begin inc(i); Zi := 2*Zr*Zi + Ci; Zr := Tr - Ti + Cr; Ti := Zi * Zi; Tr := Zr * Zr; end; If I look at the generated assembler, I noticed that only %xmm0 is used and all each time the variable needs to be retrieved from the stack. # Var Zr located in register mreg0md # Var Zi located in register mreg0md # Var Ti located in register mreg0md # Var Tr located in register mreg0md # Var Cr located in register mreg0md # Var Ci located in register mreg0md ... # [33] Zr := Tr - Ti + Cr; movsd -88(%ebp),%xmm0 subsd -80(%ebp),%xmm0 addsd -96(%ebp),%xmm0 movsd %xmm0,-112(%ebp) # [34] Ti := Zi * Zi; movsd -72(%ebp),%xmm0 mulsd -72(%ebp),%xmm0 movsd %xmm0,-80(%ebp) I thought there were more than one xmm registers. Why aren't they used? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Shootout
Hi,
Encouraged by Vincent I made an attempt to implement the Chameneos
benchmark of the Shootout. It turned out to be really hard, because we
don't have real semafores (which makes it for example impossible to
translate the C version).
However, with the RTLevent* routines, it is possible to implement it.
I have a final problem I'm unable to solve at this time. When all threads
exit, one of the threads still hangs in a RTLeventwaitfor call. We don't
know which one.
The trick is to get it out of its wait state in a safe way. My currect
solution (a set event call when the end is eached) sometimes fails,
depending on the weather or something.
If anyone wants to take a look, the source is attached.
Daniëlprogram chameneos;
uses sysutils
{$ifdef unix}
,cthreads
{$endif};
type colour=(blue,red,yellow,fade);
chamid=0..3;
var complement:array[colour,colour] of colour=
((blue,yellow,red,fade),
(yellow,red,blue,fade),
(red,blue,yellow,fade),
(fade,fade,fade,fade));
meet_event:PRTLevent;
tid:array[chamid] of Tthreadid;
const cham_colours:array[chamid] of colour=(blue,red,yellow,blue);
meetings:longint=0;
meetings_left:longint=100;
first_call:boolean=true;
state:longint=0;
var first,second:colour;
function other_creatures_colour(id:chamid;c:colour):colour;
begin
other_creatures_colour:=fade;
if meetings_left0 then
begin
if interlockedincrement(state) and 10 then
begin
other_creatures_colour:=first;
second:=c;
RTLeventsetevent(meet_event);
dec(meetings_left);
end
else
begin
RTLeventstartwait(meet_event);
first:=c;
RTLeventwaitfor(meet_event);
other_creatures_colour:=second;
end
end
else
RTLeventsetevent(meet_event); {!!! Not trusted!}
end;
function chameneos(parameter:pointer):ptrint;
var id:chamid;
other:colour;
begin
id:=ptrint(parameter);
while cham_colours[id]fade do
begin
other:=other_creatures_colour(id,cham_colours[id]);
if other=fade then
cham_colours[id]:=fade
else
begin
cham_colours[id]:=complement[cham_colours[id],other];
inc(meetings);
end;
end;
chameneos:=0;
end;
var i:chamid;
begin
if paramcount=1 then
val(paramstr(1),meetings_left);
meet_event:=RTLeventcreate;
for i:=low(chamid) to high(chamid) do
tid[i]:=beginthread(@chameneos,pointer(ptrint(i)));
for i:=low(chamid) to high(chamid) do
waitforthreadterminate(tid[i],0);
RTLeventdestroy(meet_event);
writeln(meetings);
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TLCLMemanager
Vincent Snijders wrote: Hi, The LCL contains the non-visual unit LCLMemManager: http://svn.freepascal.org/svn/lazarus/trunk/lcl/lclmemmanager.pas I would like to propose that you rename it and add it to the FCL. Aren't there more units that can be moved ? Some things in LCLProc, DynamicArray, DynHashArray, more ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Shootout
Daniël Mantione wrote: Hi, Encouraged by Vincent I made an attempt to implement the Chameneos benchmark of the Shootout. ??? Last week I submitted chamenos to shootout and it got accepted. It's only the work of one night, so it might need some improvement (it' isn't faster that the C implementation for instance) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TLCLMemanager
Micha Nelissen wrote: Vincent Snijders wrote: Hi, The LCL contains the non-visual unit LCLMemManager: http://svn.freepascal.org/svn/lazarus/trunk/lcl/lclmemmanager.pas I would like to propose that you rename it and add it to the FCL. Aren't there more units that can be moved ? Some things in LCLProc, DynamicArray, DynHashArray, more ? Maps.pp Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
