For solving the problem of proportioned distribution of ads into sites at internet-scale, we had used a random number generator within a segmented number range. It was elegant and distributed synchronization and such complexities.
Any more of such elegant tricks in production software?
Production algorithm tricks anyone?
1–10 of 20 posts
Re: Production algorithm tricks anyone?
#299% of the cool, elegant "tricks" I've seen have been applications of the following computer science concepts:
https://en.wikipedia.org/wiki/B-tree
Re: Production algorithm tricks anyone?
#3SPITBOL/370 is a SNOBOL4 implementation for IBM mainframes. The following Dr. Dobbs articles describe some of the tricks used in the code. Elegant is the wrong word but both of these techniques are clever hacks.
http://www.drdobbs.com/cpp/misusing-floating-point-arithmeti...
http://www.drdobbs.com/cpp/some-programs-are-poorly-designed...
Re: Production algorithm tricks anyone?
#4>"we had used a random number generator within a segmented number range."
Could you describe your current implementation and its elegance?
Re: Production algorithm tricks anyone?
#5>"we had used a random number generator within a segmented number range." Could you describe your current implementation and its elegance?
Ad 1 has to be shown 30% of the traffic
Ad 2 has to be shown 40% of the traffic
Remaining has to be given to RTB
generate a random number between 0:100 if the number is 0-30 the Ad 1 has to be shown if the number is 30-70 the Ad 1 has to be shown else RTB is to be called
The servers can be now independent and no need to share the state, or have a lock based counter. For large number of requests, and with a good random number generator, you will get good results.
Re: Production algorithm tricks anyone?
#6For scaling view counters on the pages of popular videos Youtube increments the counter by N views with 1/N probability for each actual view. Or so I've been told.
Re: Production algorithm tricks anyone?
#7I've always been a fan of the Fast Inverse Square Root hack.
float Q_rsqrt( float number )
{
long i;
float x2, y;
const float threehalfs = 1.5F;
x2 = number * 0.5F;
y = number;
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the fuck?
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed
return y;
}
Re: Production algorithm tricks anyone?
#8For scaling view counters on the pages of popular videos Youtube increments the counter by N views with 1/N probability for each actual view. Or so I've been told.
I've seen similar approaches used to enforce rate limit checks on APIs that get lots of traffic and are distributed amongst many different servers.
Re: Production algorithm tricks anyone?
#9For scaling view counters on the pages of popular videos Youtube increments the counter by N views with 1/N probability for each actual view. Or so I've been told.
This is really neat. You need to take only 1/N of the locks. Maybe the N can be started small and changed gradually as the views increase.
Re: Production algorithm tricks anyone?
#10>"we had used a random number generator within a segmented number range." Could you describe your current implementation and its elegance?
Ad 1 has to be shown 30% of the traffic Ad 2 has to be shown 40% of the traffic Remaining has to be given to RTB generate a random number between 0:100 if the number is 0-30 the Ad 1 has to be shown if the number is 30-70 the Ad 1 has to be shown else RTB is to be called The servers can be now independent and no need to share the state, or have a lock based counter. For large number of requests, and with a good rando…
Not to be a hater, but that seems like by far the most obvious way to do that, right?