I don't use Mac's. But, I have two servers using the same hardware as the last generation Mac Pro. Specifically dual socket quad core (i.e. 2 chips @ 4 cores each = 8 physical cores) also known as Harpertown Xeon's.
http://en.wikipedia.org/wiki/Harpertown_(microprocessor)#Harpertown One box is using two Xeon E5420 overclocked to 3Ghz the other is using two QX9775 (desktop equivalent to Xeon E5482) overclocked to 3.8Ghz. Both boxes are screamingly fast, even when handicapped by the fully buffered memory (DDR2 800 FB-DIMM) The Nehalem Xeon's are supposed to put the Harpertown's to shame. So I can't imagine how incredibly fast that setup would be. Mike --- In [email protected], "af_1000000" <af_1000...@...> wrote: > > Hello, > > Everybody needs more power !!!! > I've got some unique requirements I have been struggling with. On top of > bunch of indicators on four charts (3 monitors, TWS and IB Controller on > third monitor) there is a bunch of scripts handling trades (every one runs an > entire trade from the very beginning to the very end). Once it is launch I do > not touch it. There are usually 5-10 scripts (3500 lines of code each) > running simultaneously handling trades (there is no limit on number of > trades, with the exception of hardware to handle them). There is one main > monitoring and launching script (with gfx menus;I trade off charts)to show > what all these trades are doing. All these scripts communicate with one > another. Some run overnight. Each maintains its own log, so it can be > interrupted, suspended, resumed, ..., etc. > I need the right hardware to handle all this stuff. I have been thinking > about a new models of Mac Pro running on Xeon processors (available August > 2010). I know that some of you have been using Mac Pro and some of you are > satisfied, some of you are still short of power. I would appreciate your > comments on your experience with Mac Pro and any suggestions on that matter.I > look at Mac Pro architecture and the construction. It looks very solid and > other workstations do not look as professional as Mac Pro. An alternative > would be to build a designated workstation based on Intel i7. What kind of > processors to use in my case: more cores or higher speed ? > Any constructive help will be very appreciated. > > AF > > --- In [email protected], Dennis Brown <see3d@> wrote: > > > > Rob, > > > > I just realized the importance of what you were saying about using AA to > > calculate static arrays. One of the things that I have asked for was the > > ability to have a chart that refreshed no more often than once per X time > > to slow it down. Using AA the way you are doing it would give me that > > ability. I will have to experiment with that. I thought I had no use for > > AA, so never really thought about it before. This could be a good approach > > for my needs for the longer timeframe calculations. > > > > Best regards, > > Dennis > > > > On Aug 3, 2010, at 7:13 AM, Dennis Brown wrote: > > > > > Rob, > > > > > > This is good to know that you made it work for you. I have the same > > > issues and have only kicked around the ideas for implementing them. One > > > minute calculations could be useful to many of my operations. > > > > > > I did do the reverse at one point before I went with futures trading. I > > > had set up a second chart for very high resolution to eliminate bad > > > ticks. Then I made artificial tickers of the clean data to feed my main > > > charts in realtime. That was before we had static arrays, so it was too > > > slow. > > > > > > Yes, I have often wanted to have more control over the number of bars > > > used in an array calculation. > > > > > > BR, > > > Dennis > > > > > > On Aug 3, 2010, at 3:40 AM, Rob wrote: > > > > > >> Dennis, > > >> > > >> I actually already use Herman's technique of running the AA periodically > > >> to calculate results that I put into static arrays for access by my > > >> other charts. However, for my purposes the static arrays only need to be > > >> calculated every minute. I didn't know you could go down to second > > >> resolutions in the AA periodic running option. > > >> > > >> Very simply the only reason I use this technique is that it allows me to > > >> calculate much longer static arrays than the rest of my charts need from > > >> an indicator basis. i.e my drawing code in my charts only requires 40 > > >> bars of data + the visible.... however, my AA code uses 6,000 historical > > >> bars and creates static arrays that my chart code than can access when I > > >> scroll backwards on the charts. > > >> > > >> As you know, one of the limitations of AB is the fact that the maximum > > >> number of historical bars required by a piece of code is applied to ALL > > >> that AFL regardless if the rest of the code requires it or not. This is > > >> a way of getting round that limitation. > > >> > > >> If I didn't use this technique my charts would be unusably slow. > > >> > > >> --- In [email protected], Dennis Brown <see3d@> wrote: > > >>> > > >>> Herman, > > >>> > > >>> You bring up some interesting points. However, if the AA hogs the > > >>> machine during the execution, then I don't see any advantage over doing > > >>> everything in the indicator script. You still need to calculate new > > >>> data when something has changed that will change the chart in a > > >>> material way. > > >>> > > >>> A similar thing could be done by having two charts. One that is open > > >>> and displaying the UI and charted data, and a second one on a top tab, > > >>> that is executing and filling in static arrays and no plots. The > > >>> advantage would be if multiple charts each ran in their own processor > > >>> (future feature?), so that a true parallel processing was taking place. > > >>> The way I do my parameters, any chart can have access to any other > > >>> charts parameters window settings, just by knowing the other chart ID. > > >>> That way one parameter window can control many charts. Now that I > > >>> think of it, I don't really have to have my parameters tied to a chart > > >>> ID at all (even though the parameter window is). Their ID could be > > >>> something completely different and unique that does not change. Just a > > >>> side effect of how I do things. > > >>> > > >>> However, the important point is to make the script more asynchronous in > > >>> that only data are recalculated when changed, no matter how often the > > >>> chart is refreshed. For instance many calculations can use the close > > >>> of the last complete bar. They do not change at every tick, just when > > >>> a new bar is complete. This will take re-architecting a lot of my > > >>> code. Not a small task (I have a lot of code), but a potentially > > >>> rewarding one. > > >>> > > >>> It would take considerable time and effort on my part, so I do not want > > >>> to start in that direction without knowing if I was wasting my time by > > >>> going in an incompatible direction to future AB development. > > >>> > > >>> There is nothing worse than to spend months working to solve a problem > > >>> that is made moot by the next release of AB. The time could have been > > >>> spent on something more productive. > > >>> > > >>> I know what you mean about conditional code. I have my Parameters UI > > >>> set up so that the parameters statements are not even executed if the > > >>> parameters window is not open, or a hierarchal section is not visible. > > >>> All my parameters are saved into static variables and picked up by the > > >>> code when needed. I can have a lot of code to make the UI very nice, > > >>> but not cost any execution overhead when not needed to interact with > > >>> the user. I might have a thousand parameters in a single system > > >>> without the UI becoming cluttered. > > >>> > > >>> I don't write overly long loops. I just have a lot of them. I might > > >>> be able to create more array logic in some cases. I do a lot of array > > >>> operations, but the tricky ones I put in loops. I'll bet there are > > >>> several that could be put into array logic with some concerted effort, > > >>> but it is better for me to debug them as loops first to get the logic > > >>> debugged. I also have debugging tools that let me see the internal > > >>> loop variables at any bar. Then I have a quick check if my array logic > > >>> is generating the right answer just by switching code on the fly to see > > >>> if anything changes in the output. > > >>> > > >>> BR, > > >>> Dennis > > >>> > > >>> > > >>> On Aug 2, 2010, at 7:11 PM, Herman wrote: > > >>> > > >>>> > > >>>> > > >>>> Dennis and Rob, > > >>>> > > >>>> Dennis, your idea of creating a generic plotting template is very > > >>>> interesting. Perhaps it could call the original code normally and > > >>>> substitute static arrays when needed. Thanks for the idea. It would be > > >>>> the nearest we can come to simulating a FreezeDisplay(). > > >>>> > > >>>> If you use loops be sure that you "break" out of them on mouse click > > >>>> to get an immediate mouse response. When I break out of a loop I > > >>>> recall the previous array result. hmm, not sure now but it may be that > > >>>> i ran into a problem doing that... not sure now. You'll have to try. > > >>>> > > >>>> I have a lot of conditional sections in my code. If() take almost no > > >>>> time to execute, especially in gfx button design this can save time. > > >>>> > > >>>> Using switch() based state machines you have to careful to design them > > >>>> so that they "fall through" in one pass (execution) if sequential > > >>>> conditions are true. If you don't you might need several executions > > >>>> (refreshes) to reach the desired state. Sometimes omitting the 'break' > > >>>> from a case section can help. > > >>>> > > >>>> My gfx GUI is extremely fast. I use an auto-hide feature so that > > >>>> buttons only show up if I move my cursor to the button area (Top of > > >>>> chart in my case). I use a floating menu (Order Bar) that only drops > > >>>> down menus when the cursor is on the header button. You can use the > > >>>> header for the most frequent choice and the drop-down sub menu for > > >>>> secondary choices. I only save states (persistent) on a mouse click, > > >>>> usually after you click the mouse a little more processing time > > >>>> doesn't matter. Such techniques get pretty close to using the Param > > >>>> window (about 3 times slower). > > >>>> > > >>>> You may be able to reduce you indicator execution time by letting the > > >>>> AA (running at 1 sec intervals) perform complex calculations in the > > >>>> background. These calculations could include calculating plots, i.e., > > >>>> in your indicator you only plot the static array results from the AA. > > >>>> This no calculations in the indicator. The AA seems to run independent > > >>>> of the Indicator formulas. Perhaps someone can explain in technical > > >>>> terms how Indicator and AA task are delegated to the computer. > > >>>> > > >>>> zero refresh time in preferences gives you the max refreshes per > > >>>> second - that is what I need to get responsive code. > > >>>> > > >>>> Not sure what you (Rob) refer to with Timed refreshes, perhaps I > > >>>> expressed myself wrong. What I meant is timed full-executions so that > > >>>> data is only calculated, say, once a second. All other passes would > > >>>> access static results from these calculations. So if a chart refreshes > > >>>> 10/times per second, 9 out of ten would use static data and only one > > >>>> calculated data. Using the AA 10/10 would use static data. The > > >>>> "average" load on your system would be reduced. Partitioning your code > > >>>> more complex ways of interlacing/staggering of calculations data may > > >>>> be possible. > > >>>> > > >>>> I am sorry, I am not a professional programmer :-) there are probably > > >>>> proper terms for all these techniques but I don't know them - I just > > >>>> make up terms as I go along. > > >>>> > > >>>> Herman > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> Herman, > > >>>> > > >>>> Now you are speaking my language. I do save the last data or plot for > > >>>> some calculations in static arrays and then substitute the plot for > > >>>> the code when I am trying to speed up the UI for some operations. > > >>>> > > >>>> My preferred technique to speed up the UI without doing a lot of extra > > >>>> code and static array memory, was to just reduce the number of bars > > >>>> with a SetBarsRequired() command at the end of the formula. This was > > >>>> only partially successful though. All my looping code will reduce the > > >>>> number of bars, but the fast AFL array operations do not. They are > > >>>> stuck with the highest number of bars ever requested since formula > > >>>> startup. I look forward to the day when I have control of reducing > > >>>> the number of fast AFL bars on the fly. That is the easy way to to > > >>>> generally speed things up. Then combined with judicious use of saving > > >>>> plots in static arrays can give the rest of the speedup for the type > > >>>> of custom UI work that we do. I even considered if I should create a > > >>>> generic template for every module that generates plots to save the > > >>>> plots or restore then based on a static variable. > > >>>> > > >>>> The problem with this is that it would slow down normal operations > > >>>> because of all the saving of static arrays. I use a state machine > > >>>> that only saves the static arrays during the first pass of the > > >>>> sequence of a UI operation that is multi-pass and time sensitive, like > > >>>> dragging an element around the chart. > > >>>> > > >>>> Many of my UI functions require multiple AFL passes to complete, and I > > >>>> have routinely tried to reduce refresh times, and reduce the number of > > >>>> formulas that execute to speed up the chart to make the UI operation > > >>>> faster. Perhaps, I should consider killing everything other than > > >>>> price bar plots and Gfx plots when processing any multi-pass UI > > >>>> function. I have a static variable called HurryUp that most of my > > >>>> functions or modules do something with to reduce computation time. I > > >>>> really have to do some major speedup code before I can take advantage > > >>>> of faster than one second refreshes. The 0.1 second refreshes will be > > >>>> very useful to me at that point. > > >>>> > > >>>> BR, > > >>>> Dennis > > >>>> > > >>>> On Aug 2, 2010, at 3:48 PM, Herman wrote: > > >>>> > > >>>> > > >>>> > > >>>> To give you software control the in-line RequestTimedRefresh() must > > >>>> have priority. I have never used the setting in Preferences so I am > > >>>> not speaking from experience here, I have it set to zero - I am mostly > > >>>> looking for faster execution, not slower/timed/paced executions. > > >>>> Remember that these settings determine the MINIMUM refresh interval, > > >>>> if you quotes come in more frequently your chart will refresh more > > >>>> frequently. Status("redrawaction") is true when a timed refresh takes > > >>>> place, false during other (RT quote, click, Param actions, etc) > > >>>> refreshes. > > >>>> > > >>>> I just see TJ's comment coming in: "These refreshes are independent. > > >>>> If you specify both you will get twice as much." I didn't know that. > > >>>> > > >>>> I do speed up refreshes on-the-fly, you can do similarly that also > > >>>> between panes/charts. For example the code I am looking right now > > >>>> speeds up my chart refreshes when I move my mouse over the chart, or > > >>>> when it is over one of my gfx buttons: > > >>>> > > >>>> PrevMX = Nz( StaticVarGet( "LastCursorXPosition" ) ); > > >>>> PrevMY = Nz( StaticVarGet( "LastCursorYPosition" ) ); > > >>>> MouseAction = CM = MX != PrevMX OR MY != PrevMY; > > >>>> StaticVarSet( "LastCursorXPosition", MX ); > > >>>> StaticVarSet( "LastCursorYPosition", MY ); > > >>>> > > >>>> if( Nz(VarGet( "OnButton" ) ) OR MouseAction ) RefreshTime = 0.1; > > >>>> else RefreshTime = 1; > > >>>> RequestTimedRefresh( RefreshTime ); > > >>>> > > >>>> "OnButton" is a variable that is set when my cursor is over a gfx > > >>>> control button, regardless where it is on the screen. > > >>>> > > >>>> To "skip" over panes/formulas while retaining the display is a little > > >>>> more difficult, it requires saving display arrays in static variables. > > >>>> There is no graphic FreezeDisplay() command. Somewhat slower than a > > >>>> FreezeDisplay() would work, if we had one, you can substitute static > > >>>> variables for the calculated arrays when you want to skip the formula. > > >>>> I don't remember having actually done this but I am thinking of > > >>>> applying this technique in a current application. It should work... > > >>>> > > >>>> You can use Status("redrawaction") or the GetPerformanceCounter() > > >>>> timer to create your delays. > > >>>> > > >>>> Using the same code in each pane should significantly reduce the work > > >>>> involved to try timing schemes, just one formula to change ;-) > > >>>> > > >>>> btw, what is your formula execution time? > > >>>> > > >>>> Doing a search in Help for refresh, timing, and such keywords will > > >>>> lead you to some distributed bits of information that can prove useful. > > >>>> > > >>>> Best regards, > > >>>> herman > > >>>> > > >>>> > > >>>>> At the moment I'm on a basic one second refresh across > > >>>>> all charts (set via preferences > Intraday)... > > >>>> > > >>>>> All my charts use the same piece of AFL (insert linked > > >>>>> into each chart)... I like the same functionality in each chart. > > >>>> > > >>>>> I will have to think about adjusting the refresh times > > >>>>> across charts. Not sure how I'd work that right now... I'm > > >>>>> still struggling with RequestTimedRefresh() vs the > > >>>>> preferences>intraday setting... you must know Herman.... > > >>>>> which one takes precedence...? > > >>>> > > >>>> > > >>>> > > >>>>> ------------------------------------ > > >>>> > > >>>>> **** IMPORTANT PLEASE READ **** > > >>>>> This group is for the discussion between users only. > > >>>>> This is *NOT* technical support channel. > > >>>> > > >>>>> TO GET TECHNICAL SUPPORT send an e-mail directly to > > >>>>> SUPPORT {at} amibroker.com > > >>>> > > >>>>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at > > >>>>> http://www.amibroker.com/feedback/ > > >>>>> (submissions sent via other channels won't be considered) > > >>>> > > >>>>> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > > >>>>> http://www.amibroker.com/devlog/ > > >>>> > > >>>>> Yahoo! Groups Links > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >> > > >> > > >> > > >> > > >> ------------------------------------ > > >> > > >> **** IMPORTANT PLEASE READ **** > > >> This group is for the discussion between users only. > > >> This is *NOT* technical support channel. > > >> > > >> TO GET TECHNICAL SUPPORT send an e-mail directly to > > >> SUPPORT {at} amibroker.com > > >> > > >> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at > > >> http://www.amibroker.com/feedback/ > > >> (submissions sent via other channels won't be considered) > > >> > > >> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > > >> http://www.amibroker.com/devlog/ > > >> > > >> Yahoo! Groups Links > > >> > > >> > > >> > > > > > > > > > > > > ------------------------------------ > > > > > > **** IMPORTANT PLEASE READ **** > > > This group is for the discussion between users only. > > > This is *NOT* technical support channel. > > > > > > TO GET TECHNICAL SUPPORT send an e-mail directly to > > > SUPPORT {at} amibroker.com > > > > > > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at > > > http://www.amibroker.com/feedback/ > > > (submissions sent via other channels won't be considered) > > > > > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > > > http://www.amibroker.com/devlog/ > > > > > > Yahoo! Groups Links > > > > > > > > > > > >
