- Niuce C++14-feature - 24 Updates
- std::unordered_map<Key,T,Hash,KeyEqual,Allocator>::emplace_hint - 1 Update
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: May 20 07:50PM -0700 On Thursday, May 20, 2021 at 2:26:34 PM UTC-4, Bonita Montero wrote: > You're really stupid ! > That's not what I said. I just said that Germans get the name Christoph > or Christof and not Christopher. Yes, it is what you said. Repeating my citation of your precise words that you trimmed from your response, you said: "... there aint any Christophers in Germany...". |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 05:31AM +0200 >> This is good for nothing. > Keep demonstrating your ignorance, its very amusing :) Parallelism is today done with threads. No one uses fork()ing anymore. |
| MrSpook_dg01t9p2@m0m4iuefk1x.edu: May 21 09:16AM On Thu, 20 May 2021 17:43:40 GMT >> Keep demonstrating your ignorance, its very amusing :) >Do you even know why fork() actually exists? Because back in the day >THREADS weren't a thing. If you want to COPY lots of program state using Threads were a thing back in mainframe days you dick, along with VMs too. >fork() then why the fuck aren't you using threads? Processes are Because in serious applications - ie nothing you write - robustness trumps speed of creation. A single process starts, loads up init then when a user or some other event needs servicing you fire off a seperate process so if that process dies it doesn't take town the whole fucking application. Oracle uses this method for good reason. Some browsers recently switched to a process-per-tab model too. It always amuses me when people who've only ever coded on windows spout a load of crap about things they know nothing about. >heavyweight OS primitives compared to threads. These days fork() and >associated horribleness like Linux's overcommit are an anachronism. Whatever you say Dilbert. https://dilbert.com/strip/1995-06-24 |
| MrSpook_mm9v3kgmmm@7_o9.co.uk: May 21 09:19AM On Thu, 20 May 2021 17:46:27 GMT >> And your source for this is .... >You are the one making the original claim so you provide a source first, >mate. Until then I will rely on common sense and Occam's Razor. If I could have found something showing that bug I'd have posted it already. However the bug existed and frankly I don't give a rats arse what you or the little girl think given both of you were probably still sucking on your mums tit when I was using this compiler. |
| MrSpook_a102e@wnyqsthof.net: May 21 09:22AM On Thu, 20 May 2021 19:23:38 GMT >Linux never implemented that model (although green threads were >close) chosing instead to use a light-weight process (clone) >1:1 model. The original linux threading system was pretty poor, in that it used seperate processes behind the scenes gerry rigged together using shared memory and other types of IPC then presented via the posix thread API as a multi threading model. Which defeated the point of using threads - ie lightweight and quick to create and destroy. IIRC that got binned from kernel 2.6 and real threads were implemented. |
| MrSpook_db0ucj9V@o6t54wlnnja_.co.uk: May 21 09:24AM On Fri, 21 May 2021 00:07:12 +0100 >processes in a multi-threaded program, fork before you launch other >threads and communicate with the child process via pipes. Then you >will be OK. The general approach to using threads+processes is you have a core process spawner and each child process then creates its own threads. You don't create the threads in the parent. |
| MrSpook_va6psV1d@w5lywejmkchyss0h4d.gov: May 21 09:24AM On Fri, 21 May 2021 05:31:05 +0200 >> Keep demonstrating your ignorance, its very amusing :) >Parallelism is today done with threads. >No one uses fork()ing anymore. They do. Go program in unix for a few years then get back to me. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 01:33PM +0200 >> Parallelism is today done with threads. >> No one uses fork()ing anymore. > They do. Go program in unix for a few years then get back to me. That's long ago. Today everything written new is threaded and by far most of the old fork()ed applications are migrated to multi-threading. That's because MT-code is easier to write and much more performant when synchronizing. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 01:38PM +0200 > Oracle uses this method for good reason. ... Look at MS SQL Server - a DB-Server with a much modern architecture - it runs solid with MT since the first version in the 90s. |
| MrSpook_md3@zi2k.com: May 21 01:32PM On Fri, 21 May 2021 13:33:43 +0200 >> They do. Go program in unix for a few years then get back to me. >That's long ago. Today everything written new is threaded and by far >most of the old fork()ed applications are migrated to multi-threading. Oh right. When did you last work on a large unix application codebase? >That's because MT-code is easier to write and much more performant when >synchronizing. You don't seem to understand that not all applications require tightly coupled flows of control. Threading has specific use cases, multi process has others. You're young and clearly have only ever used Windows probably on single CPU machines so you only see the world from a Windows POV with its crippled process model and reliance on threading because of this. When you've worked on a unix (or even VMS) with multiple CPUs (not just cores) which the application needs to use you'll have different persective then maybe you can discuss this topic. Until then you're just making yourself look stupid. |
| MrSpook_L1peqs_@c81ltrsr_gfoo1.co.uk: May 21 01:39PM On Fri, 21 May 2021 13:38:03 +0200 >> Oracle uses this method for good reason. ... >Look at MS SQL Server - a DB-Server with a much modern architecture >- it runs solid with MT since the first version in the 90s. Clearly you never used the early versions. No one would bet their company on SQL Server back then, it was an unreliable toy compared to Oracle. Even today its feature list is poor compared to Oracle plus Oracle runs on virtually every OS that it can, SQL Server is Windows only. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 03:43PM +0200 > You don't seem to understand that not all applications require tightly coupled > flows of control. ... Almost any application wich is parallel needs this. Because of that there are no new applications that use fork()ing. > Threading has specific use cases, multi process has others. No, threading replaces fork()ing. > You're young and clearly have only ever used Windows probably on single CPU > machines ... Whether you need on or the other kind of parallelism has nothing to do if you have true multiprocessing or a single CPU. > When you've worked on a unix (or even VMS) with multiple CPUs (not just cores) > which the application needs to use you'll have different persective then maybe > you can discuss this topic. Until then you're just making yourself look stupid. You're naive. |
| Mr Flibble <flibble@reddwarf.jmc>: May 21 02:44PM +0100 On Fri, 21 May 2021 09:16:55 +0000 (UTC) > too. > >fork() then why the fuck aren't you using threads? Processes are > Because in serious applications - ie nothing you write I was part of the team that invented the smartphone, dear, quite serious I think considering billions of people now have a smartphone in their pocket. > seperate process so if that process dies it doesn't take town the > whole fucking application. Oracle uses this method for good reason. > Some browsers recently switched to a process-per-tab model too. The argument isn't about spawning separate processes, dear, the argument is threads vs fork(). > It always amuses me when people who've only ever coded on windows > spout a load of crap about things they know nothing about. I've written code for various platforms including: * Sinclair BASIC * MS-DOS * Windows * HP-UX * QNX * Linux > >heavyweight OS primitives compared to threads. These days fork() and > >associated horribleness like Linux's overcommit are an anachronism. > Whatever you say Dilbert. Ah, the ad hominem, the last resort of the fractally wrong. > https://dilbert.com/strip/1995-06-24 Dilbert is a good comic strip, possibly the only thing we can agree on given you appear to be a fucktarded cockwomble. /Flibble |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 03:46PM +0200 > Clearly you never used the early versions. ... I did use it since the 90s. You don't. > No one would bet their company on SQL Server back then, > it was an unreliable toy compared to Oracle. Have you ever noticed the periodic volleys of hundreds of fixes from Oracle in the press ? Have there ever been so much fixes on SQL Server ? You're really stupid. |
| scott@slp53.sl.home (Scott Lurndal): May 21 02:15PM >>- it runs solid with MT since the first version in the 90s. >Clearly you never used the early versions. No one would bet their company >on SQL Server back then, it was an unreliable toy compared to Oracle. Sybase (the code base that SQL Server was based on) was a fairly robust and popular RDBMS in the day. Of course, SQL server ran on unix at that time (Ashton-Tate/Microsoft SQL Server 1.0). Microsoft received sole license to x86 in 1988. August 1991: Sybase goes public at a split adjusted price of $4.40. Sybase SQL server 4.0, and later 4.8 (the first smp server) and 4.9.1, all outperformed competitors by significant margins in standard benchmarks. 1993: Sybase and Microsoft dissolve their partnership. Microsoft receives a copy of the SQL Server code base. In exchange Sybase is free to deploy on the x86 platform which has now become the chip of choice for Unix. Sybase SQL Server version 4.2 and Microsoft SQL Server are identical. Their Transact-SQL (T-SQL) procedural language is the same, as is the basic process architecture. From this point the products diverge as Microsoft includes more Windows features whilst Sybase adds Enterprise features (performance and scaling). (in 1998 my former co-worker John Chen became CEO of Sybase after a stint at Pyramid). Sybase was noted for storing data in columns rather than rows. https://en.wikipedia.org/wiki/Column-oriented_DBMS |
| MrSpook_zq3a8xxm@t9c1d7aq5dby4al.gov.uk: May 21 02:44PM On Fri, 21 May 2021 15:43:30 +0200 >coupled >> flows of control. ... >Almost any application wich is parallel needs this. Because No applications need multiple CPUs? Sure about that? >of that there are no new applications that use fork()ing. Presumably have proof of this so please give a URL. >> machines ... >Whether you need on or the other kind of parallelism has nothing >to do if you have true multiprocessing or a single CPU. Thank you for proving my point. >> you can discuss this topic. Until then you're just making yourself look >stupid. >You're naive. Thats a nice hole you're digging for youself. |
| MrSpook_4ptu0Yl4x9@2q77bsgmv.edu: May 21 02:47PM On Fri, 21 May 2021 14:44:03 +0100 >> >fork() then why the fuck aren't you using threads? Processes are >> Because in serious applications - ie nothing you write >I was part of the team that invented the smartphone, dear, quite ROTFL!!!! Of course you were Walter, of course! :) Do tell us more... were you the tea boy? >> Some browsers recently switched to a process-per-tab model too. >The argument isn't about spawning separate processes, dear, the >argument is threads vs fork(). For the purpose of this argument its the same thing. >> spout a load of crap about things they know nothing about. >I've written code for various platforms including: >* Sinclair BASIC Wow, look at you! >* HP-UX >* QNX >* Linux You mean you wrote some code that happened to compile on the last 3. >> >associated horribleness like Linux's overcommit are an anachronism. >> Whatever you say Dilbert. >Ah, the ad hominem, the last resort of the fractally wrong. You dish it out, so take it like a man. |
| MrSpook_km@gfepxabk0g_ytn7ta.net: May 21 02:48PM On Fri, 21 May 2021 15:46:25 +0200 >Have you ever noticed the periodic volleys of hundreds of fixes >from Oracle in the press ? Have there ever been so much fixes >on SQL Server ? You're really stupid. Yes, I'm weally weally shtupid. |
| MrSpook_6f@fypmp_.biz: May 21 02:57PM On Fri, 21 May 2021 14:15:29 GMT >>on SQL Server back then, it was an unreliable toy compared to Oracle. >Sybase (the code base that SQL Server was based on) was a fairly >robust and popular RDBMS in the day. Of course, SQL server ran on unix Sybase was ok, I used it for quite a long time in finance as it was popular there due to a much lower install cost than Oracle. To give it credit T/SQL is a much nicer language than Oracles PL/SQL, but its dirty read transaction system was hopeless and it had no deadlock handling mechanism other than the kill one of the deadlocked processes which is frankly fucking useless and a PITA when it happens in the middle of the night - which it did, often. Oracle when presented with a deadlock does a silent rollback on one of the transactions and suspends it until it can proceed. > receives a copy of the SQL Server code base. In exchange Sybase > is free to deploy on the x86 platform which has now become the > chip of choice for Unix. Sybase SQL Server version 4.2 and Microsoft x86 chip of choice for Unix in 93? Who wrote that, Darl McBride? PA-RISC and Sparc had the unix space carved up between them back then with RS/6000 bringing up the rear. x86 was SCO which was a bit part player in the unix arena. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 05:03PM +0200 > Yes, I'm weally weally shtupid. As we say in Germany: insight is the first step towards improvement. |
| scott@slp53.sl.home (Scott Lurndal): May 21 03:05PM >x86 chip of choice for Unix in 93? Who wrote that, Darl McBride? PA-RISC and >Sparc had the unix space carved up between them back then with RS/6000 bringing >up the rear. x86 was SCO which was a bit part player in the unix arena. By 1993, USL had given up on 3B2 and was focused on x86 for SVR4 (and successors) and Sequent owned the larger database unix systems. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 05:07PM +0200 >> Almost any application wich is parallel needs this. Because > No applications need multiple CPUs? Sure about that? Wer're talking about MT vs. fork()ing, dude. > Presumably have proof of this so please give a URL. I don't have to prove this. Having foked() app with the least coupling of the parallel processsing is much harder to write with fork()ing than with MT. Shared-memory, named pipes and semaphores are much more compli- cated to handle than a single shared address-space with simple mutexes and condition-variables. And even more: this kind of parallelism is usually more performant than forked() synchronization (f.e. consider that a uncontended mutex-lock is only about a few dozen cycles in a MT-environment). |
| MrSpook_hjgci2iT0@qtinm1mgdu.info: May 21 04:12PM On Fri, 21 May 2021 17:07:44 +0200 >>> Almost any application wich is parallel needs this. Because >> No applications need multiple CPUs? Sure about that? >Wer're talking about MT vs. fork()ing, dude. You don't even know what I'm talking refering to do you? Having threads of a single application spread over multiple CPUs requires specialist hardware and can cause serious performance bottlenecks. The same restriction does not apply to multiprocess. >> Presumably have proof of this so please give a URL. >I don't have to prove this. Having foked() app with the least coupling Yes you do. Now provide some proof or STFU. >usually more performant than forked() synchronization (f.e. consider >that a uncontended mutex-lock is only about a few dozen cycles in a >MT-environment). Nice cut and paste. A) Stop using that idiotic made up word "performant". It doesn't make you sound clever, more like a dumb sheep following the herd. B) As I already said if you could bloody read, not all execution paths require close synchronisation but some DO require seperation of memory and isolation from errors - eg ssh connections. You don't want all user connections sharing the same memory in an application that involves encrypted data or every user being kicked off if 1 thread crashes you fucking mouth breathing moron! So guess what, sshd forks a new process per connection! Now spend the weekend getting a clue and dont bother replying until you have one. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 06:18PM +0200 > You don't even know what I'm talking refering to do you? Having threads of > a single application spread over multiple CPUs requires specialist hardware > and can cause serious performance bottlenecks. ... The necessities of synchronization are the _same_ for fork()ing and MT, i.e. you need to share memory at the same places in the code and you need to synchronize also at the same places. But MT is more effi- cient because of the shared address-space - a lot of synchronization then doesn't need any kernel-aid - and easier to write. Your knowledge is very superficial when it comes to parallelization ! |
| Bonita Montero <Bonita.Montero@gmail.com>: May 21 04:08PM +0200 Can anyone tell me what std::unordered_map<Key,T,Hash,KeyEqual,Allocator>::emplace_hint is good for ? The key maps totally chaotic to a hash which is reduced to a bucket-index. So there should be no way to guess a hint. So this looks to me like a total nonsense-API. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment