[fpc-pascal] optimised compiler options for "release" version
Hi, I saw the following options recommended by the ExtPascal project for a final "release" build of ones project. Does this really make a difference in speed/performance and or executable size? How safe is it to deploy such an executable to a wide variety of computers out there. -O2pPENTIUM4 -CXpPENTIUM4 -XXsi -CfSSE While developing my software I enable the following, and simply though that for the final "release" version I'll remove the 'heaptrc' support (-gl & -gh) and 'strip' the executable at the end. -CX -Cr -O1 -gl -gh -XX What is recommended? Stay with the more conservative options of FPC (-O2 -CX -XX) or the more processor specific optimisations. Please note, that I do not know what exactly our clients run, processor wise (AMD or Intel, singlecore or multi-core, etc...) I would hope everybody at least runs a P4 and up on todays computers. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] optimised compiler options for "release" version
> How safe is it to deploy such an executable to a wide variety of computers > out there. ExtPascal is more for server side application. You should know where it will be deployed and you can set more appropriate options. ;) -- -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] optimised compiler options for "release" version
Bee wrote: > ExtPascal is more for server side application. You should know where > it will be deployed and you can set more appropriate options. ;) > Well, we have a couple of CGI applications written using Free Pascal (using powtils). We deploy it on some 300+ servers. We have no clue what hardware they run on. Hence the reason I asked this question in the first place. We are also looking at deploying these applications as a "distance learning" suite to the public and using a small "embedded web server" instead of Apache. Our desktop (GUI) applications are also deployed on a few thousand pc's, and again we have no clue what hardware they are running. Is there some reasonable optimisation parameters we can use for final "release" builds of our software, or should I stick to what I am using now. Lazarus compiler setting defaults and simply disable heatrc and source code line numbers in backtraces. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Strange error
When compiling a windows program with FPC version 2.2.4 with the switch -dDEBUG (using the default configuration), after running the program I get the following message: - Error Heap dump by heaptrc unit 0 memory blocks allocated: 0/0 0 memory blocks freed: 0/0 0 unfreed memory blocks: 0 True heap size: 65536 (80 used in System startup) True free heap: 65456 --- Is this: -A joke? -An error in the error message? -Indicationg some problem with my program? and if so, how can I find it? regards Hans Maartensson ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Records as properties and Delphi compiler error
On Sunday 07 June 2009 22:19:47 Jonas Maebe wrote: > On 07 Jun 2009, at 10:35, fpcl...@silvermono.co.za wrote: > > A high level, a class is like a record that has been modified to > > include > > functions and procedures. I know that I'm over simplifying thing > > here, please > > bare with me. > > The difference you skip over is the fundamental reason why one works > and the other doesn't: a class is a pointer, while a record is a value. I understand the difference, but a pointer to a record still suffers the from the same problem as a pointer to a class i.e. if memory is not allocated then the code fails at runtime. It's interesting to note though, that Delphi allows the assignment to the fields of a record type property via the with - do construct. Is this also the case with FPC 2.3.1? > > > I'm trying to understand the logic employed by the creators of > > Delphi where > > they don't allow to write to the fields of a record type property, > > but if the > > property points to a class type, then anything goes. > > In case of a class, the property returns a pointer (namely the pointer > to the class instance data), and then you (implicitly) dereference the > pointer and write data where it points to. In case of a record, the > property returns a record's value, and then (semantically) you change > the value of this returned record (not the value of the element of the > record that the property referred to). > > This worked in previous FPC versions because rather than treating the > result of the property like a function result (which it has to, > because that's the semantical meaning of a property, so you can > transparently change them into getters/setters without breaking any > code), it treated it like a direct field access in case no getter/ > setter existed. So rather than returning a record's value, the > property returned "a reference to a record". > > > In the example bellow, > > where a property is of a class type, both Delphi and FPC compile the > > code, > > but there is no guarantee that the object referenced to by the > > property has > > been instantiated before the property is used (The programmer must > > instantiate the TTestProp class within TTestClass prior to any call > > made to xx > > the property). IMO, it would be a nice feature if the compiler could > > be > > modified to issue a warning in such a case.Again, I'm over > > simplifying, to > > the compiler, it would be similar to checking for a variable > > declaration > > before the variable is used. > > Except that it's about dynamically allocated memory and depends on > interprocedural control flow graph analysis, which makes it immensely > more complex. > > > I thing that the "error" in the way that FPC allows record > > properties to > > access the record fields could be handy if retained. Perhaps this > > feature > > could be reserved for objfpc mode. What are your thoughts on the > > matter? > > Things will remain the way they are for the reasons explained above. > > > Jonas > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: Re: [fpc-pascal] Gecko / Firefox / XPCOM
no, I did not know that. Thanx for the hint - but its stuck to QT :-( therefor I am more interested in gecko... >reply to message: >date: 24.05.2009 15:15:50 >from: "Den Jean" >to: "FPC-Pascal users discussions" >subject: Re: [fpc-pascal] Gecko / Firefox / XPCOM > >On Thursday 21 May 2009 22:34:52 Henrik Genssen wrote: >> I am trying to use the gecko libs from >> http://sourceforge.net/projects/d-gecko with lazarus. > >in case you didn't know >http://lists.lazarus.freepascal.org/pipermail/qt/2009-May/001212.html >___ >fpc-pascal maillist - fpc-pascal@lists.freepascal.org >http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: Re: [fpc-pascal] Gecko / Firefox / XPCOM
so how can this unit be converted to FPC,
as the Memorymanager of FPC seems to differ from delphi...
unit nsMemory;
{$MODE Delphi}
interface
uses
nsXPCOM;
const
NS_MEMORY_CONTRACTID = '@mozilla.org/xpcom/memory-service;1';
NS_MEMORY_CLASSNAME = 'Global Memory Service';
NS_MEMORY_CID: TGUID = '{30a04e40-38e7-11d4-8cf5-0060b0fc14a3}';
function Alloc(size: Integer): Pointer;
function Realloc(ptr: Pointer; size: Integer): Pointer;
function Free(ptr: Pointer): Integer;
function HeapMinimize(aImmediate: Boolean): Longword;
function Clone(Ptr: Pointer; size: Longword): Pointer;
function GetGlobalMemoryService: nsIMemory;
function GlueStartupMemory: Longword;
procedure GlueShutdownMemory;
procedure SetToMemoryManager;
implementation
uses
nsError, nsInit;
var
gMemory: nsIMemory;
procedure FreeGlobalMemory;
begin
gMemory := nil;
end;
function SetupGlobalMemory: nsIMemory;
begin
if Assigned(gMemory) then Exit;
nsInit.NS_GetMemoryManager(gMemory);
if not Assigned(gMemory) then Exit;
Result := gMemory;
end;
function GlueStartupMemory: Longword;
begin
Result := NS_ERROR_FAILURE;
if Assigned(gMemory) then Exit;
nsInit.NS_GetMemoryManager(gMemory);
if not Assigned(gMemory) then Exit;
Result := NS_OK;
end;
procedure GlueShutdownMemory;
begin
gMemory := nil;
end;
function ENSURE_ALLOCATOR: Boolean;
begin
Result := True;
if not Assigned(gMemory) and not Assigned(SetupGlobalMemory()) then
Result := False;
end;
function Alloc(size: Integer): Pointer;
begin
Result := nil;
if ENSURE_ALLOCATOR then
Result := gMemory.Alloc(size);
end;
function Realloc(ptr: Pointer; size: Integer): Pointer;
begin
Result := nil;
if ENSURE_ALLOCATOR then
Result := gMemory.Realloc(ptr, size);
end;
function Free(ptr: Pointer): Integer;
begin
Result := NS_OK;
if ENSURE_ALLOCATOR then gMemory.Free(ptr)
else
Result := Integer(NS_ERROR_UNEXPECTED);
end;
function HeapMinimize(aImmediate: Boolean): Longword;
begin
Result := NS_ERROR_FAILURE;
if ENSURE_ALLOCATOR then
try
Result := NS_OK;
gMemory.HeapMinimize(aImmediate);
except
Result := NS_ERROR_FAILURE;
end;
end;
function Clone(ptr: Pointer; size: Longword): Pointer;
begin
Result := nil;
if ENSURE_ALLOCATOR then
Result := Clone(Ptr, size);
end;
function GetGlobalMemoryService: nsIMemory;
begin
Result := nil;
if not ENSURE_ALLOCATOR then Exit;
Result := gMemory;
end;
const
memmgr: TMemoryManager = (
GetMem: Alloc;
FreeMem: Free;
ReallocMem: Realloc;
);
procedure SetToMemoryManager;
begin
SetMemoryManager(memmgr);
end;
end.
>reply to message:
>date: 24.05.2009 18:28:19
>from: "Flávio Etrusco"
>to: "FPC-Pascal users discussions"
>subject: Re: [fpc-pascal] Gecko / Firefox / XPCOM
>
>On Sun, May 24, 2009 at 9:30 AM, Jonas Maebe wrote:
>>
>> On 21 May 2009, at 22:34, Henrik Genssen wrote:
>>
>>> nsMemory.pas(157,17) Error: Incompatible types: got "Realloc(Pointer,
>>> LongInt):^untyped" expected ">> Pointer, LongInt):^untyped;Register>"
>>
>> As the error message says: the compiler expects the first parameter of
>> realloc to be a "var" parameter, while the declaration of realloc apparently
>> uses a value parameter.
>>
>>
>> Jonas
>
>
>Oops. I guess I assumed the code was the other way around: that the
>gecko runtime accepted an application-provided mem-allocation
>routines, and barely read the message :-$
>BTW, regarding the remaining Warnings from the OP: is there any
>optional member in TMemoryManager or do all of them need to be setup?
>
>-Flávio
>___
>fpc-pascal maillist - fpc-pascal@lists.freepascal.org
>http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Records as properties and Delphi compiler error
Hi Nino, Can you please refrain from quoting the *whole* previous message, when your reply only relates to one or two lines. If other developers want to read the whole context of the message thread they can look in their email history or the mailing list archive. It is REALLY annoying seeing 80 lines in a message and then only 3 of those lines are actually the reply and the other 77 line are quoted text! -- Regards, - Graeme - fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strange error
Hans Mårtensson schreef: When compiling a windows program with FPC version 2.2.4 with the switch -dDEBUG (using the default configuration), after running the program I get the following message: - Error Heap dump by heaptrc unit 0 memory blocks allocated: 0/0 0 memory blocks freed: 0/0 0 unfreed memory blocks: 0 True heap size: 65536 (80 used in System startup) True free heap: 65456 --- Is this: -A joke? -An error in the error message? -Indicationg some problem with my program? and if so, how can I find it? -dDebug includes -gh, the heaptrc heapmanager. It prints these statistics. If you use a custom heapmanager, then the heaptrc heap manager is not used, so no statistics are gathered. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Records as properties and Delphi compiler error
On Monday 08 June 2009 19:55:00 Graeme Geldenhuys wrote: > Hi Nino, > > Can you please refrain from quoting the *whole* previous message, when your > reply only relates to one or two lines. If other developers want to read > the whole context of the message thread they can look in their email > history or the mailing list archive. > > It is REALLY annoying seeing 80 lines in a message and then only 3 of those > lines are actually the reply and the other 77 line are quoted text! Hi Graeme, Okay. Point taken. Mind you don't blow a gasket. Remember that today is only Monday. Regards, Nino ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Records as properties and Delphi compiler error
fpcl...@silvermono.co.za wrote: On Sunday 07 June 2009 22:19:47 Jonas Maebe wrote: On 07 Jun 2009, at 10:35, fpcl...@silvermono.co.za wrote: A high level, a class is like a record that has been modified to include functions and procedures. I know that I'm over simplifying thing here, please bare with me. The difference you skip over is the fundamental reason why one works and the other doesn't: a class is a pointer, while a record is a value. I understand the difference, but a pointer to a record still suffers the from the same problem as a pointer to a class i.e. if memory is not allocated then the code fails at runtime. It's interesting to note though, that Delphi allows the assignment to the fields of a record type property via the with - do construct. Is this also the case with FPC 2.3.1? property ARecord: TSomeRecorType read FTheRecord; property AClass: TSomeClassType read FTheClass; must be treated the same as function GetARecord: TSomeRecorType; function GetAClass: TSomeClassType; Why? Because that is what a property is for. A property means you are free to change the "read" part to use a getter-function. And doing that change *must* not break any code. You can not (not in a sensible way) do GetARecord() := Neither does it make sense to do GetARecord().X := The last bit may be possible, but it would assign .X to a *temporary* copy of the record, same as MyTemp := GetARecord(); MyTemp.X := What is the Point of this assignment, the value is lost, and unless you actually have a temp variable (like in the expanded example) you can not even retrieve the assigned value. However with GetARecord() do begin x := 5; // only the temp copy writeln(x); // using the value from the temp copy end; - As for classes GetAClass() does not return a temporary copy of your class, it return a temporary pointer to your class. so the following makes NO sense GetAClass() := TClass.Create; // trying to replace the class but GetAClass().X := 5; following the temporary pointer still leads to the real object - This is because TClass behaves like a pointer. Record does not behave like a pointer ** (the whole memory occupied by all values of the record is copied). ** This difference also applies if you pass such values as params to a procedure or function. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Records as properties and Delphi compiler error
fpcl...@silvermono.co.za wrote: Graeme Geldenhuys wrote: Can you please refrain from quoting the *whole* previous message... Okay. Point taken. Thank you, Nino! Everyone, please trim your quotes! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strange error
Vincent Snijders wrote: Hans Mårtensson schreef: When compiling a windows program with FPC version 2.2.4 with the switch -dDEBUG (using the default configuration), after running the program I get the following message: - Error Heap dump by heaptrc unit 0 memory blocks allocated: 0/0 0 memory blocks freed: 0/0 0 unfreed memory blocks: 0 True heap size: 65536 (80 used in System startup) True free heap: 65456 --- -dDebug includes -gh, the heaptrc heapmanager. It prints these statistics. If you use a custom heapmanager, then the heaptrc heap manager is not used, so no statistics are gathered. Vincent All right, but with former versions of FPC there was no message if all memory was freed. And because the message is marked "error", I thought that it might indicate some problem. /Hans M. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] sparse matrix storage method
Hi, would someone know of a procedure for solving a system of linear equations using a SPARSE MATRIX storage model. if one uses the usual: array [1..1;1..1] of "mostly_zeroes" then this is a really big waist of memory. I am thinking of using: Tlist instead, but I would not like to reinvent the wheel! I would apreciate if someone could give me a tip. Thank you Alain ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strange error
Hans Mårtensson wrote: All right, but with former versions of FPC there was no message if all memory was freed. I've been getting the memory usage output for some time already. So that is normal when heaptrc unit is enabled. And because the message is marked "error", I thought that it might indicate some problem. That must be some problem in your code I think. I don't receive the "error" line when my applications quits. I use FPC 2.2.5 by the way. Regards, - Graeme - fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: JUNK: fpc-pascal Digest, Vol 60, Issue 12
-snip- agreed. This looks like TMemory manager reimplementation from the unit called via the system unit.[an include somewhere.don't ask me which one, I have been over the RTL half a dozen times this past week looking for includes] I think its in ossys.inc and heap/heaph.inc.The TMemory manager construct is a known dependancy loop. (you have to use the include file or it doesn't build.) IE: $include heaph.inc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Records as properties and Delphi compiler error
Excellent explanation. Thanks Martin. Regards, Nino //*** On Monday 08 June 2009 20:33:48 Martin Friebe wrote: > fpcl...@silvermono.co.za ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] optimised compiler options for "release" version
AFAIK only -CfSSE? and -Op??? that you have to worry. If you're not sure, just use the lowest possible value (-CfX87 and -Op386). For optimizations, even using -O3 is fine. -- View this message in context: http://www.nabble.com/optimised-compiler-options-for-%22release%22-version-tp23919446p23937284.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
