According to the C standard:
If the quotient a/b is representable, the
expression (a/b)*b + a%b shall equal a.
In your example, dividing x by -1 would make x +2147483648,
which is not representable in int32_t. May be this is
why -2147483648/-1 also exceptions out?
On Saturday, February 9, 2019 at 9:30:25 AM UTC-8, Isaac Gouy wrote:
> On Tuesday, February 5, 2019 at 3:03:42 AM UTC-8, ohir wrote:
>
>>
>> > Contributors can recreate the same benchmarking routines in C, golang,
>> JS
>>
>> This is how "benchmark game" **entertaining** sites are
On Saturday, February 9, 2019 at 9:20:41 AM UTC-8, Isaac Gouy wrote:
>
>
> On Sunday, February 3, 2019 at 10:44:11 AM UTC-8, Milind Thombre wrote:
>>
>> … a quantitative performance study/Benchmarking study … If a verifiable
>> (unbiased) study is already done and published, I'd greatly
On Sat, 9 Feb 2019 09:30:24 -0800 (PST)
"'Isaac Gouy' via golang-nuts" wrote:
> > *"Look at the history of java samples and benchmark earlier vs current at
> > same task"*
> and conclude what?
That some languages demands very deep intrinsic knowledge to get code
running faster than in its
On Tuesday, February 5, 2019 at 3:03:42 AM UTC-8, ohir wrote:
>
> > Contributors can recreate the same benchmarking routines in C, golang,
> JS
>
> This is how "benchmark game" **entertaining** sites are architectured.
> Their
> "comparisons" are moot for the industry. Look at the history
On Sunday, February 3, 2019 at 10:44:11 AM UTC-8, Milind Thombre wrote:
>
> … a quantitative performance study/Benchmarking study … If a verifiable
> (unbiased) study is already done and published, I'd greatly appreciate it
> if someone can post the link.
>
What do you not find acceptable
On Mon, 4 Feb 2019 00:13:39 +0530
Milind Thombre wrote:
> ask "Exactly how fast is golang vs say Python/JS?" or even C
It depends on domain, metrics and task at hand, but from personal experience
(Go vs C) Go is about four times faster than C at prototyping phase, two times
faster at doing
A general problem with interlanguage benchmarks is that you can only
compare those features that both languages have, so these always reduce to
lowest common denominator and are inherently biased against new features.
So for example, go will get no credit for having a garbage collector,
Thanks. You're right - this is not the way to choose a language. I was just
curious. Go has many, many more things going for it - multi core support,
networking, standard library, community ...
On Sunday, February 3, 2019 at 8:56:28 PM UTC+2, robert engels wrote:
>
> It will also depend on
I will take an experienced architect or city planner with a track record of
success over any ‘isolated numerical comparison’. Comparisons need to be made
in their entirety, and this is a skill set that often cannot be taught, and is
learned via human experience. It is similar to how many AI
Right! Just Listen to what ever the Architect's (or City Planner's) opinion
is, implement it, and we in all certainty have a performant system.
Numerical Evidence is for dummies
Whatever!
On Mon, Feb 4, 2019 at 12:18 AM Robert Engels wrote:
> I’ll state again, it’s because these benchmarks
Suggestion: specify all relevant details as we don’t know what kind of machine
you have.
I suspect your machine is a 64bit word size machine. C ints are typically 4
bytes even on 64bit word size machines. Go ints are 8 bytes on these machines.
Suggestion2: look at the generated assembly
It will also depend on which math library and compiler options you use on the C
side.
I’ll give you a bit of a warning though, if you are making decisions based
solely on tests like this you you might be missing the bigger picture of the
value of systems like Go.
A simple example, even 1.5
Yup. Using int32 in Go reduces the difference to 1.5. Thanks
On Sunday, February 3, 2019 at 8:35:46 PM UTC+2, Robert Engels wrote:
>
> Also the go program is most likely using 64 bit math. Use int32 to compare
> it correctly.
>
> On Feb 3, 2019, at 12:31 PM, Robert Engels > wrote:
>
> Don’t
I’ll state again, it’s because these benchmarks have little to do with the
success of systems. Experienced designers know this. Take, architecture,
barring some large scale dynamics, everyone would build simple boxes. It
doesn’t mean the project will be a commercial success, most likely not.
This is exactly why I asked a day or two ago if there has been a
quantitative performance study/Benchmarking study done, but nobody seems to
have the time to contribute to it. Are we expected to mindlessly adopt
whatever "New" technology is doled out without quantitative proof of its
degree of
Also the go program is most likely using 64 bit math. Use int32 to compare it
correctly.
> On Feb 3, 2019, at 12:31 PM, Robert Engels wrote:
>
> Don’t use rtdsc in the C program use gettimeofday to ensure you are comparing
> the same.
>
>> On Feb 3, 2019, at 12:22 PM, Miki Tebeka wrote:
Don’t use rtdsc in the C program use gettimeofday to ensure you are comparing
the same.
> On Feb 3, 2019, at 12:22 PM, Miki Tebeka wrote:
>
> Hi,
>
> I'm comparing two loops in Go and C. The Go code on my machine is about 3
> times slower than C. I know C can be faster but didn't think
Hi,
I'm comparing two loops in Go and C. The Go code on my machine is about 3
times slower than C. I know C can be faster but didn't think it'll be that
faster. Any ideas what's making the Go code slower?
You can see the code at https://github.com/tebeka/go-c-loop
Go Code:
package main
19 matches
Mail list logo
