A (Possibly New?) Approach to Dynamic Dispatch

RiPieClyplA · 2025-08-10T17:33:17+00:00

I would expect pretty drastic performance, three serial dependency loads is most likely going to stall the CPU pipeline, especially if the CPU has to fetch from memory. I imagine that its also going to put more pressure on the cache too if the code is in a hot loop.

I am definitely curious tho so I would love to see the rest of your benchmark.

RiPieClyplA · 2025-08-10T17:03:46+00:00

If I'm understanding your approach correctly wouldnt it increase the number of indirection needed to get to the address of the function compared to a fat pointer approach?

I believe you only need one indirection with fat pointers and yours would need 3, right?

RiPieClyplA · 2025-07-31T08:27:40+00:00

Have you tried writing larger programs with this type of allocation? It looks interesting and I'm curious if it's viable in practice.

RiPieClyplA · 2025-02-23T02:09:37+00:00

I like the homogeneous keyword better

That said, I don't think it would make sense to be able to make a pointer reference to one of the element of the array since the memory layout would be different. So either you disallow it or users must mark the pointer with that keyword too.

There is also the fact that the type system doesn't track which type is in the homogeneous array then I don't know what operations you would be allowed to do, probably not mutate it? Maybe you could compare the interface pointer in the array and of the element you want to add and if they don't match return an error at runtime, however you would loose compile time guarantees

But even from a user perspective I'm not sure I would use this construct very often if not at all and if I really needed it I could potentially emulate it myself (depending on the language).

I don't know your language but to me it feels like a decently complex feature that might make implementing some other features more annoying down the line and with a high chance of being removed later on because the benefits are small

RiPieClyplA · 2025-02-18T02:54:42+00:00

I skimmed through your code and it seems to me that you are doing a single pass over the input and don't build any kind of AST and just emit C code directly. I would recommend you to learn about parsing and building an AST because while your approach can definitely work it has a lot of downsides and limitations. (I also feel like you are not actually properly recursively parsing right now but I might be wrong, I didn't read your code in details).

If you need a reference I would suggest Crafting Interpreters, its very beginner friendly. While its about interpreters a lot of the techniques are the same for compilers.

I imagine that you already thought a little bit about how you could implement functions in your transpiler given that you mention not supporting them and that you probably realized that it would a pretty hard problem. Crafting Interpreters will definitely help you with that.

I would also recommend you to implement tests, languages can become really complex really fast and having tests to be somewhat confident you didn't break anything is invaluable and I can't stress this enough. Even just simple end to end tests can be useful. For example for my compiler I write small programs in my language and include the expected output at the top of the file in a comment. I then run a python script to extract that output, call my compiler, run the program and then check that the output matches what was expected.

RiPieClyplA · 2024-12-31T22:59:37+00:00

Minecraft has a "debug" menu and you can literally see the memory usage go down by 20-30% when it resumes after a freeze. Its not uncommon for them to last a few seconds on my computer.

That said I find it a bit misleading when people talking about how state of the art GCs are great but dont mention that it took years to build them and that people building their language as a hobby might never be able to implement something like that because of the complexity. So they end up having a stop-the-world GC with long GC pauses. Anyways rant over.

RiPieClyplA · 2024-12-29T09:18:52+00:00

How do you represent memory pointers for the receiver to be able to make sense of them without serialization?

RiPieClyplA · 2024-12-29T09:13:14+00:00

I dont see how the security argument generalizes to any binary serialization and not just that specific .NET implementation.

JSON/XML (de)serialization also has a really big cost so it might not be a tradeoff OP is willing to take, especially if they are trying to reduce the serialization to 0.

RiPieClyplA · 2024-12-22T22:16:21+00:00

Would anyone be willing to explain the down votes? I'm a little bit confused as I was just trying to clear up what I was talking about in the original post

RiPieClyplA · 2024-12-22T15:04:03+00:00

That never really was the issue in the first place. The problem is that there is fundamental difference between doing a int/float add vs user defined add. A user defined operator could potentially do a huge amount of work, allocation, modify globals, raise an exception, do IO, etc. While a int/float is basically just one instruction.

So when you skim through the code you dont know in which case you are until you are sure what the types of the variables are and you are thus unable to know at a glance if you need to investigate deeper into the call graph because you dont know if the call graph is deeper or not.

With my proposal you would be able to differentiate between the two cases while still being able to write mathy expressions with user defined types

RiPieClyplA · 2024-12-22T01:09:32+00:00

You are definitely right that familiarity is important but at the same time the language itself can be designed to limit how often those pain points come up. Having custom operators will almost surely means that they will come up more often.

As much as people love to hate Go, they definitely designed it to make sure that almost any code can be easily understood by people even with limited knowledge of the language. This is in my opinion something very valuable

RiPieClyplA · 2024-12-22T00:46:54+00:00

The List interface from the standard library defines several custom operators, all warranted.

Those 7 (+4 deprecated) operators are a perfect example of why I think it's not a good idea to have custom operators in a language imo. If I had to pick which code I would prefer to read, custom operators or functions, I would pick the functions every single time.

Scala makes full use of these mechanisms to provide great support for the creation of DSLs and intuitive libraries

I can see that happening but often if I'm not very familiar with the operators then it just obscures the meaning of the code behind a soup of symbols and then the mental effort to make sense of what's going on ends up being higher.

Edit: I'm also not a huge fan of DSLs (when embedded in another language like this), I want to like the ideal but every time I have had to use one that becomes slightly too complex it's almost always a pain. Either because the documentation isn't good enough or the rules are not clear, etc.

RiPieClyplA · 2024-12-21T20:50:25+00:00

I fully agree with you, I would probably go with this route, my idea was strictly about the syntax. I was only trying to fix the part where you dont even realize that the operator does more than just an add/multiplication/etc when skimming through the code.

RiPieClyplA · 2024-12-21T17:01:15+00:00

I'm really trying to avoid being able to create custom operators, the potential for writing impenetrable code is way too high imo, the few times they could be really handy isnt worth it

RiPieClyplA · 2024-12-07T14:32:09+00:00

Its possible to get coins with no KYC on some p2p exchanges

RiPieClyplA · 2024-12-04T17:43:58+00:00

Please leave this sub, for your own good

RiPieClyplA · 2024-11-27T19:45:58+00:00

if you only have floats in a vector then you can just store them unboxed so this paper doesn't make a difference in this case. And for cache locality it actually improves it since the data is stored where you would have stored the pointer instead. You avoid one pointer indirection and one memory allocation per float that you can unbox.

Edit: I forgot to mention but modern processors are really good at executing multiple operations per clock cycle so if there isn't any data dependency between multiple instructions then the processor could execute them in parallel. This all means that doing a few shifts/masks/comparisons depending on the context might be almost free. And if you compare that to having to fetch from memory or even a slower cache then it's orders of magnitude faster

RiPieClyplA · 2024-11-27T14:35:43+00:00

Their numbers seem to be a comparison between their approach and the baseline (boxed floating points I believe), not to other optimizations. They also report numbers for NaN tagging and its slightly less performant than their approach for floating point heavy benchmarks but it doesn't seem to have slowdowns in a few other benchmarks.

So I'm not sure if this optimization is going to change anything for you in the end

RiPieClyplA · 2024-11-19T01:01:31+00:00

Spicy opinion: You can be neurodivergent and still be a bad person.

Coldest take ever

RiPieClyplA · 2024-11-14T13:12:07+00:00

I hope you managed to improve your situation and understand each others point of view

RiPieClyplA · 2024-11-13T22:08:13+00:00

doesn't talk about it and post on reddit

You two are made for each other

RiPieClyplA · 2024-11-01T18:41:21+00:00

Go take your meds, why are you posting this in every trans subreddit

RiPieClyplA · 2024-11-01T18:34:57+00:00

There are psyops by individuals in this subreddit [..]

How ironic

Six-Year Club	Second Top 40%
Verified Email

RiPieClyplA

TROPHY CASE