Printable View
What is the "other monitoring system" to which you refer? You mean the temp/power monitoring aspects of the turbo control?Quote:
Originally Posted by ajaidev
"system agent" : that's the northbridge including IMC. Was there really that much more performance to wring out of that portion?
BTW, why was lynnfield's turbo so much better than bloomfield's?
I don't think a clarkdale would draw more idle power than my current subnotebook (IBM X60; 945GM & T2400 undervolted to 0.95V), yet it would be more powerful - for instance, it would allow me to play ALL 1080p material. While my T2400 is way faster than any of those Atom thingies out there, it's still not quite enough.Quote:
Originally Posted by saaya
Also the SSD I put in there could really use some more horsepower. So yes, a 3Ghz 32nm Dualcore with HT is exactly what I want in my subnotebook.
battery life? Pff.. I got a 110W battery, it lasts 8-10 hours anyways :p:
Guess I am just too extreme to count as your average customer eh :rofl:
100W battery? ouch... then why the h3ll are you using a subnotebook? for just 1kg more you get a full size keyboard and 15"+ full hd display... and better graphics...Quote:
Originally Posted by jcool
and too slow for 1080P? i can watch 1080P with my ul30vt... and thats an Su7300 overclocked to 1.7ghz... i think theres something wrong with your laptop? what nb/igp is it?
and you dont need a fast cpu for hd video... what you need is a discrete gpu, like ion or ion2 or something comparable from ati... a lot more efficient at decoding video in my experience...
i suppose it will have pcie 3.0 i am not sure
how many lanes does it have?? i wish it supports atleast 24 lanes.
i never liked p55 without nf200!!!
the waimea platform ( socket 1355 ) will have 40 lanes ( i think i read it somewhere ).
Okay, sample-havers. Surely you can post *something* additional?
I believe on average, if I were guessing ... 10-15% depending on work load, with some apps maybe as low as 5% and some as high as 20%.Quote:
Originally Posted by saaya
Based on what we know so far, the lower latency cache, Charlie mentioned an extra load port, which means a 5-issue design, and stuff we don't know yet. Given they are likely to keep HT alive in SB, I would also suspect they deepened the reorder buffers and increased the size of the TLBs in key places.
Memory intensive apps will benefit the most, and with an aggressive turbo scheme, both single threaded and multithreaded should see a nice pop.
Jack
They are definitely keeping HT alive in SB. :) One of the things they promise is "improved HT" performance.Quote:
Originally Posted by JumpingJack
Also, there's the rumored big increase in size of the loop-detector/trace-cache.
so you think there wont be any apps that see no perf/clock improvement on sb? i think thats overly optimistic...Quote:
Originally Posted by JumpingJack
even if its 15% faster per clock, thats still not a reason to upgrade... 15% higher ipc PLUS higher clocks, PLUS turbo, PLUS power savings in idle and few cores loaded... that would really be something you cant ignore... it would turn all current laptops into outdated "last year" equippment
Out of hundreds of apps, sure one, two a few maybe will not be sensitive to the changes, but on the whole the majority should look pretty good I suspect. The IPC gain won't be eye bulging great but it won't be anaemic either. And I am sure there will be those one or two cases where the fanboys will point to the result and say 'see, it sux' ignoring the 80% to 90%+ population where the gains are good to great ... just like the chorus of 'Nehalem sux as a gaming CPU' we saw when it first was introduced. Heck, SB will show no gains in GPU limited games and this will be a common fanboy claim I am certain of that.Quote:
Originally Posted by saaya
We know so little at this point, what we do know is that Intel is reworking the interconnect (ring bus), adding a load port, and bringing down cache latency, the rest is in a grouping 'entire architecture is reworked'.
My guess is that it is going to 5 issue and that they will widen the execution window, this will have two main effects -- single threaded performance (IPC) will see a nice pop (say 10% or so, not more than 15% I suspect), but HT situations will see a real improvement with a wider core, so heavy multithreading may show even better gains.
After 5-issues, however, IPC gains (in general) start to fall off, there is just not enough ILP to push it much futher, I have a few nice papers on the topic.
Well for x86 that is, other instruction sets can go higher.Quote:
Originally Posted by JumpingJack
The frond-end wasn't changed much as i know (with the exception of larger Loop detect buffer - can we call it trace cache now?). A back-end logic in Nehalem already can issue 6 uops each cycle (to 6 execution ports). In SB a load instruction can be issued on port 3 (in addition to port 2) that is up to 2 load uops can be issued each cycle (in Nehalem load uops can be issued on port 2 only).Quote:
Originally Posted by JumpingJack
Not really, sure there is some fluctuation ISA to ISA, but generically, ILP is hard to extract, only in certain ISAs is your statement true ... EPIC is a case here, but then EPIC is extraordinarily compiler depended to extract ILP.Quote:
Originally Posted by Hornet331
I will try to dig up those issue vs IPC papers.
My personal opinion is that we are quickly approaching a rapid law of diminishing returns on ILP (extracting IPC) in any given thread, Amadahl's law is taking over.
Yeah, I don't know really, we know so little. An extra load port implies (but does not guarantee) a wider core.Quote:
Originally Posted by kl0012
Just thinking through what would be a logical step forward for HT processors would be to bring one or more issues on board and deepen the buffers. That is one way to better extract HT performance.
Jack
Yeah I had epic in mind, since itanium is a 6-issue ľarch to beginn with. and those papers are welcome if it doesn't take to much time to dig them up. :up:Quote:
Originally Posted by JumpingJack
well it depends... is those 2 apps it doesnt scale at all in are very very common, then... whats the point of some synthetic benchmarks or professional tools scaling nicely if close to nobody uses them :DQuote:
Originally Posted by JumpingJack
thats how it was with SSE improvements in the past, so im curious what we will see with avx now...
i cant remember anybody saying it sucks for games... it kinda sucked for gamers cause it was a lot more expensive than c2d and c2q but offered the same perf and even slightly worse in some games...Quote:
Originally Posted by JumpingJack
that might be interesting for servers, but laptops? heavy multithreading on laptops? :p:Quote:
Originally Posted by JumpingJack
link pls! :DQuote:
Originally Posted by JumpingJack
amdahls law is the theoretical limit... most people forget that its far from feasible to write code that gets even close to that limitation in most situations... it just doesnt make sense... its possible to multithread most of the code we use, but does it make sense and will it actually be done? thats something intel and amd dont like to think about, as it ruins their strategy of just bumping out more and more cores in the future as a way to boost performance. they keep upping the core counts and hope that at some point, SOMEHOW, the infra structure will just MAGICALLY pick up and make use of all the cores, and that SOMEHOW, SOMEDAY a magical killer app shows up that makes use of lots of cores... :rolleyes:
so im glad to hear intel focussed on ipc with SB and didnt just give us 50% more cores... cant wait to see it in action!
I will take your other points in turn (may take a day or two, please be patient)... well, a generlized quote "Sux for gaming" was probably bad choice of words... but in general, reviews, forum fanboys, and such declared Nehalem a gaming flop ... why? Because they saw no improvement, why??? because of GPU walls, not because they tested gaming capabilities. Only one site really demonstrated what Nehalem could do in gaming scearios (Guru3D).Quote:
Originally Posted by saaya
There is a difference between a reasonable analysis of the data, and a bunch of fanboy drivel.
Examples:
http://www.xtremesystems.org/forums/...6&postcount=34
http://www.zdnet.com/blog/hardware/n...or-gaming/2434
http://forums.vr-zone.com/news-aroun...cks-games.html (snakeoil is a classic troll)
http://forum.beyond3d.com/showpost.p...4&postcount=12
http://forum.notebookreview.com/gami...alem-no-2.html
There are more XS examples, as I recall getting into debates that there is actually a such thing as a GPU limitation that hides CPU performance.
Those issue vs IPC links are coming, I had another request so it is worth the calories to dig them up.... please hang tight.
here is one ... for you and Saaya:Quote:
Originally Posted by Hornet331
http://portal.acm.org/citation.cfm?id=248209.237140
A PDF copy:
http://www.cs.utah.edu/~rajeev/cs781...olukotun96.pdf
However, this is not the prime paper I had in mind, my link (bookmark) is dead so i am trying to find it again.Quote:
We show that, due to fundamental circuit limitations and
limited amounts of instruction level parallelism, the superscalar
execution model will provide diminishing returns in performance
for increasing issue width.
EDIT: here is a nice paper on SMT and issue width, wider is better, but again diminishing returns http://twins.ee.nctu.edu.tw/courses/...ure/15_smt.pdf
Jack
Appreciate it. :)
Low latency is good for games so looking forward to benchmarks. Even 10% IPC increase in single threaded performance would be great.
One thing im sure of it wont be slower then last Uarch:D
First benches form coolaler
Attachment 105372
Attachment 105373
Attachment 105375
Attachment 105376
Attachment 105374
more in this tread
http://forum.coolaler.com/showthread...=240578&page=5
LOL they're gonna hide this thread too, that would be the 3rd I guess? :D
Hide? Its not like the infos arn't already everywhere on the web.. :p:
The other 2 threads got deleted yesterday ;). Let's hope this one stays a bit longer(than just one day) :DQuote:
Originally Posted by Hornet331
did u seen his practice video encoding?
Yes,it's practically the same per clock and per thread when compared to 45nm Nehalem....Quote:
Originally Posted by FlanK3r
You can see this here,same test done by the same guy on i7-920 (same video file,same number of files). i7-920 @ stock 2.66Ghz : 12min 20sec ; SB ES @ 2.5Ghz : 12min 35sec .Marginal difference at best. If you take into consideration that maybe i7 Turboed here and there with 8 threads,you would get around 3-5% advantage for SB Vs i7.
For SB to shine applications need to be recompiled with AVX optimizations in mind.