Live data from Hacker News

Low-Level Programming University – A roadmap to becoming a low-level programmer

github.com

101–110 of 168 posts

Re: Low-Level Programming University – A roadmap to becoming a low-level programmer

#101

Earlier quoted context omitted.

Can you clarify your statement?What does a low-level person do to improve infrastructure?

Writing and designing code that is mindful of latencies (Amdahl's law). Temporal / Spatial locality, avoiding needless copies etc.. This approach needs to start from design and also follow into implementing the code. Moreover, this is done without compromising on readability.

Umm, Amdahl's law is actually a negative result. It's saying that if you infinitely improve some magical hotspot that is 1% of your workload, the best you can only ever get to is 99%. If anything, Amdahl is telling us not to grind on trivialities.

Re: Low-Level Programming University – A roadmap to becoming a low-level programmer

#102

Don't go there. There's really not a lot of work. But if you must, low level is more a calling than a learned skill. You probably shouldn't be learning assembler. First, compilers are really quite good. Yes, it's possible to beat them (I do) but generally not by much. And not by much ain't gonna put bacon on the table. You can probably get what you need from gcc inline asm() calls. Take a look at the linux sources an…

Someone has to write those compilers. Those with the skills to do so are vital to the industry. If we want more nice high-level languages and improved operating systems, we need new people entering this area of software engineering. Otherwise, where is the next iteration of systems software going to come from?

Re: Low-Level Programming University – A roadmap to becoming a low-level programmer

#103

The bearishness here surprises me. The more a company spends on infrastructure, the more they need low-level people. A good low-level programmer can reduce cost requirements 10x or more. Any company spending millions or billions on infrastructure can make enormous savings by hiring the right people. Crucial for Google, Amazon, Facebook, and even midsize startups can see a big improvement. And its difficult to fill th…

My Facebook iPhone app weighs in at 241 MB. It has massive redundancy and you can say that again. http://blog.timac.org/?p=1707 Still, I have to say that there is indeed an opportunity for a few low level people there.

[deleted]

Re: Low-Level Programming University – A roadmap to becoming a low-level programmer

#104
post #21

About career, is low level programming job market that small we see in this threads comments ? I want to be C/C++/Rust programmer. This is quite frightening.

Take a look through the monthly HN "Who's hiring?" posts. Jobs of any kind that aren't web (front-end, back-end, or full stack) or mobile apps are vanishingly scarce. It's really quite depressing.

Us low-level types don't post there.

We know the bias against defence contractors, against the south, against the non-urban parts of the USA, and so on. We know we aren't wanted around here.

The jobs can be nice though! My place is looking to hire dozens per year. We do emulators, JIT, hypervisors, stuff like valgrind, debuggers, manual disassembly, and vulnerability research. I've been here 11 years. I've worked with more than 10 different CPU architectures and more than 10 completely different OSes. I don't normally work overtime, and I get paid more if I do. I have extreme flex-time. I never have to worry about outsourcing or H1B people. I'm never expected to take work home or be on call. I get to live in a place with no state income tax, a stand-your-ground law, almost no crime, almost no traffic or commute, and houses that commonly go for $100,000 to $400,000. We're hiring in Florida, Texas, Virginia, Maryland, Georgia, South Carolina, Alabama... totally the dream for SF and NYC people I'm sure!

Email acahalan, at gmail, if this suits you. Be sure to mention this comment.

Re: Low-Level Programming University – A roadmap to becoming a low-level programmer

#105

The bearishness here surprises me. The more a company spends on infrastructure, the more they need low-level people. A good low-level programmer can reduce cost requirements 10x or more. Any company spending millions or billions on infrastructure can make enormous savings by hiring the right people. Crucial for Google, Amazon, Facebook, and even midsize startups can see a big improvement. And its difficult to fill th…

Game development also needs people going low. Both in terms of cranking every last bit of performance from an end users machine, to packing as much information into a packet as possible to stream to the server.

Re: Low-Level Programming University – A roadmap to becoming a low-level programmer

#106

Earlier quoted context omitted.

the job market for burger flipping is high. LOL in a capitalist society, small/rare usually means high-paying! don't make it your career but it pays to know these things when writing your high-level code.

Small/rare in the supply side is only high paying when the demand is not as small or as rare. It really depends on that relation. Based on the comments I'm seeing... sounds like everyone is talking more about the demand side than the supply side... which sounds either on the edge of oversupply or just plain oversupplied. Otherwise, I agree with you. Those that understand low level issues tend to, in my experience, ju…

The demand is quite low. I think if you want a good low-level code implementation, you can easily find one on github. For example, you can easily find a good compression algorithm for your CPU budget or other application needs on github. So you can get away with mostly writing high level code and using these external libraries. Second, the demand for writing really optimized code is not as high as 10-20 years ago. Now, writing reasonably fast, readable code is OK and no one expects you to run gcc -S and count cycles unless you are working in some high frequency trading firm.

Re: Low-Level Programming University – A roadmap to becoming a low-level programmer

#107

Earlier quoted context omitted.

Could not have said it any better. Embedded development is dominated by hardware engineers who make decisions very often without the software development teams input, placing embedded folk square in the target of management angst as well. Choosing Broadcom chips without drivers, 3rd party experimental hardware who wont release data sheets, choosing USB chips that don't support host mode, miswired memory interfaces th…

In defense of HW engineers, they're often staring at a cost of goods spreadsheet. Earlier in my career, I had a driver that compiled to about 8500 bytes. I noticed the part was spec'd at 16K and wondered if it could get re-spec'd at 8K if I got it down to 8K. Yep and I got mad props from the HW types.

Understood, but when they stare at that COG sheet they should also have the prescence of mind to look for hidden costs. A toolchain and IDE with a C compiler is going to cost much less in the end to the project than a 8K chip with an assembler and no debug environment/support tools will save it. It's very easy to be penny wise and pound foolish in this area.

Re: Low-Level Programming University – A roadmap to becoming a low-level programmer

#109

Earlier quoted context omitted.

Writing and designing code that is mindful of latencies (Amdahl's law). Temporal / Spatial locality, avoiding needless copies etc.. This approach needs to start from design and also follow into implementing the code. Moreover, this is done without compromising on readability.

Umm, Amdahl's law is actually a negative result . It's saying that if you infinitely improve some magical hotspot that is 1% of your workload, the best you can only ever get to is 99%. If anything, Amdahl is telling us not to grind on trivialities.

That's not how I understood it - I thought it was about the upper limit of theoretical parallelism.

But I'm an EE, so maybe I misunderstood some finer points?

Re: Low-Level Programming University – A roadmap to becoming a low-level programmer

#110

Earlier quoted context omitted.

Writing and designing code that is mindful of latencies (Amdahl's law). Temporal / Spatial locality, avoiding needless copies etc.. This approach needs to start from design and also follow into implementing the code. Moreover, this is done without compromising on readability.

Umm, Amdahl's law is actually a negative result . It's saying that if you infinitely improve some magical hotspot that is 1% of your workload, the best you can only ever get to is 99%. If anything, Amdahl is telling us not to grind on trivialities.

If a system performance is profiled as being dominated by 80% A , 19% B and 1 % C. I'd focus on working on A first to get maximum gains. Amdahl's law gives you the backing as to why you should do this.

As a real world example, if an operation involves a network call and you see the RTT dominating the time. You may want to think of ways to avoid the call (caching etc..) if possible to get really good gains.

Post reply on HN