This would raise a simple basic question... why FPC doesn't
also use
4K buffer? If it'd improve I/O performance a lot. Any specific
technical reasons why FPC decide to allocate 256 byte for
I/O buffer?
Yes. TP compatibility. The Text internal record contains the buffer.
Could have a
I think that FPC has very limited optimalization support.
There's some difference between -O2 and none but that's about
it as far as my tests (most at the shootout) went.
FPK even mentioned that most optimalizations are useless for
real world apps.
Doesn't it even support detection of loop
Hello,
can't you increase the I/O size? I've tested large-scale I/O buffers
(80K and over) with pascal with 4x the speed of C or C++ code. Not on
the FPC compiler, though.
Hope this helps.
Thierry Coq
Bisma Jayadi a écrit :
All you do is compare standard IO performance. You don't compare
On Wed, 14 Jun 2006, George Birbilis wrote:
This would raise a simple basic question... why FPC doesn't
also use
4K buffer? If it'd improve I/O performance a lot. Any specific
technical reasons why FPC decide to allocate 256 byte for
I/O buffer?
Yes. TP compatibility. The Text internal
On Wed, 14 Jun 2006, Thierry Coq (Personnel) wrote:
Hello,
can't you increase the I/O size? I've tested large-scale I/O buffers (80K and
over) with pascal with 4x the speed of C or C++ code. Not on the FPC
compiler, though.
Use SetTextBuffer() from the system unit. You can set any size
guess C is still faster to run, but definitely not for readability and
friendliness. ;-)
C is still faster to run, or faster to compiler ?
Depends on the compiler and generated code ;-)
Cheers.
-
Marco Aurelio Ramirez Carrillo
lazarus dot mramirez at star-dev dot com [dot mx]
On Tue, 13 Jun 2006, Bisma Jayadi wrote:
All you do is compare standard IO performance. You don't compare the
compiled code's speed.
I know. But I/O performance benchmarking is one of the basic language
comparison item. When you want to participate on ACM contest
On 6/13/06, Bisma Jayadi [EMAIL PROTECTED] wrote:
Taking this in account, to be honest, I think gcc should be ashamed for
those results.
Agree! Even Java 1.4.2 (according to benchmark result at
http://www.osnews.com/story.php?news_id=5602page=3) is faster than gcc! Pity
them! :D
A lot of
Yes. TP compatibility. The Text internal record contains the buffer.
Can we have 255 byte buffer works only on TP mode? While on other modes
(DELPHI/OBJFPC) is using 4 KB buffer as the default.
-Bee-
has Bee.ography at:
http://beeography.wordpress.com
A lot of people don't realize how fast Java is. By that I mean,
console, server backend or anything not using the GUI. The GUI
(Swing, AWT, etc) is what makes a Java application slow. We did a lot
of tests with different languages and GUI toolkits before we started
with our current
war war war war war war :D
2006/6/13, Graeme Geldenhuys [EMAIL PROTECTED]:
On 6/13/06, Aleš Katona [EMAIL PROTECTED] wrote: Java is neither fast nor good. What you tested were specialized cases of
small toy use which the VM could easily optimize to an extent where GCC can only drool. However if
At the moment, I don't see how we could do this.
I almost knew nothing about the compiler and the sources, but this problem
forces me to look at the FPC compiler source and I found TextRecBufSize constant
declaration within textrec.inc file on FPC's src/rtl/inc folder. Here is the
Just for your info...
For Lazarus the GetTickCount is implemented in the LCLIntf unit, if I
remember correctly.
It stubbornly refuses to find LCLIntf unit. What should I set in a
console application to access LCL? I tried with -dLCL ad -dLCL -dLCLgtk,
adding Interfaces in the uses clause,
Giuliano Colla schreef:
Just for your info...
For Lazarus the GetTickCount is implemented in the LCLIntf unit, if I
remember correctly.
It stubbornly refuses to find LCLIntf unit. What should I set in a
console application to access LCL? I tried with -dLCL ad -dLCL -dLCLgtk,
adding
Graeme Geldenhuys ha scritto:
[...]
Just for your info...
For Lazarus the GetTickCount is implemented in the LCLIntf unit, if I
remember correctly.
Thanks,
Giuliano
_
To unsubscribe: mail [EMAIL PROTECTED] with
On 6/13/06, Lord ZealoN [EMAIL PROTECTED] wrote:
war war war war war war :D
:-)
Graeme.
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at
Below is the result on my computer. I couldn't find my original code
or result, so ran them again. I didn't have Mono installed so couldn't
test C#.
My computer specs:
Ubuntu Linux 5.10
Linux kernel: 2.6.12-10-386
CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz
Memory Total: 451852 kB
Windows
Vincent Snijders ha scritto:
Giuliano Colla schreef:
Just for your info...
For Lazarus the GetTickCount is implemented in the LCLIntf unit, if I
remember correctly.
It stubbornly refuses to find LCLIntf unit. What should I set in a
console application to access LCL? I tried with -dLCL
Wow, compiling the different apps as mentioned in the OSNews article
with optimization, made a huge difference..
GCC 4.x time went down to 37.6 seconds from 55.8
Java with server VM went down to 113.5 seconds from 161.2
Interestingly, no matter what I set for FPC, the time was constant at
55.1
I think that FPC has very limited optimalization support. There's some
difference between -O2 and none but that's about it as far as my tests
(most at the shootout) went.
FPK even mentioned that most optimalizations are useless for real world
apps.
Ales
Lord ZealoN ha scritto:
Ok, here we go.
How i created the project? From Lazarus Menu- Project/Project from archive
Some changes? In Project/Compiler Options/Linking...
Only Win32GUIAPP and Strip activated.
FPC ver.: 2.0.3
Lazarus ver: 0.9.16 beta
Exe Size: 188.928
Physic Memory:
Total:
On 6/12/06, Giuliano Colla [EMAIL PROTECTED] wrote:
Cpu, cache 1024 KB, Memory 512 MB. I had to modify the source because
GetTickCount isn't available under Linux (at least I didn't find it), so
I implemented it (both for Kylix and Lazarus) with :
Just for your info...
For Lazarus the
Alexandre Leclerc wrote:
Here are the results I've got with the version of Lord ZealoN:
Total Lazarus benchmark time: 45188 ms
Total Lazarus benchmark time: 44236 ms
Total Lazarus benchmark time: 45749 ms
Here are those with my version:
Total Lazarus benchmark time: 44156 ms
Total Lazarus
2006/6/12, Al Boldi [EMAIL PROTECTED]:
Alexandre Leclerc wrote:
Here are the results I've got with the version of Lord ZealoN:
Total Lazarus benchmark time: 45188 ms
Total Lazarus benchmark time: 44236 ms
Total Lazarus benchmark time: 45749 ms
Here are those with my version:
Total Lazarus
The PC used in the link benchmark:Type: Dell Latitude C640 Notebook CPU: Pentium 4-M 2GHz RAM: 768MB Hard Disk: IBM Travelstar 20GB/4500RPM Video: Radeon Mobility 7500/32MB OS: Windows XP Pro SP 1
File System: NTFSintmathlongmath
doublemathtrigI/OTOTAL
Visual C++9.618.86.43.510.548.8
Visual
All you do is compare standard IO performance. You don't compare the
compiled code's speed.
I know. But I/O performance benchmarking is one of the basic language comparison
item. When you want to participate on ACM contest (http://acm.uva.es/problemset)
that would be one of biggest obstacle
Those are compilers, not languages you are comparing.
How would I do performance measurement of language without its compiler?
Taking this in account, to be honest, I think gcc should be ashamed for
those results.
Agree! Even Java 1.4.2 (according to benchmark result at
27 matches
Mail list logo
