• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Taking Dell to court

2.4GHz quad core is still sufficient. I'm interested to see these Monte-Carlo statistics, then we can have a real discussion.
 
Not worth my time to create a new code but I will post some old code of mine here sometime later this week and we can do a time test. We'll have to figure out a way to prevent you from "fudging" the numbers Barney...
 
?. I won't be doing anything, so no opportunity to fudge. You run your code - use a profilling tool like gprof or valgrind, and tell us what % of CPU max your code uses, both peak and sustained. Do this in serial to begin with.
 
Not worth my time to create a new code but I will post some old code of mine here sometime later this week and we can do a time test. We'll have to figure out a way to prevent you from "fudging" the numbers Barney...
Excel VBA is not really code.
 
Absolutely correct. Last semester we had to write code valuing structured securities. The average code ran approximately 45 minutes. Specs matter. I cannot tell you how many times I had to take a break while the numbers were churning...
are you talking about Excel VBA running the water fall? Unless things drastically changed in the last 5 years, I can honestly say whatever version you were using was not well written. We did the same thing and Woody and I got this thing to run under 20 minutes in 5 year older technology (on Woody's Mac and my old Thinkpad).

The specs of the machine won't help you just hide a bad implementation.
 
are you talking about Excel VBA running the water fall? Unless things drastically changed in the last 5 years, I can honestly say whatever version you were using was not well written. We did the same thing and Woody and I got this thing to run under 20 minutes in 5 year older technology (on Woody's Mac and my old Thinkpad).

The specs of the machine won't help you just hide a bad implementation.
Yes, waterfall.

Funny you should mention it. Mine runs in 15 minutes and was one of the fastest in the class. But no it won't hide bad implementation but would still show which computer is more powerful. The computers with higher specs should complete the run in less time regardless.
 
Yes, waterfall.

Funny you should mention it. Mine runs in 15 minutes and was one of the fastest in the class. But no it won't hide bad implementation but would still show which computer is more powerful. The computers with higher specs should complete the run in less time regardless.
As VBA speed is heavily dependent on many other variables, it is really not the best thing to compare system speeds with. Even if you used something such as C where you can control many of those variables, there are still others which cannot be controlled for. The OS itself, and how it manages processes/threading is a variable. Hence, this is not really a good experiment to compare raw hardware specs no matter how you do it.
 
Yes, waterfall.

Funny you should mention it. Mine runs in 15 minutes and was one of the fastest in the class. But no it won't hide bad implementation but would still show which computer is more powerful. The computers with higher specs should complete the run in less time regardless.


Alain just hit the nail on the head (another mac fan, I wonder why?), and explains exactly why it doesn't matter a shit if you have 1000 3Ghz processors in your laptop vs 4 2.2Ghz ones. It is all about your implementation, and algorithms. There are relatively few algorithms and codes that make use of >1 core, nevermind 4, 6, 8 or however many you want in your laptop. And there are relatively few algorithms and codes that can even get 50% of peak CPU performance on a single CPU. Do you think that 50% @ 3GHz and 50% @ 2.2Ghz is making a big difference in run-time?

What you should be doing is choosing a laptop based on its user experience, reliability etc. and for that you don't get better than a mac. As a programmer, I couldn't think of anything worse than not having a *nix terminal at the ready whenever I need.
 
In my experience, the one spec that determine's a computer's brick wall in performance (in everyday use) is RAM.
 
I agree that for MC development and learning 4 cores is adequate, but someone wanting to go the whole way might want to look at GPU computing. There is of course Amdahl's law, so don't ever imagine that 8 cores will go 8x as fast, though it can be instructive to deal with the extra chance of hitting a very complex condition that causes subtle bug to manifest itself.

I find that I do use all of whatever machine I have, a constant that has persisted for decades.
 
It's perfectly possible for your program to run 8x as fast on 8 cores. As usual, the point is that it depends on your algorithms. Processor clock speed has been pretty much constant for several years now. Clock speed means nothing anymore. It's about utilising the cores you're given, and that requires re-writing 90% of the algorithms that exist today. If you expect to get a big improvement in performance by just buying a more powerful computer with more cores without rewriting the rule book (as MRoss did), then dream on.
 
Back
Top