pervognsen

// Estimating CPU frequency...
// CPU frequency: 4.52 GHz
// sum1: value = 15182118497126522709, 0.31 secs, 5.14 cycles/elem
// sum2: value = 15182118497126522709, 0.17 secs, 2.93 cycles/elem

#define RW(x) asm("" : "+r"(x))

typedef struct Node {
	u64 value;
	struct Node *next;

Fraktality

local Dumpster = {} do
	Dumpster.__index = Dumpster

	local finalizers = setmetatable(
		{
			["function"] = function(item)
				return item()
			end,
			["Instance"] = game.Destroy,
			["RBXScriptConnection"] = Instance.new("BindableEvent").Event:Connect(function() end).Disconnect,

rygorous

why doesn't radfft support AVX on PC?

So there's two separate issues here: using instructions added in AVX and using 256-bit wide vectors. The former turns out to be much easier than the latter for our use case.

Problem number 1 was that you positively need to put AVX code in a separate file with different compiler settings (/arch:AVX for VC++, -mavx for GCC/Clang) that make all SSE code emitted also use VEX encoding, and at the time radfft was written there was no way in CDep to set compiler flags for just one file, just for the overall build.

[There's the GCC "target" annotations on individual funcs, which in principle fix this, but I ran into nasty problems with this for several compiler versions, and VC++ has no equivalent, so we're not currently using that and just sticking with different compilation units.]

The other issue is to do with CPU power management.

vurtun

Gilbert–Johnson–Keerthi (GJK) 3D distance algorithm

The Gilbert–Johnson–Keerthi (GJK) distance algorithm is a method of determining the minimum distance between two convex sets. The algorithm's stability, speed which operates in near-constant time, and small storage footprint make it popular for realtime collision detection.

Unlike many other distance algorithms, it has no requirments on geometry data to be stored in any specific format, but instead relies solely on a support function to iteratively generate closer simplices to the correct answer using the Minkowski sum (CSO) of two convex shapes.

sebbbi

Setup:
1. Index buffer containing N quads (each 2 triangles), where N is the max amount of spheres. Repeating pattern of {0,1,2,1,3,2} + K*4.
2. No vertex buffer.

Render N*2 triangles, where N is the number of spheres you have.

Vertex shader:
1. Sphere index = N/4 (N = SV_VertexId)
2. Quad coord: Q = float2(N%2, (N%4)/2) * 2.0 - 1.0
3. Transform sphere center -> pos

vurtun

zeux

// g++ -O3 -o uniquevalues uniquevalues.cpp  -std=c++11 -Wall -Wextra -DNDEBUG
// results for N = 10000000:
// distinct_count_stdhash(values,N)  :  1340.096 cycles per operation (best) 1340.096 cycles per operation (avg)
// distinct_count_goodhash(values,N) :  137.917 cycles per operation (best)   137.917 cycles per operation (avg)
// distinct_count_sort(values,N)     :  258.619 cycles per operation (best)   258.619 cycles per operation (avg)

#include <iostream>
#include <algorithm>
#include <unordered_set>
#include <vector>

bkaradzic

Notes on header files

After over 20 years working with C/C++ I finally got clear idea how header files need to be organized. Most of the projects in C++ world simply dump everything in .h file, and most of my C++ code was organized this way. Lately I started to separate function declaration from implementation as it was done in C. Now .h headers are exclusevely intended for function and class declaration with doxygen documentation style comments. Inline implementation of functions, class method implementation, etc. goes into .inl headers or .cpp files.

For example .h file would contain only declaration and doxygen style documentation comment:

	/// Convert size in bytes to human readable string.
	void prettify(char* _out, int32_t _max, uint64_t _value)

Fraktality

local LerpCIELUV do

	-- Combines two colors in CIELUV space.
	-- function<function<Color3 result>(float t)>(Color3 fromColor, Color3 toColor)

	-- https://www.w3.org/Graphics/Color/srgb
	
	local clamp = math.clamp
	local C3 = Color3.new
	local black = C3(0, 0, 0)

zeux

// This file is designed to be included in D3D9-dependent code instead of d3d9.h, while adding minimal amount of junk
#pragma once
 
#include <BaseTyps.h>
#include <BaseTsd.h>
 
// stdlib.h
#ifndef _INC_STDLIB
#define _INC_STDLIB
#endif