Re: [fpc-pascal] Effective memory allocation
Hi, Hi All, I am programming a Bloom Filter and need a high-performance way to On what platform are you doing this ? I am programming on Linux, but it will be used on both Windows and Linux, Windows is the primary target. Well, the first thing you should ask yourself is Do I REALLY need such a large bloom filter. Everything larger than the last level cache will seriously harm your performance as you are going to trigger a lot of cache and TLB misses. In general you should target for typical L1-Cache sizes (16-32KByte) or if REALLY necessary L2-Cache-sizes (256KByte-32MByte). Everything above that will make the performance go down rapidly, especially in hashing-application the CPU can't prefetch data properly as the access-patterns are erratic. Nico ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Effective memory allocation
On 02.11.14 15:05, Xiangrong Fang wrote: Sorry, the results in previous mail was mis-labeled. The result is: Using SetLength: Alloc: 9.40781697E-0001 Clear: 2.13420202E-0001 Using GetMemory: Alloc: 2.8100E-0005 Clear: 7.74975504E-0001 SetLength will already clear the array before returning it, so the time for SetLength is approximate time(GetMem) + time(Clear). As your test allocates a gigabyte of memory the OS will not immediatly assign physical memory to your process. The pagetable after a the allocation will contain entries which create faults when accessing the virtual addresses and then the OS will fill those pages in. So on first access a lot of time will be spend inside the OSes memory subsystem. For Linux the newly allocated memory will most likely point to a read only shared physical page which only contains zeros. On the first write to one of those virtual addresses the real page allocation will trigger and Linux assigns a new empty physical page to the virtual memory area. On Linux you can avoid this by passing MAP_POPULATE to mmap when allocating the memory. For SetLength this first access is already done when clearing the memory inside SetLength. For GetMemory it is done when your explicitly access the memory by calling FillQWord later. HTH Nico ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MorphOS
On 03.11.13 23:33, jri...@comcast.net wrote: I just happened across your group while scanning the internet for topics related to my interests. I used to use Pascal uner Microware OS-9 on the Tandy Color computer and I currently use MorphOS. As to the latter, I noticed that free Pascal is listed as supporting MorphOS, but I can not find a download for that OS. Fresh from the MorphOS-guy: 16:24 Chain|Q i can't reply the ML ATM, can you reply the guy that two older builds are here: http://charlie.amigaspirit.hu/software/fpc/morphos/ 16:24 Chain|Q and there'll be a new update as soon as i fix sysutils (there's something still b0rken) 16:25 Chain|Q and later also official builds, hopefully from 2.8 (or 3.0, if no 2.8) Nico ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.7.1 | ARMHF/ARMV6 | Optimization breaks my code at -O2
On 27.05.13 09:42, Bruce Tulloch wrote: What are the optimizations made between -O1 and -O2 on this target? Are optimizations at this level materially different when comparing ARM to x86 output targets? I ask because enabling -O2 breaks my code on ARM but runs fine all the way up to -O3 on x86. It's no doubt something I'm doing wrong which -O2 is exposing so I thought I'd ask if anyone can suggest what types of error are likely with building with -O2. Prima facie is looks like the object reference (this accessed via register r0) is corrupt when execution enters this TACTOR_UPDATE (via an Inherited call). The disassembly, cpu dump and this reference below show this but it's not clear to me why or how. You're misinterpreting the GDB-Output. While this will be in r0 when the method is entered, it gets MOVed to r4 in the third instruction. Later on r0 is used for many other things. But this is always accessed via r4 (or a mov r0, r4). When you dumped the registers your PC was somewhere inside the function, not at the beginning, so you don't have direct access to the incoming values anymore. It would be helpful if you could do an compilerrun with -alnr for -O2 and -O3 and then show the two versions of that function. Please open a bugreport for that at http://bugs.freepascal.org/ Nico ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memory alignment with FPC
On 10.10.12 14:40, dhkblas...@zeelandnet.nl wrote: One more question, when using packed records, is there anything to say about performance? Are there some tests anywhere that show how the performance is impacted? This highly depends on the architecture/processor. Many architectures (like older ARMs) can not handle unaligned access at all. Such an access would create an exception, which has to be handled by the system (Linux provides the capability to emulate these faults, but at a VERY high performance cost). Thats why fpc emits byte loads for halfword and word loads on packed records. But for a words these will also take about 7-15 cycles, depending in the compiler version and core used. Newer ARM implementations can handle unaligned access, but only under some performance penalty. x86 can handle unaligned access, but most implementations (I think current atoms and via nano are an exception) will suffer a rather high performance penalty. If you only use packed records to get your data from and to disk/network you'll not see much of a difference, but you should avoid using a packed record inside something which is performance sensitive. Nico ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem compiling
On 05.08.12 23:46, dhkblas...@zeelandnet.nl wrote: I get: text.inc(199,34) Error: Illegal type conversion: Text to TextRec after updating the compiler sources from SVN. Free Pascal Compiler version 2.7.1 [2012/05/22] for i386 Anyone have an idea what could be wrong? You have to use the latest release version to compile svn-trunk, which is 2.6.0. Nico ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
