welcome to Core i7 965 into the Top 40 computers.

here

Still climbing!

the press has many articles for your reading.

help yourself.

my friend movieman did run on WCG

click here, if you like it iced and overclocked.

enjoy! and get ready to crunch, it will be available in store the 17th, in quantity :)

Who?

welcome to Core i7 965 into the Top 40 computers.

here

Still climbing!

the press has many articles for your reading.

help yourself.

my friend movieman did run on WCG

click here, if you like it iced and overclocked.

enjoy! and get ready to crunch, it will be available in store the 17th, in quantity :)

Who?

Wow! What can we expect for the 920 & 940?

---

- Luke.

Say Who?
Why don't you overclock yours?
http://setiathome.berkeley.edu/results.php?hostid=4613769
I am sure you can do better than that. I can with my Q6600 G0.

welcome to Core i7 965 into the Top 40 computers.

here

Still climbing!

the press has many articles for your reading.

help yourself.

my friend movieman did run on WCG

click here, if you like it iced and overclocked.

enjoy! and get ready to crunch, it will be available in store the 17th, in quantity :)

Who?

Wow! What can we expect for the 920 & 940?

a ruff estimate is around 25 to 30% faster than Core 2 Quad same frequency. Then, if you overclock, you 'll beat skulltrail ... especially with fast memory.
I am running at 1866Mhz DDRIII, at 4.0Ghz :)

Say Who?
Why don't you overclock yours?
http://setiathome.berkeley.edu/results.php?hostid=4613769
I am sure you can do better than that. I can with my Q6600 G0.

if you look carefully, on longer units, it is almost as fast as the Top MACs.
remember, it does calculate 8 at a time and it is a single processor.

Say Who?
Why don't you overclock yours?
http://setiathome.berkeley.edu/results.php?hostid=4613769
I am sure you can do better than that. I can with my Q6600 G0.

if you look carefully, on longer units, it is almost as fast as the Top MACs.
remember, it does calculate 8 at a time and it is a single processor.

I saw a lot of 17 credit WU done in about 1200 seconds. You can do better I am sure. My Q6600 does 17 credit WU in about 800 seconds.

Here a just 3 of the few thousand news stories and reviews on the Core i7....

Intel Core i7 reviews arrive - and yes, it's fast!
Intel Core i7 965 Extreme Edition Review
Intel Core i7 - Nehalem arrives and FSB departs

The latter two just 1 hour old, and the first is just 7 minutes old according to Google News!

The Tick has become a Tock....

---

- Luke.

I prefert this one, a real pro in tech doing his job:

http://www.pcper.com/article.php?aid=634

Say Who?
Why don't you overclock yours?
http://setiathome.berkeley.edu/results.php?hostid=4613769
I am sure you can do better than that. I can with my Q6600 G0.

if you look carefully, on longer units, it is almost as fast as the Top MACs.
remember, it does calculate 8 at a time and it is a single processor.

I saw a lot of 17 credit WU done in about 1200 seconds. You can do better I am sure. My Q6600 does 17 credit WU in about 800 seconds.

you are doing 4 in 800 seconds, I am doing 8 in 1200 seconds ... in average, Core i7 if much better.

you are pushing one out in average ever 200 seconds, Core i7 is pushing one every 150 seconds :)
only the dual MACs do better, and on 45 credits, take a look, it equal the MACs with a single processor.

Yeah more credits in 1200 seconds.

Yeah more credits in 1200 seconds.

exactly, in my computers, one is running stock frequency, the other one at 4.0Ghz, both Core i7 965.

Hey Who?
Are you runing the Intel "Smackover" motherboard with the x58 chip?

yes, i use smackover.

Methinks it's time to move over to Intel.......

Francois, will the integrated graphics (2009) hit the performance?

---

Methinks it's time to move over to Intel.......

Francois, will the integrated graphics (2009) hit the performance?

I am doing all i can to get good integrated Performance in the GPU.
The increase in bandwidth of Core 17 gives it a fair change to be impressive too.

I dusted off Fred W's data vac about three days ago when I noticed crunch3r's post in the new computer thread pointing out two Nehalem SETI hosts. One of those hosts has been running a 64-bit science ap of build 42, the other a 32-bit ap of build 41. Which does better differs by Angle Range:

On the possibly false
assumption that the hosts were not changed over the period
represented, there appears to be a systematic difference. At VLAR,
Neh_1 gets lower times, while at VHAR Neh_2 gets lower times. In the
crucial central region the points are packed too tightly to make a fair
conclusion in this representation.

An expanded view suggests strongly that Neh_1 has the advantage from
AR 0.432 through 0.447 at the least. Together with the VLAR
advantage, this suggest that with the current ap versions, the 64 bit
ap from build 42 beats the 32 bit ap from build 41 on these Nehalem
hosts.

In these views, using straight reported times, the Nehalem hosts
generally get longer times than a 2.79 GHz Conroe-class Q6600 Quad and
particularly a 2.83 GHz Penryn-class Q9550 Quad. The 64-bit build 42
ap wins at VLAR, but overall this view suggests inferiority in reported time, as has been discussed in this thread.


The computer listing on the SETI site shows these as 8-CPU processors.
Nehalem is reported to have a modernized hyperthreading capability.
I think it very likely that we are looking at the fruit of
hyperthreaded operation, so for comparison of Quad-core to Quad-core,
it is proper to divide the reported Nehalem CPU times in half. The next
two graphs use a secondary y axis to provide this comparison. In the
VLAR range the Nehalem results are triumphant, far superior to even
the Q9550 results. In the VHAR range the Nehalem advantage is
considerably less, but still very substantial (by far more than the
rather small probable clock rate difference of approximately 3.2 GHz
vs. 2.8 GHz).

The portion of the crucially important mid-AR range for which we have
comparison also shows utterly compelling Nehalem advantage:

Overall, I should mention that the Q6600, E6600, and Q9550 data shown
were all recorded with the processors running 3 Einstein and 1 SETI
result. So far as I know, the Nehalem results are probably from
running 8 simultaneous SETI jobs.

Whether or not that is the case, I have strong reason to believe,
based on actual measurement on an earlier science ap, that the Q6600
SETI times would have degraded signficantly with three simutaneous SETI
jobs, and considerably worse at 4. I expect that the larger cache of
the Q9550 reduces this effect, but have not made observations. I
expect that Nehalem will degrade less, given the considerable effort
and expense that has gone into its considerably different memory
access architecture. In summary, my graphs almost certainly understate the
(already very large) advantage of a fully SETI-loaded Nehalem over a fully SETI-loaded Q6600.

Key questions:

1. what actual clock frequency are the Nehalem hosts running (ap
reporting appears to be unreliable, though the central tendency may be
toward a slight overclock).
2. were the Nehalem results generated running hyperthreaded?
3. how many SETI aps were actually running simutaneously when these
were generated?
4. what fraction of wall clock hours since these two hosts were signed
up to SETI have they actually been running SETI? The current RAC
seems lower than my optimistic assessment of their capabilities if
runnning 8 aps 24x7, especially for the longer-running host 4603078
(Neh_2).

---

I dusted off Fred W's data vac about three days ago when I noticed crunch3r's post in the new computer thread pointing out two Nehalem SETI hosts. One of those hosts has been running a 64-bit science ap of build 42, the other a 32-bit ap of build 41. Which does better differs by Angle Range:

On the possibly false
assumption that the hosts were not changed over the period
represented, there appears to be a systematic difference. At VLAR,
Neh_1 gets lower times, while at VHAR Neh_2 gets lower times. In the
crucial central region the points are packed too tightly to make a fair
conclusion in this representation.

An expanded view suggests strongly that Neh_1 has the advantage from
AR 0.432 through 0.447 at the least. Together with the VLAR
advantage, this suggest that with the current ap versions, the 64 bit
ap from build 42 beats the 32 bit ap from build 41 on these Nehalem
hosts.

In these views, using straight reported times, the Nehalem hosts
generally get longer times than a 2.79 GHz Conroe-class Q6600 Quad and
particularly a 2.83 GHz Penryn-class Q9550 Quad. The 64-bit build 42
ap wins at VLAR, but overall this view suggests inferiority in reported time, as has been discussed in this thread.

The computer listing on the SETI site shows these as 8-CPU processors.
Nehalem is reported to have a modernized hyperthreading capability.
I think it very likely that we are looking at the fruit of
hyperthreaded operation, so for comparison of Quad-core to Quad-core,
it is proper to divide the reported Nehalem CPU times in half. The next
two graphs use a secondary y axis to provide this comparison. In the
VLAR range the Nehalem results are triumphant, far superior to even
the Q9550 results. In the VHAR range the Nehalem advantage is
considerably less, but still very substantial (by far more than the
rather small probable clock rate difference of approximately 3.2 GHz
vs. 2.8 GHz).

The portion of the crucially important mid-AR range for which we have
comparison also shows utterly compelling Nehalem advantage:

Overall, I should mention that the Q6600, E6600, and Q9550 data shown
were all recorded with the processors running 3 Einstein and 1 SETI
result. So far as I know, the Nehalem results are probably from
running 8 simultaneous SETI jobs.

Whether or not that is the case, I have strong reason to believe,
based on actual measurement on an earlier science ap, that the Q6600
SETI times would have degraded significantly with three simultaneous SETI
jobs, and considerably worse at 4. I expect that the larger cache of
the Q9550 reduces this effect, but have not made observations. I
expect that Nehalem will degrade less, given the considerable effort
and expense that has gone into its considerably different memory
access architecture. In summary, my graphs almost certainly understate the
(already very large) advantage of a fully SETI-loaded Nehalem over a fully SETI-loaded Q6600.

Key questions:

1. what actual clock frequency are the Nehalem hosts running (ap
reporting appears to be unreliable, though the central tendency may be
toward a slight overclock).
2. were the Nehalem results generated running hyperthreaded?
3. how many SETI apps were actually running simultaneously when these
were generated?
4. what fraction of wall clock hours since these two hosts were signed
up to SETI have they actually been running SETI? The current RAC
seems lower than my optimistic assessment of their capabilities if
running 8 apps 24x7, especially for the longer-running host 4603078
(Neh_2).

You need o make It more obvious as to which of the two Neh_'s are which, As I had to dig to find out which is which and I'm still not so sure.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

I think I see one little flaw in Your very pretty graphs, Which of the two Neh(1 or 2) is 64 bit? Pink or Orange?

JokerCPoC (and any others responding), please edit your reply, even if already posted, to remove duplication of all the graphs.

Thanks.

As to your question, I did document that answer both by providing links to the hosts and in the subtitle.

The one I called Neh_1 and consistently displayed as orange diamonds was running 64-bit build 42, and the one I called Neh_2 was running 32-bit build 41.

---

You need o make It more obvious as to which of the two Neh_'s are which, As I had to dig to find out which is which and I'm still not so sure.

The graphs say it all - Neh_1 is 64 bit, Neh_2 is 32 bit.

F.

[edit]And another nice piece of work by the stats-master[/edit]

---

I think I see one little flaw in Your very pretty graphs, Which of the two Neh(1 or 2) is 64 bit? Pink or Orange?

JokerCPoC (and any others responding), please edit your reply, even if already posted, to remove duplication of all the graphs.

Thanks.

As to your question, I did document that answer both by providing links to the hosts and in the subtitle.

The one I called Neh_1 and consistently displayed as orange diamonds was running 64-bit build 42, and the one I called Neh_2 was running 32-bit build 41.

Well It's not that obvious, I mean Neh_1 and Neh_2 could have been called:

Neh_64

Neh_32

More obvious isn't It?

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's