Re: [fpc-pascal] parameter list declaration

[leledumbo via fpc-pascal]

> I found this: http://www.freepascal.org/docs-html/ref/refse91.html but I
think it's not really clear, especially for newbie

Newbies often skip http://www.freepascal.org/docs-html/ref/refli5.html so
they can't read the diagrams used in all later sections.

> Compare that to official document from Delphi here:
> http://docwiki.embarcadero.com/RADStudio/Berlin/en/Parameters_(Delphi)
> which I think a bit more clear.

Their wiki content is actually user contributed, no better than Lazarus/FPC
wiki. It sometimes feels easier to read because it's written from user POV,
while official docs are written in more in-depth technical POV.



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/parameter-list-declaration-tp5728069p5728088.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/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[wkitty42]

On 04/01/2017 02:33 PM, Jürgen Hestermann wrote:

Am 2017-04-01 um 19:42 schrieb wkitt...@windstream.net:

consider this: when using a string var and writing to a binary file...
you reuse the string var for each value written...
if you don't clear the string var between fills then the binary will
contain "garbage" in the unused positions of the string var...
you can see this "garbage" when you view the binary file in hex mode...
the "garbage" being older longer string data than the current string data in

the var...

this var may be a global throwaway string var...


This can only happen for older string types where the actual length
can differ from the reserved memory (maximum string length).
With managed strings, this should never be possible as it would write
only the bytes of the current length.


some situations call for fixed length records... this same "garbage" effect will 
be seen in them...



I also don't see how this applies to an array of integers.


it may not... the subject doesn't differentiate... it only says "array" so i 
provided an example to your query about why this clearing may be desired... i 
just happened to use an array of char that we loving know as string[255]...



--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list* unless
   private contact is specifically requested and granted.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-01 um 19:42 schrieb wkitt...@windstream.net:
> consider this: when using a string var and writing to a binary file...
> you reuse the string var for each value written...
> if you don't clear the string var between fills then the binary will
> contain "garbage" in the unused positions of the string var...
> you can see this "garbage" when you view the binary file in hex mode...
> the "garbage" being older longer string data than the current string 
data in the var...

> this var may be a global throwaway string var...

This can only happen for older string types where the actual length
can differ from the reserved memory (maximum string length).
With managed strings, this should never be possible as it would write
only the bytes of the current length.

I also don't see how this applies to an array of integers.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[wkitty42]

On 04/01/2017 07:31 AM, Jürgen Hestermann wrote:

I am wondering what the purpose of filling all
array elements with zero's could be.
If I want to discard all elements I would simply delete
the whole array (setlength(MyArray,0) ).


consider this: when using a string var and writing to a binary file... you reuse 
the string var for each value written... if you don't clear the string var 
between fills then the binary will contain "garbage" in the unused positions of 
the string var... you can see this "garbage" when you view the binary file in 
hex mode... the "garbage" being older longer string data than the current string 
data in the var... this var may be a global throwaway string var...


we've seen the above since back in the TP3 days, at least... in some cases, 
we've been able to extract enough "garbage" to break security on a system... 
especially when there was enough left to suss out the leading part...


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list* unless
   private contact is specifically requested and granted.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Threading vs Parallelism ?

[Gary Doades]

>> On Mar 31, 2017, at 5:32 PM, Michael Schnell  wrote:
>> 
>> Regarding the view of the application (disregarding execution speed) or of 
>> the application programmer, there is no difference between real ("Hardware") 
>>  and virtual (e.g. threads) parallelism. These dirty basics need to be 
>> handled by the software and hardware infrastructure.
>> 
>> The use of real (e.g. multi CPU) parallelism that the application allows for 
>> being divided into multiple parallel "Threads". his fact given Hardware 
>> parallelism can speed up the execution, while even virtual parallelism 
>> allows for improving the latency of definable parts the application.

> I’m not understanding how parallelism could apply to anything besides 
> breaking down a task so that it can run on multiple hardware compute units.

> Why would you ever break a task into 100 threads when you could just run it 
> one thread?

"Events".

One gets into the grey area of threads and "processors". As an example you 
could divide a program into two threads, one reading and one writing. 
Immediately after issuing a write request, you could start reading the next 
item in a separate thread before the write is complete. This works because the 
I/O subsystem is mostly independent so that the OS can schedule another thread 
(or process) which is not waiting for the I/O subsystem to reply. Using only a 
single thread, the whole program has to wait for the I/O write to finish before 
starting the next read.

In this way a single process on a single "processor" (at least CPU) can 
interleave tasks to speed up the overall performance of the application. This 
could be extended to a myriad of cases of course.

Hence the recent upsurge in "async" routines, which only works if used properly 
of course.

Cheers,
Gary.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

Am 2017-04-01 um 15:09 schrieb Ryan Joseph:
> Because the array is being iterated and I need to know which values 
are set.
> Basically I have a dynamic array I grow to a certain size and this 
process happens in a loop.
> The options are to allocate/free the array every cycle or clear 
memory and allocate the array once.


If you just need to reuse the same array and only need to zero its elements
then of course fillchar would be the fastest approach (it saves the memory
reallocation step).

But this works only for standard array element types (like integer etc.).
Managed types have to be reset element by element.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Ryan Joseph]

> On Apr 1, 2017, at 6:31 PM, Jürgen Hestermann  
> wrote:
> 
> I am wondering what the purpose of filling all
> array elements with zero's could be.
> If I want to discard all elements I would simply delete
> the whole array (setlength(MyArray,0) ).

Because the array is being iterated and I need to know which values are set. 
Basically I have a dynamic array I grow to a certain size and this process 
happens in a loop. The options are to allocate/free the array every cycle or 
clear memory and allocate the array once.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 01.04.2017 13:31 schrieb "Jürgen Hestermann" :
>
> I am wondering what the purpose of filling all
> array elements with zero's could be.
> If I want to discard all elements I would simply delete
> the whole array (setlength(MyArray,0) ).
>
> But when should it be useful to keep all elements and
> just overwrite them all with zero's (which is also very time consuming)?
> If the exisiting values are no longer valid then why not
> simply delete these elements?
> It's the fastest way to get rid of them.
> If elements were zero before overwriting them with zero's
> I cannot even distinguish between original and overwritten elements.
>

If you wouldn't change the size of the array then merely doing FillChar (if
not working with managed types) is more performant then freeing the array
and allocating it again (which will also zero out the elements).
Normally the performance difference isn't *that* important, but sometimes
that difference can make or break something.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Jürgen Hestermann]

I am wondering what the purpose of filling all
array elements with zero's could be.
If I want to discard all elements I would simply delete
the whole array (setlength(MyArray,0) ).

But when should it be useful to keep all elements and
just overwrite them all with zero's (which is also very time consuming)?
If the exisiting values are no longer valid then why not
simply delete these elements?
It's the fastest way to get rid of them.
If elements were zero before overwriting them with zero's
I cannot even distinguish between original and overwritten elements.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 01.04.2017 10:35 schrieb "Ryan Joseph" :
>
>
> > On Apr 1, 2017, at 2:50 PM, Ryan Joseph 
wrote:
> >
> > Yeah, I was concerned with just compiler types or weakly retained
classes where I’m just keeping the reference.
>
> Another question. Is it more efficient/faster to reallocate a new array
of the same size or call FillChar on the existing array?

I think that FillChar should be faster as reallocating would need setting
the array to Nil and recreating it (SetLength with the same length won't
touch the existing elements) thus loosing any gain of reallocate and then
there'd still be the internal FillChar of the array.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Threading vs Parallelism ?

[Ryan Joseph]

> On Mar 31, 2017, at 5:32 PM, Michael Schnell  wrote:
> 
> Regarding the view of the application (disregarding execution speed) or of 
> the application programmer, there is no difference between real ("Hardware")  
> and virtual (e.g. threads) parallelism. These dirty basics need to be handled 
> by the software and hardware infrastructure.
> 
> The use of real (e.g. multi CPU) parallelism that the application allows for 
> being divided into multiple parallel "Threads". his fact given Hardware 
> parallelism can speed up the execution, while even virtual parallelism allows 
> for improving the latency of definable parts the application.

I’m not understanding how parallelism could apply to anything besides breaking 
down a task so that it can run on multiple hardware compute units.

Why would you ever break a task into 100 threads when you could just run it one 
thread?

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Ryan Joseph]

> On Apr 1, 2017, at 2:50 PM, Ryan Joseph  wrote:
> 
> Yeah, I was concerned with just compiler types or weakly retained classes 
> where I’m just keeping the reference.

Another question. Is it more efficient/faster to reallocate a new array of the 
same size or call FillChar on the existing array?

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Ryan Joseph]

> On Apr 1, 2017, at 2:39 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> It totally depends on the type. In case of primitive types like integers 
> there is indeed only the performance difference (though if you know that the 
> element size is four FillDWord could be even faster, depending on the 
> implementation in the RTL).
> If you have managed types however or class instances the result of the 
> FillChar (or equivalent) would be memory leaks.
> 
> 

Yeah, I was concerned with just compiler types or weakly retained classes where 
I’m just keeping the reference.

Thanks.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Setting record values

[Ryan Joseph]

> On Apr 1, 2017, at 2:46 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> I haven't looked at it in detail, but it could be that both have similar 
> efficiency. You could also add "inline" to the MakePoint function which 
> should get rid of a potential temporary variable if the compiler doesn't do 
> that already anyway.
> Alternatively you could also declare a constructor "TPoint.Make" or so (that 
> despite its name doesn't do any dynamic memory allocation either) which you 
> can declare as inline as well.

How is the constructor any different from the function?

> 
> In the end you can always check the assembler code.

Not sure how to do that or what to look for. It appears to me without knowing 
how the compiler works that there would be some allocating and copying of 
memory which is more overhead than assigning a value directly. Maybe it’s 
totally trivial but if it is it’s something I should cut out of my design going 
forward.


Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Threading vs Parallelism ?

[Michael Schnell]

On 31.03.2017 10:18, Tony Whyman wrote:

Neither of the above implies multiple CPUs or processing units.
Regarding the view of the application (disregarding execution speed) or 
of the application programmer, there is no difference between real 
("Hardware")  and virtual (e.g. threads) parallelism. These dirty basics 
need to be handled by the software and hardware infrastructure.


The use of real (e.g. multi CPU) parallelism that the application allows 
for being divided into multiple parallel "Threads". his fact given 
Hardware parallelism can speed up the execution, while even virtual 
parallelism allows for improving the latency of definable parts the 
application.


-Michael
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Threading vs Parallelism ?

[Michael Schnell]

On 30.03.2017 18:29, Jon Foster wrote:


I say threading is parallelism, even if just one form of it. The other 
methods of parallelism I mentioned here could also be done in FPC with 
the appropriate code.
Threading is the way parallelism can be achieved using a "standard" 
programming language and running the result as a "standard" program on a 
"standard" OS with "standard" computer hardware.


Of course there are lots of other options such as Multiple Data CPU 
instructions, starting multiple programs. and even using FPGAs (to be 
programmed in languages like "VHDL" (where parallelism is the "simple" 
syntax, while sequential execution needs do be dedicatedly coded).


The only thing that seems to be a viable option for a future "normal" PC 
compiler could be stuff like "parallel loops" (appropriate Pascal syntax 
is already done in Oxygene), as a syntax candy on a library allowing for 
parallelism by using a thread pool.


-Michael

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Setting record values

[Sven Barth via fpc-pascal]

Am 01.04.2017 05:59 schrieb "Ryan Joseph" :
>
> I’ve been using a design pattern in my code which I think is probably
pretty stupid so I’d like to make sure. Assume I have a type like TPoint
below and I want to set the value I’ll doing something like point :=
PointMake(x, y). How does the compiler handle this? It probably has to
allocate some memory on the heap so shouldn’t I always be setting values
using the alternative TPoint.SetPoint? It’s maybe not a big deal but it’s
something I’d like to clear up if it’s inefficient.

Records are only located on the stack (or in case of global variables the
data sections). If you want them on the heap then you'd need to explicitly
do that using pointers.

> function PointMake (_x, _y: integer): TPoint;
> begin
>   result.x := _x;
>   result.y := _y;
> end;
>
> procedure TPoint.SetPoint (_x, _y: integer);
> begin
>   x := _x;
>   y := _y;
> end;
>
> same outcome but which is more efficient?

I haven't looked at it in detail, but it could be that both have similar
efficiency. You could also add "inline" to the MakePoint function which
should get rid of a potential temporary variable if the compiler doesn't do
that already anyway.
Alternatively you could also declare a constructor "TPoint.Make" or so
(that despite its name doesn't do any dynamic memory allocation either)
which you can declare as inline as well.

In the end you can always check the assembler code.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Array clearing

[Sven Barth via fpc-pascal]

Am 01.04.2017 05:42 schrieb "Ryan Joseph" :
>
> As far as the compiler is concerned what’s the difference between
clearing an array using a for-loop vs. FillChar? It seems like iterating
the array would be slower but what does FillChar do exactly and is it
faster? The primary concern here is that the memory originally allocated
(using SetLength right?) remains in the same location.
>
> var
>   list: array of integer;
>
> SetLength(list, 10);
>
> for i := 0 to high(list) do
>   list[i] := 0;
>
> FillChar(list[0], Length(list) * sizeof(integer), 0);

It totally depends on the type. In case of primitive types like integers
there is indeed only the performance difference (though if you know that
the element size is four FillDWord could be even faster, depending on the
implementation in the RTL).
If you have managed types however or class instances the result of the
FillChar (or equivalent) would be memory leaks.

Plase also note that after a SetLength the new elements are already 0 (or
equivalent).

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] parameter list declaration

[Michael Van Canneyt]

On Sat, 1 Apr 2017, Mr Bee via fpc-pascal wrote:


Hi all, I'm looking for official reference for function/procedure
parameter list declaration in Pascal.  I found
this: http://www.freepascal.org/docs-html/ref/refse91.html but I think
it's not really clear, especially for newbie.  For example, when exactly
we need to use/put ; (semicolon) instead of , (comma) in parameter list.


You can always use a ;

When parameters are of the same type, you can use ,


Compare that to official document from Delphi
here: http://docwiki.embarcadero.com/RADStudio/Berlin/en/Parameters_(Delphi) 
which
I think a bit more clear.


I don't see how you can compare the 2. There is no diagram on that page.

Anway,
http://www.freepascal.org/docs-html/ref/refse91.html
is the "official" reference. 
It doesn't get more official than that.


Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal