CS or EE degree for C# developer

[eas]

I wonder why though if they are focusing on high performance trading applications they are using C# and .NET?  The performance is fine for most applications, but C# just like VB.NET and Java, are all interpreted into a sort of byte code that runs in a virtual machine.

This is easily explained: You misunderstand how the .Net Common Language Runtime works. C# and other CLR languages are compiled into a sort of byte code. That byte code isn't executed through interpretation, instead the CLR compiles it into native instructions which are then executed. The same is basically true of most Java these days.

My understanding is that high-performance trading applications have many moving parts. Some of them are extremely performance critical, others less so. Execution speed and consistency is important, but so is individual and team productivity, turn-around time, and other software engineering priorities. Perhaps a function will run faster coded in C, but it may take twice as long before it compiles and executes without obvious error, and what happens if, someone mishandled some pointer math and the thing buys 1M shares when it should have sold 2M? Perhaps C# would have been a better choice after all.

Also, note, this job listing clearly states that this job is for desktop trading software used by account managers, etc.

As for the CS or EE requirement. Who knows, who cares? It could be thoughtless crap. It could be an attempt to skew the applicant pool in a particular direction. Job listings provide potential applicants clues what the employer really wants, and how they think about the job, but they shouldn't be taken absolutely literally, because chances are, the employer isn't sure what they want, or if they are, they aren't sure how to get it. So, they do their best, see what they get, and then go from there.

I will say that the people I know who have worked on user facing software for financial services haven't had CS degrees, or EE degrees. One has a degree in English, the other in Philosophy and the third in Classics. All at least as valid as qualifications for such work as a CS or EE degree, because often, the hard part of software isn't the algorithms, or data structures, or any of that, its understanding the people using them and the organizational context in which they work. In other words, its about figuring out messy humans. The code doesn't matter if no one uses it. The code doesn't matter if it confuses the users and/or sets them up for mistakes.

[Stonent]

I wonder why though if they are focusing on high performance trading applications they are using C# and .NET?  The performance is fine for most applications, but C# just like VB.NET and Java, are all interpreted into a sort of byte code that runs in a virtual machine.

This is easily explained: You misunderstand how the .Net Common Language Runtime works. C# and other CLR languages are compiled into a sort of byte code. That byte code isn't executed through interpretation, instead the CLR compiles it into native instructions which are then executed. The same is basically true of most Java these days.

Well I've compiled .EXE files with c# that will run on windows or raspberry pi with no changes, unless Mono is doing something in the background.

It was by accident that I figured it out.

[tggzzz]

I wonder why though if they are focusing on high performance trading applications they are using C# and .NET?  The performance is fine for most applications, but C# just like VB.NET and Java, are all interpreted into a sort of byte code that runs in a virtual machine.

This is easily explained: You misunderstand how the .Net Common Language Runtime works. C# and other CLR languages are compiled into a sort of byte code. That byte code isn't executed through interpretation, instead the CLR compiles it into native instructions which are then executed. The same is basically true of most Java these days.

There is a key difference between Java Hotspot and .NET assemblies.

Java HotSpot measures what is actually being executed (i.e. cross-method and cross-class sequences of invocations), and then optimises the hell out of that - which is enabled by having a solid definintion of language and memory model.

.NET makes guesses about what might be executed based on static analysis, which can never be as good as dynamic analysis since it is the Halting Problem in another guise. That optimisation is hindered by having to interoperate with code marked "unsafe".

If you doubt the efficacy of HotSpot, search for HP's Dynamo compiler, and be surprised!

[Howardlong]

Without wishing this to be a justification one way or the other, the biggest complaint I have of JIT compiled stuff is the start up time. The most obvious thing to me is that the hardware config is so rarely if ever changed, but JIT compilers still recompile on first use.

In the database world (and I guess now also in the JIT world) for the past 15 years, well meaning and supposedly clever profiling and statistical methods frequently recompile code: when they notice the way the code is used in different ways, with differing data profiles, they introduce different plans on the fly.

The biggest problem with these schemes is that they introduce indeterministic behaviour, both from the compilation overhead, particularly in startup time, and from having a steady base to reliably perform non-functional testing and provide a consistent user experience. To my mind, there is far too much effort put on creating a good average result for some marketing and academic headlines compared to giving a reasonable and consistent one.

While I don't discount ku

[tggzzz]

Without wishing this to be a justification one way or the other, the biggest complaint I have of JIT compiled stuff is the start up time. The most obvious thing to me is that the hardware config is so rarely if ever changed, but JIT compilers still recompile on first use.

Counterpoint: the length of time it takes to update windows, partly because all the last-stage compilation (I've forgotten what they call it; specialisation?).

I've found it very useful to be able to run the same executable (i.e. Java bytecode) on many different machines, including Windows, Solaris, Linux and HP-UX. (And even, during development, to occasionally have the same single distributed application sharing memory across different processors and operating systems! Shudder)

The biggest problem with these schemes is that they introduce indeterministic behaviour, both from the compilation overhead, particularly in startup time, and from having a steady base to reliably perform non-functional testing and provide a consistent user experience. To my mind, there is far too much effort put on creating a good average result for some marketing and academic headlines compared to giving a reasonable and consistent one.

There I'll agree, but that is a far far wider topic than early/late JITting! Let's start with L1/L2/L3/TLB caches and work up the hardware/software stack from there...