3 ms·

> I found all I've learn is worth nearly nothing in industry It really depends what you work on. Doesn't even have to be high end. When working on performance

by ascar 4y ago

> I found all I've learn is worth nearly nothing in industry It really depends what you work on. Doesn't even have to be high end. When working on performance critical code I was glad about my computer science and math education more than once. And performance can get interesting even at a few million users or regardless of user-count in realtime applications. When writing business logic without performance and scalability in mind, yea, all that knowledge remains dormant. Reality is that there is simply far more business logic work out there than performance critical code.

zasdffaa 4y ago
All my understanding of perf-critical code has come from understanding of the usual - pathological cases for algorithms, memory layout, cache friendliness etc. etc. None of that except perhaps a very little of the first, came from my formal education, it's all been down to me reading up on stuff. Can you give me an idea of what your CS & maths education gave you that you found so useful for tuning code? Maybe I'm missing something important.
- ascar 4y ago
  > algorithms, memory layout, cache friendliness all of this was an integral part of my formal education. Algorithms and datastructures and complexity analysis was mandatory in the undergraduate studies, the lower-level stuff mostly in elective postgraduate classes of my computer science program. From the top of my head also things like operating systems, compilers, networking, vectorization (SIMD), instruction pipelining, branch prediction, threading, NUMA, thread-pinning/affinity that help understanding how my code is actually executed. On the math side set theory, probability theory and analysis also came in handy more than once. Linear algebra I guess if I had to deal with matrices, which is probably relevant in the AI/machine learning fields (not my area of expertise). All of my math education was mandatory undergraduate classes. Sure, it's well established that you don't need formal education to learn all these things (which applies to most fields, not just CS), but they are certainly part of computer science and taught as part of formal education at I would assume most good universities. From my experience (which is Germany and Japan, not the US) especially postgraduate degrees are what you make of them. You can learn nothing relevant for performance critical engineering or you can learn a ton.
  - zasdffaa 4y ago
    >> algorithms, memory layout, cache friendliness > all of this was an integral part of my formal education. Other than algos, we got none of this. > the lower-level stuff mostly in elective postgraduate classes of my computer science program. From the top of my head also things like operating systems, compilers, networking, vectorization (SIMD), instruction pipelining, branch prediction, threading, NUMA, thread-pinning/affinity that help understanding how my code is actually executed. We got compilers. Otherwise none of this - in fact these are not computer science by some definitions. It was pretty much maths at the end. I don't think we were well served in some ways. > which is Germany and Japan, not the US I'm in the UK.
    - ascar 4y ago
      > We got compilers. Otherwise none of this Did you have the option to take the relevant classes as electives in your postgraduate studies? My postgraduate had a single mandatory course and otherwise just required that I spread my classes among 3 of ~7 major focus areas. One of these areas was computer architecture, which taught me most of the low-level things I listed above. Another thing I forgot above was formal education in distributed systems and databases, especially the postgraduate databases class that covered the inner workings (like transactions, WAL, dependencies, rollbacks, etc.) and distributed databases, which nicely connected with the distributed systems lecture (which dealt a lot with CAP theorem and consensus, e.g. paxos). That's also something you can learn on the job, but the formal education gave a pretty broad background that I would think is hard to learn on the job. > computer science by some definitions I guess if there is a distinction between computer science and for example computer engineering they would mostly end up on the computer engineering side of things, which sits somewhere between computer science and electrical engineering. Though the level on which I studied these concepts in our computer science department was to understand how it works, history and state of the art and it's implications on software. It was less about how to create such a system from the electrical engineering side of things.
      - zasdffaa 4y ago
        > Did you have the option to take the relevant classes as electives Dunno. It was a long time ago. To be fair, a lot of the stuff you mention learning just didn't exist back then - it was a long time ago. Then again, we did a database course and we got no hands-on with a real DB at all. It was all random guff about functional dependencies etc. I learnt literally nothing useful. I know about WAL etc from learning after. > I guess if there is a distinction between computer science and for example computer engineering You nailed it. Engineering vs science. The science was taught purely in the abstract, application of it to real problems was even held somewhat in contempt by one lecturer. It could and should have been so much better.

by ascar 4y ago

zasdffaa 4y ago

All my understanding of perf-critical code has come from understanding of the usual - pathological cases for algorithms, memory layout, cache friendliness etc. etc. None of that except perhaps a very little of the first, came from my formal education, it's all been down to me reading up on stuff. Can you give me an idea of what your CS & maths education gave you that you found so useful for tuning code? Maybe I'm missing something important.

ascar 4y ago
> algorithms, memory layout, cache friendliness all of this was an integral part of my formal education. Algorithms and datastructures and complexity analysis was mandatory in the undergraduate studies, the lower-level stuff mostly in elective postgraduate classes of my computer science program. From the top of my head also things like operating systems, compilers, networking, vectorization (SIMD), instruction pipelining, branch prediction, threading, NUMA, thread-pinning/affinity that help understanding how my code is actually executed. On the math side set theory, probability theory and analysis also came in handy more than once. Linear algebra I guess if I had to deal with matrices, which is probably relevant in the AI/machine learning fields (not my area of expertise). All of my math education was mandatory undergraduate classes. Sure, it's well established that you don't need formal education to learn all these things (which applies to most fields, not just CS), but they are certainly part of computer science and taught as part of formal education at I would assume most good universities. From my experience (which is Germany and Japan, not the US) especially postgraduate degrees are what you make of them. You can learn nothing relevant for performance critical engineering or you can learn a ton.
- zasdffaa 4y ago
  >> algorithms, memory layout, cache friendliness > all of this was an integral part of my formal education. Other than algos, we got none of this. > the lower-level stuff mostly in elective postgraduate classes of my computer science program. From the top of my head also things like operating systems, compilers, networking, vectorization (SIMD), instruction pipelining, branch prediction, threading, NUMA, thread-pinning/affinity that help understanding how my code is actually executed. We got compilers. Otherwise none of this - in fact these are not computer science by some definitions. It was pretty much maths at the end. I don't think we were well served in some ways. > which is Germany and Japan, not the US I'm in the UK.
  - ascar 4y ago
    > We got compilers. Otherwise none of this Did you have the option to take the relevant classes as electives in your postgraduate studies? My postgraduate had a single mandatory course and otherwise just required that I spread my classes among 3 of ~7 major focus areas. One of these areas was computer architecture, which taught me most of the low-level things I listed above. Another thing I forgot above was formal education in distributed systems and databases, especially the postgraduate databases class that covered the inner workings (like transactions, WAL, dependencies, rollbacks, etc.) and distributed databases, which nicely connected with the distributed systems lecture (which dealt a lot with CAP theorem and consensus, e.g. paxos). That's also something you can learn on the job, but the formal education gave a pretty broad background that I would think is hard to learn on the job. > computer science by some definitions I guess if there is a distinction between computer science and for example computer engineering they would mostly end up on the computer engineering side of things, which sits somewhere between computer science and electrical engineering. Though the level on which I studied these concepts in our computer science department was to understand how it works, history and state of the art and it's implications on software. It was less about how to create such a system from the electrical engineering side of things.
    - zasdffaa 4y ago
      > Did you have the option to take the relevant classes as electives Dunno. It was a long time ago. To be fair, a lot of the stuff you mention learning just didn't exist back then - it was a long time ago. Then again, we did a database course and we got no hands-on with a real DB at all. It was all random guff about functional dependencies etc. I learnt literally nothing useful. I know about WAL etc from learning after. > I guess if there is a distinction between computer science and for example computer engineering You nailed it. Engineering vs science. The science was taught purely in the abstract, application of it to real problems was even held somewhat in contempt by one lecturer. It could and should have been so much better.