The 8/16 if same speed. There's no point to have 2 separates CPU rather than one, maybe it's even worse cause communication would occur thru motherbord rather than in CPU.
If not much concurent use, I'd go with lower core count but higher clock speed. Remember Filemaker only use 1 core when running scripts.
In the filmaker world it's the Ghz that counts
Thanks for that, planning on running (cpu intensive) server script(s) while users run short, low cpu scripts.
Your advice still hold?
depends how much script running at the same time.
it's only if you've motre than 4 scripts on the server running at the same time, which I doubt that you nedd much cores.
I'd go with a 6 one that I'd overclock to 4.2 Ghz and more (that's what I use) Sandy Bridge, Ivy bridge are only 2/3 % faster but less o'clockable.
Curious to know how much FileMaker Pro takes adavantage of multiple cores/multiple processors? Anyone got some insight to this?
FileMaker fully supports multiple processors and can spin each thread off to a different processor. This means that the more processors you have, the better is can support a lot of users. However, each thread can only use one processor. You cannot split the same thread among multiple processors. This means as an single user of FileMaker, you will not go any faster on a multi-core machine than if you were on a single core. For large deployment of FileMaker with lots of users, you will want as many processors as possible, not to mention also RAM and fast drives. As a single user setup wanting the fastest performance, you won't care about multiple cores, only getting the fastest GHz processor possible.
I guess you're refering toe filemaker server 12, because FMS 11 have never been once able to use more than 2 cores (and yes I through a bunch simultaneous of stuff to it). That experience is in line with a technet conf that said in the FMS 9 days that 2 cores are the limit that FMS can support.
I think it changed a bit with 12. They separated more stuff. So if avaialble FMS 12 will use a core for webservice, a core for backups, a core for server side processing, one for serving clients. But it's not clear if it's able to scale nicely : if 2 server side script are running does it use one core for each, etc. So I'll be a beliver wen someone will post a screenshot of 800% cpu utilisation for FMS.
One thing is for sure, more core won't speed up a particalura script, as you said
FMS11 was also multi-processor aware and you can see this if you have a lot of users hitting a server, however it did not seem to do this particularly efficiently in my opinion. As you noted, any given script will be assigned a single thread and can only go to a single processor with no benefit from multiple cores. FMS12 is also multi-processor aware, but it is a complete re-write of the software in 64 bit and we're still learning about how it behaves with various memory sizes and processor loads. So far I am impressed, but I bet that as a first 64 bit version, there is a lot of future optimization coming. And FileMaker client will someday become 64 bit, but I can only imagine the headaches that will come with all the re-writes required for plugins. Plus a 64 bit client will be guaranteed not to work on Windows XP and I can finally tell my clients to dump that old technology.
As I see it, there are several - sometimes fundamental - limitations to fine-grained multithreading in FileMaker (Server).
With respect to FileMaker Script language (as a programming language):
- In most programming languages that support parallelization or multi-threading, it is still the case that the programmer has to indicate the blocks that can be used by the compiler (whether it creates byte-code or machine code) to create parallel or threaded code.
- There exist compilers that can find automatically certain source code parts that can be parallelized or threaded; however, autoparallelization is still a very difficult problem to solve, since the compiler needs e.g. to recognize if there are conditions that hinder parallelization such as iterative variables or functions that depend on the result of the previous loop step, interprocess communication etc.. Usually this is solved the way that the programmer can give the compiler a hint whether a source code part is parallelizable / threadable or not, and then the compiler will do the rest.
- The lack of any FileMaker Script steps that indicate a parallelizable / threadable block shows me that FM Inc. hasn't yet thought of multi-threading Scripts.
- FM Inc. will probably not offer this option, since it would violate the KISS principle of the current Script language, and load the burden on the developer to decide which blocks (mostly loops) can be multi-threaded, e.g. to find if there aren't any dependencies on record/variable/function level, race conditions (global variables!) or other interactions or abort conditions that prohibit threading. No, FileMaker Script language was devised to be simple, and will remain so.
- There are many "high-level" script steps, especially those requiring user interaction (for find, pause, dialog ...) that prohibit threading.
- "Low level" steps such as Set Field, Set Variable are already too granular that it is worth to multithread them on application level.
With respect to database transactions:
- Transactions in relational databases should adhere to ACID properties (atomicity, consistency, isolation, durability). At least FileMaker does so for A,C, and I. As soon as this goes to distributed transactions (and distributed databases), that might be difficult or impossible to achieve (see English and German Wikipedia articles on ACID, they differ somewhat in this aspect).
So, I assume that FM Inc. choose a very pragmatic approach with regards to multi-threading:
- On FMS, distribute tasks on user/fm client/service/web session level
- On FM client, use multi-threading on display (layout) engine level
(Edit: the last point is incomplete: Just use Apple's Activity Monitor to inspect the threads of FileMaker Pro / Advanced)
Message was edited by: MartinBraendle