«

On Fri, 21 Mar 2008 10:01:52 +1300, Ian Collins <ian->
wrote:

>Razii wrote:
>> More results this time java.class compiled to native Windows (instead
>> of using VM) by using JET compiler.
>>
>> http://www.excelsior-usa.com/ (JET compiler can be found here)
>>
>> 10 bibles (43 meg file)
>>
>> Time for reading, sorting, writing: 2453 ms (Java with JET)
>> Time for reading, sorting, writing: 2391 ms (Java with JET)
>> Time for reading, sorting, writing: 2344 ms (Java with JET)
>> Time for reading, sorting, writing: 2437 ms (Java with JET)
>>
>> Time for reading, sorting, writing: 5281 ms (c++)
>> Time for reading, sorting, writing: 5703 ms (c++)
>> Time for reading, sorting, writing: 3921 ms (c++)
>> Time for reading, sorting, writing: 3718 ms (c++)
>>
>Every action has an equal and opposite reaction:
>
>javac IOSort.java
>java IOSort
>Time for reading, sorting, writing: 2952 ms

That's Sun's VM, not JET native compiler (the post you replied to).

>CC IOSort.cc -library=stlport4 -fast
>./a.out
>Time for reading, sorting, writing: 1100ms
>
>So either my system has a poor Java implementation, or yours has a poor
>C++ one. Which proves nothing.

C:\>CL /O2 IOSort.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

IOSort.cpp
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\xlocale(342) :
warning C
4530: C++ exception handler used, but unwind semantics are not
enabled. Specify
/EHsc
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

/out:IOSort.exe
IOSort.obj

C:\>IOSort
Time for reading, sorting, writing: 6171 ms

C:\>IOSort
Time for reading, sorting, writing: 3953 ms

C:\>IOSort
Time for reading, sorting, writing: 3984 ms

On Fri, 21 Mar 2008 09:44:10 +1300, Ian Collins <ian->
wrote:

>
>Without any mention of the C++ compiler options used to build it.

How many times you need that info? I posted it in the first post and
several times after that.

C:\>CL /O2 IOSort.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

IOSort.cpp
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\xlocale(342) :
warning C
4530: C++ exception handler used, but unwind semantics are not
enabled. Specify
/EHsc
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

/out:IOSort.exe
IOSort.obj

C:\>IOSort
Time for reading, sorting, writing: 6171 ms

C:\>IOSort
Time for reading, sorting, writing: 3953 ms

C:\>IOSort
Time for reading, sorting, writing: 3984 ms

I think I will go cross post about how republicans are better than
democrats to NGs for both. Then I'll see how many posts it gets so I
can feel good about myself.

You still did not answer for the facts pointed out in my earlier
thread:
1) Measure from process enter to process exit ( Too hard for you? )
2) Limit execution and performance query to a single core (Also too
hard for you? )
3) Use a performance query with a guaranteed granularity of 1 ms.
clock has no such guarantee, not even close, it can be off by an
entire second!
4) Cheer that all you've proven is one particular code block runs
better or worse than another in your environment, with your tools.
5) Feel good that your thread grew by 1

Real computer _scientists_ would have a much larger sample size and
account for every factor. But you're not a scientist, you're a smelly
troll

On Thu, 20 Mar 2008 16:01:02 -0700 (PDT), Christopher
<> wrote:

>1) Measure from process enter to process exit ( Too hard for you? )
>2) Limit execution and performance query to a single core (Also too
>hard for you? )
>3) Use a performance query with a guaranteed granularity of 1 ms.
>clock has no such guarantee, not even close, it can be off by an
>entire second

You are posting nonsensical things that's why I didn't respond. We are
calculating only the time for reading, sorting, and writing (nor for
VM start up), and you don't need separate "performance query with a
guaranteed granularity of 1 ms". Who cares about "1 ms" or even "100
ms" anyway? It's irrelevant.

On Mar 20, 6:20 pm, Razii <DONTwhatever...@hotmail.com> wrote:
> On Thu, 20 Mar 2008 16:01:02 -0700 (PDT), Christopher
>
> <cp...@austin.rr.com> wrote:
> >1) Measure from process enter to process exit ( Too hard for you? )
> >2) Limit execution and performance query to a single core (Also too
> >hard for you? )
> >3) Use a performance query with a guaranteed granularity of 1 ms.
> >clock has no such guarantee, not even close, it can be off by an
> >entire second
>
> You are posting nonsensical things that's why I didn't respond. We are
> calculating only the time for reading, sorting, and writing (nor for
> VM start up), and you don't need separate "performance query with a
> guaranteed granularity of 1 ms". Who cares about "1 ms" or even "100
> ms" anyway? It's irrelevant.

Huh? Your results are in the 300 ms range, and an error of
potentially 100 ms doesn't bother you?

I'm convinced this is a joke now. Early April Fool's I guess.

On Thu, 20 Mar 2008 17:10:55 -0700 (PDT),
wrote:

>Huh? Your results are in the 300 ms range, and an error of
>potentially 100 ms doesn't bother you?

No, the difference of 100 ms doesn't bother me. It shows there is no
speed difference.

>I'm convinced this is a joke now. Early April Fool's I guess.

You are the joke. You have no USENET history and most of your replies
are to this thread. Did I touch a nerve? Why are you so obsessively
posting to the thread, troll?

On Mar 20, 6:20 pm, Razii <DONTwhatever...@hotmail.com> wrote:
> On Thu, 20 Mar 2008 16:01:02 -0700 (PDT), Christopher
>
> <cp...@austin.rr.com> wrote:
> >1) Measure from process enter to process exit ( Too hard for you? )
> >2) Limit execution and performance query to a single core (Also too
> >hard for you? )
> >3) Use a performance query with a guaranteed granularity of 1 ms.
> >clock has no such guarantee, not even close, it can be off by an
> >entire second
>
> You are posting nonsensical things that's why I didn't respond. We are
> calculating only the time for reading, sorting, and writing (nor for
> VM start up), and you don't need separate "performance query with a
> guaranteed granularity of 1 ms". Who cares about "1 ms" or even "100
> ms" anyway? It's irrelevant.

What's nonsensical about it?

Do you have no clue how timers work?
Do you not realize a start time could be on one core and an end
time on another? Hell, I could get a negative time if I tryed hard
enough.

Did you not pass high school math? Since when does 1 second = 100
ms? Last time I checked it was 1000

I think your a bit nonsensical

On Mar 20, 7:57 pm, Razii <DONTwhatever...@hotmail.com> wrote:
> On Thu, 20 Mar 2008 17:10:55 -0700 (PDT), dave_mikes...@fastmail.fm
> wrote:
>
> >Huh? Your results are in the 300 ms range, and an error of
> >potentially 100 ms doesn't bother you?
>
> No, the difference of 100 ms doesn't bother me. It shows there is no
> speed difference.
>
> >I'm convinced this is a joke now. Early April Fool's I guess.
>
> You are the joke. You have no USENET history and most of your replies
> are to this thread. Did I touch a nerve? Why are you so obsessively
> posting to the thread, troll?

You're right, I don't have your USENET street cred. For that, I'll
drop to my knees and thank God tonight.

Plenty of people with much more experience that I, however, have
driven gaping holes in your argument. I'm starting to question your
sanity in continuing.

On Thu, 20 Mar 2008 05:08:08 -0700 (PDT), peter koch
<> wrote:

>This is weird. If the C++ library is so bad I do not understand why
>the C++ code in your example is so much clearer than the Java
>equivalent with an "endless" loop that is exited in the middle.

If C++ library is so great, can you write by only using standard c++
library code that can do the following (and your code must be simpler,
easier to read, and use only standard library) like I am doing below.

import java.math.*;
import java.util.*;
import java.io.*;
public class Prime {

public static void main(String[] args) throws Exception {

FileWriter fstream = new FileWriter("prime.txt");
BufferedWriter fout = new BufferedWriter(fstream);
PrintWriter out = new PrintWriter (fout);
int bits = 1000;

BigInteger bigInteger;
long start = System.currentTimeMillis();
for (int i = 0; i <= 10 ; i++)
{
bigInteger = BigInteger.probablePrime(bits,new Random());
out.println(bigInteger); out.println();
}
out.flush();
long end = System.currentTimeMillis();
System.out.println("Time for generating ten " + bits +
" bit prime numbers " + (end - start) + " ms");
}
}




Here is what it does: it generates ten 1000 bit prime numbers and
writes them to a file. (1000 bit means an integer with 301 digits in
it)

I ran it a a few times with such results...

Time for generating ten 1000 bit prime numbers 10203 ms
Time for generating ten 1000 bit prime numbers 17031 ms
Time for generating ten 1000 bit prime numbers 10172 ms
Time for generating ten 1000 bit prime numbers 11859 ms


Pleas show us the greatestness and simplicity of c++ standard library.
The out file (prime.txt) must look something like this with ten 100
bit prime numbers

----------- out put file (prime.txt) -------

68422547233498617488436665116620648285665348766283 55397638542250959845743665351697255227934848482156 89434486652378414012615835256594530986755559695517 92642688113035546106232995370175592185209982601268 90669421170013094553214112988499526676482375353071 91192310153350766640274415682475589359999934010003 9

98486483211518133573085348356266286794764610981654 07388222336517490832458510672926299515789763227094 02640480933010851466263400137687460032794182676724 66620053539363322699566137891290552424204544448205 41158542651993392376425752312667969524325104139501 37602191350695901604620954763326091970555442911695 7

74724648412097907812636236366157966960630088491589 51320705532274543716175088447511478468738217459047 28079312273098661853005546999017052063709247186165 65734040836736522522693954611219649624496839837033 96496919624484535816579596847010140874266510985075 44081539400998332715095485255469831971353379137935 1

10307661443841358703042499578335475669167539597638 48407167084059846002406584139238882967046306908562 12509983750173132251873171918774371587210065461830 87715067594632510292725466539662500002942009673358 84673415885733539052543205929652173814970927633129 79426600350696452330211374246914002746422628134317 43

96463995604551853016948289549069167500706488848575 68971541459965770127506827253896121786333961281514 13555086512725088333312866549384014460560670203025 21872963808610107247010912672516007976711540061732 75374031756032389190673745898442648752134149486082 66363420293228878963859215418126259650539919801149 9

54641045221873312673297920369432685621636620108263 13167428236682292212471251253006159887248307492520 53626833967120697563685261217028670184618850677420 09503092046783967380301627348219679508153986615344 82769013763609307661014299189641931894663947535991 00382761079969745731739800516534157211429896913211 9

89869166421883170552914359815577047580009701259431 37197423439011525746036858282058344569686780852367 75714249370199497427166829254458118752783366306892 40644013183276875666319784308542753506315077119061 32491563930688957812901670932635095508760182677873 92376362855092373673896067114110823971413489909185 9

62766856579266202797508313683139938439974691701057 33612426682064744233764253914510057013843677656897 63899534291926083795665659301423008013385677802205 58347634504992513475196557242308159740260673773179 21799884910111659789204289025730212592107153924529 97039515880096140323963997396564459926407592393074 3

64494739769404319857051167540234122065996112119844 44557518153003140889617962537549197822342902685017 34403950769114561762540159367782346813645932881601 14886881290509673900819018753064351684370031803648 52877442035556030261006234175552168158246917246372 73382839356686596243082753244741632924204896887113 3

96454625846418159856145674067655222890793858133766 36777793253379649956921522143430515943252559790984 28944748582448511358073322946226505550962668172551 25007985663955254365098738589779202371064773827124 60314593005451787339196973168859381882333749970132 28658144723878184566555746618765030256042012226209 1

66266491546430321943528362916841240366019017922498 79123472876930930421377935289346502117906223474899 88761911826693360284881121094059190374136643270090 06557732296500158472189256248749269777181573617138 77846498350708402180443241389168320875916982789784 80911825805725946397019772973586984096476837813445 9

On Mar 20, 7:57 pm, Razii <DONTwhatever...@hotmail.com> wrote:
> On Thu, 20 Mar 2008 17:10:55 -0700 (PDT), dave_mikes...@fastmail.fm
> wrote:
>
> >Huh? Your results are in the 300 ms range, and an error of
> >potentially 100 ms doesn't bother you?
>
> No, the difference of 100 ms doesn't bother me. It shows there is no
> speed difference.
>
> >I'm convinced this is a joke now. Early April Fool's I guess.
>
> You are the joke. You have no USENET history and most of your replies
> are to this thread. Did I touch a nerve? Why are you so obsessively
> posting to the thread, troll?

*PLONK*
*WAVE*