>
> On Tuesday, March 3, 2020 at 11:25:22 PM UTC+1, Robert Engels wrote:
> A key statement in the link “ The JIT-generated code is significantly
> faster than the ahead-of-time-generated code for small matrix sizes.”
>
> Which is what you were arguing was not possible... you can’t have it both
>
On Friday, February 14, 2020 at 6:57:08 PM UTC+1, ⚛ wrote:
>
> On Friday, February 14, 2020 at 6:46:51 PM UTC+1, Robert Engels wrote:
>>
>> Yes, and then the access and iteration is slower as it needs indirection
>> to find the correct page. There is no free lunch.
>&
On Friday, February 14, 2020 at 6:46:51 PM UTC+1, Robert Engels wrote:
>
> Yes, and then the access and iteration is slower as it needs indirection
> to find the correct page. There is no free lunch.
>
> The caveats about using mutable objects, sharing, and concurrency still
> apply.
>
> A virtua
On Friday, February 14, 2020 at 6:24:08 PM UTC+1, Robert Engels wrote:
>
>
> Yes, and when you store value objects in a vector and it is resized, it is
> very expensive as you need to make copies of "large objects", vs a "pointer
> to an object".
>
A paged vector neither copies nor moves the obj
On Friday, February 14, 2020 at 3:43:40 PM UTC+1, Robert Engels wrote:
>
> If each object exists independently - which it does in this case - you
> must use a free on each object. So you are going to loop - it just may be
> hidden from you.
>
I am sorry, I do not understand your style of reasoni
On Friday, February 14, 2020 at 3:32:54 AM UTC+1, robert engels wrote:
>
> You can clearly see that the vast majority of CPU time was consumed by
> allocation and de-allocation.
>
In the case of this particular benchmark, it is pointless to be pointing
out the cost of individual malloc+free call
ain the difference in
our experiences.
>
>
> -Original Message-
> From: Robert Engels
> Sent: Feb 13, 2020 11:33 AM
> To: ⚛ <0xe2.0...@gmail.com >, golang-nuts
> Subject: Re: [go-nuts] Go without garbage collector
>
> I won't dispute that, but at leas
t, etc. I can only assume that std::map was used
> because it made the code easier/portable to write in C++ rather than adding
> an outside dependency or custom hash map. implementation (In the Java code,
> they use a custom IntegerSet, IntegerList to avoid boxing...)
>
> -Orig
On Thursday, February 13, 2020 at 3:05:45 PM UTC+1, Robert Engels wrote:
>
> The code hasn’t been changed. The performance numbers have changed
> dramatically with no developer intervention. No “hand optimizing” required.
>
C++ evolves over time also. Hashmaps have been added to C++ in C++11, whi
On Thursday, February 13, 2020 at 6:59:43 AM UTC+1, robert engels wrote:
>
> Here is some pretty indisputable evidence on the advancements of GC/JVM vs
> C++.
>
> See this paper/project https://github.com/hundt98847/multi-language-bench
> that
> was done by Google in 2011. If you read the paper,
On Wednesday, February 12, 2020 at 12:55:48 AM UTC+1, deat...@gmail.com
wrote:
>
> What about #vlang ? https://vlang.io/
>
If compile-time GC is the only memory management model that exists in V,
then it is impossible to implement in V any program requiring
dynamic/runtime GC such as a Python i
We could discuss what has "gone wrong" in the Go compiler; and how to make
it work at least in theory.
Unfortunately, me not being paid by Google is a line I am both unable and
unwilling to cross.
I feel sorry for not being able to discuss the subject of escape analysis
which by itself is quit
A difference:
- it isn't possible to derive the address of a named variable from the
address of another named variable
- it is possible to derive the value of a named const from another named
const
const (
a = 0 // b-1, c-2
b = 1 // a+1, c-1
c = 2 // a+2, b+1
)
Re
On Saturday, June 18, 2016 at 12:21:21 AM UTC+2, gordo...@gmail.com wrote:
>
> On Friday, June 17, 2016 at 4:48:06 PM UTC+2, gordo...@gmail.com wrote:
> > > I am not on a high end Intel CPU now, but when I was I found that with
> a buffer size adjusted to the L1 cache size (8192 32-bit words or 3
On Saturday, June 18, 2016 at 6:15:11 AM UTC+2, gordo...@gmail.com wrote:
>
> Here is a golang version of Daniel Bernstein's "eratspeed", which is a
> straight translation of his C code to golang without any changes other than
> as necessary to make it work: https://play.golang.org/p/Sd6qlMQcHF.
On Friday, June 17, 2016 at 4:48:06 PM UTC+2, gordo...@gmail.com wrote:
>
> I don't see the point to the exercise as far as optimizing golang is
> concerned.
It is a general rule that using more registers results in faster code.
> Your experiment just shows that Your compiler (GCC?)
My post
On Friday, June 17, 2016 at 3:52:27 PM UTC+2, gordo...@gmail.com wrote:
>
> I don't see the point of the exercise other than it proves that not
> putting the result of an operation back into the same register reduces the
> latency slightly for your processor (whatever it is?); I suspect that if
On Friday, June 17, 2016 at 2:30:12 AM UTC+2, gordo...@gmail.com wrote:
>
> > Modern x86 CPUs don't work like that.
>
> > In general, optimally scheduled assembly code which uses more registers
> has higher performance than optimally scheduled assembly code which uses
> smaller number of registe
On Thursday, June 16, 2016 at 1:06:46 PM UTC+2, Konstantin Khomoutov wrote:
>
> On Thu, 16 Jun 2016 02:12:56 -0700 (PDT)
> gordo...@gmail.com wrote:
>
> [...]
> > The current beta will work not too badly with amd64 code but still
> > doesn't use registers efficiently enough to support x86 code
On Thursday, June 16, 2016 at 11:13:12 AM UTC+2, gordo...@gmail.com wrote:
>
> No real surprises with the no bounds checks option (-B), it just
> eliminated the array bounds checks with the rest of the code the same
> (version 1.7beta1):
>
> 0x00dd 00221 (main.go:37)MOVQD
20 matches
Mail list logo
