HN user

jessermeyer

460 karma
Posts0
Comments188
View on HN
No posts found.

There are two degrees of separation here though: The software vendors and then the linux distros.

If you sell software that requires your clients to upgrade their system-wide security stack, so they might not. If it is statically linked, no need for them to.

Those are basically contradiction of terms. Orienting the program structure around the data necessarily requires control over memory layout and how it is interpretted.

We almost never hit technical limits in the renderer, streaming systems, etc. Instead, we found that pushing gameplay systems beyond the prototype stage would require more and more effort, as we'd encounter deep engine bugs, or the tooling simply did not cater to our use case.

We ended up implementing more and more tooling outside the engine, and there comes a point where UE4 became a IO/Rendering system. We'd've been happier if the engine were modular in design from the get-go.

I've worked on several. You haven't heard of them because none of them shipped due to issues with commercial engines (in particular Unreal Engine 4).

They are very difficult to use if the game play semantics are complicated and require lots of interaction with world state or world geometry. If you're making a common FPS, they are great.

There is always a minimum cost of moving data from one place to another. If you're computing on the GPU, the data must arrive there. The problem is that PCIE bandwidth is often a bottleneck, and so if you can upload compressed data then you essentially get a free multiplier of bandwidth based on the compression ratio. If the decompression time is faster than having sent the full uncompressed dataset, then you win.

But yeah, direct IO to the GPU would be great but that's not feasible right now.

I carefully chose my word "function" instead of "existence".

Give me two different universes where cognition exists but where the fundamental constants differ. Would you expect the ability to perform syllogism would be fundamentally biased to reflect the constants which brought about their existence?

I think a single employee netting even a single digit percentage in a year's worth of effort in improved performance for all of Google is an astonishing accomplishment. Trivializing a "million dollars per month" improvement just says so much about how little programmers here realize their worth to technology companies, and intellectualize ways to justify it.

Mathematicians I personally know well are stoutly religious. They describe the world of number and form and structure with the same kind of language the clergy describe God, and so there is some sense in which these are felt as aspects of the same thing.

I also know a number of engineers who are deeply religious, perhaps encouraged by recognizing "design" in nature, seemingly requiring a designer.

In my conversations with these people, their faith, while socially speaking is Christian, the specifics have hardly anything to do with traditional or orthodox theology. It's, as I perceive this, the only acceptable social structure available to them to live out these deep feelings of beauty and harmony in community.

Large web companies like Google implement their own encryption stack anyway.

On the BSD's I've used, LibreSSL is a standard kernel configuration option. I'll note on FreeBSD, LibreSSL lacks the in-kernel fast path, last I checked.

This piece accusing Watts of laziness is just as guilty.

`It’s true that Buddhism, and particularly Zen Buddhism, teaches that we are perfect just as we are, we have merely forgotten our true nature.`

As someone who has studied Zen Buddhism for a few decades, you will be very hard pressed to find anyone practiced in it refer to the words 'true' and 'perfect' so casually.

True is only meaningful with respect to an abstract system of rules, and this extends likewise to perfection. You need an external metric to determine what is, and by the same token, is not, perfect.

Zen Buddhism teaches people how to experience the world independent of that part of your mind that is actively categorizing the world into true, false, imperfect, perfect, etc. To experience your own experience of life as directly as possible, without mediation through your linguistic centers or moral philosophies. Since we're programmers, one analogy would be to reduce all those needless abstractions in the call stack down to the essential turing-complete read/write add/sub and jump instructions.

So Alan is forcing an important point on the Yogi. You can only know or define enlightenment with respect to an abstract system of thought. Remove the abstraction, and there is a complete liberation. No meaningful way to form distinctions. "Doesn’t he see the Brahman everywhere, and in all people, all beings". All becomes one. There is no difference between the enlightened and the non-enlightened in the non-conceptual world. Which is the world that Zen teaches how to experience, if for no other reason than to reveal that it is possible, and provide a renewed perspective on the seemingly ordinary miracle of conscious life.

What makes you think culling triangles is going away? Ray tracing is usually done with a highly approximated volume or planar representation of the scene, which is then applied to surface triangles.

Rendering objects that 'we can't see' has been done for as long as shadow caster light sources have been around. Even though we cannot see the mesh directly, the light can, and the viewer can see the shadow. These indirections all play their role in the greater "rendering equation", and the specific solution depends on the constraints of the application and resources of the development team.

Some renderers have abandoned triangles altogether for signed distance fields, but this involves re-creating from scratch the entire art pipeline.

Modern renderers:

Use the GPU to decide what to render, and in a growing number of cases, will cull triangles in compute (software) instead of letting the fixed pipeline do it. The vertex shader feeds parameters to the fragment shader even if the triangle is culled (depth or backfacing), so with vertex counts climbing, there is a lot of dead time spent feeding fragment shaders that are never ran.

Render at a lower resolution and temporally upsample to a higher resolution.

Using low overhead apis that optimize command recording performance (DX12, Vulkan) and transfer / memory access.

Multithread all the things.

Obsess over data locality and compression.

Hi everyone, my group at NASA is looking to hire a US citizen junior programmer government contract to help assist with our mission to map every tree on the planet! If you're a US resident and want to help us tackle exascale compute problems, please submit your resume here: https://workforcenow.adp.com/mascsr/default/mdf/recruitment/...

You can visualize our team's findings here (and help me replace this site with something much cooler) https://trees.pgc.umn.edu/app

Our paper: https://www.nature.com/articles/s41586-020-2824-5

We are seeking someone with low level C/C++ experience.

Compiler, Language, and Software engineer people do not often overlap, and so neither do their constraints. Over time you see opposing drift occurring, where language people end up designing languages nice for language development, software engineers design software nice for software development, and so on..

Consider what is nice for compiler development but is not nice for software engineering.

Thanks. Currently Odin would cache i on the stack for retrieval later, granting LLVM the ability to load it into a register if profitable with knowledge that after the read, `i` is constant, which bypasses the RAW hazard after the initial read.

My view is that undefined behavior is a trash fire and serious effort should be undertaken to fix the situation before it gets even more out of hand.

Thanks. I was thinking of strict-aliasing and the associated undefined behavior, which Odin forbids. Odin's atomic intrinsics model after C11 closely (and require the programmer to emit memory barriers when cache behavior must be controlled by instructions). I believe the final memory model will be platform defined. There is no built-in atomic data type in Odin. Only atomic operations are available, and most sync primitives are implemented in the standard library wrapping OS capabilities (WaitOnAddress), etc.

The parent comment said: >then have a data race, it's functionally equivalent to undefined behavior

This is a matter of interpretation but there is a categorical difference between "this read is undefined so the compiler will silently omit it" and "this read will read whatever value is in the CPU cache at this address, even if the cache is stale". The difference is a matter of undefined behavior from the language versus the application being in an undefined state.

Obviously Odin does not use C's memory model. And in instances where LLVM optimizes Odin for UB, it is a bug, and not a feature. Odin explicitly opts out of all optimization passes that depend or leverage UB, but that's a moving target.

For example, as mentioned in the article, Odin does not leverage LLVM's poison value optimizations, which are derived from optimizations exploiting undefined behavior.

Sure, some code is slowed. But can you point to a well known and well used algorithm whose runtime characteristics depend upon exploiting UB? If you code goes fast because it's doing undefined things the compiler strips away, that's a structural bug in the application, in my view.

I should clarify. I may have mistyped.

Odin allows type inference at the declaration level `foo := 1` for example, and a few other places, largely from the constant system. 1 can be an integer, float, or even a matrix, given the larger context.

What I meant was implicit type conversion. Integers do not automatically cast as booleans in Odin, as an example.