[erlang-questions] trading systems

[Joel Reymont]

On Oct 1, 2009, at 8:43 PM, Jayson Vantuyl wrote:

> Erlang assumes that binaries don't change.  Note that it never  
> modifies them, only makes new ones.  Given that the compiler  
> optimizes for this (or should), I would be careful about modifying  
> binaries after they make it to Erlang.

An Erlang binary in the driver is an iovec structure or something like  
that. I assume I'll just create a new binary (structure) once I have  
new data. I'll have to experiment with this.

> If you're very speed conscious, I would recommend running in 32-bit  
> mode.  With everything I've done, it seems faster to page a GB of  
> data in/out of memory than it does to deal with the larger pointers-- 
> especially in something pointer-heavy (like a dynamic language).

I'm assuming it's an Erlang-specific suggestion, right? http://www.kx.com 
  flies with 64 bits, Mozilla's TraceMonkey Javascript engine is up to  
20% faster with 64 bits on some benchmarks. There are more registers  
available for the compiler to use, etc. In short, I disagree since  
your suggestion is quite general and is not backed up by known use  
cases.

> Okay.  Haskell might be another option.  If you're going typed, it's  
> the best, but it's probably suboptimal due to lack of libraries.

I assume you have not used Haskell for heavy-duty projects but heard  
of it and maybe tinkered with it. I used Haskell for a networking  
project I extensively wrote about (google for Erlang vs Haskell). I  
switched to Erlang in the end and felt much better. Haskell is lazy  
which makes performance unpredictable.

> Okay.  Also, avoid templates

Why? I interviewed with a hedge fund. They use templates extensively  
and it makes sense. Partial template specialization is just the ticket  
to optimize generic code at compile time.

> and try compiling for size.  In cache-sensitive environments, I've  
> found that -Os gets me better performance that -O99 just because of  
> the smaller code size.

I agree with this.

> In particular, debugging of concurrent code can be very nice.  http://souja.net/2009/04/making-sense-of-erlangs-event-tracer.html

Yes, thanks. I've been using tracing for years now.

> That makes sense.  It sounds like the selling points are  
> debuggableness, fault-tolerance, scalability, and concurrency.

And faster time to market.

> That all makes sense.  Good luck on the latency front, though, as  
> each of those traits increases latency.

Thanks. I'm not aiming to be the top dog but I would like to have a  
very strong showing.

---
fastest mac firefox!
http://wagerlabs.com