Hi,
Can you publish the C++ test program as well ? I have the ROOT installed
and would like to explore the issue further.
-mura
On Wednesday, October 18, 2017 at 6:21:17 PM UTC+8, mura wrote:
>
> Could you use `perf record ./test f64s.root` and then `perf report
> --stdio` for both t
between C++ and Go too.
:D
-mura
On Tuesday, October 17, 2017 at 6:48:43 PM UTC+8, Sebastien Binet wrote:
>
> hi,
>
> (thanks for having a look at this)
>
> On Tue, Oct 17, 2017 at 6:01 AM, mura >
> wrote:
>
>> Hi,
>>
>> A sequential read with `dd if=f64s.
probably does some kind of caching
or preloading.
-mura
On Monday, October 16, 2017 at 11:53:56 PM UTC+8, Sebastien Binet wrote:
>
> hi there,
>
> I have this Go program that reads a binary file format coming from CERN.
> I am trying to get it running almost as fast as its C
Just thought about maybe this could be used to generate the C header and
source files for C binding.
Currently we have to write a hybrid language called cgo for FFI. It's not
always the best approach.
I'd like to have a C header that can be included to implement a 'driver'
for the Go runtime an
A ANSI-C (probably with GNU extension if helpful) transpiler/backend would
be much more useful than a C++ one.
C is far more widespread and easier to integrate. C *and* C++ projects can
both integrate C source. But C projects cannot integrate C++ source.
The users who want to build the gc compi
I don't know the answer but if I were you, I would start from looking at
Windows applications written in Go and see how they have done.
For instance, the package https://github.com/lxn/walk has implemented lots
of Windows GUI stuff. It would probably provide the information you are
looking for.
nction
whenever possible.
Hopefully there are other places that can be speeded up without messing up
the code.
On Sunday, August 28, 2016 at 12:43:23 AM UTC+8, mura wrote:
>
> Hi gophers,
>
> We have some legacy systems which use 3DES cryptos extensively and we are
> attemp
was written in an unmanaged and non-GC
language.
On Sunday, August 28, 2016 at 12:07:39 PM UTC+8, Sam Whited wrote:
>
> On Sat, Aug 27, 2016 at 11:43 AM, mura >
> wrote:
> > Although the culprit can not be completely singled out yet, the Go pprof
> > tool has show
.
On Sunday, August 28, 2016 at 3:53:46 AM UTC+8, agl wrote:
>
> On Saturday, August 27, 2016 at 9:43:23 AM UTC-7, mura wrote:
>>
>> We have some legacy systems which use 3DES cryptos extensively and we are
>> attempting to re-write some parts of it in Go recently.
>>
Hi gophers,
We have some legacy systems which use 3DES cryptos extensively and we are
attempting to re-write some parts of it in Go recently.
As an initial experiment, we found that the system overall is about 2x~3x
slower than the original C version.
Although the culprit can not be completely s
Does it depend on CGO? I think CGO dependency is the most annoying issue of
existing GUI libraries in Go.
Two suggestions: how about adding some screenshots and a godoc link?
On Saturday, August 27, 2016 at 11:04:27 PM UTC+8, howar...@gmail.com wrote:
>
> I mentioned this on the list a littl
Hi,
Generally speaking, you may find it a bit of struggling if you are trying
to write Go code in an attempt to emulate *how* other languages can do, or
to argue with the compiler about how a fresh learner would come to think in
the first place. A tip for making the learning/adaption process sm
used in the parameter list
> of the func that you call.
>
> Regards,
>
> On Friday, July 1, 2016 at 9:06:30 AM UTC+2, mura wrote:
>>
>> Hi all,
>>
>> I confronted with a confusing problem regarding struct conversion.
>>
>> See https://play.golang.o
replaced
with rsa.PublicKey
According to the spec, two structs are convertible as long as their
underlying types are identical.
Is this case my misunderstanding or just a bug (either in the compiler or
in the spec)?
mura,
Thanks
--
You received this message because you are subscribed to the
14 matches
Mail list logo
