Raptor Launching Talos II Lite POWER9 Computer System At A Lower Cost

[davide445]

Ok I can answer by myself, Talos II board can't support Nvlink lacking the needed specific hardware (and I suppose also being more cost competitive in this way).
Being so I need to say this will put the bare performance out of the equation to justify the price tag.
Without counting the platform openness (an interesting positioning, but there are countless R&D departments not using Power architecture) the remaining differentiator is the software stack, in my case PowerAI Vision working only on power hardware.
Will test more to understand if really make the difference.

[davide445]

I know it's an old thread but the only one I discovered on the topic.
Being testing PowerAI Vision for my work, I was also considering a Business Case for the purchase of a Talos II hardware.
What I didn't get (apart the open source nature I'm not considering) is the advantage vs a x86 hardware.
As example cant understood if a Talos II Lite board support Nvlink with the GPU or not.

[coder]

Interesting case, although bottom-mounted PSU would require long cables:

http://www.lian-li.com/pc-v3000/

[chithanh]

it should have 5 PCIe slots(2 x16 slots, 1 x8 slot and 2 x4 slots).

A similar thing is possible, but it was not within the constraints that madscientist159 mentioned (same mobo as the Talos II, but with some components left out).

For example, IBM Power System S922 in Single-Socket POWER9 configuration offers onboard SAS and:

• PCIe slots with single processor:
  • One x16 Gen4 low-profile, half-length slot (CAPI)
  • One x8 Gen4 low-profile, half-length slot (with x16 connector) (CAPI)
  • Two x8 Gen3 low-profile, half-length slots (with x16 connectors)
  • Two x8 Gen3 low-profile, half-length slots (one of these slots is used for the required base LAN adapter)

In addition, for this server a PCIe Gen3 NVMe carrier card with two M.2 sockets is available (but I understand installing it disables one PCIe x8 slot).

Such a configuration would have avoided the PCIe weakness that makes Talos II Lite non-viable to me, but at the same time probably would have increased cost.

[starshipeleven]

I wish there was a Power9 system with a standard ATX mobo, liquid cooler, and also I do not need a SAS controller(I just need SATA, and NVMe), also lets get rid of the RS232 ports and add more USB ports, it should have 5 PCIe slots(2 x16 slots, 1 x8 slot and 2 x4 slots).

So... you want a Power9 equivalent of x86 motherboards. You aren't alone in this.

Note that SAS controllers are the only reliable type of controller to add more Sata ports if your chipset does not provide enough (or at all). Because SAS controllers also run Sata drives fine, and are so much more reliable than crappy Marvell or Asmedia chipsets you find in pcie sata controllers.

[mzs.112000]

I wish there was a Power9 system with a standard ATX mobo, liquid cooler, and also I do not need a SAS controller(I just need SATA, and NVMe), also lets get rid of the RS232 ports and add more USB ports, it should have 5 PCIe slots(2 x16 slots, 1 x8 slot and 2 x4 slots).

[coder]

I use malloc(1) only because malloc(0) might return NULL, but malloc(1) will return a non-NULL pointer as long as enough memory is available. Also initializing the memory isn't necessary as I never dereference the pointer. I just cast the pointer to a smaller type.

Agreed that it doesn't matter for your program, but I needed it for mine. Actually, needn't even have been on the heap.

Anyway, to put it succinctly:

bool le = (*(uint8_t *) foo32 == (uint8_t) *foo32);

Or, what I say in English:

less-significant byets at lower addresses.

Some people will say it doesn't matter, but I think this just has an undeniable elegance and simplicity to it.

The real question is: how much code is there that has such dependencies on LE? I'm pretty sure most open source developers never test their stuff on BE, so I don't trust it.

[chithanh]

I use malloc(1) only because malloc(0) might return NULL, but malloc(1) will return a non-NULL pointer as long as enough memory is available. Also initializing the memory isn't necessary as I never dereference the pointer. I just cast the pointer to a smaller type.

[coder]

No, I'm talking about casting pointers - not values. Also, you didn't malloc enough and didn't initialize the memory.

Fixed:

Ok, so you say that the following C code:

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

int main() {
void *foo = malloc(4);
uint32_t *foo32 = (uint32_t *) foo;
uint8_t *foo8 = (uint8_t *) foo32;
*foo32 = 0x01234567;
printf("0x%02x\n", (int) *foo8);
}

Will produce different output depending on the endianness of the host system? I don't have a BE system to check right now, will maybe try later.

Yes, I'm saying LE will print 0x67 and BE will print 0x01.

The important point is to go from foo32 to foo8. This way, a compiler could decide to offset the pointer for you. Not saying it will, but it would at least have enough information to do so. Anyway, whether it would was my question, but everything I've seen points to "no".

[chithanh]

my limited web research clearly suggests that the effect of pointer casting will change, based on endianness.

Ok, so you say that the following C code:

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

int main() {
        void *foo = malloc(1);
        uint32_t bar = (uint32_t) foo;
        uint32_t baz = (uint32_t)(uint64_t) foo;
        printf("%s\n", bar == baz ? "true" : "false");
}

Will produce different output depending on the endianness of the host system? I don't have a BE system to check right now, will maybe try later.