|
Hi steve,
My last post was siting in my outbox for 8 hours so it
is probably irrelevant as you have covered most things
discussed.
I noticed that your idle temp is quite a bit higher
than mine (oced) It is around 22 deg C idle. I also think 68 deg is right on the
limit. General rule of thumb, if it is too hot to touch, then its too hot. I
wonder if your case fan is running too slow, or airflow is restricted some how.
It might be worthwhile to ring dell support and have a
chat.
D / Paul - Thanks for pointing out CoreTemp,
that is a nice little tool. Finished testing now, CoreTemp says the max temp
for my CPU should be 100 degrees C. Idle temps are about 42, and under
full load it takes about 10 mins for the temps to creep up to 68, then stops
right there and never gets any higher. So on this setup anyway, it seems that
I have quite a nice margin of safety...
D - re overclocking, I took another look at the
BIOS just for the heck of it....Should I be seeing some sort of setting for
"multiplier"?....because I can't find one so am thinking that you are
*still* correct and Dell is not letting us do this....Well that should make my
secision *really* easy... 8 - )
Steve
----- Original Message -----
Sent: Tuesday, May 27, 2008 1:17
PM
Subject: RE: [amibroker] Re: Dual-core
vs. quad-core
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
![]()
__,_._,___
|