Friday, May 21, 2021

Digest for comp.lang.c++@googlegroups.com - 6 updates in 2 topics

"daniel...@gmail.com" <danielaparker@gmail.com>: May 21 12:59PM -0700

On Friday, May 21, 2021 at 10:08:46 AM UTC-4, Bonita Montero wrote:
> 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.
 
The hint is of course useless when keys are unique, as they must be for std::unordered_map.
However, the hint can be meaningful for std::unordered_multimap, when keys are
equivalent. The Standard specifies that both std::unordered_map and std::unordered_multimap
satisfy the type requirement "unordered associative container", which has the emplace_hint function,
hence both container types have it. The Standard also allows implementations to ignore the hint.
At a quick glance, it looks like Microsoft's implementation ignores the hint for both container types,
while gcc's uses it for equivalent keys.
 
Daniel
"Öö Tiib" <ootiib@hot.ee>: May 21 02:29PM -0700

On Friday, 21 May 2021 at 17:08:46 UTC+3, Bonita Montero wrote:
> 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.
 
Some code that used map can be faster and with less changes switched
to use of unordered_map. Also some generic code can be used for both.
Even if implementation ignores that hint there is slight performance
potential as it returns only iterator not pair<iterator,bool> like emplace.
If implementation does not ignore that hint then it can also fail faster.
That is important when fails are frequent.
Mr Flibble <flibble@reddwarf.jmc>: May 21 05:19PM +0100

On Fri, 21 May 2021 16:12:43 +0000 (UTC)
> 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.
 
Specialist hardware? LOL. You appear to have no clue as to how modern
CPUs work or how operating systems are designed. Modern CPUs have
MULTIPLE CORES with SHARED CACHES.
 
 
> >I don't have to prove this. Having foked() app with the least
> >coupling
 
> Yes you do. Now provide some proof or STFU.
 
The fractally wrong often think they are right and EVERYBODY ELSE is
wrong.
 
 
> 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.
 
"Performant" is a perfectly cromulent word, dear.
 
> 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!
 
Word salad, dear.
 
 
> 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.

Ah, a classic case of psychological project there, dear.
 
/Flibble
scott@slp53.sl.home (Scott Lurndal): May 21 04:25PM

Bonita Montero <Bonita.Montero@gmail.com> writes:
<ATTRIBUTION DELETED INTENTIONALLY BY BM>
>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 !
 
You are both arguing past each other.
 
Both forking and multithreading are useful in the right situation.
Bonita Montero <Bonita.Montero@gmail.com>: May 21 06:36PM +0200

> Both forking and multithreading are useful in the right situation.
 
fork()ing is almost never used today for parallelism.
"daniel...@gmail.com" <danielaparker@gmail.com>: May 21 09:42AM -0700

On Friday, May 21, 2021 at 10:15:45 AM UTC-4, Scott Lurndal wrote:
> 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.
 
Indeed. Before the IPO, employees held options on x number of shares
at $2.20. Just before the IPO, Sybase did a reverse split, and
suddenly the employees had options on x/2 shares at $4.40. In
any case, the employees did well, I think I sold mine about a year
later for $50.
 
> 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.
 
In the mid to late 80's, Sybase used their own implementation of
"cooperative threads" on a number of UNIX RISC boxes and VAX
VMS. Consequently Sybase SQL Server could handle multiple
connection requests with a single process, whereas Oracle
required one process per connection, and required about half
a megabyte of memory per connection. Sybase also used a
simpler locking mechanism than Oracle, using page locking
rather than row locking. Oracle's row locking was in principle
better, but it could only keep track of a limited number of rows,
and often escalated to table locks. These factors gave Sybase a
big advantage for on-line applications, and it quickly established
itself in that space, especially with brokerage companies and
wholesale banks that needed to develop on-line trading systems for
derivative products.
 
In the late 1980's, Sybase did outperform Oracle on benchmarks
by some margin. However, when multiprocessing hardware
became widely available by the early to mid 1990's, the
situation was reversed. Oracle's dumb one connection per
process could scale easily on these machines, but not
Sybase's cooperative threading.
 
> 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.
 
My understanding at the time was that the agreement was that
Microsoft had the sole right for Windows and OS/2 systems, and
Sybase for UNIX and VAX. Sybase originally thought Windows
was unimportant, but panicked when NT came out. Sybase
became desperate to get out of the agreement, while Microsoft
thought it was fine the way it was. The only way Sybase could
get out of it was basically by giving away the rights to SQL Server.
Sybase then did make a version of SQL Server for Windows NT,
but it was unsuccessful, Microsoft owned that space.
 
> Sybase SQL Server version 4.2 and Microsoft
> SQL Server are identical.
 
I don't believe that's true. Microsoft claimed to have rewritten
the internals. Their initial version on OS/2 certainly supported
native OS/2 threads.
 
> point the products diverge as Microsoft includes more Windows features
> whilst Sybase adds Enterprise features (performance and scaling).
 
> Sybase was noted for storing data in columns rather than rows.
 
Not SQL Server, SQL Server was implemented as a B-Tree with rows
in pages, the same as Oracle. You're thinking about Sybase IQ,
which was a business analytics tool, introduced around 1996.
 
Daniel
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)