se because "copy" was not public in the record. I can set a
flag [cnf_ignore_visibility] in the compiler
Bye,
Benito
On 23.07.23 16:35, Hairy Pixels via fpc-devel wrote:
On Jul 23, 2023, at 7:13 AM, Benito van der Zander via
fpc-devel wrote:
with my patch, "copy&qu
had about them is why they can't be inlined. Does anyone
have the answer for that? Not being able to be inlined is the biggest
performance problem I suspect, followed by the copy operator which gets called
redundantly on assignment to temporary memory.
On Jul 22, 2023, at 7:07 AM, Benito van der
Hallo,
i made a patch for faster management operators:
https://gitlab.com/benibela/fpc-source/-/commit/1aa0866112c97dd0c7ed7f3a4b1c7ab6420cb942
And it has been working fine on fixes3_2, but when I tried to apply it
on main, I get an error message:
views.inc(4318,17) Error: Wrong number
Hi,
and the FPC implementation is actually documented to not be stable in
the code:
{
QuickSort
Average performance: O(n log n)
Worst performance: O(n*n)
Extra memory use: O(log n) on the stack
Stable: no
Additional notes: Uses the middle element asthe pivot. This makes it work
well also on
Hi,
FillChar is on most platforms an assembly function and FPC *never*
inlines assembly functions.
even without inlining, rep stosb is faster than FillChar:
{$asmmode intel}
procedure repfillchar(var buffer; len: sizeuint; c: byte);
begin
asm
mov al, c
mov rdi, buffer
mov
Hi,
it could always inline it.
For small sizes do that mov and for large sizes do rep stosb on x86. It
is very fast nowadays. Faster than FillChar on my Intel laptop. (except
for mid sizes like 128 bytes)
Bye,
Benito
On 16.04.22 01:26, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
Hi,
in my big decimal unit, I need to divide by 10 all the time,
e.g.
https://github.com/benibela/bigdecimalmath/blob/master/bigdecimalmath.pas#L1324-L1325
would the magic div help there much?
Bye,
Benito
On 09.11.21 22:12, J. Gareth Moreton via fpc-devel wrote:
This one for
Hi,
that is a great idea
It especially useful for generics, where each specialization can create
a huge amount of identical methods
Best,
Benito
On 13.10.21 19:33, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
So one optimisation that has cropped up a couple of times is finding
Hi,
Don't forget that the record/management operator approach will again
blow up binary size; for every variable declared like this you risk
creating a new type.
the classic Delphi way was to use an interface for freeing. It only
requires one type and nothing blows up.
type
TDefer =
Hi,
what about overloading operators for OBJECTs?
They do not conflict with any default operators.
I expected this to work, but it did not compile:
type generic TXQHashset = object //(specialize
TXQBaseHashmap)...
class operator =(const a, b: TXQHashset): boolean;
end;
Cheers,
Hi,
I'm against adding support for this. Dynamic arrays have guaranteed
behavior. If users find that this behavior is not appropriate for
their use case then they should not use them (or as you already
suggested, preallocate them).
well, setlength does not always initialize the array
and: https://bugs.freepascal.org/view.php?id=36603 a regression when
passing empty strings to regexpr
perhaps its follow-up: https://bugs.freepascal.org/view.php?id=36701
On 25.07.20 16:26, Martin wrote:
Could the fix for issue https://bugs.freepascal.org/view.php?id=36017
be merged to
Hi J. Gareth,
I once added -a to debug my Android app, and then it did not start
anymore on some devices...
Bye,
Benito
On 19.07.20 05:09, J. Gareth Moreton wrote:
Hi everyone,
I've noticed something a bit weird with the Free Pascal Compiler when
you use the the -a option to dump the
Hi J. Gareth,
that is a really important optimization.
Especially with new record management operators. I am going to wrap
almost all my variables in records, so they will be automatically
initialized.
I have suggested it in the bug tracker, but it was closed, because they
say the bug
,
Benito
On 27.04.20 07:46, Sven Barth wrote:
Am 26.04.2020 um 23:42 schrieb Benito van der Zander:
Hi Sven,
It's not that simple. In principle you're right that the compiler
could try to merge more implementations, but this does not depend on
the declaration of the generic, but the use
, Sven Barth wrote:
Am 26.04.2020 um 14:01 schrieb Benito van der Zander:
Hi,
perhaps it could be used to merge specializations (if fpc cannot do
that on its own):
Like when you have a hashmap THashMap, and need three
specializations:
THashMap
THashMap
THashMap
It is basically three times
Hi,
perhaps it could be used to merge specializations (if fpc cannot do that
on its own):
Like when you have a hashmap THashMap, and need three
specializations:
THashMap
THashMap
THashMap
It is basically three times the same hashmap, but if fpc does not detect
that, it might generate
Hi,
if someone needs even more bits: I once made a 65-bit integer type
Cheers,
Benito
On 23.04.20 07:27, Sven Barth via fpc-devel wrote:
Am 22.04.2020 um 22:21 schrieb Bart via fpc-devel:
Hi,
Please don't feel offended, but this typo just made me smile:
(And a smile is what we need in
Hi,
I use TortoiseHg and then a Mercurial to Git converter...
Unfortunately the linux distributions do not want to maintain it and
most ship with an outdated TortoiseHg in their package management
Best,
Benito
On 27.10.19 17:48, Florian Klämpfl wrote:
Am 27.10.19 um 15:32 schrieb Martok:
Hi,
Am 04.07.19 um 19:51 schrieb Marco van de Voort:
If $ifdef was a single char token, maybe. And for a trivial feature,
not a core one, like conditional compiling.
So the compiler will correctly give an error.
... but not at or near the place where the mistake is made.
Some
Hi,
Am 28.06.19 um 11:24 schrieb George Bakhtadze:
If FPC somehow guarantees that a global field (even only of simple
types) can be atomically read and written from any thread for ANY
platform that is a very strong guarantee and worth mention in
documentation.
btw, how would you do that if
Hi Gareth,
there are more optimizations to look at
An user could write custom string enumerators to replace such
assignments in loops and try to manually solve that issue.
But then
https://bugs.freepascal.org/view.php?id=34915
the enumerators are stored in memory rather than registers, so
Hi',
I don't see a need to add management operators to objects. Objects
have constructors and destructors, so they don't need Initialize and
Finalize operators
One need would be to automatically call the destructor
It could make the code much simpler, especially when it also replaces
An object based container library would also be helpful.
With classes stored on the heap you always need additional memory
access. Just one, but that is already bad in performance critical loops
Best, Benito
Am 06.06.19 um 18:23 schrieb George Bakhtadze:
It would be also great if there
Hi,
The trick with enumerators is to never make them classes, and use
advanced records instead, I've found. This way you avoid the heap
allocation and the implicit try/finally. Also make sure you inline the
MoveNext and GetCurrent!
that's what I do.
But the generated assembly is still
Hi,
there is NewPascal with improved memory safety/smart pointers:
http://newpascal.org/
but we try as much as possible to break old code.
I have noticed that. All my code has been broken by the codepage aware
strings and TEncoding
and FPC's goal to remain Delphi-compatible.
So
van der Zander
mailto:ben...@benibela.de>> geschrieben:
Hi,
The issue I was talking about is the fact that atomic operations
do function as global memory synchronisation operations across
all cores (at least not on all architectures). If core 1
atomatically inc
us not use the string for anything .
Bye,
Benito
Am 02.01.19 um 21:52 schrieb Jonas Maebe:
On 02/01/19 21:46, Martin Frb wrote:
On 02/01/2019 21:22, Benito van der Zander wrote:
Hi,
but if another core can do anything to the string, the refcount
should already be 2, one for this core and one for
Hi,
but if another core can do anything to the string, the refcount should
already be 2, one for this core and one for the other core, should it not?
UniqueString has such a test:
Function fpc_ansistr_Unique(Var S : Pointer): Pointer; [Public,Alias :
'FPC_ANSISTR_UNIQUE']; compilerproc;
Wait - why does that code not raise a 5033 "Function Result does not seem to be
set"? Add a second property "Property MyOtherString : String Index 2 Read
GetString;", and now its provably wrong. No warning. This seems wrong,
considering what we just talked about on fpc-pascal.
Because there
Hi Michael,
there was a discussion in this issue
https://bugs.freepascal.org/view.php?id=33323
Cheers,
Benito
Am 28.11.18 um 19:51 schrieb Michael Ring:
The more I dig the more I ask myself if not the rtl routine is to
blame for the issue in the first place because it only takes
Hi,
why is sizeof on object/class fields sometimes allowed and sometimes not?
type TTest = object
f: integer;
class procedure test;
end;
class procedure TTest.test;
begin
writeln(sizeof(f)); // does not compile
writeln(sizeof(TTest.f)); // compiles
end;
---
type TTest =
Hi,
case of strings could also use some optimization
does it still call fpc_ansistr_compare_equal ?
fpc could hash the strings, or build a trie, even testing the length
first would help
Cheers,
Benito
Am 03.08.2018 um 21:57 schrieb J. Gareth Moreton:
Hi everyone,
So I'm pondering
Hi,
In theory a call to _mcount could be replaced with a
compilerproc, which you could then override in the RTL, allowing a way to
add support for various profilers.
If it became fully overridable, you could put a callback between any
branch/line/function and create instrumentalization not
Hi,
XP is still important
yesterday I had a dream about some kind of ebook reader with multiple
pages, like 7 displays in a row on a foldable sheet, each for one page.
(and something about a washing machine) At first the displays looked
like Android, but when you took it apart, you noticed
7 14:55:53 +0100
Benito van der Zander<ben...@benibela.de> wrote:
[...]
That would be quite a slow down.
Is it?
I saw no speed difference between
var x = 1;
for (var i=0;i<10;i++) x++;
and
var x = [1];
for (var i=0;i<10;i++) x[0]++;
in Firefox.
Of course not. First
22:24, Mattias Gaertner wrote:
On Sun, 17 Dec 2017 21:43:45 +0100
Benito van der Zander <ben...@benibela.de> wrote:
Hi,
Naturally, any memory pointer operation is not possible in Javascript.
Code that relies on this will not work.
it would be great, if pointers were added.
There
Hi,
Naturally, any memory pointer operation is not possible in Javascript.
Code that relies on this will not work.
it would be great, if pointers were added.
One trick would be to wrap every variable that is accessed by a pointer
in an array (or object). The array can then be used as
Hi,
how do you recompile fpc after making a small change in the compiler,
like enabling the debugmsg define in x86/aoptx86.pas?
make buildbase says nothing was changed, and make clean; make buildbase
recompiles not just the compiler, but also the rtl, which is a waste of
time.
Bye,
Hi,
trunk is always broken, is it not?
Perhaps that is why it is called trunk. After all a trunk is an
incomplete tree. Just a little bit more than a completely broken tree
(stump)
Best,
Benito
Am 02.09.2017 um 19:03 schrieb Sven Barth via fpc-devel:
Am 02.09.2017 17:06 schrieb
Hi,
Isn't rax needed for the call to Free?
I think self stays in rdi
Perhaps we need a new calling convention that keeps self in rax. Or the
return value in rdi
Cheers,
Benito
Am 21.08.2017 um 15:45 schrieb Stefan Glienke:
Isn't rax needed for the call to Free?
Hi,,
SomeProc(Builder
.Build('1')
.Build('2')
.Build('3').Value);
That's exactly what I wanted to use it for
And since a string builder is such a low level construct, mostly used
for performance improvements, it needs to be fast without additional
Hi,
This pattern is not inherently efficient. Why should it be ?
It is not efficient, because of the pointless instruction!
Bye,
Benito
Am 21.08.2017 um 08:39 schrieb Michael Van Canneyt:
On Sun, 20 Aug 2017, Benito van der Zander wrote:
Hi,
why does fpc not remove
Hi,
why does fpc not remove the calculation of the return value of inline
functions, when the return value is unused?
For example
type TUtility = class
function doSomething: TUtility; inline;
end;
function TUtility.dosomething: TUtility;
begin
writeln();
result := self;
end;
adds a
Hi,
r35545, too ? (http://bugs.freepascal.org/view.php?id=31135)
Bye,
Benito
On 04/26/2017 03:17 PM, Marco van de Voort wrote:
In our previous episode, Bart said:
The issue is fixed by merging r33007, 33008, 33561 and 34384 (unit exeinfo).
Probably r35886 should be merged as well.
45 matches
Mail list logo
