Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Grad vs. Senior Dev

ericlippert.com

Post reply on HN
Print view View original

71–80 of 392 posts

Re: New Grad vs. Senior Dev

#71

Post by jakear »

TeMPOraL wrote: post #61
jakear wrote: post #50

Heh... reminds me of my first proper MS internship, when I too was responsible for speeding up some code, this time in the VS Code Go extension. This code was responsible for tokenization, so it affected pretty much every operation and ran on every edit. Important shit. Day 1: do some basic hoisting. O(n^3) => O(n^2). Tokenization times for a 10k line file go from ~15s to 500ms. Sweet. Days 2-30 [1]: ideate, develop,…

> But hey, all the people working in 500k line files must really love the couple seconds my month of toiling (more importantly, my month of not doing other, more impactful things) saved them. This stuff matters. These couple seconds per operation may very well be a difference between being able to open a 100k+ LOC file in the same editor you're doing your other work in, vs. giving up in frustration and looking for so…

This is true, but my approach was still not a great one. It turns out the data structure was only accessed in a very specific way, which I could have exploited to dramatically simplify the implementation. If I had researched the problem more before diving into my original idea, I could have achieved the same end goal with much less work.

Lessons upon lessons :)

Re: New Grad vs. Senior Dev

#72

Post by mettamage »

ericlippert wrote: post #22
mettamage wrote: post #5

> NO! YOU CAN’T JUST USE BRUTE FORCE HERE! WE NEED TO USE SEGMENT TREES TO GET UPDATE TIME COMPLEXITY DOWN TO O(LOG N)! BREAK THE DATA INTO CHUNKS AT LEAST! OH THE INEFFICIENCY!!! I'm the opposite of this stereotype, and I think there are more like me. Two reasons as to why: (1) Psychological: I never had this. As a junior dev, I don't like to optimize because I feel a bit of pain when I need to moderately focus. I c…

The "malice" aspect is a great one and I did not go into that in this post because of course back in the 1990s we were not at all concerned that someone would maliciously craft inputs that would slow down this algorithm. In modern code we'd want to do a threat model that considered the consequences of untrusted inputs.

Neither did Intel :P

Come to think of it, neither do beginning game-designers. They think that players will play their game as intended.

I like that you're standing still at the malice part as it is becoming seemingly more important every day.

Re: New Grad vs. Senior Dev

#73

Post by dwheeler »

dilyevsky wrote: post #67
corysama wrote: post #65

Earlier quoted context omitted.

It’s because Big O is Computer Science. Cache effects are Software Engineering. Professors of CS do a fine job of teaching CS. They even briefly mention that there is a implicit constant factor k in O(k n log(n)) and then they never mention it again. They certainly don’t mention that k can easily vary by 128x between algos. AKA: 7 levels of a binary tree. Or that most of the data they will be dealing with in practice…

Every good cs course has a section on cache aware algorithms. And i call bullshit that constant factor is not mentioned too

Mentioned, yes, but often not learned. In many situations the only thing that matters is the constant factor. If the number of data items is relatively small, the difference between N log N and and N squared may be completely dominated by the constant factor. In addition, there is the challenge of maintaining the code later and making sure it's correct.

Re: New Grad vs. Senior Dev

#74

Post by cwzwarich »

jakear wrote: post #50

Heh... reminds me of my first proper MS internship, when I too was responsible for speeding up some code, this time in the VS Code Go extension. This code was responsible for tokenization, so it affected pretty much every operation and ran on every edit. Important shit. Day 1: do some basic hoisting. O(n^3) => O(n^2). Tokenization times for a 10k line file go from ~15s to 500ms. Sweet. Days 2-30 [1]: ideate, develop,…

I'm curious: why can't you do tokenization in linear time? And why not use incremental tokenization for an editor?

Re: New Grad vs. Senior Dev

#75

Post by vardump »

thedance wrote: post #69
vardump wrote: post #60

Earlier quoted context omitted.

Very much true. REP SCASB on 1994 (same year as the incident in the article) Intel Pentium would have taken 9 + 4 * n clock cycles [0][1] to go through a string. So scanning 4 chars long string takes 25 clock cycles. [0]: Agner's instruction tables page 123: https://www.agner.org/optimize/instruction_tables.pdf [1]: Plus one extra cycle to decode REP prefix, if previous instruction took 1 cycle.

It could be faster than some alternatives under some circumstances. A loop would probably be more code (== icache pressure) and would consume at least a register and a BTB entry.

It's certainly been a while since I last optimized for the original Pentium architecture. Still faintly remember U & V pipes, unexplained causes for stalls, etc.

As even nowadays, it would likely depend on the particular algorithm and data set. I'd be surprised if you can't do better than 4 cycles per char for sufficiently long strings. Most likely for short strings, REP SCASB wins due to setup costs. (Actually that article's skipto method would have of course used REP CMPSB, but that's just splitting hairs.)

Remember that even original Pentium could execute up to two instructions per clock. Unless you messed up with those damn U & V pipes. :-)

The hypothetical faster-than-rep solution would need to process data in 32-bit chunks, faux vector style.

Re: New Grad vs. Senior Dev

#77

Post by vvanders »

dwheeler wrote: post #73
dilyevsky wrote: post #67

Earlier quoted context omitted.

Every good cs course has a section on cache aware algorithms. And i call bullshit that constant factor is not mentioned too

Mentioned, yes, but often not learned. In many situations the only thing that matters is the constant factor. If the number of data items is relatively small, the difference between N log N and and N squared may be completely dominated by the constant factor. In addition, there is the challenge of maintaining the code later and making sure it's correct.

Yup, so much truth here.

Take a look at Real-time Collision Detection[1]. I takes a great look at both algorithmic complexity and cache awareness. That's how it should be done.

[1] https://www.amazon.com/dp/1558607323

Re: New Grad vs. Senior Dev

#79

Post by fjfaase »

Everyone who has done profiling knows that (almost always) the performance problem is in the part that you least expect it. But also that sometimes you wrestle to improve the performance of an algorithm hitting a hard wall and than someone comes up with an idea, often resulting from a fresh look on the problem, that results in an improvement of several orders. I guess that performance is at least as counter intuitive as statistics. The same is true for some other things like scalability and reliability.

Actually, I think that it scares the hell out of most of the developers that it is so difficult to get a grip on these things. It is so easy to think that there is a simple solution, a grand idea that will fix the problem. I still find myself falling in the trap and this after having developed software for over 30 year. It is the Dunning–Kruger effect over and over again. I guess it more that as a more senior engineer, you have experienced a little more often.

Re: New Grad vs. Senior Dev

#80

Post by 9wzYQbTYsAIc »

chiefalchemist wrote: post #8
gen220 wrote: post #4

Earlier quoted context omitted.

Putting it another way, knowledge with the bare minimum experience required to be effective is very sharp, and that sharpness is sometimes what’s required to cut through old, retrospectively “wrong” ways of doing things. I don’t disagree with what you’ve said, I think we all have met plenty of people fitting your description, I just mean to say there’s another side of the coin. As food for thought, much (not all) of…

The New Grad had knowledge. The Senior Dev had Understanding. Understanding > Knowledge It's that simple.

Being pedantic here, but knowledge is equivalent to understanding (information being knowledge without understanding). Wisdom is the word you were looking for (knowledge being wisdom without experience):

The New Grad had knowledge. The Senior Dev had Wisdom.

Wisdom > Knowledge.

Post reply on HN