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

171–180 of 182 posts

Re: FizzleFade

#171

Post by open_bear »

tripzilch wrote: post #166
Illniyar wrote: post #159

Earlier quoted context omitted.

Conway's game of life is at best school homework, it does not correlate to any programming done in a real job.

I'm frankly a bit offended by the type of computer science and computer programming that you dismiss as not a "real job". Sure, Conway's Game of Life is a toy problem, but the optimizations used to make it run fast (which go way beyond mere bit-twiddling, btw) are useful tools and practice in a programmer's mental toolbox, for solving real problems. Certainly, a programmer who "merely" plugs frontends into backends w…

Totally agree.

> (which go way beyond mere bit-twiddling, btw)

I was fascinated by optimizations people come up for Game of Life by reading Michael Abrash's Black Book.

> a programmer who "merely" plugs frontends into backends with databases"

I am such a programmer: never have used bit manipulation in my job, and while it is kinda boring, it is a job, and someone has to do it.

Re: FizzleFade

#172

Post by leni536 »

tripzilch wrote: post #164
leni536 wrote: post #11

> Since 320x200=64000, it could have been implemented with a 16 bits Maximum-length register. But then you have to calculate modulus for 200 or 320.

except the pixels are in a linear framebuffer, the fizzlePixel(x, y) function has a multiplication by 320 in it to calculate the address in the buffer. so you could skip both the modulo and the mul if you go straight for obtaining a random shuffled framebuffer index. unless maybe fizzlePixel does additional bookkeeping for some purpose.

> has a multiplication by 320

Huh the original implementation seems to have a lookup table instead of that, interesting.

https://github.com/id-Software/wolf3d/blob/05167784ef009d0d0...

Re: FizzleFade

#173

Post by dakom »

ksk wrote: post #132
dakom wrote: post #73

Earlier quoted context omitted.

Anecdotal evidence - I cut my teeth on C and a dabble of asm as a kid (even writing z80 opcodes directly for fun!). I vaguely remember wrangling bits to drive logic. I also wrote webpages as Apache C modules with binary logic to parse requests :D That was a long time ago in tech terms (~15 years). In the intervening gap I spent most of my time in scripted languages (as3, c#, etc.). Result? I don't know how to wrangle…

>I rely on Unity, Adobe, Google, etc. to worry about those optimizations so I can stand on their shoulders and benefit. It seems to me like they might be doing the same thing! For all the supposedly smart people they hire, TBH I can't think of a single product that feels fast/performant to me.

Ultimately that's a subjective call. If I had to write the Unity Editor and enable it to hit the targets they do - man I don't even know where to start. Seems like voodoo to me, personally I'm extremely impressed but I admit it might just be my lack of knowledge of what's possible now (last time I did low-level graphics stuff was amateur mucking around with mode 13h and SDL)

Re: FizzleFade

#174

Post by peteretep »

seanwilson wrote: post #96
peteretep wrote: post #17

Earlier quoted context omitted.

> 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…

> 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 developer and maintenance. Why do people feel the need to generalise about things developers of different ages do...? Knowing when to save on…

    > Why do people feel the need to
    > generalise about things developers
    > of different ages do
Mostly it was a tongue-in-cheek reply to a comment doing the same...

Re: FizzleFade

#175

Post by fundabulousrIII »

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…

For most operational purposes there isn't a crying need for optimizations and handwritten assembly outside the kernel but a good programmer must at least recognize where something like this is called for and be able to implement (imo).

Re: FizzleFade

#176

Post by fundabulousrIII »

Illniyar wrote: post #147
bitexploder wrote: post #49

Earlier quoted context omitted.

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…

Never needed to interpret a packet, I intercept communications at the 7th layer to troubleshoot things - namely http connections. I don't poke at memory, I use a profiler that tells me what every piece of code and variables I use take in memory. I don't design cache friendly data structures, I use redis. I would wager that my experience is closer to the development situation and needs of the majority of programmers.…

These design|use patterns depend entirely on a level of abstraction facilitated by code you don't understand and I have seen this bite people badly.

Using redis or memcache or whatever semi-persistent , network available data store for key value pairs only has middling value (to me) and relies on adopting a data model that is severely limited in scope. If you can't understand the structure of a 'packet' on the network then you can't really troubleshoot network dependent services that provide your L7 function.

Re: FizzleFade

#177

Post by fundabulousrIII »

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…

This is where some knowledge as a syseng or SA comes in very handy. Programmers tend to come up with cool solutions to a problem in their wheelhouse but it may not be the most cost effective or efficient solution. Having domain knowledge is very important.

Re: FizzleFade

#178

Post by fundabulousrIII »

afpx wrote: post #21
peteretep wrote: post #17

Earlier quoted context omitted.

> 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…

It depends on the person, obviously. But, I hope you sprinkle in a few of those types of analysis questions in your standardized interviews so that older people like me even have a chance. It hurts (both emotionally and financially) to be rejected by younger teams because they assume things about me that aren't true. I now get the dreaded "has too much experience and would be bored" rejection line all too often.

There is only one way to go there. Start a consultancy and be your own boss. That is about it for us older folks. Most of your customers don't want stellar code: they want you to fix what is broken (which is simple enough).

Re: FizzleFade

#179

Post by fundabulousrIII »

spatulon wrote: post #42
eru wrote: post #25

Earlier quoted context omitted.

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.

That is a fascinating world to me. I've about 25 years C, rudimentary intel x86 asm and good ability to understand new hardware. Seems to me that at 40+ this is an industry that I could still be of use in. Any pointers?

Re: FizzleFade

#180

Post by xorcist »

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).

See, now you fell for the same fallancy. Something that is smart must surely be more expensive, but this is seldom true. A method that is simple is easier to describe, easier to implement and could very well be more performant than a more complicated one.
Post reply on HN