ejolson
Posts: 1884
Joined: Tue Mar 18, 2014 11:47 am

Re: .NET Core - Raspbian or Win10IoT?

Mon May 21, 2018 11:54 pm

Heater wrote:
Mon May 21, 2018 10:00 pm
No.
Were your timings performed with a Raspberry Pi and if so what kind?

Changing the inner loop to read

Code: Select all

        for (int hw=0;hw<SIZE*SIZE;hw++){
            if(hw==SIZE*SIZE/3)
                a[hw] = ((a[hw] * 42)  + next()) % 100000;
            else next();
        }
avoids most of the memory accesses while preserving the computation of the one value needed for the answer. I'll call the modified code change1 and the original code heater. The results on a Raspberry Pi 3B+ for the modified code are

Code: Select all

$ gcc -O3 -mcpu=cortex-a7 -o change1 change1.c
$ time ./change1 
Seed: 938247, 23097423, 52309875, 297340234
Result: 28247

real    3m15.617s
user    3m14.890s
sys 0m0.640s
which compares to the results of the original code given by

Code: Select all

$ gcc -O3 -mcpu=cortex-a7 -o heater heater.c
$ time ./heater 
Seed: 938247, 23097423, 52309875, 297340234
Result: 28247

real    3m34.791s
user    3m33.995s
sys 0m0.580s
These timings indicate that only about 10 percent of the runtime for the original code is related to memory access of the array (plus the multiply by 42 and remainder after division by 100000). Thus, the benchmark is mostly reporting the speed of a particular random number generator.

Note that the original version of the random number generator does not define the state as volatile. Since the pseudorandom number generator performs a real calculation, any optimisation that still produces the correct sequence of numbers is fine. In particular, turning off optimisation by declaring the state volatile may not be what the original authors had in mind when they wrote "It has excellent (sub-ns) speed, a state size (128 bits) that is large enough for mild parallelism."

jahboater
Posts: 2911
Joined: Wed Feb 04, 2015 6:38 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 6:44 am

FYI, some more about these new (2018) generators in:-

http://xoshiro.di.unimi.it/

Heater
Posts: 9822
Joined: Tue Jul 17, 2012 3:02 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 9:12 am

jahboater,

Take a trivial hello.c program to show the small overhead:-

OK. The regular "Hello World" program:
$ cat hello.c
#include <stdio.h>

int main (int argc, char* argv[])
{
printf("Hello world!\n");
return(0);
}
I build it as C and C++:

Code: Select all

$ cp hello.c hello.cpp
$ gcc -Os -o hello_c hello.c
$ g++ -Os -o hello_cpp hello.cpp
$ ls -l hello_*
-rwxrwxrwx 1 me me 8600 May 22 01:55 hello_c
-rwxrwxrwx 1 me me 8608 May 22 01:55 hello_cpp
Oh look, the C++ version is 8 bytes bigger. But wait:

Code: Select all

$ strip hello_*
$ ls -l hello_*
-rwxrwxrwx 1 me me 6312 May 22 01:58 hello_c
-rwxrwxrwx 1 me me 6312 May 22 01:58 hello_cpp
That's better. Both the same.

What about those libraries then ?

Code: Select all

$ ldd hello_c
        linux-vdso.so.1 =>  (0x00007fffd9f28000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5a25780000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5a25c00000)
$ ldd hello_cpp
        linux-vdso.so.1 =>  (0x00007fffe7065000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc29b810000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc29bc00000)
Exactly the same.

If you look at the generated code with "objdump -d" you will find they are instruction for instruction the same.

There is no overhead in compiling C code with C++.

Unless there is something wrong with your compiler :)

jahboater
Posts: 2911
Joined: Wed Feb 04, 2015 6:38 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 9:38 am

Heater wrote:
Tue May 22, 2018 9:12 am
Unless there is something wrong with your compiler :)
Perhaps its different compiler versions (or how they were configured). What do gcc/g++ -v say?
Maybe recent standards (C++20?) require extra libraries.

Code: Select all

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --enable-languages=c,c++ --enable-checking=no
Thread model: posix
gcc version 8.1.0 (GCC) 
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --enable-languages=c,c++ --enable-checking=no
Thread model: posix
gcc version 8.1.0 (GCC) 
$ 
The huge number of instructions needed to execute the cpp version of hello world was in part due to loading the extra libraries (strace). Those extra libraries probably account for the size increase too.
As you say the five insns are the same (they both convert printf to puts).
I have no idea why g++ loads libm.

Code: Select all

$ gcc -Os -o hello_c hello.c
$ g++ -Os -o hello_cpp hello.cpp
$ ls -l hello_*
-rwxr-xr-x 1 jah jah 6312 May 22 10:27 hello_c
-rwxr-xr-x 1 jah jah 6512 May 22 10:28 hello_cpp
$ size hello_*
   text    data     bss     dec     hex filename
   1114     544       8    1666     682 hello_c
   1267     592       8    1867     74b hello_cpp
$ strip hello_*
$ ls -l hello_*
-rwxr-xr-x 1 jah jah 4192 May 22 10:29 hello_c
-rwxr-xr-x 1 jah jah 4384 May 22 10:29 hello_cpp
$ ldd hello_*
hello_c:
  linux-vdso.so.1 =>  (0x00007ffe64dfe000)
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdd61c78000)
  /lib64/ld-linux-x86-64.so.2 (0x000055744c552000)
hello_cpp:
  linux-vdso.so.1 =>  (0x00007ffca7129000)
  libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4089959000)
  libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4089650000)
  libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f408943a000)
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f408906f000)
  /lib64/ld-linux-x86-64.so.2 (0x000056161e995000)
$
BTW, "ls" is usually not good at showing small size differences in executables - "size" is better.

Heater
Posts: 9822
Joined: Tue Jul 17, 2012 3:02 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 11:27 am

ejolson,

My timings are made on PC running Ubuntu 16.04.4. When I have a moment I'll dig out a Pi 3 and time it there.

Changing the inner loop as you have done defeats the point of having the huge array. Which I intended to demonstrate the effects of not being cache friendly. It changes the intent of the program entirely.

Just for you I have reverted the state to not being volatile. As per the original xoshiro128** PRNG. But as I said earlier this is not about the code being a PRNG. I just used that as a stand in for some code one might have.

Also I intend that the steps are applied to all elements of the array so I added a final step of adding up all the elements.

Here is my new benchmark:

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <limits.h>

#define SIZE  10000
#define ITERS 100
/*
  This is xoshiro128** 1.0, our 32-bit all-purpose, rock-solid generator. It
  has excellent (sub-ns) speed, a state size (128 bits) that is large
  enough for mild parallelism, and it passes all tests we are aware of.

  For generating just single-precision (i.e., 32-bit) floating-point
  numbers, xoshiro128+ is even faster.

  The state must be seeded so that it is not everywhere zero.
*/

static inline uint32_t rotl(const uint32_t x, int k) {
    return (x << k) | (x >> (32 - k));
}

static uint32_t s[4] = {938247, 23097423, 52309875, 297340234};

uint32_t next(void) {
    const uint32_t result_starstar = rotl(s[0] * 5, 7) * 9;
    const uint32_t t = s[1] << 9;

    s[2] ^= s[0];
    s[3] ^= s[1];
    s[1] ^= s[2];
    s[0] ^= s[3];

    s[2] ^= t;

    s[3] = rotl(s[3], 11);

    return result_starstar;
}

int main(int argc, char* argv[])
{
    int (*a)[SIZE];
    a = (int (*)[SIZE])calloc(SIZE * SIZE, sizeof(int));

    printf("Seed: %d, %d, %d, %d\n", s[0], s[1], s[2], s[3]);

    for (int iters = 0; iters < ITERS; iters++)
    {
        // Multiply every elemnt by 42
        for (int h = 0; h < SIZE; h++)
        {
            for (int w = 0; w < SIZE; w++)
            {
                int *element = &a[h][w];
                *element = ((*element * 42) + next()) % 100000;
            }
        }
    }

    int sum = 0;
    for (int h = 0; h < SIZE; h++)
    {
        for (int w = 0; w < SIZE; w++)
        {
             sum += a[h][w];
        }
    }
    // Print the sum of all elements
    printf("Result = %d (expect 809823336)\n", sum);
}
I run it like so:

Code: Select all

$ g++ -Wall -O3 -o junk junk.cpp
$ time ./junk
Seed: 938247, 23097423, 52309875, 297340234
Result = 809823336 (expect 809823336)

real    0m23.189s
user    0m22.813s
sys     0m0.359s

$ em++ -s ALLOW_MEMORY_GROWTH=1 -o junk.js -O3 junk.cpp
$ time node junk.js
Seed: 938247, 23097423, 52309875, 297340234
Result = 809823336 (expect 809823336)

real    0m48.262s
user    0m47.625s
sys     0m0.516s
[/code]
These timings indicate that only about 10 percent of the runtime for the original code is related to memory access of the array (plus the multiply by 42 and remainder after division by 100000). Thus, the benchmark is mostly reporting the speed of a particular random number generator.
Err, no. "Those" timings are for running your version which is a totally different program.

If I swap the order of array traversal in there, use a[w][h] instead of a[h][w], this is what happens:

Code: Select all

$ time ./junk
Seed: 938247, 23097423, 52309875, 297340234
Result = 809823336 (expect 809823336)

real    1m19.376s
user    1m18.938s
sys     0m0.438s
Almost three times slower because we broke cache friendliness. That indicates that pretty much all run time of the program is related to memory access!

You do have a point though. If the PRNG was really slow it would mask the effect of memory access order.

Heater
Posts: 9822
Joined: Tue Jul 17, 2012 3:02 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 11:32 am

jahboater,
Perhaps its different compiler versions (or how they were configured). What do gcc/g++ -v say?
Maybe recent standards (C++20?) require extra libraries.
I have gcc version 5.4.0 20160609 here.

I have never seen g++ compile C code to anything different to gcc.

Although sometimes it will refuse to compile C code as it is a bit more fussy about types.

I'm curious to know why your compiler is so borked. I presume you are on Raspbian. I have to dig out a Pi and try it for myself.

jahboater
Posts: 2911
Joined: Wed Feb 04, 2015 6:38 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 12:10 pm

Heater wrote:
Tue May 22, 2018 11:32 am
I have gcc version 5.4.0 20160609 here.
Well 5.4 is a long way different from 8.1. The new compiler supports a lot of later standards, such as full support for C++17 and C17, also experimental support for C++20 etc - things may have changed.
I have never seen g++ compile C code to anything different to gcc.
It is the same code, identical, just g++ includes extra libraries now.
I'm curious to know why your compiler is so borked. I presume you are on Raspbian. I have to dig out a Pi and try it for myself.
On the Pi3+ Raspbian I get similar results.

Code: Select all

$ size hello_*
   text	   data	    bss	    dec	    hex	filename
    805	    280	      4	   1089	    441	hello_c
   1035	    304	      4	   1343	    53f	hello_cpp
[email protected]$ ldd hello_*
hello_c:
	linux-vdso.so.1 (0x7ef25000)
	/usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f11000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76dd2000)
	/lib/ld-linux-armhf.so.3 (0x76f27000)
hello_cpp:
	linux-vdso.so.1 (0x7ee28000)
	/usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f2f000)
	libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76de7000)
	libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76d68000)
	libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76d3b000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76bfc000)
	/lib/ld-linux-armhf.so.3 (0x76f45000)
$ 
I do not think my compiler is "borked" - just three generations later :)

jahboater
Posts: 2911
Joined: Wed Feb 04, 2015 6:38 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 1:38 pm

Heater,

Incidentally, it looks like V8 Javascript engine is the latest version.
When comparing JS against C perhaps you should use a similar recent version of the C compiler (gcc 8) to be fair? (Thats apart from declaring key variables volatile :) :) )

Heater
Posts: 9822
Joined: Tue Jul 17, 2012 3:02 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 1:57 pm

Interesting. gcc 6.3.0 on a Debian Stretch PC does the same:

Code: Select all

$ g++ -Wall -O3 -o junk_cpp junk.cpp
$ gcc -Wall -O3 -o junk_c junk.c
$ size junk_*
   text    data     bss     dec     hex filename
   2471     624       8    3103     c1f junk_c
   2510     672       8    3190     c76 junk_cpp
And it pulls in libstc++ and libm.

On the other hand we can do this:

Code: Select all

$ gcc -Wall -O3 -o junk_cpp junk.cpp
$ gcc -Wall -O3 -o junk_c junk.c
$ size junk_*
   text    data     bss     dec     hex filename
   2471     624       8    3103     c1f junk_c
   2471     624       8    3103     c1f junk_cpp
Which is the same size and does not pull in the C++ libs.

And yes, it is actually compiling both as C++. I put a little class in there to be sure it's not using C.

jahboater
Posts: 2911
Joined: Wed Feb 04, 2015 6:38 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 2:48 pm

Thats bizarre!!!

Heater
Posts: 9822
Joined: Tue Jul 17, 2012 3:02 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 3:07 pm

jahboater,
When comparing JS against C perhaps you should use a similar recent version of the C compiler (gcc 8) to be fair?
Good idea. I don't have an OS with anything later than 6.3.0 installed so that is not going to happen for a while. I inclined to believe it won't make much difference.

Who is to say I can't have volatile there? As I said at least twice now the fact that I have used a PRNG in there is beside the point. It's just an example of some code. Besides, as a source of random numbers I may well want to have the seed changing, perhaps updated by an interrupt handler that is reading from a real random source. In which case volatile is appropriate.

Heater
Posts: 9822
Joined: Tue Jul 17, 2012 3:02 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 3:10 pm

jahboater,
That's bizarre!!!
It's certainly confusing. Something changed to cause the extra libs to be pulled in, even when they are not used.

jahboater
Posts: 2911
Joined: Wed Feb 04, 2015 6:38 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 3:23 pm

Heater wrote:
Tue May 22, 2018 3:07 pm
Who is to say I can't have volatile there?
Nothing - as long as you use something exactly equivalent in the JS version.
Otherwise the two programs are doing something different and no comparison can be drawn.

jahboater
Posts: 2911
Joined: Wed Feb 04, 2015 6:38 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 3:31 pm

Heater wrote:
Tue May 22, 2018 3:07 pm
jahboater,
When comparing JS against C perhaps you should use a similar recent version of the C compiler (gcc 8) to be fair?
Good idea. I don't have an OS with anything later than 6.3.0 installed so that is not going to happen for a while. I inclined to believe it won't make much difference.
Not on x86/x64 perhaps as code generation for that platform is very mature. ARM is different, early versions of the GCC on ARM produced poor code which got rapidly better. I think its flattened out now as GCC 8 doesn't seem any better than GCC 7 on the Pi (but is better in other respects). I am using C18!!

This script works to install GCC. On a Pi3 or Pi3+ you should just be able to run it with no changes. It will download and build gcc 8.1.0. If the build works, it can install it for you. You need 6GB or so of free disk space and an afternoon for the build to run.
viewtopic.php?f=33&t=212636

Heater
Posts: 9822
Joined: Tue Jul 17, 2012 3:02 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 3:37 pm

jahboater,
Nothing - as long as you use something exactly equivalent in the JS version.
Otherwise the two programs are doing something different and no comparison can be drawn.
The JS version is compiled (or transpiled) from the same C++ source. I can't make it any more equivalent than that.

ejolson
Posts: 1884
Joined: Tue Mar 18, 2014 11:47 am

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 3:46 pm

Heater wrote:
Tue May 22, 2018 3:07 pm
jahboater,
When comparing JS against C perhaps you should use a similar recent version of the C compiler (gcc 8) to be fair?
Who is to say I can't have volatile there? As I said at least twice now the fact that I have used a PRNG in there is beside the point. It's just an example of some code. Besides, as a source of random numbers I may well want to have the seed changing, perhaps updated by an interrupt handler that is reading from a real random source. In which case volatile is appropriate.
The idea of modifying the pseudorandom number generator state using an interrupt while in the middle of executing a call to next() is a race condition that volatile doesn't solve. It only makes sense to reset the state between calls. As far as I can tell, the only effect of volatile in this code is to disable optimisations--an odd thing to do in a benchmark.

jahboater
Posts: 2911
Joined: Wed Feb 04, 2015 6:38 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 4:31 pm

ejolson wrote:
Tue May 22, 2018 3:46 pm
As far as I can tell, the only effect of volatile in this code is to disable optimizations--an odd thing to do in a benchmark.
Especially as it would affect only one of the two languages being compared.

Benchmark comparisons of two languages are very difficult. Fairness means using a strict common subset of the features provided by each language. That usually means a small simple program which is then not representative of real workloads.

Heater
Posts: 9822
Joined: Tue Jul 17, 2012 3:02 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 6:15 pm

ejolson,
The idea of modifying the pseudorandom number generator state using an interrupt while in the middle of executing a call to next() is a race condition....
You might have to elaborate on that, because I don't see any race condition.

The PRNG is mashing around a bunch of random looking bits. If my interupt, or more likely other thread, updates one of those seed values with some actual random bits occasionally, where is the race condition?

Is there some reason that I am not aware of that doing so would make the output less random than I expect?

I guess if I wanted to update all the seed values together, atomically, then I would need to take extra measures. Like disabling interrupts while next() runs, wrapping it in a mutex or implementing some complex lock-free but atomic update mechanism. Wrapping a mutex or some lock around it would kill performance.
...that volatile doesn't solve.
The "volatile" is not there to solve any race condition problem.

Consider: Potentially all the variables, including the seed, in that little program could be held in processor registers. If our CPU had enough regs and the optimizer was smart enough. In which case it would never see updates to the seed values planted in memory by some interrupt handler or other thread. The volatile ensures that it would see such updates.
It only makes sense to reset the state between calls.
Not necessarily. See above.
As far as I can tell, the only effect of volatile in this code is to disable optimisations--an odd thing to do in a benchmark.
See above.

Anyway, it does not matter. By popular request the "volatile" has been removed.

Heater
Posts: 9822
Joined: Tue Jul 17, 2012 3:02 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 6:33 pm

jahboater,
Benchmark comparisons of two languages are very difficult. Fairness means using a strict common subset of the features provided by each language. That usually means a small simple program which is then not representative of real workloads.
Yes, it's an interesting problem.

How about a no holds barred approach? Here is a ton of input data, this is how it should be transformed, do it in your language of choice by whatever means possible to make it fast.

Of course, for example, the guy implementing a Fast Fourier Transform in Python is going to beat the guy doing naive Fourier transform in C, above a certain input data set size.

But I think we can allow them to learn techniques from each other.

A few years back I had a C++ process collecting data from multiple socket connections in XML format, transforming and filtering that data and then passing on through other socket connections.

On a lark I reimplemented it in Javascript running under node.js. The code obvioulsy looked totally different. I was amazed to find the JS version was not much slower than the C++. All that XML parsing takes it's toll no mater what. The clincher was that the JS code was much smaller and simpler, much easier to extend and maintain.

jahboater
Posts: 2911
Joined: Wed Feb 04, 2015 6:38 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 6:52 pm

Heater wrote:
Tue May 22, 2018 6:33 pm
How about a no holds barred approach? Here is a ton of input data, this is how it should be transformed, do it in your language of choice by whatever means possible to make it fast.
I like that. The constant then is the "problem" not the program.
So implement your FFT in JS or C or Python using all the power and features of each language - completely disregarding the the fact that the other languages may have nothing comparable - thats their loss.
Then compare the speed.
Probably the best kind of inter-language benchmark.

Your example was probably limited by the network speed :)

Heater
Posts: 9822
Joined: Tue Jul 17, 2012 3:02 pm

Re: .NET Core - Raspbian or Win10IoT?

Tue May 22, 2018 7:09 pm

jahboater,
Your example was probably limited by the network speed.
I had a good look at that particular problem. It was not network limited. All that XML parsing takes a ridiculous lot of CPU cycles. Of course it sucks network bandwidth as well, what with being so verbose.

Of course both the C++ and JS versions were using some library to parse the XML. libxml if I recall correctly. So we end up with most of the actual work, socket connections, XML parsing, etc, being done in C anyway. Whatever overhead JS had as it managed all that was not much greater than the C++ version.

pauliunas
Posts: 41
Joined: Mon Feb 26, 2018 7:43 am

Re: .NET Core - Raspbian or Win10IoT?

Wed May 23, 2018 6:49 pm

I didn't expect this to escalate so far :D :D
but if you guys love comparing speeds so much, who wants to compare Raspbian vs. Win10IoT with .NET for me? :D
Still can't find time to do it myself, not before my exams.

Heater
Posts: 9822
Joined: Tue Jul 17, 2012 3:02 pm

Re: .NET Core - Raspbian or Win10IoT?

Wed May 23, 2018 7:22 pm

pauliunas,
I didn't expect this to escalate so far...
That's what we do. Gotta push things as far as they will go...
...but if you guys love comparing speeds so much,...
Not so much. I'd rather have ease of development. Performance demands, in terms of speed and power/memory consumption, etc, is an annoying thing we are forced to think about quite often.
...who wants to compare Raspbian vs. Win10IoT with .NET for me?
Sorry not me. Until such time as MS open sources their OS and decouples it from Windows and Azure it is of no use to me.

I imagine C# apps are the same slow as they are on Linux :)

pauliunas
Posts: 41
Joined: Mon Feb 26, 2018 7:43 am

Re: .NET Core - Raspbian or Win10IoT?

Wed May 23, 2018 7:35 pm

Heater wrote:
Wed May 23, 2018 7:22 pm
pauliunas,
I didn't expect this to escalate so far...
That's what we do. Gotta push things as far as they will go...
...but if you guys love comparing speeds so much,...
Not so much. I'd rather have ease of development. Performance demands, in terms of speed and power/memory consumption, etc, is an annoying thing we are forced to think about quite often.
...who wants to compare Raspbian vs. Win10IoT with .NET for me?
Sorry not me. Until such time as MS open sources their OS and decouples it from Windows and Azure it is of no use to me.

I imagine C# apps are the same slow as they are on Linux :)
Nah they're not really slow :) I just probably messed up with optimization settings, because I don't know anything about them. Anyway, just how likely would it be for you to waste your time digging around the spaghetti of Windows source code if it ever were released publicly? Dunno about you, but I wouldn't want to even approach it lol. Just like any other big spaghetti software. If it works it works, there's no need to have the source code for that :)

jahboater
Posts: 2911
Joined: Wed Feb 04, 2015 6:38 pm

Re: .NET Core - Raspbian or Win10IoT?

Wed May 23, 2018 7:38 pm

pauliunas wrote:
Wed May 23, 2018 6:49 pm
but if you guys love comparing speeds so much,
Make it work, then make it fast ...

Return to “Other programming languages”

Who is online

Users browsing this forum: No registered users and 1 guest