time make -j 64
==
It might not build modules - which present a lot of files thsu I/O.
"make -j .. deb-pkg" builds & packs both image & modules (the
benchmark has selected for build approx 75% of all available modules )
___
fpc-devel m
make -j has a dramatic effect on an SMP system, particularly if it can
find groups of jobs without too much interdependence.
=
The benchamark was surprising. Diring it, me observed 80..95% load of
each CPU still having high I/O load on the RAID1. How can it be ?!
Whi
"make -j 16 deb-pkg" vs "make -j 2 deb-pkg", sure :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
so that compilation could start while the disk is stressed by loading
all other PPU files, required for the compilation of units with more
dependencies.
==
Disk I/O is a huge low-down to avoid on any price (like databases do
with their indexing). Today me tested building LINUX kernel 3.
C users and developers are trained in this, and have their experience in
detangling the web of deps etc, have developed semi-automated helper tools
etc.
---
Inflicting this on the Pascal masses is unrealistic and undesirable.
==
100% !
C(++) building system is a nightmare. I
I am not so sure about this.
===
Hmm - 20 (!) times (!!) difference. Usually it means design flaws thus
broad ways for improvements & reworks.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.or
BTW, devoted people for maintaining the WWW-site is a great matter :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Rethink the whole 20 string types mess, and implement only one string
type for 3.0 onwards.
==
No, No ! It'll 100% be slow & problematic UTF8.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listin
Even if you would implement something like the Unix "find" or "ls"
programs, they would be more likely to be limited by I/O and all sorts
of file/directory attribute lookups than code page conversions of file
names.
1) I/O is heavily cached on modern a-lot-of-RAM machines & 2)
conversi
Ignoring ligatures or other foreign languages' constructs and habits
will bite you, sonner or later.
==
To handle this, constantly size growing fixed-char enconings exit.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.
How many functions have you written that replaces
characters in an UTF-8/UTF-16 string with different size characters?
=
Me adore UTF-8 - a great way of storing unicode text, using non-latin
passwords,.. ! But if we have the RTL string type UTF-8 then we should
also have whole RTL
> Do you mean replacing a character in an UCS-2/UCS-4 string can be
> implemented more efficiently than in an UTF-8/UTF-16 string?
>
Sure, just scan the string char by char as array elements and replace
as matches encounter. Like working with integer arrays.
___
Why deal with single characters, by index, when working with
substrings also covers the single-character use?
Possibly because it tens times as slower for multiple chars processed.
___
fpc-devel maillist - fpc-devel@lists.freepascal
If you replied to this mail then you lost me.
I don't understand what problem of UTF-8 for the RTL you want to point
out. Can you explain again?
==
Substringing etc manipulation only via normalizing to fixed-char type
which may be inefficient (especially because it performs for each
i
For example?
==
Sometime reading directory/file names. Sometime PostgreSQL produces
UTF-8 dumps with errors causing problems to converting to single byte
encoding (KOI8-R) - me have to use the "-c" switch of ICONV for such
conversions. Really not seldom errors, but You (latins) are just
Because these documents are in UTF-8 parsing is about 2-3
times faster on these documents, searching is about 20 to 50% faster
=
Because You name is latin ANSISTRING "Mattias Gaertner" :) But
Imagine gigabytes of 4 bytes/char UTF-8 text.
__
Me always get excited how Graeme defends the solutions of his choice :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
For that reason there is no
speed difference between using a UTF-16 or UTF-8 encoded string. Both
can be coded equally efficient.
==
No in common, since UTF-8 needs error handling, replacing for
unconvertable bytes etc operations which may effect initial data which
makes per-byte comp
How well will your "access char via index" code perform on
that?
=
It'll mean "now is the time to switch to UCS-4" :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I have implemented multiple text edit/display widgets that do plenty
of string manipulation... all based on the UTF-8 encoding. I have
suffered NO speed penalties.
Sure no problems for GUI. But how about processing large texts ?
___
fpc
Performance heavily depends on what you do and you can find good
examples
==
Hmm.. are there implementations of UTF-8 substringing, string
comparision etc - but not using intermediate HEAVY normalizations
from/to fixed char length type for BOTH input arguments ?
Though me'm sure th
But if you are such a UTF-16 (actually UCS-2 as
that is what MSEgui supports) fan
=
If Martin can implement UTF-16 (with surrogate pair) support in MSEgui
string units (and these units fully cover absenting code of FPC RTL )
then the things are excellent.
PS:
UTF-8 is very-very sl
Handling 1..4(6) bytes is less efficient than handling surrogate
*pairs*.
===
But surrogate pairs break array-like fast char access anyway, isn't it ?
And there's a lot of room for optimizing utf-8 operation for instance
http://bjoern.hoehrmann.de/utf-8/decoder/dfa/.
Also a publicatio
For non-fixed char length there's nothing better than UTF8 (default
ASCII compatible, ready for any future alphabets,..). For fixed-char
length (fast string operations etc) also there's nothing better than
UCS-2 (the Earth coverage ) & UCS-4 (the galaxy coverage).
The non-fixed char length UTF-
For non-fixed char length there's nothing better than UTF8 (default
ASCII compatible, ready for any future alphabets,..). For fixed-char
length (fast string operations etc) also there's nothing better than
UCS-2 (the Earth coverage ) & UCS-4 (the galaxy coverage).
The non-fixed char length UTF-16 (
UTF-16 (for
fast per-char access etc optimizations)
Oops, UTF-32, for sure :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I obviously have lot of issues with the RTL suggestions being thrown
around in the past. eg: I have heard lots about the RTL mostly likely
being UTF-16 only, or being spilt into 3 versions AnsiString,
==
How about supporting in the RTL all versions of UCS-2 & UTF-16 (for
fast per-
Since the Delphi versions are incompatible amongst each other, how can
a single RTL and compiler mode switch support *all* these versions?
Really the team seems to fights to FPC + Lazarus be capable of
building thousands of Delphi based components - archivers, cyphers,
audio pr
No, Unicode is large than UCS-2. Also about your "alien language"
comment. Unicode includes code points not just for spoken languages,
but for anything that can be written. eg: musical notes, scientific
symbols, advanced math symbols, map glyphs, smiley faces (can be used
in in email's, IM prog
This probably explains the difference. MSEgui uses UnicodeString and is
compiled with -Fcutf8 for assignement of Unicode string constants to
UnicodeString variables and transparent conversion of Unicode string
constants to system encoding at runtime.
=
Really. MSEgui doesn't expose a
Fine with me: let's kick all those complicated utf-8 and utf-16
=
Isn't UCS-2 enough for all possible coverage on the Earth planet ?
Even chineese people use "64K-" dictionary (the sipmplified alphabet)
for computer typing.
PS:
UCS-4 (and UTF-8 BTW) looks appropriate for future
These fields are private for a reason.
Making them protected exposes them e.g. in TForm and TDatamodule from
Lazarus, which is a can of worms we are not going to open.
Such (exposing private fields to the protected level) properties may
have special names whi
>
>>> Am 21.07.2012 23:06, schrieb Ivanko B:
>>>> No, just reorder the fields so that they can be properly $IFDEFed as
>>>> protected for nonLAZARUS and left (private) as is otherwise.
>>>
>>> Why should lazarus people have less chances to mess wi
.
Then additional protected properties exposing private fields can also
be a part of these contracts - as a agreed exclusions to the
contracts.
2012/7/22, Ivanko B :
> A (global) compiler option "treat private as protected" might be
> another solution.
>
> Same
ing protected "brother" properties for related private fields
( less appealing than "1)" = people using them knows what they do )
2012/7/22, Ivanko B :
> Alternatives we present are discarded as sub-optimal or not to your liking.
> Let me recapitulate:
>
> 1.
relates to old issues, but there may be future issues
(subjects to wait until get fixed) - Martin, Graeme are mainly
bothered by them - whether it'll be possible to fix them in 1..2 days
(customer etc requirements) and in such manner that not to rebuild FPC
at developer's side.
2012/7/22
directive to turn said optimization off
==
But everyone wants the optimization ! (sure without breaking consequences)
2012/7/22, Ivanko B :
> Asking for changes to make base classes more flexible is not bothering
> us. It's a regular part of software development, and
Asking for changes to make base classes more flexible is not bothering
us. It's a regular part of software development, and in the best case
every user of FPC comes out ahead in the end thanks to the resulting
changes.
Hacking around the type system that results in certain optimizations
becoming
mp; patches, ..) of the forked feature of mainstream
project.
2012/7/22, Sven Barth :
> Am 22.07.2012 09:24 schrieb "Hans-Peter Diettrich" :
>>
>> Martin schrieb:
>>
>>> On 21/07/2012 16:55, Ivanko B wrote:
>>>>
>>>> The problem now
ivate(N) needing replacement
with Private(N)relaxed will be revealed at 1-st compilation.
2012/7/22, Martin Schreiber :
> On Saturday 21 July 2012 23:57:50 Florian Klämpfl wrote:
>> Am 21.07.2012 23:06, schrieb Ivanko B:
>> > No, just reorder the fields so that they can
But for very base (not yet specialized) classes - a good idea.
2012/7/22, Ivanko B :
> Why should lazarus people have less chances to mess with private fields?
> =
> AFAIK, they haven't to use any crackers up to now and it is a normal
> way for the mainstream - where c
.
Either we make them public for all or for nobody
=
It 'll break the regular (99% of cases) access rights in classes and
may greatly rise number of bugs.
2012/7/22, Florian Klämpfl :
> Am 21.07.2012 23:06, schrieb Ivanko B:
>> No, just reorder the fields so that they can
/22, Ivanko B :
> No, just reorder the fields so that they can be properly $IFDEFed as
> protected for nonLAZARUS and left (private) as is otherwise. Sure not
> every filed but those the non-mainstreams developers ask. This'll
> allow the non-mainstreams to start fixing right now.
related $IFDEF so on.
2012/7/21, Florian Klämpfl :
> Am 21.07.2012 20:47, schrieb Ivanko B:
>> I don't see cracker classes as valid code.
>> =
>> Then the FPC team should eliminate the need in such crackers - via
>> either disabling (via licencing, prison
non-mainstreams ( the above "{$ifdef
nonLazarus}" etc ).
2012/7/21, Florian Klämpfl :
> Am 21.07.2012 18:48, schrieb Martin:
>> On 21/07/2012 16:55, Ivanko B wrote:
>>> The problem now is that cracker classes can't be used in future anymore
>>> because of
Or an option:
{$ifdef nonLazarus}
protected
...
{$else}
private
...
{$endif}
Then MSEgui/FPgui/.. may be compiled with "-DnonLazarus" option
2012/7/21, Ivanko B :
> The problem now is that cracker classes can't be used in future anymore
> because of the new class field
The problem now is that cracker classes can't be used in future anymore
because of the new class field ordering optimisation, so I dared to ask.
==
The guys, this point is important !
All the discussion members are right in their arguments (Martin's &
the "community" impatience to fix
47 matches
Mail list logo
