NothanUmber ·
Hi,
wouldn't it be nice if one would be able to define truely parallel execution paths in SM? Currently different paths seem to be numbered by these "spots" and then executed in that order. (Surely one can also parallelize those paths, too using heuristics as they are used for databases with transactions or superscalar cpus but there are limits to that approach as there are many cases in which such a heuristic can't decide whether parallel execution can lead to undesired results or not and thus has to execute the paths in a serial manner in order to be sure). Couldn't one just define that all paths are potentially executed in parallel and introduce a pair of synchronization components (both with n inputs and n outputs that are automatically generated like e.g. for the selector but on both sides) that assure that all paths that pass the "sync start" component at the same time will also leave the "sync end" together (results of shorter calculation paths are automatically delayed then in order to achieve the desired behaviour). That way the user would care about synchronization issues and schematics that are written now will be able to take advantage of 16 core processors and super-SSE-28 extensions that may be supported from upcoming SM versions in the future without changing anything. The decision would have to be made soon though, as it would break the way SM is currently working - what doesn't matter too much atm. as there aren't too many schematics out yet and everybody is just playing around while waiting for SM 1.0.
Greetings, NothanUmber