|
As I recall Dell has used proprietary motherboards in the
past and have prevented any overclocking. I think I've read that they are
starting to use more mainstream components but I don't know how wide spread that
is. Dell has taken the attitude (again, in the past) that they
don't want you messing with it and cause support problems.
d
PS - when you download coretemp - use the main link and not
one of the mirror sites - they look like traps to me - very confusing - I tried
one and somehow wound up on a page that wanted me to pay for some other
software.
Hi D - Thank you! I have looked over
the CoreTemp website now, I will install it and run some tests before I go any
further. I definitely want to know that I am not causing temps to rise to a
level that might damage the CPU. I think I will pass on the overclocking for
now, but FYI I am just using the stock fan that came with the computer...may
have to think about changing it if CoreTemp shows overly high temps. Yes my
CPU is the Intel Q6600, I don't really know any details about the
motherboard, I built the computer online at Dell if that tells you
anything... Thanks again, I can report back with CoreTemp results if
anyone is interested...
Steve
----- Original Message -----
Sent: Tuesday, May 27, 2008 11:21
AM
Subject: RE: [amibroker] Re: Dual-core
vs. quad-core
As long as the temp stays down you'll be ok.
Several years ago I had a water cooled dual Xenon rig and had some runs that
took several days - never missed a beat.
Are you using the cpu fan that came with the chip or an
after market one? If you do overclock then you'll definitely need to
get a good after market fan - check www.maximumcpu.com for reviews.
I'd do it anyway just as insurance - the prices are very reasonable
unless you get exotic which shouldn't be necessary.
I looked back in the thread but didn't see where you
said what mother board you're using... And you did mention the 6600 - is
that your cpu?
d
Hi Paul - Something occurred to me today and
I was hoping to get your opinion ( as well as D's or anyone else with
the knowledge who would care to comment ). Do you think, even *without*
overclocking, that running these chips flat-out at 100% for hours or days
at a time could possibly cause overheating and subsequent
damage/destruction to the chip? Is there a simple and cheap way to
just monitor the temps ( no overclocking involved ) to be sure we do
continue running flat-out if temps are approaching or entering the danger
zone? Thanks very much!
Steve
----- Original Message -----
Sent: Monday, May 26, 2008 7:44
AM
Subject: RE: [amibroker] Re:
Dual-core vs. quad-core
Steve,
My knowledge on OC is quite limited, I have
only OCed 3 pcs in the last 4 to 5 years. Fortunately, they are all
still working, so you can say that my experiences have been favourable.
OC reminds a lot about Car Hot Rodding in my younger days. they are
quite similar, both are attempts to modify a basically mass manufactured
product to performance higher than their specifications. Both are
based on home grown wisdom rather than instituitionalised research.
OCing is basically elevating both the CPU clock speed as well as that of
the memory bus, and my methods, all from what I read on the internet are
always based on first clocking the memory controller hub (MCH), and once
that is done, overclock the CPU by increasing the multiplier, (CPU
speed is always adjusted as a multiplier of bus speed becasue they need
to be synchronised).
The danger related to OC is always that of
overheating, firstly the CPU, and secondary the MCH. So choosing a MB
that has decent cooling features for particularly the MCH is of the most
importance.(CPU are always well looked after by MB manufacturers, and
increasingly MCH is going the same way). In addition, the faster the
memory, the more sucessful the exercise is. So My advice is always
getting the fastest memory you can afford. (this is even more so given
what Tomasz has said recently in his AB performance
tests.
Before you overclock, you need to download a
few tools
1. cpuz
2. coretemp
3. memory tesing
You also need to find a set of instructions for
your MB. I found this set of instruction for my MB pretty good http://www.hardforum.com/showthread.php?t=1169366 In
this instruction, you will find where to download the tools I mentioned,
as well as a good methodology to follow. You may be able to find you MB
specific instructions on this site.
Also I found that disabling all devices that I
dont need helps - these include parallel and serial ports,
basically all the things I dont use and I can disable through
the Bios setting.
Testing: I only use AB for stress and
performance testing (I use the recommened software from the
site for diagnostic tests), because that is what I'm ocing for.
What I would suggest would be to use a few of your AFLs, insert in
them a few Getperformancecounter statements (AB
function). These should include a relatively simple AFL,
a long and complicated AFL testing lots of symbols (to
test Memory access performance) and one that
is somewhere in between. At the same time - monitor the
temperatures. These are far more meaningful tests than the stress tests
that most OC sites recommend.
I think dingo
is quite an expert in this area. may be he will say a few
words.
Cheers
Paul.
Hi Paul - I found your comment about
overclocking interesting, have googled around a bit but find that most
of the discussion is over my head. For example The Overclockers
Forum
discusses overclocking the Intel Q6600
chip on my new computer and people are claiming to get as much as
3.8GH out of this 2.4 GH chip. If you can find the time, would you
mind saying a few words about overclocking, how it is done, and what
are the dangers/limits etc? Do you need special software to monitor
the core temps? Thanks!
Steve
----- Original Message -----
Sent: Wednesday, May 14, 2008
2:12 AM
Subject: RE: [amibroker] Re:
Dual-core vs. quad-core
I havent noticed any slow down when
I run 2 instances of AB optimizing almost on a continuous bases
on my core 2 Duo. I have 4 Mb L2 cache. In fact with
overclocking, I'm able to increase the core speed significantly, and
noticably faster on AB optimization, without increasing the
temps to above 50 deg C
Hello,
I just run the same code on my relatively new
notebook (Core 2 Duo 2GHz (T7250))
and the loop takes less than
2ns per iteration (3x speedup). So it looks like the data sits
entirely inside the cache.
This core 2 has 2MB of cache and
thats 4 times more than on Athlon x2 I got.
> If what
you say is true, and one core alone fills the memory
>
bandwidth, then there should be a net loss of performance while
> running two copies of ami.
It depends on
complexity of the formula and the amount of data per symbol
you
are using. As each array element has 4 bytes, to fill 4 MB of
cache
you would need 1 million array elements or 100 arrays
each having 10000 elements
or 10 arrays each having 100K
elements. Generally speaking people testing
on EOD data where
10 years is just 2600 bars should see speed up.
People using
very very long intraday data sets may see degradation,
but
rather unnoticeable.
Best regards,
Tomasz
Janeczko
amibroker.com
----- Original Message -----
From: "dloyer123" <dloyer123@xxxxxxcom>
To:
<amibroker@xxxxxxxxxps.com>
Sent:
Tuesday, May 13, 2008 8:12 PM
Subject: [amibroker] Re:
Dual-core vs. quad-core
> Nice, tight loop. It is good
to see someone that has made the effort
> to make the most
out of every cycle and the result shows.
>
> My new
E8400 (45nm 3GHz, dual core) system should arrive tomorrow.
> The first thing I will do will be to benchmark it running
ami. I run
> portfolio backtests over a few years of 5
minute data over a thousand
> or so symbols. Plenty of data
to overflow the cache, but still fit
> in memory. No trig.
>
> I'll post what I find.
>
> If what
you say is true, and one core alone fills the memory
>
bandwidth, then there should be a net loss of performance while
> running two copies of ami.
>
>
>
> --- In amibroker@xxxxxxxxxps.com,
"Tomasz Janeczko" <groups@xxx>
>
wrote:
>>
>> Hello,
>>
>>
FYI: SINGLE processor core running an AFL formula is able to
> saturate memory bandwidth
>> in majority of most
common operations/functions
>> if total array sizes
used in given formula exceedes DATA cache size.
>>
>> You need to understand that AFL runs with native
assembly speed
>> when using array operations.
>> A simple array multiplication like this
>>
>> X = Close * H; // array multiplication
>>
>> gets compiled to just 8 assembly
instructions:
>>
>> loop: 8B 54 24 58 mov
edx,dword ptr [esp+58h]
>> 00465068 46 inc
> esi ;
increase counters
>> 00465069 83 C0 04 add
eax,4
>> 0046506C 3B F7 cmp esi,edi
>> 0046506E
D9 44 B2 FC fld dword ptr [edx+esi*4-
> 4] ; get element of
close array
>> 00465072 D8 4C 08 FC fmul dword ptr
[eax+ecx-
> 4] ; multiply by element of high
array
>> 00465076 D9 58 FC fstp dword ptr [eax-
>
4] ; store result
>> 00465079 7C E9 jl
> loop ;
continue until all elements are processed
>>
>> As you can see there are three 4 byte memory accesses
per loop
> iteration (2 reads each 4 bytes long and 1 write
4 byte long)
>>
>> On my (2 year old) 2GHz
Athlon x2 64 single iteration of this loop
> takes 6
nanoseconds (see benchmark code below).
>> So, during 6
nanoseconds we have 8 byte reads and 4 byte store.
> Thats
(8/(6e-9)) bytes per second = 1333 MB per second read
>>
and 667 MB per second write simultaneously i.e. 2GB/sec combined
!
>>
>> Now if you look at memory
benchmarks:
>> http://community.compuserve.com/n/docs/docDownload.aspx?webtag=ws-
>
pchardware&guid=6827f836-8c33-4063-aaf5-c93605dd1dc6
>>
you will see that 2GB/s is THE LIMIT of system memory speed on
> Athlon x64 (DDR2 dual channel)
>> And that's
considering the fact that Athlon has superior-to-intel
> on-die integrated memory controller
(hypertransfer)
>>
>> // benchmark code - for
accurrate results run it on LARGE arrays -
> intraday
database, 1-minute interval, 50K bars or more)
>>
GetPerformanceCounter(1);
>> for(k = 0; k <
1000; k++ ) X = C * H;
>> "Time per single iteration
[s]="+1e-3*GetPerformanceCounter()/
>
(1000*BarCount);
>>
>> Only really
complex operations that use *lots* of FPU (floating
>
point) cycles
>> such as trigonometric (sin/cos/tan)
functions are slow enough for
> the memory
>> to
keep up.
>>
>> Of course one may say that I am
using "old" processor, and new
> computers have faster RAM
and that's true
>> but processor speeds increase FASTER
than bus speeds and the gap
> between processor and
RAM
>> becomes larger and larger so with newer CPUs the
situation will be
> worse, not better.
>>
>>
>> Best regards,
>> Tomasz
Janeczko
>> amibroker.com
>> ----- Original
Message -----
>> From: "dloyer123"
<dloyer123@x..>
>> To: <amibroker@xxxxxxxxxps.com>
>>
Sent: Tuesday, May 13, 2008 5:02 PM
>> Subject:
[amibroker] Re: Dual-core vs. quad-core
>>
>>
>> > All of the cores have to share the same front
bus and
> northbridge.
>> > The northbridge
connects the cpu to memory and has limited
>
bandwidth.
>> >
>> > If several cores are
running memory hungry applications, the
> front
>> > buss will saturate.
>> >
>> > The L2 cache helps for most applications, but
not if you are
> burning
>> > through a few G
of quote data. The L2 cache is just 4-8MB.
>> >
>> > The newer multi core systems have much faster
front buses and
> that
>> > trend is likely to
continue.
>> >
>> > So, it would be nice
if AMI could support running multi cores,
> even
>> > if it was just running different optimization
passes on different
>> > cores. That would saturate
the front bus, but take advantage of
> all
>>
> of the memory bandwidth you have. It would really help those
> multi
>> > day walkforward runs.
>>
>
>> >
>> >
>> > --- In
amibroker@xxxxxxxxxps.com,
"markhoff" <markhoff@> wrote:
>>
>>
>> >>
>> >> If you have a
runtime penalty when running 2 independent AB jobs
> on
>> > a
>> >> Core Duo CPU it might be
caused by too less memory (swapping to
>> >
disk)
>> >> or other tasks which are also running
(e.g. a web browser, audio
>> >> streamer or
whatever). You can check this with a process explorer
>>
>> which shows each tasks CPU utilisation. Similar, 4 AB
jobs on a
> Core
>> >> Quad should have
nearly no penalty in runtime.
>> >>
>>
>> Tomasz stated that multi-thread optimization does not
scale good
>> > with
>> >> the CPU
number, but it is not clear to me why this is the case.
>
In
>> > my
>> >> understanding, AA
optimization is a sequential process of
> running
>> > the
>> >> same AFL script with
different parameters. If I have an AFL with
>> >>
significantly long runtime per optimization step (e.g. 1 minute)
> the
>> >> overhead for the multi-threading
should become quite small and
>> >> independent
tasks should scale nearly with the number of CPUs
> (as
>> > long
>> >> as there is sufficient
memory, n threads might need n-times more
>> >>
memory than a single thread). For sure the situation is
>
different if
>> >> my single optimization run takes
only a few millisecs or
> seconds,
>> >
then
>> >> the overhead for
multi-thread-managment goes up ...
>> >>
>> >> Maybe Tomasz can give some detailed comments
on that issue?
>> >>
>> >> Best
regards,
>> >> Markus
>> >>
>> >
>> >
>> >
------------------------------------
>>
>
>> > Please note that this group is for
discussion between users only.
>> >
>> >
To get support from AmiBroker please send an e-mail directly to
>> > SUPPORT {at} amibroker.com
>> >
>> > For NEW RELEASE ANNOUNCEMENTS and other news
always check DEVLOG:
>> > http://www.amibroker.com/devlog/
>>
>
>> > For other support material please check
also:
>> > http://www.amibroker.com/support.html
>>
> Yahoo! Groups Links
>> >
>> >
>> >
>>
>
>
>
>
------------------------------------
>
> Please note that this group is for discussion between
users only.
>
> To get support from AmiBroker please
send an e-mail directly to
> SUPPORT {at}
amibroker.com
>
> For NEW RELEASE ANNOUNCEMENTS and
other news always check DEVLOG:
> http://www.amibroker.com/devlog/
>
> For other support material please check also:
> http://www.amibroker.com/support.html
>
Yahoo! Groups Links
>
>
>
No virus found in this incoming
message.
Checked by AVG.
Version: 8.0.100 / Virus Database:
269.24.1/1468 - Release Date: 5/26/2008 3:23
PM
No virus found in this incoming message.
Checked
by AVG.
Version: 8.0.100 / Virus Database: 269.24.1/1468 - Release Date:
5/26/2008 3:23 PM
__._,_.___
Please note that this group is for discussion between users only.
To get support from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
For other support material please check also:
http://www.amibroker.com/support.html
![]()
__,_._,___
|