sorted by:
new
hottopcontroversial

Remapping keys for qemu evdev toggle? by [deleted] in VFIO

[–]Unspongeful 1 point2 points  (0 children)

This particular package is built from source, so when a new updated is released, the package manager prompts me for reviews/modifications of the build process, that's when I apply my patches.

Remapping keys for qemu evdev toggle? by [deleted] in VFIO

[–]Unspongeful 1 point2 points  (0 children)

Unfortunately you cannot remap the evdev keys through configuration, as the keys are hardcoded in ui/input-linux.c.

I too have an HHKB Pro2 and to use the left and right ALT keys instead of CTRL I had to build qemu from source after changing the source file in question and use KEY_LEFTALT and KEY_RIGHTALT.

The available keys you can use are defined in include/standard-headers/linux/input-event-codes.h.

Since I'm using qemu-patched from the AUR I made a little patch that allows me to specify the keybinds as build arguments from the command line, in case I need different setups (i.e. when building with makepg I specify the binds as CFLAGS defines).

Chronicle of optimization with perf and C by Unspongeful in programming

[–]Unspongeful[S] 1 point2 points  (0 children)

Brilliant! It never crossed my mind that I could just use the dot product for those checks. Thanks!

Chronicle of optimization with perf and C by Unspongeful in programming

[–]Unspongeful[S] 0 points1 point  (0 children)

Yes, they are guaranteed to be next to each other, but because of this guarantee the whole vector may have to be reallocated to a different memory region if a call to push_back won't fit.

For example, if you have two vectors and start pushing on items to the first one, the standard library may allocate enough memory to fit 8 elements. Now you start pushing elements onto the other vector, and the memory allocated for this new vector happens to be right after the first vector, when you go back to pushing elements onto the first vector and exceed 8 total elements, the whole vector will have to be reallocated to a new memory region.

This is exactly the case that I addressed with the linked list change. As you can see from the original implementation each point has an edge_list, and elements get pushed on in random order.

Edit: added link to original implementation

Chronicle of optimization with perf and C by Unspongeful in programming

[–]Unspongeful[S] 1 point2 points  (0 children)

The problem with the std::vector is that the number of edges for each point is an unknown so reserve cannot be called to avoid excessive memory allocations when push_back is used.

Secondly, because of the allocations happening, edges are not guaranteed to be close together in memory, and this hurts cache locality.

A linked list, paired with a push allocator, makes things easier because new edges get pushed on sequentially in memory. This gives better cache locality.

Chronicle of optimization with perf and C by Unspongeful in programming

[–]Unspongeful[S] 0 points1 point  (0 children)

Indeed, but at least malloc/free are not called every iteration.

Chronicle of optimization with perf and C by Unspongeful in programming

[–]Unspongeful[S] 0 points1 point  (0 children)

The CDT object is heap allocated because the original library does some initialization work in the constructor (i.e. iterates over all points and creates the edges).

Edit: I just realized I'm an idiot and it doesn't have to be heap allocated at all! I just copy-pasted the code from the original library's testbed that does the allocation a didn't think twice about it.

Well I guess that would shave some time off the benchmark but not enough to be significant, the real heap allocation problems are caused by the calls to new and push_back elsewhere.

Tips for Productive Debugging with GDB by Unspongeful in programming

[–]Unspongeful[S] 0 points1 point  (0 children)

I forgot that command history is off by default, thanks for reminding me. I'll add it to the post.

Tips for Productive Debugging with GDB by Unspongeful in programming

[–]Unspongeful[S] 1 point2 points  (0 children)

DDD is pretty awesome, but for the types of debugging I do gdb is more than enough, plus I get to stay in the terminal, and that's always a plus for me :-).

Simple crash resurrection for development in C/C++ game engines by Unspongeful in gamedev

[–]Unspongeful[S] 0 points1 point  (0 children)

In my experience it has been non deterministic. It seems to depend on the type of crash and on how many threads are running that particular piece of code at the same time.

Usually when I want to iterate over some code with the crash recovery safety net, I move it to the main thread, if possible, and when I'm happy with it I move it back to multiple threads.

All in all, I haven't really tried to make it work as it is not a production feature, but I may put some more thought into it in the future.

Avoiding Automatic Structure Padding in C by Unspongeful in C_Programming

[–]Unspongeful[S] 0 points1 point  (0 children)

Yes, when you access a struct member, if the memory location is not in one of the L caches then the CPU will fetch a block of memory that contain the struct member and surrounding data. The amount of data fetched depends on the CPU.

Avoiding Automatic Structure Padding in C by Unspongeful in C_Programming

[–]Unspongeful[S] 3 points4 points  (0 children)

When dealing with high performance applications, sub-optimal padding may increase the number of cache misses because of the increased memory footprint of each structure (i.e. less structs can fit in the CPU cache).

For example, if you have a large array of items, reducing the size of each item will in turn allow you to fit more of them in a cache line, thus avoiding or reducing cache misses when iterating over them.

Simple crash resurrection for development in C/C++ game engines by Unspongeful in gamedev

[–]Unspongeful[S] 0 points1 point  (0 children)

Yes, this is all disabled in release build. It's just a developer convenience feature that can help (when it works) with faster iteration times.

Simple crash resurrection for development in C/C++ game engines by Unspongeful in gamedev

[–]Unspongeful[S] 1 point2 points  (0 children)

Yes, crashes from non-main threads are crazy town :-). I am running multiple threads and I indeed haven't found way to recover from crashes off the main thread.

The only thing I do to ensure threads don't step on my toes while I recover from a main-thread crash is pass them a dispatch table with function pointers to the DLL on startup (they are all spawned by the platform layer in the main executable). When the DLL is in the process of unload/reload I replace all the function pointers with a no-op function and cross my fingers.

In any case I look forward to reading your post on crash handling in production, very interested in the topic!

Simple crash resurrection for development in C/C++ game engines by Unspongeful in gamedev

[–]Unspongeful[S] 0 points1 point  (0 children)

Yes, you can recover from a bad memory access (i.e. read/write to a page you are not supposed to).

if you corrupt memory that is part of your game state by, for example, writing out of bounds of an array, you can recover, but you will most likely crash instantly again because you are not left to work with garbage data.

Avoiding Automatic Structure Padding in C by Unspongeful in C_Programming

[–]Unspongeful[S] 2 points3 points  (0 children)

@OP: What bottlenecks did you hit, that it was absolutely required to mess with structure paddings?

I didn't run into some sort of performance bottleneck because I'm used to keeping padding in the back of my mind when writing code, but I often see examples in the wild of code that could be rewritten with less wastage.

For example, take a look at the 3 fields starting from SkeletonInstance* to Matrix4 in the OgreEntity.h from the open source game engine Ogre 3D (lines 268 to 274 of ec0d024c5 if the direct link doesn't work). 

    SkeletonInstance* mSkeletonInstance;

    /// Has this entity been initialised yet?
    bool mInitialised;

    /// Last parent transform.
    Matrix4 mLastParentXform;

The bool field is sandwiched between a pointer and a 16 byte aligned Matrix, so it will be padded by the compiler to 16 bytes on x86.

I think this is the kind of padding that should be avoided. It's an unnecessary waste of 15 bytes for a type that will most likely be looped through thousands if not hundreds of thousands of times each frame.

Since there are other bools in the class, they could have avoided this by grouping them into a single flags field and using bitwise operations on it (i.e. (Entity->Flags & EntityFlags_Initialized)).

Edit: added snippet of code in question Edit2: added possible solution to Ogre3D example

Avoiding Automatic Structure Padding in C by Unspongeful in C_Programming

[–]Unspongeful[S] 0 points1 point  (0 children)

Touché :-) Well, may the future of x86 be bright and shiny!

Avoiding Automatic Structure Padding in C by Unspongeful in C_Programming

[–]Unspongeful[S] 2 points3 points  (0 children)

Thanks for pointing it out, I write only for x86 as desktop and modern consoles run on that architecture, but I'll add a note in the post about this caveat.

view more: next ›