[fpc-pascal] Re: Register variables slowing down floating point operations
On Thu, 12 May 2011 20:54:16 +0200 cobines wrote > I have written the following program: > ... > max := 1; > for i := 0 to max do > vd := i / max; A really smart compiler would notice that this in this loop the value of vd is never examined, the loop being equivalent to vd := 1 ; and would code it appropriately. This sort of thing caused all kinds of trouble some 20 (30?) years ago with benchmarks involving small timing loops of this kind. One has to be very, very careful before believing such timing results! I have recently been "modernizing" my old benchmark programs, with many bizarre results. Funny things like replacing fixed size arrays by dynamic ones making things slower ... until I put the code inside a subroutine: the optimizer did a super job optimizing access to the local variables inside the subroutine! One should really use a large, complex program to test how well optimization works. Results with short loops are, as you found, likely to give inconsistent and misleading results. By the way, I gave up writing Assembler programs for number crunching when optimized Free Pascal got within 10% of the best I could do. That was some years ago and there have been several improvements in Free Pascal since: the compiled code is now, I think, faster than anything I could do in Assembler. And, yes: I have the odd program that goes faster with optimization off! Most like optimization on. For comparison, my Assembler was over 4 times faster than Turbo Pascal 3.01A for a similar number crunching application. Andrew Bennett ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Oberon Day 2011, N. Wirt speaking!
Jeppe, Do you know if the talks there will be recorded? Could be nice :) i don't know, i am not part of the organizing committee, but i will post any link here. Markus ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: generics question
Err... because at the time, T is not yet known. It would still fail to
compile even if you don't do any specialization. I guess the compiler does
type checking while parsing the generic class (and its methods) declaration,
not while specializing (well... it would still do type checking when
specializing, but the error would be a little cryptic due to missing exact
error location).
IMHO a solution would be to have additional compile-time syntax to check the
type of T (but this may cause a lot of headache due to inheritance concept).
Since it's impossible with the current state, the current solution would be
to declare a procedural type (with T as argument) inside the generic class
and instead of calling blah directly make it a procedural variable of that
type as argument of Test (since it's a class function). The caveat is of
course you have to pass Blah all the time. But unfortunately... it doesn't
work as well :(
Here's your modified program (compiled, but just run and see its output):
{$mode delphi}
uses
SysUtils;
function Blah(const val: Integer): string; inline; overload;
begin
Result:= IntToStr(val + 1);
end;
function Blah(const val: string): string; inline; overload;
begin
Result:= val + '1';
end;
type
TTestGen = class
type
TBlah = function (const val: T): string;
public
constructor Create();
class function Test(val: T; ABlah: TBlah): string; inline;
end;
{ TTestGen }
constructor TTestGen.Create();
begin
end;
class function TTestGen.Test(val: T; ABlah: TBlah): string;
begin
Result:= ABlah(val);
end;
type
TTestInt = TTestGen;
TTestString = TTestGen;
begin
WriteLn(TTestInt.Test(1,@Blah));
WriteLn(TTestString.Test('test',@Blah));
end.
If I don't overload Blah and pass the correct function for each call, then
the result is correct. Somebody's gotta file a bug report.
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/generics-question-tp4389896p4395332.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
[fpc-pascal] Re: Macro Processing
No for me, FPC has everything a macro could do (in a safer manner sometimes). The current macro implementation is enough for me (I just use it to save some typing when writing bindings with incompatible calling convention between platforms). -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Macro-Processing-tp4393149p4395343.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
Re: [fpc-pascal] Re: generics question
But is very strange, that this works:
type
TTestGen = class
constructor Create();
class function Test(val: T): string; inline;
end;
function Blah(const val: Integer): string; inline; //overload;
begin
Result:= IntToStr(val + 1);
end;
{function Blah(const val: string): string; inline; overload;
begin
Result:= val + '1';
end;
}
{ TTestGen }
constructor TTestGen.Create();
begin
end;
class function TTestGen.Test(val: T): string;
begin
Result:= Blah(val);
end;
type
TTestInt = TTestGen;
//TTestString = TTestGen;
begin
writeln(TTestInt.Test(2));
//writeln(TTestString.Test('2'));
readln;
end.
T is also not yet known. Why does it not work with overloaded functions
? IMHO this is not consequent.
Cheers,
Adrian.
On 14.05.2011 11:09, leledumbo wrote:
> Err... because at the time, T is not yet known. It would still fail to
> compile even if you don't do any specialization. I guess the compiler does
> type checking while parsing the generic class (and its methods) declaration,
> not while specializing (well... it would still do type checking when
> specializing, but the error would be a little cryptic due to missing exact
> error location).
>
> IMHO a solution would be to have additional compile-time syntax to check the
> type of T (but this may cause a lot of headache due to inheritance concept).
> Since it's impossible with the current state, the current solution would be
> to declare a procedural type (with T as argument) inside the generic class
> and instead of calling blah directly make it a procedural variable of that
> type as argument of Test (since it's a class function). The caveat is of
> course you have to pass Blah all the time. But unfortunately... it doesn't
> work as well :(
>
> Here's your modified program (compiled, but just run and see its output):
>
> {$mode delphi}
>
> uses
> SysUtils;
>
>
> function Blah(const val: Integer): string; inline; overload;
> begin
> Result:= IntToStr(val + 1);
> end;
>
> function Blah(const val: string): string; inline; overload;
> begin
> Result:= val + '1';
> end;
>
> type
> TTestGen = class
> type
> TBlah = function (const val: T): string;
> public
> constructor Create();
> class function Test(val: T; ABlah: TBlah): string; inline;
> end;
>
> { TTestGen }
>
> constructor TTestGen.Create();
> begin
> end;
>
> class function TTestGen.Test(val: T; ABlah: TBlah): string;
> begin
> Result:= ABlah(val);
> end;
>
>
> type
> TTestInt = TTestGen;
> TTestString = TTestGen;
>
> begin
> WriteLn(TTestInt.Test(1,@Blah));
> WriteLn(TTestString.Test('test',@Blah));
> end.
>
> If I don't overload Blah and pass the correct function for each call, then
> the result is correct. Somebody's gotta file a bug report.
>
> --
> View this message in context:
> http://free-pascal-general.1045716.n5.nabble.com/generics-question-tp4389896p4395332.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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics question
I have not yet looked at the parsing of methods of generic classes
during my work on the generics, but when I'll implement generic methods
I'll try to take a look at your problem.
Regards,
Sven
On 12.05.2011 12:37, Adrian Veith wrote:
Hi,
I try this:
type
TTestGen = class
constructor Create();
class function Test(val: T): string; inline;
end;
function Blah(const val: Integer): string; inline; overload;
begin
Result:= IntToStr(val + 1);
end;
function Blah(const val: string): string; inline; overload;
begin
Result:= val + '1';
end;
{ TTestGen }
constructor TTestGen.Create();
begin
end;
class function TTestGen.Test(val: T): string;
begin
Result:= Blah(val);
end;
type
TTestInt = TTestGen;
TTestString = TTestGen;
and get an error: can't determin which overloaded function Blah to use.
It would be nice if this could work. It would be a way to inject inline
functions into a generic class - avoiding virtual functions.
BTW. If I only have one Blah and only one corresponding specialization
it works.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
