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

FizzleFade

fabiensanglard.net

Post reply on HN
Print view View original

41–50 of 182 posts

Re: FizzleFade

#41

Post by bitexploder »

Illniyar wrote: post #31
pasta wrote: post #5

I have the feeling that knowledge about bits is lacking by a lot of younger coders. And I also think this is what causes bloatware. CPUs are powerful enough to use a naive fade transition. But coders who are aware of the internal workings can make it even faster on todays hardware. Great article and imho still relevant on todays much more powerful computers.

Why? I mean if you look at the majority of work that programmers do today - frontend/backend web development and apps, there is no need to have knowledge about bits. In fact, if I see someone using binary operators in languages such as Java,JS,Ruby etc... I'll immediately consider it bad code, regardless of context - it's just not the right tool for the level of abstraction in these languages. The fact is that in the…

This just seems wrong to me. There are plenty areas of programming where knowing a little bit about internal data representation, either in memory or in your data store can help you make better choices. Not everyone needs to be a system programmer, but folks still need general computer awareness. We just aren't far enough from the CPU yet. Sufficiently advanced understanding of algorithms implies computer architecture awareness to me.

I get what you are writing about here, that higher level concepts dominate programming many common apps today, but it seems like a weird place to allow yourself to have a knowledge gap.

Re: FizzleFade

#42

Post by spatulon »

eru wrote: post #25
digi_owl wrote: post #23

Earlier quoted context omitted.

Sadly many these days conflate "embedded" with RPi, Beaglebone or some other SoC on a board...

Even the chips you find on your credit card have quite a lot of RAM these days, don't they?

In the automotive world (with the exception of infotainment and assisted/autonomous driving systems), ECUs have amounts of RAM measured in kilobytes, not megabytes. I've left the industry now, but I /think/ the powertrain ECUs I worked with usually had around 256KB of RAM.

Re: FizzleFade

#43

Post by wmccullough »

peteretep wrote: post #39
xorcist wrote: post #22

Earlier quoted context omitted.

> I wonder if people find older developers miss obvious solutions that involve throwing small amounts of money and/or hardware at business problems, I regularly see the exact opposite: People throwing money and hardware at problems instead of doing the simple and obvious thing. I guess that makes me officially old.

> People throwing money and hardware at > problems instead of doing the simple > and obvious thing There are (almost) no technical problems, just business decisions. Programmer time for development and maintenance is expensive. Hardware is decreasingly so (also it's CapEx, so nobody cares if you literally light it on fire).

I find this too. Even the so-called proprietary algorithms many companies tout aren't even that complicated because 90% of their business runs on a REST over CRUD in SQL web service with a slightly different bootstrap theme on the frontend.

Re: FizzleFade

#44

Post by notzorbo3 »

peteretep wrote: post #17
pasta wrote: post #5

I have the feeling that knowledge about bits is lacking by a lot of younger coders. And I also think this is what causes bloatware. CPUs are powerful enough to use a naive fade transition. But coders who are aware of the internal workings can make it even faster on todays hardware. Great article and imho still relevant on todays much more powerful computers.

> I have the feeling that knowledge > about bits is lacking by a lot of > younger coders. And I also think > this is what causes bloatware From a management perspective, I wonder if people find older developers miss obvious solutions that involve throwing small amounts of money and/or hardware at business problems, and instead turn to "clever" solutions that are costly in terms of extra developer time needed for deve…

Managers often think throwing more hardware at the problem will fix things. But hardware scales sub-linearly. Solving the actual underlying problems can easily get you exponential payoffs.

Anecdote: One of my managers once spent €70000¹ worth of hardware to speed up an application because he believed it would be cheaper than to optimize the code. Naturally, no-one had done any kind of performance analysis, so while the upgrade made things about 20% faster, it still wasn't enough. It took me all of 20 minutes to figure out that caching was disabled on the database and it had no indexes whatsoever². 30 minutes of work yielded a few thousand percent speed increase.

¹) This was a long time ago before SSDs existed and buying a hardware RAID of fast disks and fast CPUs / memory was extremely expensive.

²) DBAer consultants of a certain large database vendor are not worth the horrendous hourly fee they ask.

Re: FizzleFade

#45

Post by deanCommie »

bitexploder wrote: post #41
Illniyar wrote: post #31

Earlier quoted context omitted.

Why? I mean if you look at the majority of work that programmers do today - frontend/backend web development and apps, there is no need to have knowledge about bits. In fact, if I see someone using binary operators in languages such as Java,JS,Ruby etc... I'll immediately consider it bad code, regardless of context - it's just not the right tool for the level of abstraction in these languages. The fact is that in the…

This just seems wrong to me. There are plenty areas of programming where knowing a little bit about internal data representation, either in memory or in your data store can help you make better choices. Not everyone needs to be a system programmer, but folks still need general computer awareness. We just aren't far enough from the CPU yet. Sufficiently advanced understanding of algorithms implies computer architectur…

It shouldn't feel wrong to you. In today's connected big-data world, the vast majority of your performance latency is from querying your data (if you structure your db incorrectly), followed closely by client to server communication.

That's the p90 use case for development people are doing.

Re: FizzleFade

#46

Post by smcl »

zimpenfish wrote: post #35
ishi wrote: post #4

Cool, I knew that LFSRs were used in ciphers. I was not aware that they were also useful for implementing old-school graphical effects. https://en.wikipedia.org/wiki/Linear-feedback_shift_register...

I'm not sure I'd call Wolfenstein 3D "old-school". But then I did start with computers in 1980.

It's funny where we draw our lines. Some younger guys will call Half-Life 2 old-skool, which for me felt like it was just a couple of years ago.

Re: FizzleFade

#47

Post by lorenzk »

deanCommie wrote: post #45
bitexploder wrote: post #41

Earlier quoted context omitted.

This just seems wrong to me. There are plenty areas of programming where knowing a little bit about internal data representation, either in memory or in your data store can help you make better choices. Not everyone needs to be a system programmer, but folks still need general computer awareness. We just aren't far enough from the CPU yet. Sufficiently advanced understanding of algorithms implies computer architectur…

It shouldn't feel wrong to you. In today's connected big-data world, the vast majority of your performance latency is from querying your data (if you structure your db incorrectly), followed closely by client to server communication. That's the p90 use case for development people are doing.

What's a "p90 use case"?

Re: FizzleFade

#48

Post by theon144 »

Illniyar wrote: post #31
pasta wrote: post #5

I have the feeling that knowledge about bits is lacking by a lot of younger coders. And I also think this is what causes bloatware. CPUs are powerful enough to use a naive fade transition. But coders who are aware of the internal workings can make it even faster on todays hardware. Great article and imho still relevant on todays much more powerful computers.

Why? I mean if you look at the majority of work that programmers do today - frontend/backend web development and apps, there is no need to have knowledge about bits. In fact, if I see someone using binary operators in languages such as Java,JS,Ruby etc... I'll immediately consider it bad code, regardless of context - it's just not the right tool for the level of abstraction in these languages. The fact is that in the…

>the majority of work that programmers do today - frontend/backend web development and apps

Therein lies your bias, and the rest of your comment just follows.

Re: FizzleFade

#49

Post by bitexploder »

deanCommie wrote: post #45
bitexploder wrote: post #41

Earlier quoted context omitted.

This just seems wrong to me. There are plenty areas of programming where knowing a little bit about internal data representation, either in memory or in your data store can help you make better choices. Not everyone needs to be a system programmer, but folks still need general computer awareness. We just aren't far enough from the CPU yet. Sufficiently advanced understanding of algorithms implies computer architectur…

It shouldn't feel wrong to you. In today's connected big-data world, the vast majority of your performance latency is from querying your data (if you structure your db incorrectly), followed closely by client to server communication. That's the p90 use case for development people are doing.

So many simple things are only easy if you know bits. Interpreting a packet capture, poking at memory, designing cache friendly data structures, ... It is like second nature to me. If it isn't required (obviously it isn't, it must at least be a strong competitive advantage). I am not that old. I don't have get off my lawn moments. I grew up (really learned at least) on a processor (P133) where bits started mattering less, but they still mattered.

Re: FizzleFade

#50

Post by bitexploder »

lorenzk wrote: post #47
deanCommie wrote: post #45

Earlier quoted context omitted.

It shouldn't feel wrong to you. In today's connected big-data world, the vast majority of your performance latency is from querying your data (if you structure your db incorrectly), followed closely by client to server communication. That's the p90 use case for development people are doing.

What's a "p90 use case"?

90th percentile use case
Post reply on HN