[fpc-pascal] ReadXMLFile in fcl-xml package
Hi, I use ReadXMLFile from fcl-xml package to read XML file in UTF-8 encoding. Then I parse Nodes and use TextContent property which is string in system encoding ... but I need it in UTF-8 encoding. So I use again UTF8Encode(Node.TextContent). Is there any SIMPLE way how to say that ReadXMLFile should not perform translation from UTF-8 to system encoding? (may be somehow with custom TDecoder or so ... or use Laz_ versions or ...?) Thanks -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ReadXMLFile in fcl-xml package
On Thu, 18 Sep 2014 09:43:21 +0200 LacaK wrote: > Hi, > I use ReadXMLFile from fcl-xml package to read XML file in UTF-8 encoding. > Then I parse Nodes and use TextContent property which is string in > system encoding ... but I need it in UTF-8 encoding. > So I use again UTF8Encode(Node.TextContent). > Is there any SIMPLE way how to say that ReadXMLFile should not perform > translation from UTF-8 to system encoding? > (may be somehow with custom TDecoder or so ... or use Laz_ versions or ...?) The Lazarus sources contain units to read/write XML using UTF8 strings. The units are based on the fcl-xml units. The widestrings were replaced with UTF8 Ansistrings. lazarus/components/lazutils/laz2_xml*. The units work standalone. You don't need Lazarus for them. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Random thread lockup. QueueAsyncCall??
Hi There, I am writing my "prime finder" app to understand how thread synchronization works. I tried two methods (critical section and rtlevent), both have problem. For example the rtlevent version will run for a while then randomly stops. However, after the thread stops working it seems that the GUI is still responsive. Here is three core functions from then rtlevent version: procedure TPrimeFinder.Execute; begin while not Terminated do begin RTLeventWaitFor(Barrier); if not IsPrime then Number := 0; Application.QueueAsyncCall(@AddPrime, PtrInt(Self)); RTLeventResetEvent(Barrier); end; end; procedure TPrimeFinder.AddPrime(data: PtrInt); var tr: TPrimeFinder; begin tr := TPrimeFinder(data); with fmMain do begin if tr.Number > 0 then begin cnt += 1; if tr.Number > max then max := tr.Number; end; tr.Number := num; RTLeventSetEvent(tr.Barrier); Inc(num); leCount.Text := IntToStr(cnt); leMax.Text := IntToStr(max); end; end; procedure TfmMain.Button1Click(Sender: TObject); var i, c: Integer; begin num := 2; c := StrToIntDef(edThreads.Text, 1); if c < 1 then c := 1; SetLength(wk, c); for i := 0 to c - 1 do begin wk[i] := TPrimeFinder.Create(False); wk[i].FreeOnTerminate := True; wk[i].Barrier := RTLEventCreate; wk[i].Number := num; Inc(num); RTLeventSetEvent(wk[i].Barrier); end; end; I suspect that it is blocked on the RTLeventWaitFor, because if I use this: RTLeventWaitFor(Barrier, 1000); It will periodically pause for 1 second, then continue. Is this a problem in Application.QueueAsyncCall, or I made some mistakes? Thanks! Xiangrong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Random thread lockup. QueueAsyncCall??
2014-09-18 23:10 GMT+08:00 Xiangrong Fang : > > I suspect that it is blocked on the RTLeventWaitFor, because if I use this: > > RTLeventWaitFor(Barrier, 1000); > > It will periodically pause for 1 second, then continue. > I found the problem myself. Instead of writing: while not Terminated do begin RTLeventWaitFor(Barrier); if not IsPrime then Number := 0; Application.QueueAsyncCall(@AddPrime, PtrInt(Self)); RTLeventResetEvent(Barrier); end; I should write: while not Terminated do begin RTLeventWaitFor(Barrier); RTLeventResetEvent(Barrier); if not IsPrime then Number := 0; Application.QueueAsyncCall(@AddPrime, PtrInt(Self)); end; Because when doing the AsyncCall, the main thread may have called RTLeventSetEvent BEFORE the RTLeventResetEvent() is called. Xiangrong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optimal number of threads for SMP
2014-09-15 11:10 GMT+02:00 Xiangrong Fang : > （hyper-threads)? If the CPU has hyper threading then these should show up as individual cores (CPUs). They call a "core" with 2 processors on it a "core" but each of these "cores" is actually two complete processors (cores in the conventional meaning of the word) that just share some common circuitry to speed up some things (and slow down other things). If you have 2 hyper cores then your operating system should actually report 4 CPUs (cores) because that is what it actually is if you remove all the intel marketing terminology, no need to double any numbers. If it reports 4 CPUs then you have exactly 4 CPUs. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optimal number of threads for SMP
In our previous episode, Bernd said: > If the CPU has hyper threading then these should show up as individual > cores (CPUs). They call a "core" with 2 processors on it a "core" but > each of these "cores" is actually two complete processors (cores in > the conventional meaning of the word) that just share some common > circuitry to speed up some things (and slow down other things). > > If you have 2 hyper cores then your operating system should actually > report 4 CPUs (cores) because that is what it actually is if you > remove all the intel marketing terminology, no need to double any > numbers. If it reports 4 CPUs then you have exactly 4 CPUs. Hyperthreading doubles the execution stream logic, so that one core can take two incoming streams of instructions. The idea is that when one thread stalls, or executes unoptimal code, the other thread can run, increasing utilization. But that is more something like 10%, not doubling it. Since the rest of the core (the execution units) can't actually handle processing two streams at full speed. You are probably confused with AMD's module system, which does duplicate cores, and only shares some logic (like AVX) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optimal number of threads for SMP
Marco van de Voort wrote: Hyperthreading doubles the execution stream logic, so that one core can take two incoming streams of instructions. The idea is that when one thread stalls, or executes unoptimal code, the other thread can run, increasing utilization. But that is more something like 10%, not doubling it. I'd expect somewhat better than 10%, but another complicating factor is that it will depend on the cache architecture. Also in the general case some architectures can manage a lot of integer threads but have a massive bottleneck if multiple threads try to do floating point operations. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optimal number of threads for SMP
In our previous episode, Mark Morgan Lloyd said: > > Hyperthreading doubles the execution stream logic, so that one core can > > take two incoming streams of instructions. The idea is that when one thread > > stalls, or executes unoptimal code, the other thread can run, increasing > > utilization. But that is more something like 10%, not doubling it. > > I'd expect somewhat better than 10%, It's a bit low. It is more like 15%. Based on kernel compile benchmarks on phoronix.com done with and without HT. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
