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 ?!
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
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
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
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.
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
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
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
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)
conversion
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
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
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
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
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
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 ?
___
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
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
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
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.
___
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
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
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
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
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
(N) needing replacement
with Private(N)relaxed will be revealed at 1-st compilation.
2012/7/22, Martin Schreiber mse00...@gmail.com:
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 be properly $IFDEFed
feature of mainstream
project.
2012/7/22, Sven Barth pascaldra...@googlemail.com:
Am 22.07.2012 09:24 schrieb Hans-Peter Diettrich drdiettri...@aol.com:
Martin schrieb:
On 21/07/2012 16:55, Ivanko B wrote:
The problem now is that cracker classes can't be used in future anymore
because
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
directive to turn said optimization off
==
But everyone wants the optimization ! (sure without breaking consequences)
2012/7/22, Ivanko B ivankob4m...@gmail.com:
Asking for changes to make base classes more flexible is not bothering
us. It's a regular part of software
but it 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, Ivanko B
.
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 ivankob4m...@gmail.com:
A (global) compiler option treat private as protected might be
another solution.
Same
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
Or an option:
{$ifdef nonLazarus}
protected
...
{$else}
private
...
{$endif}
Then MSEgui/FPgui/.. may be compiled with -DnonLazarus option
2012/7/21, Ivanko B ivankob4m...@gmail.com:
The problem now is that cracker classes can't be used in future anymore
because of the new class field
( the above {$ifdef
nonLazarus} etc ).
2012/7/21, Florian Klämpfl flor...@freepascal.org:
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 the new class field ordering optimisation, so I
...@freepascal.org:
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, prisoning etc) the impatient
[mainly because of impatient customers] non-mainstreams (non
/22, Ivanko B ivankob4m...@gmail.com:
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
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 flor...@freepascal.org:
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 ivankob4m...@gmail.com:
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
38 matches
Mail list logo
