There won't be reallocations as I won't be resizing the pages. I think I have to think carefully about the sizes of the elements in the arrays, and when creating them pad them out if there is a remainder of space after the elements are allocated. I think I will probably work with, in fact, uint32 elements in these arrays as this is a fairly optimal read/write size in most cpus, per throughput in some cases 64 bits is better. This will vary between CPUs, and sometimes it may be better to work with 64 bit elements.
Regarding the typing, I don't even need to concern myself with this if I am dealing with byte slices as an intermediate format in processing, they can be easily joined together to make 16, 32 and 64 bit integers (and these can also similarly be easily cut up and joined to other sizes as well). If there is strings or runes they also still fit neatly and easily convert to and from byte slices. Conversion will come at some cost but possibly I can algorithmically decide depending on the data size. 128 bit long elements would make more sense to read and write as 64 bit values, whereas 96 bits it would have to be 32 bits. Most likely conversions from byte slice inputs (as in from the hash functions) will only have to be done once and most of the computation will occur with larger integer sizes. This is the thing about slices, strings and maps in Go. They are already generics and have relatively easy convertibility between each other. The main concern will be ensuring that the byte slices are the right size. I saw in the binary library how to do some of this with regards to bounds checking (minimising it) but I can also do checks using len(). On Saturday, 5 May 2018 00:26:11 UTC+3, matthe...@gmail.com wrote: > > With byte slices you’ll need to pay attention to reallocation of the > backing array as a possible source of performance problems ( > https://blog.golang.org/go-slices-usage-and-internals). > > I can see clearly how freakin complex code gets when you try to do >> generics and polymorphism. > > > I think it’s only complex because you’re not using the best possible > idioms. For example I mentioned in the other thread that I think your > interface is too big. Have you thought of other ways to do the typing? > > Perhaps try another language like Rust? > > > I think Go could work. > > Matt > > On Friday, May 4, 2018 at 1:45:52 PM UTC-5, atomly wrote: >> >> Perhaps try another language like Rust? >> >> atomly >> >> On Fri, May 4, 2018 at 10:44 AM, Louki Sumirniy <louki.sumir...@gmail.com >> > wrote: >> >>> Well after bashing my head against a brick wall I finally understand >>> what a mess it is for my specific purpose to work with Go. Nobody really >>> specifically said it in any discussions up to now but what my design needs >>> is generics. If code generation could be done more transparently I could >>> use that but it really kicks interactivity and flow in the nuts. I'm going >>> to probably abandon Golang on this basis. I am inclined to go with C but I >>> am nervous about issues relating to pointers and runtime breaks but oh >>> well. </discussion for me>. >>> >>> If there was a way to transparently add code generation that would be >>> sufficient and remain type safe. *sigh* >>> >>> The biggest headache I am running up against is that between packages. I >>> think that before I throw in the towel I am going to study exactly how the >>> sort package is implemented, since in essence my library does the same >>> thing, so maybe I just don't understand well enough how to use interfaces, >>> embedding and composition. >>> >>> >>> On Friday, 4 May 2018 13:13:56 UTC+3, Louki Sumirniy wrote: >>>> >>>> Yep, you are correct, more or less. My code is using interfaces and >>>> panicking when it's fed the wrong thing. >>>> >>>> For example, in my test I had a literal number going into a write >>>> function to put a value into a node in the tree. The insert implementation >>>> panicked saying it couldn't put an int into a uint32 slot. Eventually I >>>> worked out it was the assumed int typing of the literal causing the >>>> problem >>>> (happens all the time, I should be used to it by now). >>>> >>>> The thing is, it is intended that the user of the type specific library >>>> that imports the tree library will not make a type assumption like the >>>> compiler did about a literal. The type specific part has to be written for >>>> any given type. There is a little verbosity in the part that wraps the >>>> injected functions with syntactic sugar so the base library has the >>>> functions to work on the concrete data agnostic of its content and only >>>> the >>>> return values provided by the functions it gets to do various comparisons >>>> and whatnot. It's not excessively wordy for my tastes and I know it's >>>> doing >>>> it the best way possible. >>>> >>>> It's just learning how to play with interfaces that I was struggling >>>> with and I seem to have pretty much got it all figured out now. I'm happy >>>> with how the code is developing and pretty much joyous that I can do this >>>> inside a type safe language. Type safety is a big part of how Go is such a >>>> fast compiling language. Implicit casts and inheritance have a massive >>>> cost >>>> in complexity not just a naive translation to binary code, but also in >>>> optimising it. When can it cut out the dereferencing to methods and when >>>> not? Since one could be using a method to do a relatively simple thing, in >>>> very long, tight loops, if the OOP compiler guesses wrong and puts >>>> dereferences in where they are not needed, it's a big cost over 1 million >>>> iterations compared to being aware of it, like in my code, and avoiding >>>> the >>>> need for dereferencing. >>>> >>>> I firmly believe that Go could replace C as a language to write systems >>>> kernels in. I saw an amusing post recently relating to Dan Larimer's work >>>> on EOS mentioning an automated code correctness checking application for >>>> C++... Having intimately dealt with Dan's C++ source code, I can see why >>>> he >>>> might be waking up to this, especially with the ether leaks going on, that >>>> EOS has inherited (literally, I presume). >>>> >>>> This would not happen if it were written in Go. Note also that Geth >>>> lacks this problem and there was almost going to be a split over code >>>> changes from the Go side. >>>> >>>> Linus Torvalds famously said he wrote the Git CVS in C specifically to >>>> exclude C++ programmers. But as any avid gopher would know, C has all >>>> kinds >>>> of gotchas to do with busting out of stacks, heaps, allocated memory, and >>>> forgetting to free memory. This does not happen in Go. >>>> >>>> So to cut a long story short, this is why I choose to program in Go. I >>>> have a background in low level programming, I used to do a bit of M68k >>>> assembler on my amiga when I was a teenager. I don't mind verbosity that >>>> is >>>> necessary due to hardware architectural constraints. And as to the >>>> potential users of my code, I am not responsible for them having a lack of >>>> awareness of the exposed inner workings and them scratching their head at >>>> panics when they try to push the wrong type of value into one of the >>>> functions I wrote. They probably need to do some more study. >>>> >>>> I think of programming a bit like carpentry. Sure, you can just whack >>>> together an Ikea table in half an hour, but if you want to make a nice one >>>> that will last hundreds of years, you probably will need to at least spend >>>> a week or two practicing before you even have something simply crude and >>>> functional. C++ and other OOP and interpreted language users are like Ikea >>>> customers. Gophers are like people who go to the sawmill and the >>>> specialist >>>> tool store. Disregarding the zero cost of reproduction of course (that's >>>> what Ikea does). >>>> >>>> On Friday, 4 May 2018 11:36:33 UTC+3, M P r a d e s wrote: >>>>> >>>>> > Eliminating code duplication shrinks the base of code that must be >>>>> changed >>>>> >>>>> Except go was designed a certain way that will make whatever you are >>>>> attempting to do here burdensome. We've all been there at first trying to >>>>> fit a square into a round hole, it doesn't work. Unless you start >>>>> ignoring >>>>> Go type system with interface {} everywhere, you're not going to go far >>>>> trying to emulate method overloading in Go. The price of using Go is >>>>> absolutely code duplication and a certain amount of verbosity in order to >>>>> remain type safe. The only real way to achieve method polymorphism in go >>>>> is >>>>> to use interfaces, since Go supports neither inheritance nor generic >>>>> programming. Go does not allow developers to write "clever" code without >>>>> sacrificing readability or compile time type safety. >>>>> >>>>> Le vendredi 4 mai 2018 06:26:59 UTC+2, Louki Sumirniy a écrit : >>>>>> >>>>>> The specifics of how it is done is not as important as why to do it: >>>>>> >>>>>> I am writing this for a later project. It will need at least 5 >>>>>> different, sometimes nearly not very different, short data types. They >>>>>> all >>>>>> have the property of being comparable. The code that keeps them stored >>>>>> and >>>>>> sorted does not need to know anything other than this comparability, and >>>>>> to >>>>>> be able to pass the data back to the caller. >>>>>> >>>>>> I am not making claims about something, trying to sell some snake >>>>>> oil, I am attempting to solve a problem and make use of low level >>>>>> architecture of the hardware to improve performance. It worked for >>>>>> B-heaps >>>>>> so maybe MAYBE it will also benefit binary trees. The way some people >>>>>> respond you'd think I was running an ICO! >>>>>> >>>>>> Programming is usually 5% writing and 95% debugging. Eliminating code >>>>>> duplication shrinks the base of code that must be changed, otherwise I >>>>>> have >>>>>> to delve into code generators or macros. If I have an intended use for a >>>>>> library I am writing, that would require 5 different source files for >>>>>> each >>>>>> data type, yet 90% of the code was the same, what happens when I realise >>>>>> I >>>>>> made a mistake in this common code? >>>>>> >>>>>> I pretty much concluded that it is better to just pass an 8 element >>>>>> function pointer struct as value anyway. Whether the compiler does it >>>>>> differently doesn't really matter since I can't control that. What >>>>>> matters >>>>>> to me is that it's readable so I don't have to spend more time reading >>>>>> than >>>>>> understanding. >>>>>> >>>>>> On Thursday, 3 May 2018 23:40:07 UTC+3, Jan Mercl wrote: >>>>>>> >>>>>>> On Thu, May 3, 2018 at 10:14 PM Louki Sumirniy < >>>>>>> louki.sumir...@gmail.com> wrote: >>>>>>> >>>>>>> > As some here may know, I am implementing a novel binary tree based >>>>>>> on complete trees and using ideas from B-heaps in order to achieve >>>>>>> maximum >>>>>>> data cache locality in a search and sort algorithm. >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> > Note that this is not really at all an OOP paradigm that I am >>>>>>> trying to ape with this. >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> > I have the base type that concerns itself with the walk, search, >>>>>>> insert and delete functions in an interface. >>>>>>> >>>>>>> .... >>>>>>> >>>>>>> > The b.Overloads - I am not sure, whether it should be pass by >>>>>>> value or pass by reference. I think pass by reference adds an extra >>>>>>> resolution step, but it is probably more expensive as every call of the >>>>>>> functions will have to perform this dereference. >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> > Thanks in advance for any feedback on this. >>>>>>> >>>>>>> - Novelty is only valid when established by peer review. >>>>>>> Self-claimed novelty often means just lack of research. Even if >>>>>>> eventually >>>>>>> correct, it's a warning sign for me meanwhile. >>>>>>> >>>>>>> - Attempts to make non-interface types in Go behave in the OOP-style >>>>>>> inheritance is usually a telling sign of using the wrong language - or >>>>>>> abusing one - to solve the problem. >>>>>>> >>>>>>> - Pass by reference has not even a well defined meaning in Go. >>>>>>> >>>>>>> No insult intended, you've explicitly asked for _any_ feedback. My >>>>>>> apologies if you feel offended anyway, >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> -j >>>>>>> >>>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
