Hacker Newsnew | past | comments | ask | show | jobs | submit | rswier's commentslogin

> I suspect there is some clever base between 1 and 2 which is trivial to compute

Something like this perhaps (although this might be too much granularity):

  (8 + (cap & 7)) << ((cap >> 3) + 1)

  16 18 20 ... 30
  32 36 40 ... 60
  64 72 80 ... 120
  128 ... etc.


I remember seeing a paper that concluded the expansion should not be more than the golden ratio (ϕ = 1.618033988749). Given how widespread the golden ratio, I'd hypothesise that it's probably optimal.

The first three fractions approximating ϕ are: 3/2, 8/5 and 21/13. The first two are quick and easy to compute.


If the multiplier is less than the golden ratio, then the new allocation fits into the memory released from the previous two allocations.


But most allocators will not actually take advantage of that, so it’s a pretty dubious argument.


Good point, I haven't actually checked if any realloc implementations do that.


I thought, oh, you only need two bits for the multiplier, that gives you four multiples of each tier size, that should be enough.

But that means the largest buffer (with a slightly less sophisticated formula than yours) is ((2 << 2) * 2 << (2 <<(8 - 2) - 1)) = 32 exabytes.

Meanwhile, yours has a maximum of 60 GB. So i don't think you have too much granularity!


Are there any good resources for learning how to render dichroic thin films with multiple internal reflections and refraction indexes? Basically, I would love to render something like this[1] in real time.

[1] https://www.youtube.com/watch?v=BVQ34NlTi-E?mute=1


Look into spectral rendering.

For a very simple form, you can sample a specific wavelength with each ray, trace it using wavelength-dependent refraction indices (e.g., from the Sellmeier equation) whenever you compute refraction or internal reflection. Then tint the ray by the color and visible intensity of the wavelength when averaging it into the image pixel.

For a lot more detail, see e.g., "Efficient Spectral Rendering on the GPU for Predictive Rendering" (https://hal.inria.fr/hal-03331619/document).


A naive spectral path tracer can be less complex (code wise) than a "normal" one. You just trace each photon with its wavelength instead of tracing RGB (or some other full spectrum) per path. Since this abstraction is closer to physics, it makes a lot of code easier to reason about. Wavelength dependent refraction is straightforward, you just use the index of refraction for the photon you are tracing.

I find this code base extremely easy to read despite not being a C++ (It has that Carmackian quality). Pretty easy to use to port to the language of your choice. https://github.com/TomCrypto/Lambda To get the kind of effect you see in the youtube video you'd render diamond or something with extreme refraction.

This is far from real time though of course. It will run an order of magnitude slower than anything you can do with full spectrum rays. So doing it in realtime would probably be just like subsurface scattering is done in real time: you just have to cheat. Perhaps there can be some inspiration from the real thing though.


I'm just an amateur who played around with rendering in various ways, raytraced and rasterized. In order to get the results similar to the video (without hacks), you're gonna need caustics, refraction and reflections, all together with realistic lightning. You're not gonna be able to get that looking nice without a physically accurate render engine, which will most likely be using raytracing. And raytracing (compared to rasterization) is not gonna be able to run anywhere near real-time (more like at least seconds per frame, if you really ramp down the samples [image will be more noisy]).


The March 1931 issue of Television News[1] is a fantastic snapshot in time of the development of Television.

Amazing all those various silly spinning disk systems peppered throughout the magazine...and then buried on page 48 there's Philo T. Farnsworth[2] and his "scanning electric pencil"! Huzzah!

[1] https://worldradiohistory.com/Archive-Television-News/Televi...

[2] https://en.wikipedia.org/wiki/Philo_Farnsworth


Here are the course notes from an AT&T Compiler Construction Course by "Aho, Sethi, et. al."

https://archive.org/details/CompilerConstructionCourse_Dec83


Tiger Innovations | Herndon, VA | Spacecraft Embedded Software, VHDL | Full-time | Onsite

Tiger Innovations is a small high technology company specializing in developing spacecraft and space-related systems for a broad range of US Government customers. We have an immediate need for real-time embedded Software Engineers and Computer Engineers. Created by and for engineers, Tiger Innovations values talent and curiosity over resume buzzword bingo.

If you are interested in working on challenging technical problems in a multi-disciplinary environment (i.e. cool stuff) then take a look at our ad and apply at:

https://www.tigerinnovations.com/careers/index.html


Ah you guys need to use the slogan "every team is a tiger team!" hehehe.


I made a branch of c4 that includes struct support. I should probably add it to the master branch so it gets more visibility: https://github.com/rswier/c4/blob/switch-and-structs/c4.c


c4.c author here - selfie seems to fill a niche between c4 and my other more full featured compiler/os swieros. Very cool!

https://github.com/rswier/swieros/blob/master/00README.txt


Yep, I just meant to point out they're different. Selfie is something educators wrote for their purposes. c4.c is more like a piece of code poetry.


More details on "Primeval" C can be found here: https://www.bell-labs.com/usr/dmr/www/primevalC.html

Just recently, fragments of the earliest Unix OS source code and B interpreter were discovered [0]. Now, the earliest Unix for the PDP-7 and PDP-11 [1] can run under emulation thanks to the incredible efforts of Warren Toomey and others at the Unix Heritage Society [2].

[0] https://github.com/DoctorWkt/pdp7-unix

[1] https://github.com/DoctorWkt/unix-jun72

[2] http://www.tuhs.org


The code appears to be some of the most ancient Unix Kernel Source Code yet found. This is previous to the PDP-11 1st Edition. Still, many of the familiar bits are there (ed, cat, etc..) A pretty historically significant chunk of code!


Warren Toomey from The Unix Heritage Society (TUHS) posts:

http://minnie.tuhs.org/pipermail/tuhs/2016-February/006622.h...

With the link:

http://www.tuhs.org/Archive/PDP-11/Distributions/research/Mc...

From the Readme:

  The structure of the kernel source code is very similar to that of the 1st Edition Unix scan at

  http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v1/PreliminaryUnixImplementationDocument_Jun72.pdf

  Here is what I can glean from the files:

  01-s1.pdf     contains the kernel source divided into sections S1 to S9
  02-hw.pdf     has hardware details of the PDP-7
  03-scope.pdf  has information about the PDP-7 scope
  04-cas.pdf    seems to be a user-mode program that uses the PDP-7 scope
  05-1-4.pdf    user-mode programs: adm, ald, apr, as
  06-5-12.pdf   user-mode programs: bl, bc, bi, cat, check, chown, chmod, cp, chrm
  07-13-19.pdf  user-mode programs: db, dmabs, ds, dsksav, dskres, dskio, dsw, init
  08-rest.pdf   user-mode programs: ed. Also at the beginning some B code (?)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: