Live data from Hacker News

FizzleFade

fabiensanglard.net

141–150 of 182 posts

Re: FizzleFade

#141
post #136

Stupid question: Why can't you just take an array of all the pixels, randomize it and then iterate it to draw?

1) That's a lot of memory

2) Accessing memory is the slowest thing you can possibly do on a computer, other than IO

Re: FizzleFade

#142
The Atari 2600 video hardware used these all over the place instead of traditional counters. It saved them a lot of gates that counters would require.

Re: FizzleFade

#143

An alternative approach that works for every resolution: http://antirez.com/news/113

"just scramble the address" was the solution that immediately came to mind. feistelNet looks a little heavy though, is it really necessary? would you not get the same effect from straight xor on the x and y coords?

Re: FizzleFade

#144
post #58
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 agree. Unfortunately, it feels like there is so many people out there lacking the fundamental engineering background to write software. I once spent an hour "optimizing" a piece of code that ran in 15 minutes, which tested an embedded system. The resulting code ran in 4 seconds. The root cause was a complete misunderstanding of how microprocessor interrupts work. I spent a week re-writing a 4000 line C-function, wh…

I was taught about low-level architecture (and version control too) in the first year of my CS course. Is this not standard?

Re: FizzleFade

#145

Related: https://en.wikipedia.org/wiki/Linear_congruential_generator A pseudo-RNG that cycles through a all elements of a modulo-ring. Example for a 2^32 bit cycle: X(n+1) = (a * X(n) + c) mod m a = 134775813 c = 1 m = 2^32

I thought of this too, but it might be a bit more taxing on an old CPU to do excess multiplication than a simple XOR and test.

Re: FizzleFade

#146
post #68

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…

> 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. Clojure is written in java (and clojure). It uses bit operations to implement Software Transactional Memory and persistent collections. Is it a bad code? You seem to think a programmer sh…

I don't know enough about Clojure, but I think you are saying that Clojure itself is using bit operations behind the hood - of course it's ok for a language implementation to use bit operations.

But if any of your Java code for applications or libraries used bit operations, I'll call it bad code.

Re: FizzleFade

#147

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.

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.

I don't see why knowledge of bit operations are necessary to do a good programming job.

Re: FizzleFade

#148

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…

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

I'm definitely bias towards frontend/backend web development and apps (I.E. mobile/desktop apps).

But that's not to say the premise is bad - I don't think it's wrong to assume the majority of work is in that area, definitely for young developers. There aren't that many real-time and performance-demanding programming jobs compared to web development.

I don't think even game-programming uses bit operations heavily these days- most of the low-level work is done by third party engines.

Re: FizzleFade

#149

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…

> using binary operators [...] bad code, regardless of context > the performance profile is dominated by bad algorithms, wrong data structures Do you know how you often implement good algorithms and data structures? You wouldn't implement a bloom filter as a high level array of 1/0 integers, would you?

I would definitely implement a bloom filter with an array of booleans, and will not use bit operations to modify the cells.

Whether I use array access or a bitmask will mean nothing performance-wise, since the bloom filter itself is likely already speeds up a different algorithm by an order of magnitude.

Re: FizzleFade

#150

Earlier quoted context omitted.

Did your coworker correct it with "this is more readable" or "this is the correct way to do it"? The first is arguable (though I don't personally agree with the argument), the second just betrays a real lack of knowledge.

Don't the two bits of code have completely different behaviour? And the code with the bitshift is undefined on negative integers (in C). So the bottom code could indeed be the "correct way to do it".

Fair, with negative ints they're different. They have the same behavior on positive ints, though.
Post reply on HN