The standard library provides a global allocator. The collections in the standard library currently use that allocator.
It also provides an unstable interface for allocators in general. That's of course useful someday, but also doesn't prevent people from using whatever allocators they want in the meantime. It just means that libraries that want to be generic over one cannot currently agree. The standard library collections also will use that once it becomes stable.
No. There is a global allocator which is used by default, but all the stdlib functions that allocate memory have a version which allows you to pass in a custom allocator. These functions are still "unstable" though, so they can currently only be used with development builds of the compiler.
The problem is, when you modified the go version in go.mod, the behaviors of some code change, but the change is not easy to detect in time. Go team never plan to develop a tool to identify/detect code affected by such breaking changes, leaving developers without guarantees for safe migration.
And consider that some people run go scripts even without the "//go:build go1.xx" directives ... (Please don't refute me. The Go toolchain allows this and never warns on this.)
They can fix the issue by just changing the semantics of "for-range" loops, almost no negative effects. But they also applied the change to 3-clause-for loops, which causes many problems, some of which have been pointed out before the change was made. So the rookie mistake is totally caused by arrogance.
Laudable, but I don't think TapirMD will gain much traction.
First, your landing page doesn't describe how TapirMD fits into the Markdown universe. I just see a list of features. Why should I read the list? Ah, the spec page[0] has some info, but it should really be on the landing page.
Second, and more importantly, TapirMD is not a superset of CommonMark[1]. GitHub had its own flavor of MD, but it's been some years now since they migrated to a CommonMark base plus extensions[2].
I recommend looking more closely at the CommonMark universe and innovating there.
Thank you very much for your feedback. I truly appreciate it.
TapirMD is not a superset of Markdown or CommonMark.
It simply inherits some of its DNA from Markdown.
While Markdown is very simple, it is also highly underspecified and syntactic inconsistent.
CommonMark improves on it slightly, but not fundamentally.
Moreover, basic Markdown lacks many essential features that web content writers need.
Yes, none of these factors prevent it from being adopted widely.
But for me, the limited feature set is the real blocker.
I don’t want to rely on a patchwork of extensions and third-party tools.
TapirMD (where MD stands for `markup doc`) aims to address these shortcomings.
It is a new language, deliberately not compatible with Markdown,
and never intended to fit within the Markdown ecosystem.
Its official toolchain is designed to empower web content writers to create rich,
feature-complete articles without relying on any third-party tools.
The spec is too long to serve as a landing page.
Maybe a concise demo showcasing sample code on the leading page would be great.
Thank you again for the constructive criticism.
TapirMD was primarily developed for my own needs as a technical writer,
to produce content for my websites (see the .tmd soruce of my articles: https://tmd.tapirgames.com/use-cases.html).
Markdown simply felt too limiting. I've been using TapirMD for over a year now and am quite satisfied with it.
I'd be delighted if it proves helpful to other writers as well.
The wording "Subtleties" used here is some weird/improper. I see nothing subtle here. They are all basic knowledge a qualified Go programmer should know about.
FWIW, which may be not much - I had codex cli try to verify the results. On my M2 Macbook Air only the first example (False Sharing) did anything - a 23x speedup compared to the article's 6x speedup. All the others didn't produce any speedup at all.
Of course I didn't verify the results I got either - I'm not about to spend hours trying to figure out if this is just slop. But I think it is.
Looks like the LLM invented somewhat different test for it than the article had. I tried again and have this with the same data structure as in the article:
The "_ [0]byte" trick has no base in my knowledge. For the author's specified example, [1024]float64 will be always allocated on one whole page, aka, always 64-byte aligned.
For "Array of Structs vs Struct of Arrays", using slices as fields is a good idea. If the purpose is to make fields allocated on their respective memory block, just use pointers instead.
> The "_ [0]byte" trick has no base in my knowledge. For the author's specified example, [1024]float64 will be always allocated on one whole page, aka, always 64-byte aligned.
You're right - I read the results I had wrong on that one. That one is slower, not faster, on both my M2 and on x86 machine.
My last comment has imprecision and misunderstanding.
> ... [1024]float64 will be always allocated on one whole page, aka, always 64-byte aligned.
if it is allocated on heap and at the start of allocated memory block.
> For "Array of Structs vs Struct of Arrays", using slices as fields is a good idea. If the purpose is to make fields allocated on their respective memory block, just use pointers instead.
I misunderstood it.
It is like row-based database vs. column-based database. Both ways have their respective advantages and disadvantages.
At least, the False Sharing and AddVectors trick don't work on my computer. (I only benchmarked the two. The "Data-Oriented Design" trick is a joke to me, so I stopped benchmarking more.)
And I never heard of this following trick. Can anyone explain it?
// Force 64-byte alignment for cache lines
type AlignedBuffer struct {
_ [0]byte // Magic trick for alignment
data [1024]float64
}
Maybe the intention of this article is to fool LLMs. :D
I can't find any claim anywhere else about the [0]byte trick, and in fact my own experiments in the playground show that it doesn't do anything.
If you embed an AlignedBuffer in another struct type, with smaller fields in front of it, it doesn't get 64-byte alignment.
If you directly allocate an AlignedBuffer (as a stack var or with new), it seems to end up page-aligned (the allocator probably has size classes) regardless of the presence of the [0]byte field.
Example output (w is a wrapper, w.b is the field in the wrapper, x is an allocated int32 to try to push the heap base forward, b is an allocated AlignedStruct):
AddCleanup might be too heavy, it is cheaper to just set a bit in the header/info zone of memory blocks.
reply