'Just OTC markets'? MT4 was meant for that.. it wasn't designed to do much else very well. I can't fault it for focusing on one thing and doing that one thing reasonably well. I agree about the lack of custom timeframes as a native out of the box feature though... you can get 2, 3, n-minute / tick / etc... timeframes but you gotta do it with 3rd party scripts.. the scripts are free online but aren't very user friendly. Aside from tick charts, the n-minute charts can be built off history data, so they fill out fine. No, it's really a broker problem... it depends on how they implement MT4 and their execution style. MT4 is quite capable of fill confirmations across an ECN within a few hundred milliseconds of being sent out from the client terminal. Plus, I said 'under a second for fills' not 'slower just because MT4'. Portfolio wise, you can call any symbol, timeframe, etc all from within the EA regardless of what pair you set to test... that means you can backtest baskets, pairs trades, etc... and that's all native. So I'm not sure why you're saying that. As for it being trustworthy... you get out what you put in. I go out of my way to import clean tick data to test from, and it gives me a very refined modeling quality. It does lack multithreading... yeah, that kinda sucks, but that doesn't limit the ability of the software, it just means that some tasks could happen faster (mostly backtesting work) if it was thread optimized. 64-bit won't change much if you understand how it does it's testing and manages data. Even on the tick level with backtesting (the most memory intensive) you won't find the 32vs64 bit argument to be a bottleneck. Again, it would be nice to have.. just not a huge deal. --- Anyway... it sounds more like you're sour about the whole industry (OTC forex) than just MT4.. and I'm ok with that. I just like presenting balanced info, and some of the things you're saying are weighted in the 'marketing' world as much more than they really are in the 'technical' world between platforms. Don't get me wrong, compared to MultiCharts or NinjaTrader (which have most of the features you were harping on MT4 for missing.) MT4 has a hard time keeping up without people using the built in scripts to extend the platform. (And personally I love both MC and NJ, great software.) And when it comes to Futures / Equities, MT4 would not be a good choice at all. ...But for what the majority of spot FX traders need, I haven't seen MT4 really limit anyone feature wise (again, only looking at the software side of things, not the limits a cruddy broker can impose by botching their MT4 setup.) It can do a lot more than you seem to think..
EAs and custom indicators do this as well. They are plentiful. You can even construct custom indexes to your own weighting as an indicator to display along side the chart. Screeners, scanners, etc... all available. Not out of the box, but way more flexible than some platforms since you can edit nearly everything about them on the code level.
What? No major performance gains with 64-bit?? You have to be kidding me. That's the funniest thing I ever heard of. What piece of crap 64-bit/32-bit softwares have you tested? lol Your opinion I got it you are MT4 nerd. Still MT4 simply is an amateurish POS software just for the reasons I mentioned. It's simply limited. MC and NT? Pfff... How do you do real-time scanning in table format with MT4. Just curious. You export scanning results to csv and import them to Excel? That would be pretty slow. Custom indexes? Wow, every good software is capable of doing that with ease in real-time. More flexible than what? Editing on code level? That's not a revolutionary thing. Most softwares can do that.
See, it's shit like this that makes me not even want to bother responding to you. I'm getting really tired of your inferences and putting words in my mouth. Read carefully and understand context (you know, the skills you learn in grade school) or stop responding. I never said "no performance gains".. I said '32-bit' wouldn't be a noticeable bottleneck (ie, given the workload and memory requirements of the average trader or algo writer needs of an execution platform, you wouldn't come to a bottleneck that could be solved by 64bit software.) There's always going to be some traders out there that can benefit from 64bit in general, but the workloads that benefit the most come from the sciences and math applicaitons that most people keep outside their trade execution environment anyway. In other words, I don't know anyone who puts out a trading platform that does R, matlab, and other computationally intense frameworks justice. That's not my opinion, I listed a series of facts. I stated what's possible. I know because I use (or have used) multiple brokers who can reach such performance levels with MT4. "Your opinion" There are many ways... most involve simple indicators you can add to the platform that pull info from MT4's history center on multiple symbols and do the calcs for you... presenting it all nicely next to your chart in real time. But you can also use the built-in DDE server to stream quotes to Excel, and any Excel VBA macro / program you have that does the work on that end as well. You can also stream data to a SQL database and sic other applications at it (whichever you like.) There's many other ways as well, I'm just pointing out a few of the more flexible ones. --- Ok, question time: if you're not into MC or NJ, what platform do you like? What's the shining gem that blows away everything? Don't hold out on us, you've been so opinionated so far you gotta have some ace up your sleeve! Do tell
What are you talking about? "Wouldn't be a noticeable bottleneck" is similar to small performance loss or less limitation or whatever. With 64-bit you can handle much more data and with same data sizes 64-bit is just faster. Around 30%. Now you talking about average trader. Yeah MT4 users are mostly peanut butter trader. lol I mentioned facts too. Executions are slower with same broker. "Next on the chart". Yeah "cool" stuff. Do I wanna cook in the living room? No. Excel & stuff - slow and not comfortable. Ridiculous. I don't have to sell something. Just telling that in comparison MT4 is sh*t. Well it's sh*t in comparison to your mentioned MC or even NT too.
Increases memory limits to above 4Gb per process on a system already running a 64bit OS... which most trading platforms don't even approach such limits on their own. As for your 30% claim, do post some sort of reference to that which shows a 30% increase in performance for workloads relevant to the average trader. You said it, now back it up. 64bit does not automatically equal 30% increase in speed for all types of computational work. So specifically, show me some benchmark results that prove your execution and charting package will be better off by 30% just for being a 64bit binary. If you get into the heavier stuff where 64bit optimization starts to make an impact, then it's usually the kinda work that's best left to software specifically designed to do such analysis (and not your execution platform.) The point is, 64bit optimization helps out a lot for specific computing tasks.. but as it relates to a trade execution platform it's not the next 'sliced bread.' How is it that you post here as a trader, but so easily make a correlation == causality mistake like this? If one broker makes a choice to implement MT4 in a away that slows down execution (because they want a few seconds to confirm orders, need a few hundred more milliseconds to get a hedge in place if they are dealing to you, or want to protect themselves against people arb'ing their price feed), or just bridges to their native platform so extra steps for execution are involved, that does not make the software itself the cause of the delayed execution. Just the existence of a different broker who can execute faster using the same software is enough to nullify your argument. Common dude, you're smarter than that... i think... I was mentioning an 'option' not something required... but it sounds like you have preferences. Your own preference doesn't make software good or bad. It just makes you picky. Pfft.. .at least I can stand up for something. When given the chance, you'd rather just be a critic instead of offering a constructive alternative of your own.
I'm not talking about execution only since the topic isn't execution. I'm talking about the whole package. It's limited. End of story. I won't waste more time on this As for 64-bit difference. Well, I don't need to show anything. What do pics prove anyway? They could be "photoshopped". Fact is that the 64-bit app I'm using is 30% faster than 32-bit app on same machine e.g. doing backtest and optimizations. But I did not do comparison 32-bit app and 64-bit app both on 64-bit OS. That's what I could do in addition.
Surprise, surprise. 32-bit app on 64-bit OS is slower than 32-bit app on 32-bit OS, well 45%. And 32-bit on 64-bit vs 64-bit on 64-bit - it's 100% slower. So much for "not noticeable bottleneck" As for 32-bit on 64-bit being slower than 32-bit on 32-bit ... my guess is that maybe it's because of the emulation on 64-bit.
Hey, that's cool.. looks like the developers of that app focused solely on the 64bit architecture and hardware... Which app is this? The 64bit OS plus 32bit binary should be the same as the 32-32 setup.. so that's an odd result. There isn't any emulation going on since the architecture is nearly the same (64bit is mostly just a memory registry extension.) Anyhoo.. one key thing is how developers code for target hardware. Sometimes they code specifically for newer chips (which pretty much all new processors are x86_64 capable now) and utilize any hardware functions that could speed up specific types of computations. To then take this code and make it 32bit friendly from a compatibility point of view, they often cut all hardware specific optimization down to just "i586/i686" base compatibility (think back to Pentium 3s). This pretty much kills performance when using it in 32bit mode since most newer hardware assisted computing features are left untouched. So a lot of what you're seeing can be related to how the developers put out their software. Think about it, how would the same hardware do the same task that much slower when the only difference is it has less addressable memory to work with at the time of processing yet it hardly breached the less addressable memory limit anyway? ....this isn't me downplaying your results, just giving more info on what could cause them, since a 100% difference isn't normal.. but I can't fault you for presenting and arguing for what you've experienced first hand. If you'd like, I can point out a few places online that collect benchmarks of various application types and workload types and test them in different software/hardware setups... this would better illustrate my point.
Maybe you should read up on WOW64 to understand how 32-bit applications will run slower on a 64-bit system.