5 added 20 characters in body
source | link

A lot of the predominant focus I find in my field, at least, is throughput with a focus on optimizing bulky algorithms over homogeneous data. Much seems to be forgotten about keeping things highly responsive for all the disparate (or simply small) tasks in between. I like how Mike put it, that the constants here tend to be just as important as algorithmic complexity.

One way to optimize for latency in this kind of perspective (possibly flawed) is to recognize that homogeneity and even contiguous memory layouts (and therefore often locality of reference) are often broken by disparate data types. From a machine level, data actually takes on a uniform and homogeneous data of bits and bytes (albeit with alignment requirements that vary based on the type of registers and instructions being used). The stack can store a wild mixture of data types for this reason, as it's modeled at the bits and bytes level rather than the notion of a homogeneous container of elements (and one way to improve latency is to utilize the hell out of it). Understanding this can help you reach down to the custom memory allocator level and start preallocating more disparate types of data in bulk, pooling from a common memory pool to provide requested memory chunks for lots of disparate data types.

In this sense, we're still kind of applying those bulky data-oriented design mindsets, but flattening away the disparity by reaching towards the lower-level, common denominator notion of bits and bytes in memory instead of "data type" (a meta concept which is often obliterated for the most part anyway at runtime). With that kind of adjustment, the idea of the more throughput-focused techniques and latency-focused techniques start to blur more and more together, since we're reducing the disparity in representation that can lead to hiccups in performance.

A lot of the predominant focus I find in my field, at least, is throughput with a focus on optimizing bulky algorithms over homogeneous data. Much seems to be forgotten about keeping things highly responsive for all the disparate tasks in between. I like how Mike put it, that the constants here tend to be just as important as algorithmic complexity.

One way to optimize for latency in this kind of perspective (possibly flawed) is to recognize that homogeneity and even contiguous memory layouts (and therefore often locality of reference) are often broken by disparate data types. From a machine level, data actually takes on a uniform and homogeneous data of bits and bytes (albeit with alignment requirements that vary based on the type of registers and instructions being used). The stack can store a wild mixture of data types for this reason, as it's modeled at the bits and bytes level rather than the notion of a homogeneous container of elements. Understanding this can help you reach down to the custom memory allocator level and start preallocating more disparate types of data in bulk, pooling from a common memory pool to provide requested memory chunks for lots of disparate data types.

In this sense, we're still kind of applying those bulky data-oriented design mindsets, but flattening away the disparity by reaching towards the lower-level notion of bits and bytes in memory instead of "data type" (a meta concept which is often obliterated for the most part anyway at runtime). With that kind of adjustment, the idea of the more throughput-focused techniques and latency-focused techniques start to blur more and more together, since we're reducing the disparity in representation that can lead to hiccups in performance.

A lot of the predominant focus I find in my field, at least, is throughput with a focus on optimizing bulky algorithms over homogeneous data. Much seems to be forgotten about keeping things highly responsive for all the disparate (or simply small) tasks in between. I like how Mike put it, that the constants here tend to be just as important as algorithmic complexity.

One way to optimize for latency in this kind of perspective (possibly flawed) is to recognize that homogeneity and even contiguous memory layouts (and therefore often locality of reference) are often broken by disparate data types. From a machine level, data actually takes on a uniform and homogeneous data of bits and bytes (albeit with alignment requirements that vary based on the type of registers and instructions being used). The stack can store a wild mixture of data types for this reason, as it's modeled at the bits and bytes level rather than the notion of a homogeneous container of elements (and one way to improve latency is to utilize the hell out of it). Understanding this can help you reach down to the custom memory allocator level and start preallocating more disparate types of data in bulk, pooling from a common memory pool to provide requested memory chunks for lots of disparate data types.

In this sense, we're still kind of applying those bulky data-oriented design mindsets, but flattening away the disparity by reaching towards the lower-level, common denominator notion of bits and bytes in memory instead of "data type" (a meta concept which is often obliterated for the most part anyway at runtime). With that kind of adjustment, the idea of the more throughput-focused techniques and latency-focused techniques start to blur more and more together, since we're reducing the disparity in representation that can lead to hiccups in performance.

4 added 45 characters in body
source | link

With a predominant focus on low-latency programming, probably K&R's C Programming Language is a bit basic and out-of-date. I still have fondness for that book but it's more of a piece of history now. Perhaps more useful would be to study more of those real-time fields like audio processing, game engines, data-oriented design, and embedded system programming, as well as simply newer books on the C language.

With a predominant focus on low-latency programming, probably K&R's C Programming Language is a bit basic and out-of-date. I still have fondness for that book but it's more of a piece of history now. Perhaps more useful would be to study more of those real-time fields like audio processing, game engines, data-oriented design, and embedded system programming.

With a predominant focus on low-latency programming, probably K&R's C Programming Language is a bit basic and out-of-date. I still have fondness for that book but it's more of a piece of history now. Perhaps more useful would be to study more of those real-time fields like audio processing, game engines, data-oriented design, embedded system programming, as well as simply newer books on the C language.

3 added 44 characters in body
source | link

One way to optimize for latency in this kind of perspective (possibly flawed) is to recognize that homogeneity and even contiguous memory layouts (and therefore often locality of reference) are often broken by disparate data types. From a machine level, data actually takes on a uniform and homogeneous data of bits and bytes (albeit with alignment requirements that vary based on the type of registers and instructions being used). The stack can store a wild mixture of data types for this reason, as it's modeled at the bits and bytes level rather than the notion of a homogeneous container of elements. Understanding this can help you reach down to the custom memory allocator level and start preallocating more disparate types of data in bulk, pooling from a common memory pool to provide requested memory chunks for lots of disparate data types.

In this sense, we're still kind of applying those bulky data-oriented design mindsets, but flattening away the disparity by reaching towards the lower-level notion of bits and bytes in memory instead of "data type" (a meta concept which is often obliterated for the most part anyway at runtime). With that kind of adjustment, the idea of the more throughput-focused techniques and latency-focused techniques start to blur more and more together, since we're reducing the disparity in representation that can lead to hiccups in performance.

One way to optimize for latency in this kind of perspective (possibly flawed) is to recognize that homogeneity and even contiguous memory layouts are often broken by disparate data types. From a machine level, data actually takes on a uniform and homogeneous data of bits and bytes (albeit with alignment requirements that vary based on the type of registers and instructions being used). The stack can store a wild mixture of data types for this reason, as it's modeled at the bits and bytes level rather than the notion of a homogeneous container of elements. Understanding this can help you reach down to the custom memory allocator level and start preallocating more disparate types of data in bulk, pooling from a common memory pool to provide requested memory chunks for lots of disparate data types.

In this sense, we're still kind of applying those bulky data-oriented design mindsets, but flattening away the disparity by reaching towards the lower-level notion of bits and bytes in memory instead of "data type" (a meta concept which is often obliterated for the most part anyway at runtime). With that kind of adjustment, the idea of the more throughput-focused techniques and latency-focused techniques start to blur more and more together.

One way to optimize for latency in this kind of perspective (possibly flawed) is to recognize that homogeneity and even contiguous memory layouts (and therefore often locality of reference) are often broken by disparate data types. From a machine level, data actually takes on a uniform and homogeneous data of bits and bytes (albeit with alignment requirements that vary based on the type of registers and instructions being used). The stack can store a wild mixture of data types for this reason, as it's modeled at the bits and bytes level rather than the notion of a homogeneous container of elements. Understanding this can help you reach down to the custom memory allocator level and start preallocating more disparate types of data in bulk, pooling from a common memory pool to provide requested memory chunks for lots of disparate data types.

In this sense, we're still kind of applying those bulky data-oriented design mindsets, but flattening away the disparity by reaching towards the lower-level notion of bits and bytes in memory instead of "data type" (a meta concept which is often obliterated for the most part anyway at runtime). With that kind of adjustment, the idea of the more throughput-focused techniques and latency-focused techniques start to blur more and more together, since we're reducing the disparity in representation that can lead to hiccups in performance.

2 added 160 characters in body
source | link
1
source | link